[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposal #13: Structure Sharing in Arguments
- To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
- Subject: Proposal #13: Structure Sharing in Arguments
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Sat, 26 Jul 1986 20:34:00 -0000
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: Msg of 26 Jul 1986 13:55-EDT from Daniel L. Weinreb <DLW at QUABBIN.SCRC.Symbolics.COM>
- Sender: FAHLMAN@C.CS.CMU.EDU
in any reasonable implementation the &REST argument will
have been freshly consed.
That's an extremely odd idea. The entire reason that we have &REST
arguments at all is to avoid the need for consing the list. Had we
intended for the list to be freshly consed, we would never have
implemented &REST at all; we'd have just let the caller cons up a list
and pass it as a regular argument.
THAT's an extremely odd idea, in my view. It seems to me that the
entire reason we have &REST args is to allow users to call functions
with arbitrary numbers of arguments, and we inherited the &REST syntax
from MUDDLE or somewhere. If the idea was to avoid consing up a list,
why in the world did we specify that &REST returns a list, instead of
defining some version of LEXPR that passes back the extra args one by
one upon request. (As I said earlier, I will be proposing soon that we
add something along those lines. The lack of a non-consing way of
handling arbitrary numbers of arguments is a big omission in the
If we ignore stack-consing, we see that in the overwhelming majority of
cases the &REST list will necessarily be freshly consed from distinct
arguments that were passed to the function. Only in the case of the
last arg to APPLY is there a pre-existing list around that could be
incorporated into the &rest structure, and I now believe that we should
just require this list to be copied so the the whole issue goes away.
It won't affect overall efficiency in any noticeable way.