[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
- To: CL-Cleanup@SAIL.Stanford.EDU
- Subject: Re: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
- From: masinter.pa@Xerox.COM
- Date: 8 Dec 88 23:21 PST
- In-reply-to: Jon L White <jonl@lucid.com>'s message of Sat, 3 Dec 88 01:46:15 PST
Sigh.
This issue has plagued us for a long time. There have been several
substantive comments since Version 4.
I'll add that I still prefer the proposal I outlined (awkwardly) in
November 1987, which was neither explicitly-vague or explicitly-defined.
The "sequence" functions
NREVERSE DELETE DELETE-IF DELETE-IF-NOT DELETE-DUPLICATES NSUBSTITUTE
NSUBSTITUTE-IF NSUBSTITUTE-IF-NOT
and the destructive set manipulation functions
NUNION NINTERSECTION NSET-EXCLUSIVE-OR
should be explicitly-vague, but the others
SETF of GETF, REMF, SETF of GET, REMPROP, NCONC, NRECONC, NBUTLAST,
NSUBST, NSUBST-IF, NSUBST-IF-NOT
should be specified.
Since the argument for explicitly-defined is portability and the utility of
reliable definitions, and the argument for explicitly-vague is performance,
we should leave things explicitly vague only where
a) it matters for performance and
b) reasonable programs would not rely on the
"defined" behavior
I believe the things I say should be explicitly-vague are the ones where
good style would avoid depending on side-effect behavior and where
performance matters, while the ones I say should be explicitly-defined,
there are reasonable applications which might rely on the explicit
definition, and no strong claims that "explicitly-vague" can make a
difference in performance.
Is this a reasonable analysis?
If so, are these the right choices?