Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)

[Masinter.pa@Xerox.COM]

No offense was intended in my message. I think that you have provided
some data which will help give a much stronger justification for
MAKE-EXPLICITLY-VAGUE. 

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.

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.