This page is part of the web mail archives of SRFI 17 from before July 7th, 2015. The new archives for SRFI 17 contain all messages, not just those from before July 7th, 2015.
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