&Rest args and Optimizations

[MURRAY@cs.umass.edu]

NOTE:  The ELIOT that has been arguing about &Rest args
       is Chris Eliot, and NOT Eliot Moss, as someone believed.

  Sharing an &Rest list with a list given to apply is clearly an optimization,
and as such, should not be required.  However, if it is allowed, 
destructively modifying an &rest list becomes extremely dangerous, and hence
should never be done.  In fact, it might be appropriate to say it is "an error" 
to modify one.

  I think this is a big mistake.  The cleaner approach to this and other
issues like it is to consider the language issues first.  A well-defined
language that is portable, easy to understand and debug is what's 
important.  Optimizations are the domain of the implementation.  
That's the whole idea behind DECLARE.  
Smart Compilers, tricky type representations, multiple function entry points,
etc, are important, but are all PERFORMANCE issues, not semantic ones.

  In the case of &Rest args, it seems to me that the right way to deal
with it is to say the list is always freshly consed.  If a compiler
can recognize that the list is never modified, it would be free
share it's structure with an Apply arg.  If it can determine the
list is inaccessable on function return, it is free to stack-allocate it.
Providing declarations to help the compiler are very useful, but still can
be ignored without changing the program's correctness.

  In regards to &More, or whatever, I think the &Rest mechanism is
perfectly adequate.  A stack consed &Rest eliminates the conses,
which seems to be what people want to avoid.