[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: rst@Think.COM

       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.

						    barmar

    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.

                                                barmar