[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: REST-LIST-ALLOCATION (Version 3)
- To: will@fog.cs.uoregon.edu
- Subject: Issue: REST-LIST-ALLOCATION (Version 3)
- From: Jon L White <jonl@lucid.com>
- Date: Tue, 3 Jan 89 22:27:25 PST
- Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
- In-reply-to: William Clinger's message of Tue, 3 Jan 89 08:59:44 PDT <8901031659.AA06887@fog.cs.uoregon.edu>
re: To my way of thinking, APPLY never copies any arguments so APPLY is
perfectly consistent with FUNCALL even if &REST lists are always
freshly consed. You see, my understanding of APPLY is that it calls
its first argument on the elements of the list that is its second
argument (or the analagous thing if you give it more than two arguments).
The arguments, therefore, are the elements of the list, not the list
itself, and so the arguments are not copied.
There was much debate on the Common-Lisp mailing list some months back,
and I vaguely remember the upshot being that "users" definitely did not
want the _default_ state of &rests to be anything optimized -- it leads
to far too much confusion when debugging. On the other side, numerous
implementors (especially those with roots in MIT) argued at length for
the freedom to make one or other time-saving or space-sharing hack.
In acknowledgement of the trade-off between efficiency and "clean,
simple" semantics, people seemed willing to allow a declaration which
permited one or more of these hacks. For example, DYNAMIC-EXTENT could
be applied to the variable holding the &rest argument, meaning that
it is OK to stack-cons it. Gail Zacharias stated this position most
succinctly -- the demand for simple semantics by default, with "hair"
to be added at the users discretion -- although it would take me a
while to resurrect the old mail. [Frankly, however, I don't remember
anyone proposing a declaration/proclamation that permitted the
APPLY-->&rest hack.]
Many of the arguments against "sharing" were similar to what I've quoted
from your msg above. I agree with your explanation of APPLY, even
though I'm an implementor with "roots in MIT" (actually, so is GZ!).
Lucid's implementation works similar to Xerox/Envos' Medley in regard
to &rest treatment; however it does have a stack-consing capability
enabled by declarations. Either way, as Larry Masinter points out,
it would be a tremendous re-vamp of the implemntation to even permit
the smallest amount of sharing when called via APPLY.
-- JonL --