[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)
- To: Pavel.pa@Xerox.COM, CL-Cleanup@sail.stanford.edu
- Subject: Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)
- From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
- Date: Wed, 7 Dec 88 22:47 EST
- In-reply-to: <881206-151032-6974@Xerox>
Date: Tue, 06 Dec 88 15:10:26 PST
From: Pavel.pa@Xerox.COM
My responses to Glenn's recent message:
ASSERT, CTYPECASE, and CCASE on the other hand should NOT deal with
multiple values. Semantically, they are dealing with individual values
(in the case of ASSERT, it is a list of individual values which can be
respecified by the user -- individually).
You point about CTYPECASE and CCASE is very well taken; consider them
removed from the proposal. That was a bit of a thinko on my part. ASSERT,
on the other hand, should stay. In the case of ASSERT it is NOT a list of
individual values, but of individual PLACES. Sure they can be individually
changed by the user. But doesn't that user specify an expression whose
value will be stored? Can't that expression return multiple values? I am
not compelled to remove ASSERT.
Right. It is reasonable.
Addition of a builtin setf-method for the VALUES function.
I wouldn't mind seeing this in the language at all, but it wasn't clear to
me just what the X3J13 policy was concerning the addition of new SETF
methods.
I can see leaving it out of a proposal which is otherwise clarification
only. I can also see how making multiple value handling explicit, as
you intend, will make the lack of setf method for VALUES stick out like
a sore thumb.