Re: &REST lists

[NGALL@G.BBN.COM]

Hmm... I'm getting a little confused by the issue of structure-sharing
the CONS object (and the CONSes linked to it) that is the value of an
&REST parameter.  In general, there are two consequences of structure
sharing:

1) (The one alluded to in your message.) If one modifies the CAR or
CDR cell of a shared CONS, other parts of the system may be affected
(e.g., a calling function call form could be modified).

2) (This is the one that bothers me.) Some other part of the system
may modifiy a shared CONS at any time.  This means that although the
list (chain of CONSes) that is the value of the &REST parameter has
indefinite extent, some part of the system (e.g., some internal part
of the function calling mechanism) could modify the CAR or CDR cell of
any of the CONSes.  For example, I could assign the value of the &REST
parameter (e.g., the list (1 2 3)) to the special variable *FOO*,
return from the function, and discover that the value of *FOO* is now
(1 . !!!END!!!).  The CONS is still there, but someone else (e.g., the
function-return mechanism) modified its CDR cell.

If you are suggesting that (2) would be possible under the
clarification of &REST, then saving the value of the &REST parameter
is fairly useless.  One would have to COPY it to prevent it from being
smashed.

If on the other hand, you are promising that a CL implementation will
never (internally) modify any CONS comprising the list that is the
value of an &REST parameter, then this should be stated explicitly in
the clarification to &REST.

In summary, stating that "the CONSes of the &REST list have indefinite
extent, but may be shared by other parts of the system", implicitly
allows the behavior mentioned in (2), and this makes saving the CONSes
relatively useless.

-- Nick

    ...
    Date: Fri, 11 Mar 88 14:04 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
    ... The premise that values of &rest parameters have indefinite
    extent does not imply the conclusion that each value of an &rest
    parameter is an independent object that does not share structure with
    any other object.  There is general agreement on the premise, but
    certainly not on the conclusion.
    
    Please don't confuse the issue of extent, on which Symbolics still
    deliberately violates the standard (this is a well-known, documented
    violation, which will go away when we get the resources to make it
    go away) with the issue of structure sharing.