[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(typep 3 'complex) => t

    But under my interpretation, (DECLARE (COMPLEX FIXNUM)) would be
much more useful, since the it would be a declaration that the user
could reasonably make, yet would give the system the useful
information that both the realpart and imagpart are fixnums.  In this
case, the compiler could reasonably store the realpart and imagpart as
separate fixnums, and would only have to canonicalize them when it is
forced to pointerize the number.

    In the case of a float component type, there is no difference in
the results of the two interpretations, since complex float types are
not canonicalized.  I think that the definition of complex rational
types was not thoroughly thought out due to their novelty.

    If there were no RATIONAL type, then it would make sense to argue
that COMPLEX should be useless by analogy with RATIO, but if we are
trying to provide a useful type system, then it is silly.

    Perhaps COMPLEX should remain what everyone thought it was, but
there is definitely a need for the type that I think COMPLEX ought to
be.  I think that there is a strong argument that my interpretation
should get the "good" name, since it is what people will usually want
to use.