function-type-rest-list-element

[Jon L White <edsel!jonl@labrea.Stanford.EDU>]

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.  I myself forget the horrible
intricacies of array types from time to time.  Worse yet, I waffle between
preferring (1) and (2) depending on the latest "arguments" for one or
the other.  To me, this indicates that an easy solution isn't at hand.

While there seemed to be no clear consensus on saying that types "must be" 
portable, 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.  At first blush, it might seem to be a
corollary of "upgrading"; but it isn't at all.
  

-- JonL --