[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


I generally agree with your assessment, Larry, although I am pessimistic
about bringing up &rest vectors again -- a *lot* of code already exists
in the Common Lisp world  which assumes that the &rest parameter is bound
to a list.

On the other hand, while Kent may have noticed the large number of messages
sent recently to Common-Lisp@sail on this topic, but I wonder if he read 
them?  The overwhelming majority of them concerned user disatisfaction with 
the unexpected "sharing" of rest lists -- our issue REST-LIST-ALLOCATION.  As 
Gail Z put it so succinctly -- if the CL spec can't get its act together to 
guarantee non-sharing in &rest lists, then there *must* be some construct 
added to the language so that the discerning user can prevent it.  In my
message to Common-Lisp@sail of 8 Apr 88 01:00:38 PDT I quoted her:
   Gail Zacharias talked about the common idiom of simply doing a COPY-LIST on 
   every &rest argument, to insure some normalcy.  Her reasoning seems, to me, 
   to bolster the case for those who claim that that CL semantics are deficient
       Subject: &REST Lists
       Date: 24 Mar 88 12:23:15 EST (Thu)
       From: gz@spt.entity.com (Gail Zacharias)
       . . . 
       If Common Lisp doesn't require unshared &rest lists, then I think
       it must provide a declarative version of this idiom so the COPY-LIST can
       be portably avoided when it's redundant.  Seems to me that the fact that
       this is a common case where users find a need for conditionalization 
       indicates a real deficiency in Common Lisp's specification.
       . . . 
   Of course, the problem isn't only the sharing of &rest lists, but the more 
   common flaw that they may, unannouncedly, have dynamic extent.  By this, I 
   mean the bug where a stack-allocated &rest list can creep out into global 
   data structures, even though it will surely disappear when the frame that 
   created it returns.  Allegedly, Symbolics is going to fix this bug in their 
   next release (and TI may have already fixed it?); but we are now five years 
   beyond the first CL specification!

So as you say, we have a responsibility to resolve the very thorny issue

On the other hand, since CL semantics already requires indefinite extent
for &rest values, and since Symbolics has been in violation of this part
for so many years, *** and because a subset of users find dynamic extent
extremely userful *** then I don't think it would hurt all that much
to bless the effort to standardize the syntax for asking for it.

-- JonL --

P.S.: When I questioned whether Kent read the messages sent to Common-Lisp
      mailing list, there was no intent to question his mental compotence.
      Some months back he defended the dumping of a Symbolics internal 
      discussion onto the CL-Cleanup mailing list by saying that he refused 
      to read the allegedly voluminous Common-Lisp mails,  and thus couldn't 
      carry on the discussion there.