Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)

[David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>]

    Date: 2 Nov 87 18:22 PST
    From: 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. 

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
minutes.

    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".

Fine.

    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. 

Fine.

    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.