[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: setf order of evaluation
Date: Wed, 9 Sep 87 14:40 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: 9 September 1987, 10:31:51 EDT
From: Timothy Daly <DALY@ibm.com>
(setq r '(a 1 b 2 c 3))
(setq s r)
(setf (getf r 'b) (progn (setq r nil) 6))
what is the value of R and S?
Both Symbolics and Lucid seem to generate
R = (B 8) and S = (A 1 B 2 C 3)
so I think the behavior you describe is a bug (although the description
in CLtL is so ambiguous that the implementors of the respective systems
could easily disagree with me.)
I agree that it is a bug. Cf pg 99: "As an example of these semantic
rules, in the generalized-variable reference (SETF reference value)
the VALUE form must be evaluated AFTER all the subforms of the
reference because the value form appears to the right of them"
I didn't look inside the Lucid implementation, but in the Symbolics
implementation the source of the bug is that (get-setf-method 'r)
returns NIL, NIL, (#:G6411), (SETQ R #:G6411), R, whereas it should
return (#:G6410), (R), (#:G6411), (SETQ R #:G6411), #:G6410. See
CLtL page 104 for the description of the meaning of these values.
Changing it to return the latter makes your SETF example behave as you
expected, evaluating R -before- bashing it, and setq'ing it to the updated
property list -after- setq'ing it to nil.
Unfortunately, on pg 105 the setf method for the variable X is defined
to be () () (#:g0001) (setq X #:g0001) X. So if this is the right
place to fix things, then CLtL must be fixed too. This is fine with
me, but it would make SETF methods less efficient (or require them to
be more intelligent about optimizing).