CLHS: Issue SETF-OF-VALUES Writeup

#

## Issue SETF-OF-VALUES Writeup

    Issue:             SETF-OF-VALUES
    References:        SETF, GET-SETF-METHOD-MULTIPLE-VALUE
    Related issues:    SETF-MULTIPLE-STORE-VARIABLES
                       LISP-SYMBOL-REDEFINITION
                       PACKAGE-CLUTTER
                       MULTIPLE-VALUE-SETQ-ORDER
    Category:          ADDITION, CHANGE
    Edit history:      v1, 12 Feb 1991, Sandra Loosemore

    Problem description:

      The writeup for issue SETF-MULTIPLE-STORE-VARIABLES indicates that
      adding support for multiple store variables makes it easy to write
      a SETF method for the VALUES function, yielding a powerful
      MULTIPLE-VALUE-SETF-like form.  The proposal didn't actually
      define VALUES as a SETF place on the rationale that this could be
      easily done by users in a portable fashion; however, issue
      issue LISP-SYMBOL-REDEFINITION prohibits users from defining a SETF
      method for VALUES or any other symbol that is exported from the
      COMMON-LISP package.  (Issue PACKAGE-CLUTTER does not prohibit
      implementations from defining VALUES as a SETF place as an extension,
      though.)

      There are two proposals, ADD and REMOVE-PROHIBITION.  The two proposals
      are not mutually exclusive.

    Proposal (SETF-OF-VALUES:ADD):

      Define VALUES as a SETF place in the standard.

      For a form such as

      (setf (values <place1> .... <placen>) <value-producing-form>)

      the setf methods for each of the nested <placei> are obtained as if by
      GET-SETF-METHOD-MULTIPLE-VALUE.  The order of evaluation is as follows:

      (1) subforms of the nested <placei> are evaluated in left-to-right order.
      (2) The <value-producing-form> is evaluated, and the first store variable
          from each <placei> bound to the values as by MULTIPLE-VALUE-BIND.
          If the setf method for a nested <placei> involves more than one store
          variable, then the additional store variables are bound to NIL.
      (3) Finally the storing forms for the nested <placei> are evaluated in
          left-to-right order.

      Note that (as required by CLtL), the storing form for SETF of VALUES
      returns the values of the store variables as its values.  (This might
      be more or fewer values than what the <value-producing-form> returns.)

      Rationale for proposal ADD:

        SETF of VALUES is a powerful feature.  Even if it were made possible to
        define it portably, it is useful enough to warrant being included as
        a standard, built-in part of the language.  Standardizing this feature
        will prevent problems with a proliferation of similar features that all
        have slightly different names or semantics.

    Proposal (SETF-OF-VALUES:REMOVE-PROHIBITION):

      Permit users to define SETF methods and/or SETF functions for places
      whose names are external symbols in the COMMON-LISP package, provided
      that the standard does not already define the symbol as a name of a
      SETF place.

      Rationale for proposal REMOVE-PROHIBITION:

        There are other potential SETF places besides VALUES that a user might
        conceivably wish to define SETF methods for, that are named by external
        symbols in the COMMON-LISP package.  The writeup for issue
        SETF-MULTIPLE-STORE-VALUES suggested CONS and VECTOR, for example.

    Examples:

    Current Practice:

      Chestnut's Lisp-to-C translator implements proposal ADD.

    Cost to Implementors:

      For proposal ADD, the SETF method for VALUES will need to be written.

      For proposal REMOVE-PROHIBITION, implementors will have to be careful
      about defining additional SETF places on symbols exported from the
      COMMON-LISP package, since those definitions might be overridden by
      user-supplied definitions.

    Cost to Users:

      None.  This is an upward-compatible extension.

    Cost of non-adoption:

      Users are prohibited from doing something useful for no good reason.

    Performance impact:

      Probably none.

    Benefits:

      The costs of non-adoption are avoided.

    Esthetics:

      It looks OK to me.

    Discussion:

      CLtL-II notes that a proposal to add VALUES as a SETF place was
      submitted in September 89, but I can find no record of it in the
      minutes from either the November 89 or June 90 meetings.

      I have no idea what the semantics of a SETF method on CONS or VECTOR
      might be.

    -------

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