Re: [Sbcl-devel] the (COMPLEX type) type

[Christophe R. <cs...@ca...>]

Bruno Haible <br...@cl...> writes:

> The type specifier (COMPLEX type) should, according to ANSI CL's description
> (HyperSpec/Body/syscla_complex.html), only depend on
> (upgraded-complex-element-type type).
> [...]
> [Taken from clisp's type.tst]
> Platform: Linux/x86. SBCL version: 0.8.9 compiled by CMUCL 18e.

Thank you for the report.  I believe I've fixed this (properly, this
time; those interested in SBCL history may wish to know that the
broken behaviour was almost entirely my fault in the first place, and
dates back to the halcyon days of pre7) in sbcl-0.8.10.9, but I'm
still uncertain about details; if there are still observable oddities,
we want to know about them. :-)

In particular, I think UPGRADED-COMPLEX-PART-TYPE is fairly bogus, in
that there is no sensible answer to
  (upgraded-complex-part-type '(eql 0))
or to
  (upgraded-complex-part-type '(or single-float double-float));
the first because the type lattice upgrading requirement is
inconsistent with the meaning of the type (COMPLEX (EQL 0)), and the
second because in fact the complex specialized representations don't
form a lattice at all, because there is no complex representation that
can hold all objects of type REAL.

Cheers,

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)