On Sun, Apr 07, 2002 at 11:40:36AM +0100, Christophe Rhodes wrote:
> On Sat, Apr 06, 2002 at 11:18:20AM -0600, William Harold Newman wrote:
> > I've attached the updated patch. It still doesn't handle
> > (SUBTYPEP 'ATOM 'NIL) but it seems to get everything else right.
> > (And probably tomorrow I'll take a shot at the ATOM-vs.-NIL case.)
> I like it :) Thanks.
> As for (subtypep 'ATOM 'NIL), the potential confusion will arise because
> some hairy types [say '(SATISFIES FOO), with
> (defun foo (x) (and (numberp x) (> x 2) (evenp x) (primep x)))], are
> equivalent to the NIL type without the compiler being sufficiently smart
> to notice. At a guess, the similar call-next-method ish change will
> work in the NAMED :COMPLEX-SUBTYPEP-ARG2 method as for the UNION method.
Everything (i.e. all the commented-out tests in tests/type.impure.lisp,
and the type system CMUCLisms in clocc-ansi-test) seems to work now. My
draft changelog entry looks like
making SUBTYPEP work better on ATOM (which is tricky because
it contains a naughty NOT, and which CMU CL SUBTYPEP
mostly punted on in a way that ANSI forbids), in a way
inspired by but different from CSR "get atom subtype"
...Do CALL-NEXT-METHOD, more or less, when before UNION-TYPE's
COMPLEX-SUBTYPEP-ARG2 would return NIL NIL.
...reviewed all COMPLEX-SUBTYPEP-ARG1 methods adding defensive
code to handle the new TYPE2 args that they may see now
...hacked HAIRY-COMPLEX-SUBTYPEP-ARG1 type method so that it
understands that ATOM isn't a subtype of any built-in
type except T and ATOM itself
(After changes above, we can deal with most of the cases that
CSR's patch did, but not yet (SUBTYPEP 'ATOM NIL). I
posted the code to sbcl-devel, got the green flag from
CSR, and forged ahead.)
...factored out the CALL-NEXT-METHOD-ish logic used in the
UNION-TYPE COMPLEX-SUBTYPEP-ARG2 method so that it can
be used in other COMPLEX-SUBTYPEP-ARG2 methods
...used the CALL-NEXT-METHOD-ish logic not only for NAMED
(to deal with (SUBTYPEP 'ATOM NIL)) but also in other
COMPLEX-SUBTYPEP-ARG2 methods which looked as though
they could (or just might) benefit from it
...The precondition "this will never be called with a hairy
type as TYPE2" in !HAS-SUPERCLASSES-COMPLEX-SUBTYPEP-ARG1
is now broken. (It would've been easier to figure this
out if the precondition had been expressed as an
assertion instead of just a comment. Oh well...)
...The SATISFIES FBOUNDP types floating around (mostly in pprint)
aren't really very good types in the sense of ANSI CL,
because they're not in general fixed sets, but can
change with time, so when the compiler attempts
reasonable tests and optimizations on them, things
will get confused. So convert them to explicit calls
to FBOUNDP, and/or just punt them somehow.
?? ...Factor out the "type can conceal other types" predicate
in general. (Replace FLET SIMPLE-CTYPE?, and various
expressions involving HAIRY-TYPE-P, with a
CTYPE-CAN-CONCEAL-OTHER-TYPES? structure slot accessor,
and set that slot for HAIRY and COMPOUND CTYPEs.)
(Remove ridiculous #+(OR SBCL CMU) in my local CLOCC "ANSI"
test cases :TYPE-LEGACY-405, :TYPE-LEGACY-410, and
:TYPE-LEGACY-437. Otherwise we *fail* those tests now
that we have ANSI behavior! What were the CLOCC guys
Now bug #58 is gone too. Cool!
where the ?? item hasn't been done yet. The current state of the
patch is attached.
If it continues to look right to me and everyone else, I'll
probably do the "factor out" bit tomorrow and then commit it.
William Harold Newman <william.newman@...>
"Just opened Christmas pressie from Sauron. Pretty, pretty, pretty,
pretty ring!" -- http://home.nyu.edu/~amw243/diaries/wraith.html
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C