function-type-rest-list-element

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 23 Feb 88 14:07:00 EDT
    From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>

    We oppose the proposal FUNCTION-TYPE-REST-LIST-ELEMENT:
    USE-ACTUAL-ARGUMENT-LIST.

    We feel that although specifying the element type in a function
    type specifier is slightly more convenient, it is outweighed by
    its inconsistency and lack of expressiveness.

    If specifying the element type of lists is an important issue,
    and we think it is, then we should extend the LIST type to be
    a list type:
      (LIST [<element-type> [<length>]])
    just like for VECTOR.  In fact, it would also be wise to
    extend SEQUENCE in the same way.

But the analogy to VECTOR is false!  (VECTOR element-type) does not
mean a vector all of whose current elements are of type element-type.
Nor does it mean a vector constrained such that that all elements
that can be stored into it are of type element-type.  The ambiguous
language on CLtL p.47 might lead you to think that's what it means,
but CLtL p.45 makes it clear.  For declaration, (VECTOR element-type)
[via (ARRAY element-type (*))] means a one-dimensional array
of the most specialized type that is capable of holding objects of
type element-type.  Therefore, unless element-type is STRING-CHAR
or BIT, or a subtype of one of them, this guarantees exactly nothing
about the types of the elements of the vector.

Maybe the element-type argument to these type-specifiers should mean
something else, but that's what it means in Common Lisp as currently
defined.

    VAX LISP has always made use of FUNCTION type specifiers, although
    it has ignored the &REST and &KEY type information.

    There's no reason why someone might not write a function type
    specifier with &REST being a supertype of LIST.  It just can't
    conflict with LIST.

Yes, but I don't see what that could be useful for.

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 that thought
materializing &REST arguments as lists was too inefficient, especially
if you didn't bother to do the (fairly simple) flow analysis needed to
figure out that the list has dynamic extent and doesn't have to be
consed in the heap.  So in your implementation, you made a new
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.  If the
FUNCTION declaration is for the benefit of callers, then the FUNCTION
declaration should be independent of whether the callee is written with
&REST or with &REST2.

 From this I conclude that the &REST type specifier nested within a
FUNCTION declaration shouldn't say anything about lists.