copy-seq

[Barry Margolin <barmar@Think.COM>]

    Date: 30 May 89 13:18
    From: chapman%aitg.DEC@decwrl.dec.com

    Here's your original comment.


    >    >P. 3-217, COPY-SEQ: In the description, remove the clause "that is
    >    >EQUALP to sequence", and add the sentence "The elements of the result
    >    >are EQL to the corresponding elements of sequence."  The fact that the
    >    >result is EQUALP is not part of the definition of COPY-SEQ, it's merely
    >    >a consequence of the definition of EQUALP.  If you want to mention
    >    >EQUALP, you can add this to the Notes: "(EQUALP X (COPY-SEQ X)) ->
    >    >true".  But since it's already in the Examples, it's not really
    >    >necessary.
    >    I understand what you're saying, but on page 248 of CLtL, the predicate
    >    used is EQUALP, so I'll leave it that way.
    > 
    >This has to do with the difference between a language SPECIFICATION and
    >an informal language DESCRIPTION.  CLtL is a description; we are
    >supposed to be writing a precise specification.  Simply stating that the
    >result is EQUALP to the original is not precise enough; there are many
    >ways to copy a sequence that result in an EQUALP-but-not-EQL copy.  If
    >you think I should write a cleanup proposal for this, I will; however, I
    >think it is so obviously what was intended that it isn't necessary.
    I'll send a note to the drafting committee so we won't have yet another
    issue at the June meeting. ok?

    Here's moon's response to your suggestion.

    >From:	DECWRL::"Moon@STONY-BROOK.SCRC.Symbolics.COM" "David A. Moon  30-May-89 1243 EDT" 30-MAY-1989 12:39:48.36
    >To:	aitg::chapman
    >CC:	
    >Subj:	question @ COPY-SEQ
    >
    >Cc: quinquevirate@sail.stanford.edu
    > 
    >    Date: 30 May 89 10:52
    >    From: chapman%aitg.DEC@decwrl.dec.com
    > 
    >    Does anyone have a problem if I change the predicate in the description
    >    from EQUALP to EQL?
    > 
    >Yes, that would be completely wrong!  What CLtL says is correct.
    >It's true that one could invent a stronger predicate than EQUALP
    >which COPY-SEQ would be an identity under, in particular, one that
    >was case-sensitive for character and string comparison.  However,
    >among the existing Common Lisp predicates, EQUALP is the only one
    >under which COPY-SEQ is an identity function.

    Barmar, if you continue this debate, please copy me on it.
    kc

Kathy is twisting my words; I DIDN'T say to change EQUALP to EQL!  I
said that "COPY-SEQ creates a copy of sequence that is EQUALP to
sequence." is not a good definition (COPY-TREE fits that description,
but we wouldn't want COPY-SEQ to do a COPY-TREE), and should be replaced
with "COPY-SEQ creates a copy of sequence.  The elements of the result
are EQL to the corresponding elements of sequence."  The Notes section
could then mention that the result is EQUALP to the argument.

CLtL isn't very specific about what goes on when things are copied in
many cases.  COPY-SEQ is described in terms of SUBSEQ, but neither of
them explicitly prohibits the implementation from copying other than
just the backbone of the sequence.  However, I definitely think this
restriction was intended, and I doubt any implementation is violating
it.  Now that I've discovered this ambiguity, I think the ANS should fix
it.

Part of the reason for these types of ambiguities is that the author
assumes that the reader understands the relationships between Lisp
objects.  When speaking of "the sequence", "the array", "the list", Lisp
wizards understand that this only refers to the backbone structure, and
doesn't include the elements contained by the object.  But less wizardly
implementors might not have our background, and we owe it to them to be
explicit.  Otherwise, Murphy's law implies that someone is going to do

(defun copy-seq (seq)
  (typecase seq
    (list (copy-tree seq))
    ...))

I haven't even mentioned the fact that the COPY-SEQ description in the
dANS doesn't say that it always returns a newly-allocated sequence (CLtL
says this indirectly, because COPY-SEQ is defined in terms of SUBSEQ,
which says it explicitly, but the dANS only mentions SUBSEQ in the
Notes, which don't count).  Therefore, according to the dANS, it's
possible for

	(eql (copy-seq foo) (copy-seq foo))

to be true.