Proposal #13: Structure Sharing in Arguments

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

    Date: Fri, 25 Jul 86 15:06 EDT
    From: Guy Steele <gls@Think.COM>

    I think the lesson here is that, in general, you shouldn't ever clobber
    a CONS if you don't know where it has been.  Certain CL primitives do
    guarantee to cons up fresh lists, and you can safely clobber their
    results.  Everything else you ought to be careful with, and that
    includes &rest arguments, the results of PARSE-BODY, the results of FOO,
    and so on.  Unless a function or other construct is clearly documented
    to indicate that it is okay to clobber its result, then you should avoid
    doing so.

I agree so strongly with the above statement that I'm going to waste
hundreds of people's time by including it in my message so that they
have to read it again.  The negation of this statement is practically
the definition of poor programming practice.

    Date: Tue, 22 Jul 86 21:39:37 pdt
    From: hpfclp!diamant@hplabs.HP.COM

    ....it better be clear that the
    list returned may not be something which will go away on exiting the
    function (which could happen if the parameter list were stored on the
    stack and a pointer to that list was returned -- apparently what
    Symbolics does).

Symbolics has always agreed that this aspect of our implementation is
not in conformance with Common Lisp, and have said so in our
documentation.  We just haven't gotten around to fixing the bug yet, for
engineering reasons that I won't bore you by expounding.  No one should
think that we oppose Diamant's statement above.

    Date: Sun, 27 Jul 1986  23:01 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    13A: Specify that the &REST or &BODY argument to a macro may be the very
    list from the macro call, and not a copy.  Therefore, if this argument
    is destructively modified, the originl text of the macro may also be
    altered.

Agreed.  Make sure the word is "might", not "must", where you now use
the ambiguous word "may" in two places.

Vanroggen brought up &WHOLE.  The manual already implies that the &WHOLE
argument is required to be the original form, and not a copy, but this
should be made more explicit.  Is this big enough to be a separate issue?

    13B: Specify explicitly that the &REST argument in a function has
    indefinite extent and may, for example, be returned to the function's
    caller.

Agreed.

    13C: The &REST list in a function is not necessarily a freshly-consed
    list.  If the function is called with APPLY, the &REST list may share
    top-level structure with the last argument to the APPLY.  Users should
    keep this in mind if they are considering destructive modifications to
    such a list.

Agreed, but the wording should be changed to say that an &REST argument
might share structure with something else regardless of how the function
was called, and simply use APPLY as an example.  There is no reason to
put extra restrictions on the implementation here.

    - OR -

    13C': The &REST list in a function is freshly consed upon function entry.
    It shares no top-level structure with any pre-existing list.

It's a bad idea to base the language specification on the idiosyncracies
of a particular implementation.