[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]

Issue SETF-OF-VALUES Writeup

Issue:             SETF-OF-VALUES







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,


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

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.


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.


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.


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

might be.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.