[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: SETF-SUB-METHODS (Version 2)
- To: Moon@stony-brook.scrc.symbolics.com
- Subject: Issue: SETF-SUB-METHODS (Version 2)
- From: Jon L White <email@example.com>
- Date: Wed, 25 May 88 16:05:30 PDT
- Cc: CL-Cleanup@sail.stanford.edu
- In-reply-to: David A. Moon's message of Tue, 24 May 88 15:01 EDT <19880524190108.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
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 --