#

## Issue MULTIPLE-VALUE-SETQ-ORDER Writeup

    Issue:            MULTIPLE-VALUE-SETQ-ORDER
    References:       MULTIPLE-VALUE-SETQ, SYMBOL-MACROLET
    Related issues:   SYMBOL-MACROLET-SEMANTICS
                      SETF-SUB-METHODS
                      SETF-OF-VALUES
    Category:         CLARIFICATION
    Edit history:     V1,  1 Jun 1990, Sandra Loosemore
                      V2,  6 Jun 1990, Sandra Loosemore
                      V3, 12 Feb 1991, Sandra Loosemore

    Problem description:

    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
    "i"?

    Proposal (MULTIPLE-VALUE-SETQ-ORDER:LIKE-SETF-OF-VALUES):

      Clarify that

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

      Rationale:

        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.

    Current Practice:

      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.

    Performance impact:

      The situation probably doesn't crop up enough for it to have a
      significant impact.

    Benefits:

      This part of the language specification becomes less vague.

    Esthetics:

      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.

    Discussion:

      An earlier version of this issue (with three different proposals) was
      discussed at the June 90 meeting.
    -------

Copyright 1996-2005, LispWorks Ltd. All rights reserved.