Comment 8 for bug 1733400

Stas Boukarev <email address hidden> writes:

> I don't think that there's actually any ambiguity anymore.
> "(typep object '(complex type-specifier)) returns true for all complex
> numbers that can result from giving numbers of type type-specifier to
> the function
> complex, plus all other complex numbers of the same specialized
> representation. Both the real and the imaginary parts of any such
> complex number must
> satisfy:
> (typep realpart 'type-specifier)
> (typep imagpart 'type-specifier)"

Oh wow, I had completely not seen this on the page for TYPEP. I'd been
assuming that everything I needed was on the System Class COMPLEX page

> None of the sentences contradict each other, but when you combine them
> all you get a restricted space of (and (typep realpart
> 'type-specifier) (typep imagpart 'type-specifier))

I now think that the two sentences you've quoted above do contradict
each other, except if (upgraded-complex-part-type X) = X for all X.
Otherwise the upgrading brings in complexes (by the first sentence)
whose components don't match the type specifier (contradicting the
second sentence)

Maybe a trivial upgraded-complex-part-type is what we need to do. It
wouldn't be the worst outcome, I suppose, but it's not great. I'm
pretty sure the standardizers weren't thinking about exotic values of X
but the text is what it is.

> it was probably worded that way to handle (complex float), and it's
> even stated that array and complex types are handled differently.
> "The small differences between the subtypep specification for the
> array and complex types are necessary because there is no creation
> function for complexes which allows the specification of the resultant
> part type independently of the actual types of the parts."

This is talking about subtypep, not typep. I know they're related... I
agree that the difference looks like it's intending that (complex real)
is OK and means the union of all complexes (and (complex float) is the
union of all floaty complexes).