Re: setf.scm

[Maciej Stachowiak <mstachow@mit.edu>]

mdj@nada.kth.se writes:
> Mikael Djurfeldt <mdj@nada.kth.se> writes:
> 
> > constructor: (make-procedure-with-setter GETTER SETTER)
> > selector:    (procedure-getter PROCEDURE-WITH-SETTER)
> > selector:    (procedure-setter PROCEDURE-WITH-SETTER)
> 
> Or maybe:
> 
>   make-getter-with-setter

I think `make-procedure-with-setter' makes more sense. 

>   getter
>   setter
> 
> and, of course,
> 
>   getter-with-setter?
> 

How about calling this `has-setter?' (that would nicely encapsulate
the case of generic functions that have setters).

Also, calling a procedure-with-setter normally should call the getter,
thus making `getter' somewhat superfluous except for pedantic
completeness.

> > If our `define-class' macro binds accessors, there now occurs the
> > question whether we should let the method of the getter generic
> > function be a procedure-with-setter or if the getter should be a
> > procedure-with-setter consisting of a generic function getter and
> > setter.
> > 
> > The former alternative (method is p-w-s) requires that set! does the
> > method lookup.
> 
> Just to clearify: If the getter and setter are stored in the method of
> a generic function, set! needs to do a dispatch on the getter
> arguments in order to retrieve the setter:
> 
> In the Goops-free Guile, (set! (G A1 ...) V) will be expanded to
> ((setter P) V A1 ...).  What I'm saying is that if the
> getter-with-setter pair is stored in the procedure slot of the method,
> P needs to be calculated from G by dispatch on A1 ...
> 
> Sigh... maybe the other alternative (letting the object system treat
> getter-with-setters whose getter is a generic function as a generic
> function) is better anyway.
> 

Perhaps a generic function could always effectively be a
procedure-with-setter, but would automatically recompute a generic
function to be its setter whenever a method is added. I'm not sure if
this substantially differs from your suggestion above.

Or, to avoid the need for magic entirely, each generic could have an
associated setter generic and the user would be required to add
methods to that explicitly.

CLOS appears to effectively take this route - if you have
`my-generic-function' defined, you need to expicitly define a function
called `(setf my-generic-function)' to have it work with setf. This
actually makes sense to me - it is not a priori clear that the setter
of a generic function should always just do the same dispatch but use
the setters of the methods. There needs to be a nice syntax for adding
methods to a generic's setter however.

> (Yes, this whole issue would have a very simple answer if Guile had
>  the object system builtin.)

How so? It would still be really bad to make set! know anything about
generic dispatch in that case, IMO.

 - Maciej