[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)



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?