[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
- To: email@example.com
- Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 1 Dec 88 02:17 EST
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: <8811300617.AA03229@bhopal>
Date: Tue, 29 Nov 88 22:17:59 PST
From: Jon L White <firstname.lastname@example.org>
... 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
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
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?