Issue status

[Eric Benson <edsel!eb@labrea.stanford.edu>]

   Date: 25 Nov 87 17:49 PST
   From: Masinter.pa@Xerox.COM

   This isn't quite up to date as I've missed a few, but I thought I should
   go ahead and send it out if you're keeping a score card... I think we
   have some new members of the distribution list as of the last week or
   so...

    - SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
      (Change recommendation for (get-setf-method symbol)?)
      Ready for release

Perhaps you missed my message about this issue, since I sent it during
the meeting.  Here it is again:

There's a problem with this SETF method for symbols.  Consider the
following simplified version of SETF from p.107 of CLtL:

(DEFMACRO SETF (REFERENCE VALUE)
  (MULTIPLE-VALUE-BIND (VARS VALS STORES STORE-FORM ACCESS-FORM)
      (GET-SETF-METHOD REFERENCE)
    (DECLARE (IGNORE ACCESS-FORM))
    `(LET* ,(MAPCAR #'LIST (APPEND VARS STORES) (APPEND VALS (LIST VALUE)))
       ,STORE-FORM)))

This results in the following macrexpansion for (SETF X 1), using the
new SETF method for symbols:

(LET* ((G0002 X)
       (G0001 1))
  (SETQ X G0001))

The value of G0002 is never used.  The problem is that X might be
unbound, so even just binding it to a local variable will fail.  I
don't think we want to require implementations to eliminate
unnecessary bindings in SETF expansions, just to get correct
semantics.  Nor should each SETF-like macro need a special case when
the location being stored is a symbol.

Unfortunately, I think special handling for symbols is necessary.  If
we keep the SETF method for symbols the way it is in CLtL then we need
to make a special case for symbols in the SETF methods for GETF, LDB
and the like.  If we change the SETF method as proposed here, we need
to make a special case for symbols in SETF and PSETF and any user
defined SETF-like macro that doesn't use the fifth value (ACCESS-FORM)
 from GET-SETF-METHOD.

My feeling is that we should go with the new SETF method for symbols,
but describe this problem and point out to implementors that SETF and
PSETF must handle symbols specially, effectively resorting to the old
SETF method.