We do not check for c99-mandated functions for long float (we only
check for the type). We also check for complex numbers in a separate
function and define ECL_COMPLEX_FLOAT when found.
TYPE= is only used from cmpopt's typep compiler macro which optimizes
atomic complex types by other means. Compound complex types are
handled differently for subtypep and typep (the first relies on
upgraded type and the second relies on the actual types), so we can't
rely in this case on SAFE-CANONICAL-TYPE.
This reverts commit 177ad215ea.
See #493. the issue with typecase must be resolved outside the
subtypep because these numbers indeed have the same internal
representation (see clhs entry for subtypep and typep).
Introduce a configure option controlling the installation and build
the documentation during the build instead of the install phase. Targets
for installation of the html version have also been added.
Fixes#482.
In expansions such as
(loop for i of-type some-type in some-list ...)
we were declaring the type of i to be some-type instead of the
correct (or null some-type).
Only disallow struct redefinition if we are certain about subtype
relationships in slots. Otherwise, we can wrongly disallow struct
redefinitions which don't change slot types.
This leads to compiled code checking types such as (complex
single-float) with a simple call to complexp. While this may
technically be allowed by the ANSI standard, since
upgraded-complex-part-type always returns 'real, it is very confusing
since for example typep correctly discriminates between different
complex part types.
See #468.
The :process keyword argument is used inconsistently for symbols
denoting functions and function objects. Furthermore, it isn't
needed and unused in our own code.
Since we only support vectors with element type size of a byte, we
don't need to check for non-base-strings. Also make sure to set
the byte size of the stream always to a positive value.
Issue comes from the fact that list and symbol types are not
disjoint. Fixes#475.
My personal opinion (to put some rambling in a commit message) is that
having NIL being so many things is a blatant mistake and shouldn't be
picked up for Common Lisp (though many programs would probably break
and it wouldn't be so Common then).
This is as for CLHS section 7.1.2. Error was caused by the fact that
unknown-key was a flag, so if the initarg was NIL, we were assigning
it value NIL, what is also a boolean false. Right now we collect all
invalid initargs in a list, so in case of NIL we'll get (NIL) what is
a generalized boolean true value. Closes#474.
Also add cosmetic fixes with declarations.
