Re: upgraded-complex-part-type?

[Sam S. <sd...@gn...>]

> * In message <4nn...@rt...>
> * On the subject of "Re: upgraded-complex-part-type?"
> * Sent on 29 Jul 2002 12:34:12 -0400
> * Honorable Raymond Toy <to...@rt...> writes:
>
> I have another question.  What does Clisp think (complex (eql 0))
> really is?  From a discussion on CMUCL, some think this is the empty
> type because there is not complex number whose parts are both the
> integer 0.  Others think it is identical to (complex rational) since
> CMUCL upgrades (eql 0) to rational.
> 
> I think, but don't know for sure, that ACL and Lispworks thinks
> (complex (eql 0)) is the same as (complex rational).  They both think
> (typep #c(0 1) '(complex (eql 0))) is T.

CLHS:

        Every element of this type is a complex whose real part and
        imaginary part are each of type (upgraded-complex-part-type
        typespec). This type encompasses those complexes that can result
        by giving numbers of type typespec to complex.

        (complex type-specifier) refers to all complexes that can result
        from giving numbers of type type-specifier to the function
        complex, plus all other complexes of the same specialized
        representation.

it appears that
        (complex foo bar) ==
        (complex (upgraded-complex-part-type foo)
                 (upgraded-complex-part-type bar))

therefore (typep #c(0 1) '(complex (eql 0))) is
implementation-dependent.

I fixed CLISP to follow this rule.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
cogito cogito ergo cogito sum