[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
&rest lists should not be copied
Date: Sat, 19 Mar 88 04:55:38 est
From: Barry Margolin <cernvax!mcvax!Think.COM!barmar>
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
This would keep all of the strangeness in source code *and* and in
the compiler localized to the trouble point (within apply).