Re: setf.scm

[Maciej Stachowiak <mstachow@mit.edu>]

russell.mcmanus@gs.com writes:
> Maciej Stachowiak <mstachow@mit.edu> writes:
> 
> > A setf! implementation in the form of setf.scm has been added to
> > guile.
> 
> Yes!  setf helps a lot as the size of a program grows.
> 

I agree.

> I'm a big fan of setf doing it's work at compile time.  Why?  Because
> it's relatively easy for programmers to whip up some generic closures,
> or wrap 'setf' forms in lambdas, but relatively difficult to implement
> a macro-based 'setf' facility. 

I'm not sure what you mean by either part of the last sentence. Can
you explain what you mean?

> It gives Scheme programmers access to a previously inaccessible
> point on the speed/dynamism tradeoff curve, and we've already got
> access to the completely dynamic end of the spectrum.

Umm, I don't think it provides a useful point. If I redefine `car', I
definitely don't want (setf! (car x) 4) to keep working as it did
before. Unless there are static accessors, static mutators are
useless, IMO. 

See also my other message.

> Just wondering: why not follow the Common Lisp implementation
> strategy, and use the symbol to look up the setter?  Would this solve
> the problem you describe (there must be some other cost)?
> 

Yes it would. 

There are costs, however:

* Anything used to access or set a setter must be a macro.

* Setters will not work properly with the module system (I can't have
setters for two identically named local procedures in different
modules).

I'm not sure there is any reasonable way around problem 2 - it could
look up by symbol and module name, but how would it determine which
module name you mean at macro expansion time, without actually
examining what module the symbol is bound in, thus resulting in the
evil semi-dynamic behavior?


> > I also don't think it is useful to allow getters and setters to be
> > macros (and obviously that can't be done with the non-memoizing
> > version where setter is a procedure since code written to use that
> > with macros would be utterly uncompilable). Is there a particular
> > purpose that was envisioned for?
> 
> Getters and setters should be macros for speed.  If you need dynamism
> the you can create lambdas around them.  It sounds like there is some
> reason that this is impossible in guile; could you explain why?
> 

Macros should never be used solely for speed, in my opinion. If you
care about speed, write your code so they can be inlined

I am not sure you understood what I meant, though - what I meant was
that the current code will allow you to define a macro, using defmacro
for instance, and then define a corresponding setter for that to be
used with setf!; or conversely allow a setter to be defined that is a
macro. I don't think either of these behaviors is useful, and Common
Lisp does not allow either. (the first subform of a place form may be
a macro, but it is macro-expanded, not treated directly).

 - Maciej Stachowiak