References: MULTIPLE-VALUE-SETQ, SYMBOL-MACROLET
Related issues: SYMBOL-MACROLET-SEMANTICS
Edit history: V1, 1 Jun 1990, Sandra Loosemore
V2, 6 Jun 1990, Sandra Loosemore
V3, 12 Feb 1991, Sandra Loosemore
Proposal SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM extended
MULTIPLE-VALUE-SETQ to allow symbols naming symbol-macros to appear in
the "variables" argument to MULTIPLE-VALUE-SETQ. The intent was that
this would be treated the same way as with SETQ or SETF. However, the
proposal did not address order-of-evaluation issues.
When dealing only with variables, the order in which
MULTIPLE-VALUE-SETQ performs the assignments is not relevant. On the
other hand, the storing form that results from applying the
SETF method of the macroexpansion of a symbol-macro can be fully
general. It might include references to other variables or "places"
named by other symbol-macros in the variable list. The question is,
which other variables or "places" in the list have already been set
when the storing form is evaluated?
For example, consider something like
(defun foo (v i)
(symbol-macrolet ((element (svref v i)))
(multiple-value-setq (v element i) ...)))
Does the value corresponding to "element" get stored in the new
or old value of the vector "v", at the new or old value of the index
(multiple-value-setq (<place1> ... <placen>) <value-producing-form>)
is exactly equivalent to
(values (setf (values <place1> ... <placen>) <value-producing-form>))
under proposal SETF-OF-VALUES:ADD, with the additional constraint that
each of the <placei> must be a symbol.
Assuming VALUES is added as a SETF place, it is obvious to define
of MULTIPLE-VALUE-SETQ (or MULTIPLE-VALUE-SETF) in terms of it.
Symbolics Genera 8.0 does both assignments and evaluation of place
subforms in left-to-right order.
Utah Common Lisp appears to do the assignments (and evaluation of
place subforms) right-to-left.
Chestnut's Lisp-to-C translator implements proposal SETF-OF-VALUES.
Cost to Implementors:
Assuming proposal SETF-OF-VALUES:ADD is adopted, minor.
Cost to Users:
Probably nobody depends on any particular behavior here, since
symbol-macros are a relatively new addition to the language. This
definition of MULTIPLE-VALUE-SETQ is fully upward-compatible with its
definition in CLtL.
Cost of non-adoption:
This part of the language specification remains vague.
The situation probably doesn't crop up enough for it to have a
This part of the language specification becomes less vague.
Any code that depends on any particular order is likely to be
pretty nasty. However, defining MULTIPLE-VALUE-SETQ in terms of
SETF of VALUES seems like the right approach to me.
An earlier version of this issue (with three different proposals) was
discussed at the June 90 meeting.