Issue: SETF-METHOD-FOR-SYMBOLS (version 1)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

Issue:         SETF-METHOD-FOR-SYMBOLS

References:    CLtL pp. 105, 99

Category:      CHANGE

Edit history:  Version 1   Moon 21 Sep 87

Problem description:

The description of SETF in CLtL is inconsistent in that page 99
requires side-effects to be elaborated in left-to-right order,
while page 105 specifies a setf-method for symbols that makes
it impossible to implement this in some cases, such as the test
case given below (provided by Timothy Daly of IBM).

Proposal: SETF-METHOD-FOR-SYMBOLS:TEMPORARY-VARIABLE

Change the result of (get-setf-method 'foo) from
NIL NIL (#:G1174) (SETQ FOO #:G1174) FOO
to
(#:G1175) (FOO) (#:G1174) (SETQ FOO #:G1174) #:G1175

Test Case:

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?

If side-effects are elaborated in left-to-right order,
the setq of R to NIL should not affect the result, since
it occurs after R is read and before R is written, and
therefore the value of both R and S should be (A 1 B 6 C 3).

A typical result in an implementation that believes CLtL p.105
more than CLtL p.99 is R = (B 6) and S = (A 1 B 2 C 3).

Rationale:

The general principle mentioned on p.99 should override the
specific example on p.105.  The latter is probably just a mistake.

Current practice:

Symbolics and Lucid return the incorrect result mentioned in the test
case above.  Franz returns something else: r = nil and s = (a 1 b 6 c 3).

Symbolics plans to fix this in the next release.

Adoption Cost:

SETF is an intricate part of Common Lisp, and the fact that not all
implementations currently return the same thing indicates that some
care might be required in updating implementations.  However, in
some implementations changing what get-setf-method returns when its
argument is a symbol is the only change required.

It's been pointed out that this change might cause less efficient code
to be produced in some cases, since setf methods will involve more
temporary variables, however Moon believes that the optimizations are
not difficult and probably are already done by most implementations.

Cost of non-adoption:

Users will think SETF is complicated and hard to understand, because
implementations won't conform to a simple general principle that
side-effects are elaborated in left-to-right order.

Benefits:

The opposite of what I just said.

Conversion Cost:

This change is incompatible because it changes the result of some forms
that are not erroneous.  However, it's unlikely that very many users are
intentionally depending on the current behavior.  In addition, the
current behavior is not consistent across implementations, which makes
changing it less problematic.

Esthetics:

See "cost of non-adoption".

Discussion:

I wish CLtL did a much better job of explaining the philosophy of SETF,
and included some better examples of precisely what is meant by the
"`obvious' semantics" mentioned on page 99.  I will accept some of the
blame for this lack in the documentation. --Moon