Alexey Dejneka <adejneka@...> writes:
>> Presumably it's related to the changes in type representation, but the
>> way that the presence of the FORMAT makes it compile successfully even
>> with the new type representation makes me suspect that it's not so
>> much a bug in the new type representation as a latent compiler bug
>> which is exercised by the new representation.
> Yes, you are right. I've applied a patch, it will work for some
> time... Until somebody write correct methods for intersection and
> union of function types.
Thanks. Yeah, it's an ugly problem...
> BTW, Paul's tests have revealed another problem: 0.8alpha.0.4 compiler
> fails on (MULTIPLE-VALUE-LIST (VALUES)) treating FUNCTION class as
... I've papered over this one in 0.8alpha.0.7. Thanks for raising
it. There are likely to be other instances of this general confusion
between the FUNCTION class and FUN-TYPEs; a potential refactor is to
protect areas like the one I've just patched by something like
(let ((type (just-the-fun-type-information type)))
where JUST-THE-FUN-TYPE-INFORMATION can deal with extracting the
relevant bits from not only the FUNCTION class but also potentially
scary things such as (AND GENERIC-FUNCTION (FUNCTION (T) INTEGER)).
If anyone would like to do this, feel free, as I probably won't be
able to get round to this for a little while; I'd rather like instead
to polish off the "build from clisp" problem, which will entail going
deeply into MAKE-LOAD-FORM to let us refer to -0.0...
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)