Re: difficulty of writing translators

[Marius Vollmer <mvo@zagadka.ping.de>]

Per Bothner <bothner@cygnus.com> writes:

> [...] 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 Common Lisp defines it as something like

    `((setter f) ,@args value)

that is, the value is the last argument to the setter function.  This
blends well with `set-car!', `vector-set!', etc (but not
`array-set!').

> The advantage of this design is that it is procedural, while
> setf is macro-based.  Hence setf only works for setter functions
> explicitly known (by name) at compile time, but setter works on
> procedure *values* at run-time, and is therefore much more in
> the spirit of Scheme.

I agree.  This is how it should be in Scheme.  But I also would like
it to be maximally efficient.  Using

    (set! (car x) y)

should (ideally) not be slower than

    (set-car! x y)

I think these setters will be used as the natural thing for records or
an object system and we should try to make them as fast as possible,
even if it means bending the semantics a little bit away from the
optimum.

Translating `(set! (car x) y)' into

    ((setter car) x y)

would mean two function calls, and maybe `setter' has to go around
chasing for the setter functions in some plist or something.

So we should at least spend a slot in a procedure object for the
setter, so that it can be accessed in constant time, and we should
probably handle `(set! (place ...) value)' or something like
`(apply-setter place ... value)' directly as a builtin, maybe as a new
memoized instruction.

We should also take care that a (hypothetical) compiler can optimize
it well in the common cases.  This means that it must be able to
figure out whether the place always refers to the same function, that
this function has a constant setter, and what that setter is.  This is
an issue for the setter defining interface.