Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)

[Pavel.pa@Xerox.COM]

My responses to Glenn's recent message:

    On the whole I am for the idea of SETF and some of its friends handling
    multiple values.  (I have implemented setf -- twice -- with an eye
    towards such "upwards-compatible" extensions.)  However, there are a
few
    problems with the meanings of some of the constructs which are
mentioned
    when multiple values get added, and the argument about
    GET-SETF-METHOD-MULTIPLE-VALUE being a non-uniformity and unneeded is
    unsound.

Not all of your problems with the extended semantics are correct, though
two of them are (see below).  I agree that the
GET-SETF-METHOD-MULTIPLE-VALUE argument is probably unnecessary and poorly
stated in the first place.

    SHIFTF and ROTATEF may want to require all the places involved
    to deal with the same number of multiple values, but probably for
    consistency with multiple-value handling elsewhere, should just quietly
    use NIL for missing values.

I don't think it's necessary to require all of the places to contain the
same number of values.  For consistency with the rest of Common Lisp, extra
values at each step should be ignored and missing ones defaulted to NIL.
This is (coincidentally?) also the easiest semantics to implement.

    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.

    The use and distinction of GET-SETF-METHOD and
    GET-SETF-METHOD-MULTIPLE-VALUE is quite clear:  the latter is the
    general case, and the former is for those contexts where multiple
values
    are not handled.  As such, it SHOULD give an error ...

I quite agree.  I did not intend to give any other impression.

    I don't believe it precludes
    correct handling of multiple values by any of the other setting forms
    (PSETF, SHIFTF, and ROTATEF) other than by use of PROG1 in descriptive
    examples.

A good point about the use of PROG1 in the examples; I suppose that ought
to be mentioned in the proposal in order to guide the document writers.

    I would support a proposal which proposed the following:
    
        ...
        
    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.  There are a lot of other Common Lisp forms that can meaningfully
be given SETF methods (CONS, VECTOR and QUOTE, to name some provocative
examples), but it's not clear just which ones should be ``built-in'' since
there's nothing to prevent users adding them themselves (except collisions
between two users' code for the same method).  I leave this policy decision
up to the committee.

    Clarification of GET-SETF-METHOD to say that it signals an error if the
    setf method returns other than one store variable.

I would support this clarification.