Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)

[Masinter.pa@Xerox.COM]

Frankly, I'm not particularly willing to adopt MAKE-EXPLICITLY-VAGUE on
the basis of mere speculation that this might allow some performance
improvements. The example of using %CHANGE-LIST-TO-CONS rather than
RPLACD is given, but no guidelines as to how important that could
possibly be. I have a hard time imagining that there is any program,
real or artificial, that the MAKE-EXPLICITLY-VAGUE will make more than
trivially faster. Here's my best shot at imagining one: suppose you
constructed a cdr-coded list, did DELETE on every other element using
RPLACD instead of %CHANGE-LIST-TO-CONS, and then CDR'd down it lots.
Would it run more than 5% more slowly? Wouldn't the next GC remove the
forwarding pointers?

At the risk of repeating myself, be careful to avoid confusing good
programming practice with good programming language design. Whether
users *should* write programs which depend upon exact specifications is
a style issue. 

I'm confused about Pitman's assertion that a purist would prefer
MAKE-EXPLICITLY-VAGUE. Which kind of purity? I can't imagine any part of
the programming task that MAKE-EXPLICITLY-VAGUE would make more
convenient, easier, more facile, less error-prone. 

I'd agree that we have to tighten up MAKE-EXPLICITLY-DEFINED to really
make portability possible. 

I don't think the Benefits given for MAKE-EXPLICITLY-DEFINED are what I
would write; I think the major benefit is in portability of debugged
programs. I don't think it is much of a benefit that users CAN write
programs which exploit them; rather, for those who must deal with
programs where the original programmers DID exploit them, the programs
will be more portable.

If I had to, I would rank order these in the order of importance for
specificity. For example, it seems more important to give NCONCs
behavior as specified than it does to give NREVERSE.