[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Types in CL
- To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu, labrea!barmar%Think.COM@labrea.stanford.edu
- Subject: Types in CL
- From: Jon L White <email@example.com>
- Date: Tue, 29 Dec 87 11:57:10 PST
- Cc: labrea!common-lisp%SAIL@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"
(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
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
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
are not equal-typep.
-- JonL --