issues with hairy COMPLEX types

[Nikodemus Siivola]

ANSI allows types `(COMPLEX ,FOO) to use very hairy values for
FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL
COMPLEX implementation didn't deal with this, and hasn't been
upgraded to do so. (This doesn't seem to be a high priority
conformance problem, since seems hard to construct useful code
where it matters.)

[ partially fixed by CSR in 0.8.17.17 because of a PFD ansi-tests
  report that (COMPLEX RATIO) was failing; still failing on types of
  the form (AND NUMBER (SATISFIES REALP) (SATISFIES ZEROP)). ]

(subtypep 'complex '(and number (satisfies realp) (satisfies zerop))) => NIL, NIL

[Douglas Katzman (dougk)]

this is mixing apples and oranges. We don't in general "see into" types that are expressed as SATISFIES, but if we did, then (and number (satisfies realp)) is <NIL,T>, and so adding in the (satisfies zerop) is too.
However, when adding in the (satisfies zerop) without the (satisfies realp), i.e. doing something that actually cuts off part of the space in a material way that we can't see, that's a different story.
But my point in that there are definitely two different things going on here, one easy, one not so.