Re: difficulty of writing translators

[Jim Blandy <jimb@red-bean.com>]

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.

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.