[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: common-lisp@SU-AI.ARPA
- Subject: &rest destruction
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Sun, 10 Aug 1986 19:05:00 -0000
- In-reply-to: Msg of 10 Aug 1986 02:11-EDT from Hvatum at MIT-MULTICS.ARPA
- Sender: FAHLMAN@C.CS.CMU.EDU
From: Steve Bacher (CSDL)
Subject: What's all this fuss about &rest destruction?
Conversely, I find it hard to accept the notion that Common LISP may
specify that some particular kind of argument to a function is
GUARANTEED to be freshly consed and therefore destructible. Suppose you
have a function like
(defun foo (a b &rest c) ...)
Why should I be guaranteed that the value bound to c will be
clobberable, when I am not given such a guarantee for a and b?
The situation for A and B is not the same as for C. The values for A
and B come direct from the caller. In the case of a normal call to FOO,
the value passed in for C will be a list that is freshly consed at
runtime. The only case in which C might not be freshly consed is if FOO
is called via APPLY. Since calls via APPLY are relatively rare, the
question is whether we should require copying in this rare case (which
would allow users to assume that a rest arg is ALWAYS freshly-consed),
or whether we should warn the users that the &rest arg may have shared
top-level strucutre in some rare cases.
The issue of whether &rest args have indefinite extent is a separate
one, dragged in by some random comments by DCP. It seems that everyone
agrees that Common Lisp currently requires &rest args to have indefinite
extent, and that this should not be changed.