Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

I agree with REMF-DESTRUCTION-UNSPECIFIED:EXPLICITLY-VAGUE as I think it
would be modified by ensuing discussion (be more careful in the
discussion of whether new objects are consed or not, and putting in the
missing functions SORT, STABLE-SORT, MERGE, and NSUBLIS; will there be a
version 5?), except that there is one additional change you need to
make:

Where you say
 (REMF place indicator)
  is permitted to either SETF place or to SETF any part, CAR or
  CDR, of the top-level list structure held by that place.
you also need to say that it is an error after this operation to
reference any CONS that was formerly part of the top-level list
structure and is no longer part of it.  Of course this applies not
just to REMF, but also to SETF of GETF, NREVERSE, DELETE,
DELETE-DUPLICATES, NCONC, NUNION, NINTERSECTION, NSET-EXCLUSIVE-OR,
SORT, STABLE-SORT, and MERGE and to the ones that are defined to be
equivalent to these; these are all the ones that might change
list structure rather than just replacing CAR elements.

You see, not only are these destructive functions allowed to change
the components of the conses that make up the top-level list structure
of the argument, they are also allowed to reuse the storage of those
conses for something else that isn't a cons at all.  You may recall
that this was DLA's original motivation for bringing up the issue.

I strongly disagree with Larry's contention that SETF of GETF, REMF,
SETF of GET, and REMPROP are not reasonable to include in this proposal.
If anything, the property list operators have less justification for the
user to depend on the representation than (for example) DELETE, not more
justification.

I disagree with JonL's and Larry's contention that NBUTLAST is not
reasonable to include in this proposal.  I think it would be reasonable
to implement NBUTLAST by sliding all the list elements to the right n
positions and then returning NTHCDR n of the original list.  However,
CLtL p.271 could be interpreted as -requiring- NBUTLAST to be
implemented in terms of RPLACD of a specific cons, rather than just
mentioning that as an example; if so, I would change my mind and
agree that NBUTLAST should be excluded from this proposal.

I also believe that NCONC (and hence by implication NRECONC) is
reasonable to optimize, but on that point I could easily be swayed to
change my mind since I can't think of any really plausible
optimizations.  However, CLtL doesn't offer much evidence that a
specific implementation of NCONC is required.

For the others Larry listed (NSUBST, NSUBST-IF, and NSUBST-IF-NOT), what
the proposal actually says ("is permitted to SETF any part of the TREE
of conses which must be replaced by NEW-OBJECT.") is not proposing to
allow an implementation to modify any portion of a cons other than what
CLtL requires it to modify.  Perhaps that means there is no reason to
include these in the proposal because the proposal says exactly the same
thing about these that CLtL says.  BTW CLtL appears to -require- a
side-effect for these rather than merely -allowing- a side-effect.