[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


    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

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.