[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
function-type-rest-list-element
- To: Moon@stony-brook.scrc.symbolics.com
- Subject: function-type-rest-list-element
- From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
- Date: Wed, 24 Feb 88 13:44:20 PST
- Cc: vanroggen%aitg.decnet@hudson.dec.com, cl-cleanup@sail.stanford.edu
- In-reply-to: David A. Moon's message of Tue, 23 Feb 88 17:12 EST <19880223221249.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
re: Here's an interesting thought experiment that might shed some light on
what the FUNCTION declaration, and the &REST type specifier nested
within in, might be for. Suppose you had an implementation ... [with]
lambda-list keyword &REST2, which is just like &REST except that the
value to which the parameter variable is bound is a stack-allocated
object of some implementation-dependent type, and the only legal
operations on it are LENGTH2, NTH2, DOLIST2, and APPLY2 (all just like
the standard functions with similar names except that they take one
of these funny objects as an argument where the standard functions
take a list).
The caller of a function doesn't need to know or care whether the
function accepts its arguments with &REST or with &REST2.
This "gedanken experiment" isn't hypothetical at all. VAX/NIL, one of
the predecessors of Common Lisp, actually had &RESTV and &RESTL in
addition to &REST. &RESTV guaranteed a stack-allocated VECTOR and,
&RESTL guaranteed a heap-allocated list. &REST was left ambiguous just
so that the user couldn't know which of the two kinds of structures
was being worked upon, and thus couldn't depend upon any accidental
properties.
But at "flag day", few other CL participants saw any value to cluttering
up &rest *lists*.
-- JonL --