Re: setter problem

[Harry.Bretthauer@gmd.de]

> Why not do it the way T and Pop do, and make setter be a function?
> 
> (The only argument I've heard against this is that you'd like to be able to
> export the accessor and not the setter of a function, which is easy if they're
> symbols. But it seems to me that (a) you can get that effect by introducing an
> auxilliary function, and (b) if it's that common, you can introduce export
> syntax to have the system do it for you. Compared to the simplicty and
> elegance of procedures-with-setters, this seems a feeble case. IMAO.)

There are some more aspects, where, I think the setter should have
similar behavior as the reader. For example:
1. if the reader binding is constant, the setter "binding or table
   entry" should also. 
2. if a reader reference can be analyzed statically (detecting errors,
etc.), the setter reference should also.

This can be better achieved and explained by special forms, one for
defining setters and one for refering them, rather than by a function.

This could be generalized to structure the lexical module bindings
with respect to some criteria which are orthogonal to the module
structure. It might be also usefull to allow language extenders to define new
binding spaces with lexical or other semantics.

Harry Bretthauer
German National Research Center for Computer Science (GMD)
P.O. Box 1316, W-5205 Sankt Augustin 1, Germany
Phone: +49-2241-14-2704   Fax: +49-2241-14-2072 Email: bretthauer@gmd.de