&rest lists should not be copied

[mcvax!pilatus!ceb@uunet.UU.NET]

   Date: Sat, 19 Mar 88 04:55:38 est
   From: Barry Margolin <cernvax!mcvax!Think.COM!barmar>

      From: mcvax!pilatus!ceb@uunet.uu.net
      Date: Sun, 13 Mar 88 13:22:44 +0100

      If you want to be able to freely modify the structures which are
      used to implement these features, something imbedded in the kernel of
      the language is going to have to *copy* them.  

   While this is true, it is not really significant. 

   . . . &REST lists, however, have the additional potential
   for being EQ with the list passed as the last argument to APPLY, and
   this is what needs to be specified more carefully.

. . . as they should.  What made me write were suggestions that the
*default* behavior be (at least top-level) cons structure copying.  I
wanted to demonstrate that this could be potentially expensive, but I
guess it was counter-productive to draw in the issue of lower-level
copying.  Anyhow, even enforcing only top-level copying, even if you
restrict yourself to rest lists of "reasonable" size, can cost many
conses, and should not be forced upon you.  Assuming both
kinds of behavior are desirable; one only should ask:
1. Which one should be the default?
2. How do you specify your choice?

A number have written drawing attention to existing or proposed
(mainly declare) forms to accomplish this.  As I understand these
though, I don't like them because:
1. The default behavior is copying, the more expensive of the two.
2, If the default behavior were not to copy, it would not cost much
   if at all more to ask for copying explicitly with a (let . . .
   (copy-list <rest-arg-list>) construct.  Burying such stuff away in 
   the guts of a language only bring about over-use.  On the other
   hand, explicit mention has positive effects on user optimization.
3. One should avoid fueling the "there's too much junk in common-lisp"
   fire whenever possible.
4. Declare forms are reminiscent of other programming languages I
   switched *from* to come to Lisp.  I accept them as means for
   advising the compiler to obtain faster compiled code, as long as I can
   safely ignore them when rapid prototyping.  However, at issue here
   is averting potentially incorrect behavior (I include cancer-like
   consing in this), regardless of whether you run interpreted or compiled.

About the only real efficiency argument I have been able to drum up
for intervening at the moment of function invocation (as opposed to
within the called function body) is that stack consing might be
cheaper than general consing (even if you cdr code?).  If this is
really a consideration, then why not simply add keywords to apply and
friends, such as :stack-copy-args and/or :copy-args, with defaults set
up reasonably?

This would keep all of the strangeness in source code *and* and in
the compiler localized to the trouble point (within apply).

ceb