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

&rest replacement/addition

I had hoped that the semantics of &rest lists could be completely
specified without or before getting into murky side issues like

Given my position on previous issues it should not be a surprise that
I am strongly opposed to all of the &rest replacement/additon
proposals.  I consider &rest to be a fine feature that is completely
adequate for solving the problems of passing indefinate numbers of 
arguments.  I consider it sufficiently good that it is worth spending
considerable effort giving it a precise specification, as we have
been trying to do.  I don't think it needs replacement.

There has only been one criticism of &Rest lists.  There is the
impression that this feature introduces an unacceptible inefficiency
in programs.  This impression is sufficiently strong that people are
considering pulling one of Maclisp's kludgest features out of its
grave, introducing new strange data types to Common Lisp and doing
all kinds of horrible things in order to eliminate this ineficiency.

 From the data that is available it seems that this is just
being scared of the dark.  The statistics I collected do not
directly measure the bottom line efficiency of using &Rest lists.
This certainly means that it is "possible" for dynamic situations to
exist where the efficiency of &Rest lists is exagerated.  It is also
possible that my data sample is somehow unrepresentative.

Someone suggested that the low usage of &Rest could be explained because
programmers fear its inefficiency.  This is unlikely.  The code I 
analyzed was Lisp Machine system code.  Most of this code was written
as ZetaLisp code, in which &Rest lists are *more* efficient than they
are in Common Lisp.  (Because of stack consing.)  In fact, while &Rest
may be less efficient in Common Lisp it may be used more, perhaps
because it is better specified and thus more valuable from an algorithmic

About 10% of the Common Lisp functions used &Rest arguments.  I believe
this is probably an upper bound.  A great deal of effort has been spent
on this mailing list thinking of ways to generalize all of the primitives
in Common Lisp.  Despite this effort to generalize the primitives, 90%
of the time there has been no good reason to use &Rest lists.

Furthermore, I believe there is an explanation for why people "have
the impression" that &rest/Apply must be highly optimized.  Both of these
are used in somewhat unusual coding situations that require somewhat
more thought than normal.  A tricky piece of code requires more attention
 from the programmer.  A common trap is to think the program spends as much
time executing code as the programmer spends writing it.

Without any data to support another position all of the proposals to
replace &Rest or augment it should be rejected, and its semantics should
be precisely defined as I have previously proposed.