copy

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 15 Jun 88 22:52:41 EDT
    From: Timothy Daly <DALY@ibm.com>

    Is there some reason why there isn't a general purpose COPY function
    in common lisp?

    Tim
    DALY@IBM.COM

This question gets asked a lot. Here's my personal assessment. I suspect
the answers will vary widely, though:

You don't know how much to copy without understanding the intent of an
object. If there were just 1 copy function and you wrote:
	(COPY '((A . B) . ((C . D) . NIL)))
how would you know whether to use COPY-CONS (if there were such a thing),
COPY-LIST, or COPY-ALIST?

In my opinion, the issues are the same for COPY as they are for EQUAL.
We did provide EQUAL but people complain all the time that it doesn't
"do the right thing".

The truth is that there is no unique right thing in either case.

In the case of COPY, whether you've copied enough depends on what parts
you consider "the container" and what parts you consider the "contents".
Since there can be different views on the same object, no unique function
can do the whole job.

In the case of EQUAL, the issue is similar. The function you should be
calling to determine if two things are "enough alike" (which is pretty
much what equal seems to mean to people) really depends on your intended
use. I claim that read about EQUAL and then try to invent uses and that's
why it always seems to be broken -- because they want minor perturbations
around this thing they started from. If we'd not given them something to
center their misconceptions around, they would be more likely to just
think of equality as an ill-defined (read: application-specific) problem
rather than to think that it must be uniquely determined in the absence
of an application. Consider having your boss say "Go get me someone who's
Sally's equal." It might help to know if he was looking for someone to
use on the next important work-related project or someone to substitute
on the bowling team tonight. It is not a property of Sue, Bill, or George
what EQUAL means; it is a property of the thing you intend to do with
them afterward, so (EQUAL SUE SALLY) is not the right thing. Instead, you
want (WORK-EQUAL SUE SALLY) and (BOWLING-EQUAL SUE SALLY) and so on.

Similarly, if someone was writing something down on a piece of paper
and someone asked you to "copy what they were writing", it would help for
you to know if they were planning to film your actions, take the copy
of what they'd written home to read later, or use your copy as a forgery.
Depending on the application, your actions might be very different.

The issue of what to do to fix EQUAL is before the cleanup committee
and a zillion solutions have been raised. I've suggested that the most
reasonable thing is to flush EQUAL but for pragmatic reasons we probably
will not. Still, by retaining it, people are left with the sense that
EQUAL computes "uniquely determined generic equality" when in fact it
computes "often useful but quite arbitrary equality". Perhaps someday
someone will add COPY (though I will steadfastly oppose it) but at the
very least I hope the documentation will make clear how arbitrary the
choice of its action is.

Note: It recently occurred to me that saying
 (EQUAL X Y 'CONS), (EQUAL X Y 'TREE), (EQUAL X Y 'BOWLER), etc.
 -- that is, adding an "abstract view" argument -- might give us a
 handle on things. I think people would tend to see this as redundant,
 and maybe it could even default to (TYPE-OF object). Similarly,
 (COPY X Y 'CONS), (COPY X Y 'BOWLER), etc. might give you enough
 information to know what the salient  aspects were... Naturally, to
 be really useful, you'd need to be  able to customize the way in
 which any user-defined type was copied,etc.  Anyway, I'm not
 endorsing this idea, just mentioning it as a thing to be looked at.