Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)

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

    Date: Tue, 29 Nov 88 22:17:59 PST
    From: Jon L White <jonl@lucid.com>

    ... I'd like to see a section in the spec that concerns these
    "destructive" operations to say explicity that it is perfectly
    all right for them _not_ to destroy anything but instead to
    "cons" new results. ...

I talked to a Lucid user about this tonight. That user said that your
implementation does a copy for SORT (for example) and that your GC
doesn't really keep up. His claim was that your implementation would
be faster if you did side-effect. I won't be surprised if you tell
me this problem has been fixed, but in any case it raises the point
that this is a situation which could easily arise.

I'd certainly be willing to stipulate in the proposal that there may be
circumstances in which new results are consed instead, so that users
would know they had to do the SETQ in all cases, but...

I'm not really psyched about it saying anywhere that it's "perfectly
all right". It's "all right under some special circumstances", which
may have the same legal weight. But I'd like to at least have some
verbiage in there that says that the intent is that copying would
occur only if it's really true that copying is more efficient. The
metric I would expect is that if you sit in a loop, repeatedly sorting
a list by #'< and #'> (so that it keeps changing), if a copying
implementation stays ahead of a non-copying implementation (that is,
the sum of copying + GC is still faster than copying), then it's 
really ok.

I don't want implementors to think that it's acceptable to do

 (DEFUN APPEND (&REST X) ...hair...)
 (SETF #'NCONC #'APPEND)

just because they are either too lazy to write NCONC or have some
personal crusade to wage against side-effects.

I think the reason someone calls NCONC rather than APPEND is to get
something efficient, for a price. Even if you don't modify, they've
still paid the price because they have to be afraid you've modified,
so they're entitled to know they got something for this price.

I don't propose putting all of the above in the proposal. I just
wanted to make my opinion clear. I propose changing the proposal by...

 - striking the three or so places that it explicitly reminds you
   to use SETQ in case a side-effect doesn't occur

 - adding some general purpose verbiage that says something like
   that the purpose of these operators is to provide you the most
   efficient algorithm, and that in some situations or some 
   implementations, there may be some reasons why the most
   efficient thing is to copy rather than to side-effect. As such
   none of these operators are actually required to side-effect,
   but the user should assume that, whatever the implementation, it
   will have speed competitive with or surpassing a side-effecting
   implementation.

Also, GSB points out that SORT, STABLE-SORT, and MERGE are conspicuously
absent from the list. They should be added in as well.

I'll be happy to make the changes if we can agree up front that
they sound like the right thing.

Does this sound ok?