Issue: COPY-SYMBOL-COPY-PLIST

[Barry Margolin <barmar@Think.COM>]

    Date: Tue, 10 Jan 89 17:33 EST
    From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>

	Date: Tue, 10 Jan 89 13:17 EST
	From: Barry Margolin <barmar@Think.COM>

	...
	Rationale:

	COPY-LIST is the simplest list-copying primitive.
	...

    In my book it's the -only- list-copying primitive. COPY-TREE doesn't
    copy lists, it copies trees. Abstractly, there is no relationship
    between the two except for people who think it's a bug that
     (MEMBER 'A '(B (A) C))
    doesn't find A in the given list.

If you're going to play semantic games, MEMBER searches sets, not lists.

If the definition of what it means to "copy a list" were obvious, CLtL
wouldn't need three sentences to describe it, it could simply say
"copies the list and returns the copy."  Also, the description of
COPY-LIST doesn't mention that it is THE copier for the abstract type
"list" (the first sentences of the COPY-ALIST and COPY-TREE descriptions
DO say something to that effect for their respective abstract types), it
merely describes the operation of the function.  Readers of standards
are not supposed to make assumptions based on names, so one can't assume
that copying lists in general implies COPY-LIST.

    I don't think there's much issue here, but I'm happy to go along with it
    if you think there is.

    If we do proceed, I'd go so far as to say that Kathy might want to
    document that wherever in plain text the phrase "copy the list" is used,
    the equivalent of COPY-LIST is intended, that wherever in plain text the
    phrase "copy the tree" is used, the equivalent of COPY-TREE is intended,
    and that wherever in plain text the phrase "copy the alist" is used, the
    equivalent of COPY-ALIST is intended.  This would save us having 42 more
    of these issues come up now that you've opened this particular box
    marked "Pandora"...

I agree with you in principle, but I don't think this particular case is
so obvious that it goes without saying.  What CLtL actually says in this
case is "the property list of the new symbol will be a copy of SYM's."
The problem is that COPY-TREE produces a result that has many of the
same properties as that produced by COPY-LIST, and in the case of
copying property lists it may not be so obvious which of these
properties are important.  If there were a COPY-PLIST function it would
be pretty obvious that its semantics were intended; if there were such a
function, it might conceivably copy even elements differently from odd
elements, if we were to decide that indicators and values had different
important properties.  An implementor of COPY-SYMBOL might think that
such different semantics are necessary even without the existence of
such a function.

I don't think the Pandora's box is that big.  I don't think there are
many places where lists or trees are automatically copied.  I can't
think offhand of ANY place where it might say "copy the tree" (I think
the only standard functions that know about trees as an abstract object
are TREE-EQUAL, COPY-TREE, SUBST and its variants, and SUBLIS and its
variants).

The Pandora's box isn't empty, though.  I just noticed that COPY-SEQ
doesn't specify precisely how the sequence is copied.  In fact, COPY-SEQ
says that it is equivalent to (SUBSEQ sequence 0), and the description
of SUBSEQ says "it never shares storage with an old sequence."  You and
I know that the latter means "it never shares top-level storage", but it
could easily be interpreted to mean that none of the storage of the
original object is shared.  We know that because we understand how Lisp
differentiates between a structured object and its contents, but most
traditional languages don't make such a distinction, so I think it is
important that the CL standard not presume this abstract understanding.

I'm currently writing a paper about copying and equality that I hope to
have done in time to distribute at the meeting, and it has sensitized me
to the need to specify these things explicitly.  Also, if we don't
correct them now, I'll wager we'll have to after the standard goes out
for public review (I've seen the kinds of comments that come back from
ANSI public reviews, and they can find an amazing number of nits to
pick).

                                                barmar