Re: setf order of evaluation

[NGALL@G.BBN.COM]

    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>
    
	Given
    
	 (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).

-- Nick