Re: &rest [discussion] replacement/addition

[Paul Fuqua <pf@ti-csl.csc.ti.com>]

    Date: Friday, April 8, 1988  3:43pm (CDT)
    From: Jon L White <edsel!jonl at LABREA.STANFORD.EDU>
    Subject: &rest [discussion] replacement/addition
    
    Of course, the problem isn't only the sharing of &rest lists, but the more 
    common flaw that they may, unannouncedly, have dynamic extent.  By this, I 
    mean the bug where a stack-allocated &rest list can creep out into global 
    data structures, even though it will surely disappear when the frame that 
    created it returns.  Allegedly, Symbolics is going to fix this bug in their 
    next release (and TI may have already fixed it?); but we are now five years 
    beyond the first CL specification!

We fixed it for Release 3, which came out some time ago.  We use a separate
internal data type for stack-lists, which, when the list is returned from a
function or stored into the heap, is noticed and causes the list to copied
out of the stack.  There's other hair to preserve EQness and to cope with
stack-groups and special-bindings.

As a matter of fact, I asked about the problem of APPLYing a function with a
&REST arg back when I was doing the function-calling microcode.  The easy
approach was to spread the list and re-collect it into a stack-list, which
would avoid both the sharing and the consing, but we decided at the time to
avoid the spreading overhead.  If the standard says not to share, we'll
spread and re-collect.

Incidentally, our implementation of keyword arguments also uses a &REST arg,
so &KEY implies &REST internally.  Did that appear in the statistics?  I
don't know if other implementations do the same.

The general rule around here is, "Don't modify a list if you don't know where
it came from."  Many constants in our implementation end up in read-only
areas, and there are other instances of sharing than APPLY/&REST, so it's
seen as a bad idea to use destructive operations on random data objects.

                              pf

Paul Fuqua
Texas Instruments Computer Science Center, Dallas, Texas
CSNet:  pf@csc.ti.com (ARPA too, eventually)
UUCP:   {smu, texsun, im4u, rice}!ti-csl!pf