Re: &REST lists

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 11 Mar 1988 16:42-EST
    From: 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.  

It's not considered kosher to modify shared data structure without documenting
that you do so.

					    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.  

I don't see anything in CLtL that says the function calling mechanism is
allowed to modify things.

			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.

I'm not suggesting this.

    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.

You're right.  It would be good to state explicitly that the function
call mechanism will not bash lists received as values of &REST parameters,
that users should not bash lists received as values of &REST parameters,
and that users should not bash lists passed to APPLY as its last argument.
Of course the same thing could be said about every other place in the
language where potentially shareable structure exists.