[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposal #13: Structure Sharing in Arguments
- To: common-lisp@SU-AI.ARPA
- Subject: Proposal #13: Structure Sharing in Arguments
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 28 Jul 86 21:54 EDT
- In-reply-to: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>, <860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>, The message of 23 Jul 86 00:39 EDT from hpfclp!diamant@hplabs.HP.COM, <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>, <860723130828.1.DCP@FIREBIRD.SCRC.Symbolics.COM>, <860723132120.2.DCP@FIREBIRD.SCRC.Symbolics.COM>, <860723142439.9.MILLER@UR-CASHEW.ARPA>, The message of 23 Jul 86 15:30 EDT from "BACH::VANROGGEN" <email@example.com>, <8607232003.AA00325@tekchips.TEK>, <860724141621.4.DCP@FIREBIRD.SCRC.Symbolics.COM>, <FAHLMAN.12225382154.BABYL@C.CS.CMU.EDU>, <FAHLMAN.12225383753.BABYL@C.CS.CMU.EDU>, <8607251827.AA05634@utah-orion.ARPA>, <860725150616.3.GLS@IGNATIUS.THINK.COM>, <860726135509.3.DLW@CHICOPEE.SCRC.Symbolics.COM>, <FAHLMAN.12225834449.BABYL@C.CS.CMU.EDU>, <860726171228.4.DLW@CHICOPEE.SCRC.Symbolics.COM>, <FAHLMAN.12225845128.BABYL@C.CS.CMU.EDU>, The message of 26 Jul 86 18:38 EDT from SCOTT <SAFIER%cgi.csnet@CSNET-RELAY.ARPA>, <8607262326.AA01397@utah-orion.ARPA>, <FAHLMAN.12225931299.BABYL@C.CS.CMU.EDU>, <FAHLMAN.12226167028.BABYL@C.CS.CMU.EDU>
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
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
....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 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
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
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.