[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: &REST lists
Date: 11 Mar 1988 16:42-EST
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
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
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.