[plt-scheme] Lightweight object system

Errors. And error diagnostics. Say you want to build a large system,  
like DrScheme, 200,000 lines and more. An SICP-style simulation of  
objects will catch errors much much later than an implementation that  
distinguishes objects from every other kind of data in the system.  
The very moment you send 'draw-yourself' to the factorial closure,  
you get an error that says 'factorial is not an object'. In SICP, you  
get a message that says  -: number expected; 'draw-yourself' is not a  
number; other arguments given: 1. Now you start looking at your code  
for all 2000 occurrences of 'draw-yourself' to find the one that  
could have been supplied to factorial.

When systems work, nobody cares. When errors happen, you want to fix  
them as fast as possible.

[Okay, this is unfair to the original poster, because R5RS doesn't  
provide the generative data structure facility for distinguishing  
objects from all other kinds of closures.

It's also a tiny little bit unfair to SICP-adherents: you could after  
all convert the entire program and wrap ALL values with (cons TAG  
Value) and so on. With this little global transformation, you could  
generate equivalent error messages.]

-- Matthias






On Sep 4, 2007, at 10:13 AM, Dave Griffiths wrote:

> Excuse my ignorance here (and as a bit of an aside), what are the main
> benefits to class systems over closures with local state as  
> described in
> the SICP chapter 3?
> (http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-20.html#% 
> _sec_3.1)
>
> I've managed to use these quite well as they are, including a cobbled
> togther way of doing inheritance and method overriding/passing  
> through.
>
> My guess is that more advanced things become possible and cleaner with
> some macro extensions - is this true, and if so, what are they?
>
> cheers,
>
> dave
>
>> Hi Erich,
>>
>> The first implementation of ROOS was fully R5RS. It still is to
>> a large degree. However, not all scheme implementations have
>> the advanced macro capabilities that have been described in R5RS,
>> although thay claim to be R5RS. So, I eventually resorted to a PLT
>> implementation.
>>
>> I think, with little effort it should be possible to restore the
>> implementation
>> to a R5RS one (especially x-roos.scm is important).
>>
>> --Hans
>>
>>
>> Op 4/9/2007 schreef "Erich Rast" <erich at snafu.de>:
>>
>>> Hi,
>>>
>>> I'm looking for a leightweight object system with all or some of the
>>> following features:
>>>
>>> - preferably supports multiple inheritance
>>> - "traditional" (i.e. not prototype-based or other less common
>>> approaches)
>>> - preferably pure R5RS
>>> - simple and small
>>> - fast (might be used in a realtime scenario later)
>>>
>>> I like ROOS and will perhaps use it, but it's PLT Scheme only at the
>>> moment. It might not be hard to port it to another dialect if  
>>> needed,
>>> though.
>>>
>>> What else would you recommend?
>>>
>>> Best,
>>>
>>> Erich
>>> _________________________________________________
>>>  For list-related administrative tasks:
>>>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>>
>>>
>> _________________________________________________
>>   For list-related administrative tasks:
>>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>
>
>
> http://www.pawfal.org/dave/
>
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme