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.


-------