(typep 3 'complex) => t

[Rob MacLachlan <RAM@C.CS.CMU.EDU>]

There is a bit of type sysem lossage that I noticed lately which is
unrelated to the TYPE-OF discussion.  My realization is that RATIONAL
is a subtype of (COMPLEX NUMBER), since according to p47, "...this
type encompasses those complex numbers that can result from giving
numbers of the specified type to the function COMPLEX."  Of course,
(COMPLEX 3 0) => 3.

This interpretation depends on the meaning of the phrase "complex
numbers" in the above passage.  This interperetation does not hold if
"complex number" in the above passage means a number where
(NOT (EQL (IMAGPART number) 0)).

Due to the rule for complex canonicalization, it makes no sense to
require the non-0 imagpart, since it makes the declaration useless
for complex numbers with rational components.

It seems that there is an analogy between COMPLEX and RATIONAL due to
the similarity of the complex and rational canonicalization rules.  3
is a rational, since a rational can be canonicalized to an integer.
Similarly, 3 is a complex since a complex can be canonicalized to an
integer.  The real problem is that there is no type which is to
COMPLEX as RATIO is to RATIONAL, i.e. a type that represents complex
numbers that have not been canonicalized.

If my intepretation is correct, then the COMPLEX type with no
component type specified is effectively equivalent to 
(AND NUMBER (NOT FLOAT)).  This makes the COMPLEXP function fairly
useless if it continues to be equivalent to (TYPEP ... 'COMPLEX).

There is some mumbling about "may be different for declaration and
discrimination" in the definition of the COMPLEX type specifier, but
close reading suggests that this is irrelevant to the issue at hand,
since it is really attempting to say that COMPLEX types are similar to
ARRAY types in that the implementation has freedom in choosing
component type specializations.  Comparison with the similar hemming
and hawing in the ARRAY definition supports this conclusion.

  Rob