David Rush:

>I have already looked at it, and it's ugly. It in fact implements what
>I found most objectionable about SRFI-17 in the first place. With
>SRFI-17 (as it stands) we suddenly get a whole new heap of stuff
>magically bound to language *values* and not names.

Unpleasant, yes, but *ugly*? ... ;)

I agree that this business with values rather than names is pretty
awkward, because it is possible to nonlocally effect the setter of some
getter, which can be unpleasant for maintenance, debugging, etc.  Worse,
though, the system can do similar things behind your back because of
weak guarantees on procedure equality in Scheme.  For example, if we
have

	(define fst (lambda (x) (car x)))
	(set! (setter fst) (lambda (x y) (set-car! x y)))

and also

	(define first (lambda (x) (car x)))
	(set! (setter first) (lambda (x y)
				(set! counter (+ counter 1))
			        (set-car! x y)))

then a Scheme implementation is actually allowed to let fst and first
refer to the same procedure, so that (eqv? fst first) => #t.  (R5RS 6.1)
Obviously that could get interesting.

It's not exactly brain surgery for a compiler to figure out that both
fst and first are really just _car_; if the compiler can show that car
has a known value then it can validly do the transformation, as far as I
can tell.  So now we have (setter car) involved in this mess too.

SRFI-17 relies on properties provided by many implementations but not
by the language.

--lars