Re: Generalized set!

[Per Bothner <bothner@cygnus.com>]

> Note that I finally followed Maciej and others'  advice regarding the
> order of arguments.  It is most intuitive to have the expansion:
>   (set! (PWS A1 ...) V) --> ((SETTER PWS) A1 ... V)
> and it has the advantage of working with all setters except the
> current array-set! which I think should be modified.

I don't know if it is more intuitive, but it is certainly more
consistent with exiting Scheme xxx-set! procedures.  However,
it is highly *in*compatible with functions that take a variable
number of parameters.

If I have a function:
   (define (foo x y . rest) ....)
and I want to define a corresponding setter, I have to go through some
rather unnatural contorions:
   (define (foo-setter x y . rest-and-rhs)
      (let* ((tmp (reverse rest-and-rhs))
             (rhs (car tmp))
	     (rest (reverse (cdr tmp))))
	 ...))

This becomes even worse if we provide optional and keyword parameter
specifiers.  The problem that is that required arguments in Scheme
(and Lisp) come first, and the new value (rhs) is a required argument.
That is why Kawa has the new value first in the setter:
  (set! (PWS A1 ...) V) --> ((SETTER PWS) V A1 ...)

For most users, it shold not matter which we choose.  They will
use the generalized set!, but are unlikely to define new setters
themselves.  Most setters functions have fixed arity, so which
end to add the rhs does not matter.  The tradeoff is:

* Putting the rhs last is perhaps more natural.  It is certainly
more consistent with most existing Scheme fucntions.  It also
allows the implementation to use exising xxx-set! functions
as (setter xxx) without an intermediate step.

* On the other hand, putting the rhs first works a lot better
for varags functions, and is much more consistent with how
most varargs functions are used and defined.

There is no definite "correct" answer; we have conflicting
tradeoffs.  I do want to make sure people are aware of those
tradeoffs.  Kawa puts the rhs argument first, to the extent
that is relevant, though I guess I might be convinced to
change it.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner