the array type mess....

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

I agree with your points about definitional versus implementation types.

Is it a correct summary of your comments that you want the distinction
(CLtL p.45) between declaration and discrimination to be eliminated,
with TYPEP being changed to treat array type specifiers in precisely the
way that CLtL calls "for declaration"?

To say the same thing in Lisp:
(TYPEP array '(ARRAY type *))
is currently defined to be equivalent to:
(AND (TYPEP array '(ARRAY * *))
     (SUBTYPEP (ARRAY-ELEMENT-TYPE array) 'type)
     (SUBTYPEP 'type (ARRAY-ELEMENT-TYPE array)))
I don't think you're proposing to make it equivalent to:
(AND (TYPEP array '(ARRAY * *))
     (SUBTYPEP 'type (ARRAY-ELEMENT-TYPE array)))
but rather to make it equivalent to:
(LET ((TYPE1 (IMPLEMENTATION-DEPENDENT-ARRAY-ELEMENT-TYPE 'type)))
  (AND (TYPEP array '(ARRAY * *))
       (SUBTYPEP (ARRAY-ELEMENT-TYPE array) TYPE1)
       (SUBTYPEP TYPE1 (ARRAY-ELEMENT-TYPE array))))
where an inefficient but portable definition is:
(DEFUN IMPLEMENTATION-DEPENDENT-ARRAY-ELEMENT-TYPE (TYPE)
  (ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE TYPE))
Is this accurate?

Let's look at the various things (TYPEP array '(ARRAY TYPE *)) => T
might mean, and what they mean with that proposal:

(TYPEP x TYPE) means x can safely be stored into the array:		yes
(TYPEP x TYPE) is true for all current elements of the array:		no
(TYPEP x TYPE) is true for all future elements of the array:		no
(NOT (TYPEP x TYPE)) means x cannot be safely stored into the array:	no

with CLtL's current definition of TYPEP:

(TYPEP x TYPE) means x can safely be stored into the array:		yes
(TYPEP x TYPE) is true for all current elements of the array:		yes
(TYPEP x TYPE) is true for all future elements of the array:		yes
(NOT (TYPEP x TYPE)) means x cannot be safely stored into the array:	yes

So what we're saying is that for the latter two tests you must use
ARRAY-ELEMENT-TYPE, and for the second test you must look at the
actual contents of the array.  That's probably okay, especially
when one considers that in CLtL (TYPEP array '(ARRAY TYPE *)) very
rarely returns T, and for most values of TYPE it is implementation
dependent.

(ARRAY T) remains a proper subset of (ARRAY *), and (STRING size) remains
an abbreviation for (ARRAY STRING-CHAR (size)), for the simple reason
that CLtL requires (IMPLEMENTATION-DEPENDENT-ARRAY-ELEMENT-TYPE 'STRING-CHAR)
=> STRING-CHAR (or a type specifier equivalent to STRING-CHAR).

Should the IMPLEMENTATION-DEPENDENT-ARRAY-ELEMENT-TYPE function I have
postulated as hidden inside TYPEP be made available as a standard function?

An interesting comment on all this is that we are implicitly assuming
that an implementation's spectrum of specialized array types is independent
of the size, number of dimensions, indirectness, or adjustability of the
array.  This seems unlikely to be true of all implementations.  I don't
know how to fix this deficiency.

Someone should write this up in Cleanup form and thus give us all
a chance to think about it more deeply.