function-type-rest-list-element

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

re: The discussion of ARRAY type specifiers on p.45 is talking about the
    permissible and expected representations of arrays, not of the possible
    types of the elements of such arrays.  So what's on p.45 doesn't make
    anything clear here.

Well, it's true that CLtL pp45-47 are anything but "clear".  But what
Dave is saying (I think) is that a number of wizards have groveled over 
those pages and all agree that there is only one interpretation of them
consistent with the rest of CLtL.  And that interpretaton is at variance 
with your comments:

    Setting an element of A to be something that's not of type FOO is
    an error.  The representation might allow it, because the new value
    might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it
    correct.  It's just a matter of whether the array happened to
    remember the precise type it was created with.

Perhaps the clearest indicator that CLtL really isn't saying this is
found on p291, under the description of ARRAY-ELEMENT-TYPE.  Note how
this section really is "clear" that an array made by
	(make-array 5 :element-type '(mod 5))
may legitimately have an element stored into it that is of type (mod 8)
but not necessarily of type (mod 5).

There was a rather lengthy interchange on this whole topic (about two
months ago?) on the Common-Lisp@SU-AI list.  One proposal was to require
implementations to conform with your comments quoted above, but it 
certainly didn't seem to have unanimous approval.  Someone pointed out
that all current implementations do a form of element-type "upgrading" 
on at least some :element-type specifiers.  Try it in VAXLISP, for example,
with (SIGNED-BYTE 5) instead of (MOD 5) and see what you get.

If you don't have archives of that mail interchange, I'll can arrange to 
send you a copy personally.


-- JonL --