[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: where is srfi-17 going?

This page is part of the web mail archives of SRFI 17 from before July 7th, 2015. The new archives for SRFI 17 contain all messages, not just those from before July 7th, 2015.

Mikael Djurfeldt wrote:

> It's quite easy: I did.

> There are several reasons, but the primary one is that we use this
> operator extensively in our object system.  We use the accessors to
> get and set values of slots.  Ex:

>  (set! (n o) 4711)

> means use accessor n to mutate object o so that (n o) returns 4711.

This object system seems to be broken.  In any reasonable object
system it is *not* possible to set! the value of one of the object
slots directly.

You can send a message to an object asking it to change its internal
state.  The object may or may not accept this message.  But you cannot
simply grab its internals and change them.

This is the difference between classes and structures.  You can (and
must) change the internals of structure values from the outside while
the internals of an object are opaque to you.  An agressive compiler
however can optimize a change-value message into a simple set!

Even if the interface specifies that some object internals can be
changed from the outside that doesn't mean that you can simply grab
the internals, pass them around and change them later. There may be
other constraints which you don't know, for example there may be a
monitor associated with the object.  This means that "(set! (n o)
4711)" is simply syntactic shugar for (change-preferred-parfum o 4711).