Re: difficulty of writing translators

[Maciej Stachowiak <mstachow@mit.edu>]

jimb@red-bean.com writes:
> 
> 
> Maciej Stachowiak <mstachow@mit.edu> writes:
> > bothner@cygnus.com writes:
> > > > However, it would please me (if it's not too deadly to implement) to
> > > > see functions allowed to return set!-able references:
> > > 
> > > >    (set! (my-prop) 17)
> > > >    (my-prop)             => 17
> > > 
> > > Kawa supports this (for some primitive functions - I haven't decided
> > > yet how to define such functions in Scheme).
> > > 
> > > Note that having functions "return set!-able references" is
> > > probably not the way to do it, since we want a normal call (not in a
> > > set! context) to return plain value, not a reference.  Instead,
> > > we allow functions to have "attributes", and one attribute is a
> > > functions setter function.  Then we define:
> > > 	(set! (f . args) value)
> > > as being syntactic sugar for:
> > > 	((setter f) value . args)
> > 
> > I think this interface is a good thing. In fact, I wrote something
> > similar for Guile purely in Scheme (it defined a new setf! syntactic
> > form instead of overloading set!, but was based on a property of the
> > procedure, not the symbol). I think the interface for setting the
> > setter of an ordinary Scheme procedure should be:
> > 
> > procedure: (set-setter! PROC SETTER-PROC)
> > 
> > with `set-setter!' defined as the setter of `setter', so the user can
> > do (purely for example purposes, this particular setter should be
> > predefined):
> > 
> > (set! (setter car) set-car!)
> > 
> > Is there any reason why that would be a bad interface?
> 
> Are you proposing this as an alternative to variable tracing?
> 
> If so, them I'm confused, because it seems to have the same problem
> that setter and getter functions have: the syntax is not identical to
> that of an ordinary variable assignment.  So the (quite persuasive)
> objections you made to ordinary getter and setter functions still
> apply here.

I'm not proposing it as anything. I was just commenting on Per's
suggestion in a general way. He said he hadn't thought of a way to
allow setters to be set for user-defined procedures, so I suggested
one.

IMO it is a mostly orthoginal feature to variable tracing and only
allows you to achieve a few things that superficially look the
same. The only problem it solves of the ones I mentioned is to make
read-modify-write macros work, as you mention below. But I think it is
an elegant and useful syntax in it's own right.


> 
> Because the user needs to say (set! (parameter) ...) instead of (set!
> parameter), the below objections would still seem to apply.
> 
> You wrote:
> 
>   * For a program with many configurable settings, the user should not
>   have to know, care or remember which parameters, when set, will
>   trigger extra processing immediately. It's often not even intuitively
>   obvious which will and which won't.
> 
>   * Many configurable settings are done just plain wrong because it
>   would be more of a pain for the implementor as well as the user to
>   write to procedures rather than define one variable.
> 
>   For example, hooks are implemented as variables expected to contain
>   lists of procedures, in Guile as well as in Scwm (for consistency). 
> 
>   As another example, paths "%load-path", e.g. are implemented as
>   variables that contain lists of strings, forcing any path-searching
>   code to scan the list twice on each path search, first to make sure it
>   really is a list of strings (and save their lenghts), and then to do
>   the real work.
> 
>   In both of these cases, it would be nice for the variables in question
>   to get typechecked when assigned, rather than on each use. Separate
>   setter and getter procedures might be better from a language
>   cleanliness point of view, but they are not really being used, even by
>   guile core, when they should be.
> 
>   * Macros exist which do interesting manipulations of variables; they
>   are unusable on getter-setter pairs (unless Guile gets a generic
>   setter facility like Common Lisp's setf and starts using it, which I
>   think is also a good idea. In fact, I wrote one in Guile Scheme a
>   while back, but I'm not sure if anyone is interested).
> 
> Per's idea does solve the macro issue, though.

Well, it could also solve point 2 if it resulted in people getting
motivated to change the relevant bits of code.

 - Maciej