[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]



Document: X3J13/91-412

Reference: CLtL-II, p.429


Draft 10.156 (X3J13/91-103)

Draft 12.24 (X3J13/92-102)

Barrett's public review comment #24 (X3J13/92-2524)


Edit History: Version 1, 22-Dec-91, Kim Barrett

Version 2, 19-Apr-92, Kim Barrett

(Two proposals, note confused status)

Version 3, 20-Apr-92, Kim Barrett (KMP's comments)

Version 4, 7-Jun-92, Kim Barrett

Status: Confusion! One of the proposals (REVERT or PERMIT) was passed at

the 12/91 meeting, but there is disagrement as to which.

Draft 12.24 (X3J13/92-102) was written assuming that REVERT was

the passed proposal.

Barrett now asks us to reconsider proposal PERMIT.

Proposal REVERT passed 11-0 on letter ballot 93-302;

on same ballot, proposal PERMIT failed 2-6.

Problem Description:


argument, contrary to the description of NINTERSECTION in CLtL, which

explicitly states that the second argument (list2) is not destroyed. It is

questionable whether this change was intentional or not, especially since

REMF-DESTRUCTION-UNSPECIFIED was categorized as a clarification rather than a



Affirm the wording from CLtL, prohibiting NINTERSECTION from modifying the

second (list2) argument.



to modify either list argument.

Editorial Impact:


None. The 12.24 draft assumes that REVERT was accepted.


Small. The two-line paragraph on p.14-51 of X3J13/92-102 describing the

difference between NINTERSECTION and INTERSECTION would have to be changed

slightly, specifying that both the LIST-1 and LIST-2 arguments may be

destroyed, rather than only permitting LIST-1 to be destroyed and requiring

that LIST-2 be preserved.



The intent of REMF-DESTRUCTION-UNSPECIFIED was not to change side-effect

behavior, but to tack down places where we had all pretty much agreed on

side-effect behavior but never spelled it out. This was a case where CLtL

had spelled things out, and which was probably changed unintentionally.

Some older programs may depend on this argument not getting bashed, and it

would be a shame to have some implementation decide to bash it.

Don't make an apparently unintentional incompatible change.


Affirm the more recent decision, which went through more than two years of

discussion before finally being accepted. The intent of

REMF-DESTRUCTION-UNSPECIFIED was to permit greater implementation freedom

in order to achieve better performance; prohibiting the destruction of one

of the lists may have a negative performance impact.

A ``destructive'' function that is only permitted to destroy one of it's two

arguments (with no rationale for which argument may be destroyed and which

may not) is confusing; this is the only case of such.


Current Practice:

Apple Macintosh Common Lisp 2.0 obeys REVERT.

Symbolics Genera 8.2 (and before) obeys REVERT.

Cost to Implementors:

None for PERMIT.

If REVERT is adopted, implementations that have been tracking the passed

cleanups and have taken advantage of the permission granted by

REMF-DESTRUCTION-UNSPECIFIED in this case will have to change. It may require

a significant amount of work to achieve similar performance. Implementations

that pre-existed the acceptance of that proposal may be able to revert to an

older source that obeyed the CLtL1 restriction.

Cost to Users:

For REVERT, no semantic cost for users; there may be a performance cost.

For PERMIT, an incompatible change. In some cases it may be quite difficult

to determine whether a call to NINTERSECTION can safely destroy the second


Performance Impact:

There may be a negative performance impact in choosing REVERT over PERMIT.

The ``obvious'' implementation is to iterate over the elements of one of the

lists and if that element appears in the other list then collect it, reusing

storage from the first list in the collection process. If the length of the

first list is less than the length of the second, this algorithm is

asymptotically as much as a factor of two slower than if the lists were

exchanged. Thus, by preventing such a choice of which list to destroy, REVERT

might result in slower performance for NINTERSECTION.


The status of this issue is unclear.

Date: Wed, 22 Jan 92 13:25:51 EST

From: kab (Kim Barrett)

To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

Subject: Re: Issue: NINTERSECTION-DESTRUCTION (Version 1)

> Date: Sun, 22 Dec 1991 14:48 EST

> From: kab@cambridge.apple.com (Kim Barrett)


> Does this look ok to you?


> No! My meeting notes say:


> "Move to say list-2 not modified. PASS 8-2"


> Lest you think I mis-noted this, I certainly remember lobbying for a

> position which said that REMF-DESTRUCTION-UNSPECIFIED had made the

> change unintentionally, and that we should revert the wording. Had I

> wanted to retain the wording, I would not have raised the issue.

Looks like we have a problem here. My notes just say


which is not very helpful. My memory says that we voted to affirm the

words in the draft (as stated in the draft writeup I sent you), but

obviously I could be mistaken. Unfortunately, the minutes are also



(In document 91-003b.)

Vote: 7 - 2. Passed.

There isn't any such thing in the specified document. (I pointed this out

to Jan after the last version of minutes was mailed out).

The reference to REMF-DESTRUCTION-UNSPECIFIED in 91-003b was to the following


Date: Tue, 16 Jul 1991 17:33-0400

From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>


To: kab@chestnut.com

Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, barmar@think.com, GLS@Think.COM

[Addressed to Kim because he's been keeping a list of my little nitpicks

and figuring out which shoudl be written up and distributed. Other

relevant individuals cc'd in case they have comments.]

One of Barmar's reviews turned up the following...

CLtL said plainly that list-2 was not destroyed by NINTERSECTION.

REMF-DESTRUCTION-UNSPECIFIED says quite clearly that it might be, even

though I think the intent of REMF-DESTRUCTION-UNSPECIFIED was mainly to

clarify points left vague by CLtL, not to introduce new things that were

possible to destroy.

The current draft is inconsistent in that in different places, it says

things that are consistent either with CLtL or with the cleanup issue.

The status quo is well-defined, so if no vote is taken I will believe

REMF-DESTRUCTION-UNSPECIFIED. But I don't think that people realized

they were making an incompatible change in this particular case, so I

wonder if the issue should be raised at X3J13 for confirmation.

As an aside, I note that CLtL2's wording also implies that this was a

"clarification" without making it apparent that an actual change had


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996-2005, LispWorks Ltd. All rights reserved.