This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: setf.scm


Maciej Stachowiak <mstachow@mit.edu> writes:

> mdj@nada.kth.se writes:
> > Or maybe:
> > 
> >   make-getter-with-setter
> 
> I think `make-procedure-with-setter' makes more sense. 

Why?

If the procedure has a setter it should be a getter, the names will be
shorter and the selector names more sensible.

(I have an argument for `*procedure*' but I'd like to know why you
 prefer it.)

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

I look upon make-getter-with-setter as a constructor of a new type of
object (sub-type of procedure).  I think all types should have a type
predicate.  The natural name would be its type name followed by a
question-mark.

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

I'm not so sure that it is only pedantic.  At least during program
development, especially during debugging, it is nice to be able to
retrieve the getter procedure.

> 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.

Please explain this a little bit further.

> 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.

This is a possibility, but then we're back to a situation where the
mechanism spreads over the entire language.  It would be nice to
isolate it a bit, so that ordinary generics don't have to care a bit
about setters.  (Also, note that we can't let the associated setter be
a slot in the generic, unless we introduce read-only slots.)

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

My thought was:

(set! (G A1 A2 ...) V) --> ((setter G) V A1 A2 ...)
                       <=> ((slot-ref G 'setter) V A1 A2 ...)

But it doesn't work until we have read-only slots...

/mdj