function-type-rest-list-element (really array types)

[Ram@C.CS.CMU.EDU]

    Date: Monday, 29 February 1988  22:54-EST
    From: Jon L White <edsel!jonl at labrea.Stanford.EDU>
    To:   Moon at stony-brook.scrc.symbolics.com
    Re:   function-type-rest-list-element

    re:  . . . CLtL isn't sure whether its data types are portable, fairly 
        abstract types or are ways to find out about implementation details.

    Good point.  In that series of messages a couple of months ago (?) on this 
    issue, there were basically two camps of opinions:

      (1) array types should be completely portable -- hence the exact
          equivalence class of the :element-type specifier must be "remembered"
      (2) "Upgrading" is reasonable, albeit a source of non-portability akin to 
          the fixnum/bignum split;  to do otherwise isn't worth it.

    Both Rob and Walter are espousing position (1), and may not have fully
    noticed that it isn't mandated by CLtL.

Actually I'm not proposing 1, at least as I understand what you are
saying.  My idea is that TYPEP automatically "upgrade" its type
argument to the corresponding "implementation type", i.e. a type
actually supported by the implementation.  This basically amounts to
requiring the programmer (as opposed to the array) the remember the
array element type, but in the absence of a hard semantics for
ARRAY-ELEMENT-TYPE/TYPE-OF, this is the same as requiring that arrays
"remember their element-type".

I think that analogies with the FIXNUM/INTEGER are flawed: FIXNUM has
is a precisely defined concept within the language:
    `(integer ,most-negative-fixnum ,most-positive-fixnum)

Given this definition, a Common Lisp program can have a portable
understanding of what it means to be a FIXNUM.  For example, it is
clear that
    (typep most-negative-fixnum 'fixnum)
is true in any Common Lisp implementation.

With arrays, TYPEP is simply broken.  Unless you use one of the
special element types, BIT, STRING-CHAR or T, TYPEP doesn't mean
anything on arrays.

It seems to me that the FIXNUM issue is kind of like a resource
restriction:
    "This program will only run when a fixnum is at least 16 bits."
is similar to
    "This program will only run when you can have 1e6 element bit-vectors."

In constrast, there is no way to characterize the set of
implementations in which TYPEP will work on arrays.  In fact, there
probably are no such implementations.

    [...] almost everyone agreed that the schizophrenia induced by
    CLtL p45 is a bad idea, and could easily be dropped.  This is the
    part that says "Types can therefore be used for two different
    purposes: declaration and discrimination. ...", and implies as a
    consquence that the result of:

    	(make-array <n> :element-type '<type-spec>)

    will probably not be of typep  (array <type-spec>).

    Not only is this very counterintuitive, but it really doesn't satisfy
    any need that I'm aware of.

Yes, I agree with this.

  Rob