[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: &rest replacement/addition
Date: Mon, 4 Apr 88 12:29:50 edt
From: Barry Margolin <barmar@Think.COM>
Subject: &rest replacement/addition
Actually, if this were added, the operations that extract the arguments
need not be special forms. &MORE-ARGS <var> could bind <var> to an
object of type MORE-ARGS. Common Lisp would only specify accessors for
this object, so it could be passed along with no possibility of strange
side-effects. APPLY could also be extended to allow a MORE-ARGS in
place of a list as its last argument.
But can an object of type MORE-ARGS be returned from a function, or
otherwise stuffed in data structures which survive the dynamic extent
of the function call that spawned them? That's what this whole
argument started with...
No, I don't think that's what started this particular argument. The
issue of stack-consed &REST lists is completely independent of the issue
of side-effects on shared &REST lists. They are two orthogonal
mechanisms for speeding up calls to &REST functions; in fact, they each
address different cases (stack consing speeds up normal calls, sharing
speeds up calls via APPLY). The above only addresses the issue of
preventing the strange side-effects that the latter allows, which is
what this discussion has been about. I almost added a sentence that
said that this doesn't affect the stack-allocation issue, as those
implementations that currently allocate &REST lists on the stack would
probably want to allocate &MORE-ARGS objects there, too.
Dynamic-extent &REST lists have never been valid Common Lisp (there are
examples on p.64 of CLtL that fail when &REST lists are stack-consed).
If this new proposal were to be adopted, I doubt X3J13 would allow them
to be stack-allocated, either. Presumably, Symbolics's excuse for
continuing to stack-cons &REST lists is that they were doing so before
Common Lisp, and they haven't gotten around to changing it. They
wouldn't have such an excuse with the new mechanism.