[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: setf order of evaluation
- To: NGALL@G.BBN.COM
- Subject: Re: setf order of evaluation
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 21 Sep 87 17:10 EDT
- Cc: DALY@IBM.COM, common-lisp@SAIL.STANFORD.EDU
- In-reply-to: <[G.BBN.COM]10-Sep-87 10:40:24.NGALL>
Date: 10 Sep 1987 10:40-EDT
Date: Wed, 9 Sep 87 14:40 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
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).
I'm told Symbolics will be fixing our next release to do what I said I
thought was right, rather than what CLtL says. I guess that obligates me
to write this up and submit it to the cleanup committee, which I will do.
I don't take the efficiency issue very seriously; it's very easy to
optimize the cases in question, in my opinion.