Types in CL

[Jon L White <edsel!jonl@labrea.stanford.edu>]

CLtL, p45, clearly permits the "upgrade" for arrays -- namely that a request
for an array of element-type T2 is satisified by an array of element-type
T2*, where (SUBTYPEP T2 T2*) and where T2* is the "least" such type.

For example, if an implementation only has "general" arrays and "8-bit"
arrays, then 
	(MAKE-ARRAY <n> :ELEMENT-TYPE '(UNSIGNED-BYTE 5))
could legitimately return an array of element-type '(UNSIGNED-BYTE 8).
But it would not be satisfied by a "general" type array, since there is 
a kind of array with more specialized element-type that can hold 
(unsigned-byte 5)'s.

Note that  (UNSIGNED-BYTE 5)  is *not* even equal-typep to  (UNSIGNED-BYTE 8).
[And certainly not EQ!]

However, the problem with TYPEP that you [Moon] describe is clearly one of 
the most serious flaws in the CL design -- that a variable declared to be 
of type 
		<certain-type>
and all of whose objects are created in accord with that type-specifier,
still may have *none* of its values ever satisfied by the TYPEP predicate
with that type-specifier.

We have received repeated bug reports from users whenever

   (TYPEP (MAKE-ARRAY <n> :ELEMENT-TYPE '<certain-type>)
          '(ARRAY <certain-type> *))

is false.  Many of us have reverted to treating this part of CLtL as
an unworkable braino with no particular utility.  If you or anyone else
cares to defend the typep warp, I'd be curious to hear about it.

The more generous interpretation of array element-type upgrading would 
permit the two array type specifiers
	(ARRAY (UNSIGNED-BYTE 5) *) 
	(ARRAY (UNSIGNED-BYTE 8) *)
to be equal-typep [in the above hypothetical implementation], even though 
the two element types
	(UNSIGNED-BYTE 5)
	(UNSIGNED-BYTE 8)
are not equal-typep.


-- JonL --