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! operation. 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). Jost