Email list hosting service & mailing list manager

where is srfi-17 going? Per Bothner (23 Jan 2000 21:32 UTC)
where is srfi-17 going? Shriram Krishnamurthi (23 Jan 2000 22:03 UTC)
Re: where is srfi-17 going? Per Bothner (23 Jan 2000 23:18 UTC)
Re: where is srfi-17 going? Shriram Krishnamurthi (24 Jan 2000 02:17 UTC)
Re: where is srfi-17 going? Michael Livshin (24 Jan 2000 11:01 UTC)
Re: where is srfi-17 going? Mikael Djurfeldt (24 Jan 2000 16:27 UTC)
Re: where is srfi-17 going? Mikael Djurfeldt (24 Jan 2000 17:25 UTC)

Re: where is srfi-17 going? Mikael Djurfeldt 24 Jan 2000 16:24 UTC

Shriram Krishnamurthi <xxxxxx@cs.rice.edu> writes:

> I'm CCing this message to Mikael Djurfeldt, an active Guile proponent,

[...]

> Maybe he can track down whoever added extended SET!, and get them to
> correspond.

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.

We don't want to use some long or strange name, but a name which makes
the code readable.

We have kept the original R5RS `set!' operator, but let the
generalized `set!' shadow the original one if the module providing
the generalized version is used.  This is similar in spirit to SRFI-1
providing a generalized version of `member'.

We have no supported way of setting the setter associated with a
getter, but rather have a constructor

  make-getter-with-setter GETTER SETTER

with corresponding selector

  setter GETTER-WITH-SETTER

This should not create problems for static analysis in the compiler.

(set! (GWS ARG1 ...) VALUE-FORM) expands to

  ((setter GWS) ARG1 ... VALUE-FORM)

/mdj