Issue: SETF-SUB-METHODS (Version 2)

[Jon L White <edsel!jonl@labrea.stanford.edu>]

re: You left out MASK-FIELD and CHAR-BIT.  

We certainly didn't mean to.  We intended to cover these cases with the words:

    Elaborate the documentation of SETF, especially in the case of access
    forms whose sub-forms are permitted to be generalized variable references
    [and thus which need to call GET-SETF-METHOD during setf macro expansion].

as indicated in the  preamble:

    "... when the accessing technique isn't fully specified just by looking at 
    the get-setf-method of <access-fun>.   The class of such <access-fun>'s 
    is enumerated in CLtL, at the top of p96, except that GETF is missing 
    from that list [we propose that it be added there in the next manual].


but, yes, it looks like they need to be mentioned explicitly.



re:  ... test cases ...

Glaaag, I can't believe we left out the result value of the LDB test case!
(maybe it just looked so obvious!).  All of your additions to the test
case part for LDB, MASK-FIELD and CHAR-BITS seem ok to me.   



re:  	    The case of GETF is complicated by the fact that two different
	    "place" locators are involved: one to use if the specified
	    indicator is present in the property list, and another if not.
	    For example, in (SETF (GETF (AREF ... I) 'B) 6), if the I'th slot
	    of the array is NIL, then that slot must be changed, but if it
	    contains a list with the property B then only the cons cell with
	    that property value needs to be changed.

    I strongly disagree with this.  I think it's wrong to specify that
    SETF of GETF does not store into the <place> if the value that would
    be stored there happens to be EQ to what is already there.  Common Lisp
    should either leave it unspecified, or require that the store always
    take place (I prefer the latter). 

It doesn't specify that the store into <place> *can't* take place; rather 
it only specifies which steps *must* happen, and it purposesly omits saying 
anything about the situation where stores aren't required to maintain
the property-list semantics.  However, your objection:
      "[disagree about] not store into the <place> if the value that would 
      be stored there happens to be EQ to what is already there ..." 
isn't an interesting one; rather the crux of the matter is, I believe, the
one you imply about always storing into the <place> form regardless of 
whether or not the indicator is found on the property list.  I hope I'm 
not mis-paraphrasing your objections, but I think "... EQ to what is already 
there..." is a red herring and the relevant issue is "regardless of whether 
or not the indicator is found on the property list."

What you want is for the <place-form> to be updated as the ultimate and last 
step in a setf-of-getf, precisely because the evaluation of <value-form> 
may itself have altered <place-form> during the in-between steps.  This 
suggestion would permit setf-of-getf to have side-effecting behaviour
parallel to setf-of-ldb; and based on that similarity as a simplification, 
then we agree with your change to the proposal [after all, we can't find 
anyone who really cares what the test case values for setf-of-getf return 
-- only that all CL implementations present the same order of evaluation].
In fact, that is how Lucid's implementation currently works, so we also have
some selfish motivation in altering the proposal accordingly.


re:     ... DELETE ...
    Not true.  For example, (delete 'a '(a a b a d)) does both (assuming
    I correctly understand what you meant by the typo "update some CAR slot").
    I agree that there is a parallel.

I see.  We'll try fix the wording so as not to be misleading.


Version 3 of this proposal will be forthcoming, but I fear that we've
missed the USMailing-out deadline.  It'll be up to Larry.



-- JonL --