[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
- To: Masinter.pa@Xerox.COM
- Subject: Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
- From: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>
- Date: Mon, 2 Nov 87 22:52 EST
- Cc: CL-Cleanup@SAIL.Stanford.EDU, DLA@DIAMOND.S4CC.Symbolics.COM
- In-reply-to: <871102-182243-2120@Xerox>
Date: 2 Nov 87 18:22 PST
No offense was intended in my message. I think that you have provided
some data which will help give a much stronger justification for
No offense taken, of course. Especially since, according to this
message, we seem to agree on practically everything!
For example, I was unaware of the behavior of the Symbolics GC on
cdr-coded list blocks. I didn't imagine that the difference on DELETE
would be nearly as high as you measured. I think the proposal might
say something like "For example, in one implementation, the best
implementation of DELETE under MAKE-EXPLICITLY-VAGUE is over four times
faster than the simple implementation using RPLACD." The interaction
with ephemeral garbage collection is useful to document.
However, in reviewing the language in CLtL surrounding these destructive
functions, I think that it is pretty explicit about some.
For the functions DELETE, DELETE-IF, DELETE-IF-NOT, NREVERSE, SORT,
DELETE-DUPLICATES, NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT,
NUNION, NINTERSECTION, NSET-EXCLUSIVE-OR it says "This is a destructive
operation. The argument sequence may be destroyed and used to construct
the result." so smashing either the CARs or CDRs randomly seems OK.
But most of the other functions side-effect behavior is much more
explicitly described in CLtL; I can't imagine anyone in the user
community seeing it as a step forward to make these any more vague than
they already are.
CLtL is pretty explicit about what (SETF (GETF ..) ..) does (it adds a
new pair or modifies the old), REMF (it splices out the conses),
REMPROP, NRECONC, NBUTLAST. It might be OK to also smash the CAR of the
list being spliced out with REMF.
I agree that SETF-GETF need not be changed.
It doesn't say how REMF (or REMPROP) splices out the conses, and it
doesn't define splicing to exclude splicing out both the pointer into
the pair and the pointer out of the pair.
I don't believe that NRECONC is specified any more than NREVERSE in the
current description. I believe that what goes for NREVERSE should apply
to NRECONC as well. (Indeed, in the Symbolics implementation NREVERSE
is implemented with NRECONC.)
I agree that there could be no use in vagueifying NBUTLAST. Probably
the reason it's included is because it was on my list of
list-destructing functions which I made by searching through CLtL in 3
NSUBST it says "the list structure of tree is altered by destructively
replacing with new each leaf or subtree of the tree such that old and
the leaf or subtree satisfy the test".
CLtL is also very explicit about NCONC.
I know that I have frequently written (NCONC place Y) where I can assert
that place is CONSP, assuming this is equivalent to (SETF (CDR (LAST
place)) Y). I've also written code that assumes that (SETF (GETF place
'Y) z) behaves the same as (let((plist place)) (setf (getf plist 'y)
z)) when place has a y property, i.e., that this really only changes the
CAR in the case that the property was already there.
So, I think explicitly-vague NSUBST, NSUBST-IF, NCONC, NBUTLAST are far
less useful in the language; making them vague would be a serious
backward incompatibility for no substantial benefit.
I can agree to this. NCONC is fuzzier than the rest, but since there is
no clear advantage to making the specification vague we probably
shouldn't do it.