References: SETF, GET-SETF-METHOD-MULTIPLE-VALUE
Related issues: SETF-MULTIPLE-STORE-VARIABLES
Category: ADDITION, CHANGE
Edit history: v1, 12 Feb 1991, Sandra Loosemore
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,
There are two proposals, ADD and REMOVE-PROHIBITION. The two proposals
are not mutually exclusive.
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
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.
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
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.
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
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.
The costs of non-adoption are avoided.
It looks OK to me.
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