[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH] Disjoint return types with undefined (or *
From: |
Peter Bex |
Subject: |
Re: [Chicken-hackers] [PATCH] Disjoint return types with undefined (or *?) mess up "not" typechecks |
Date: |
Tue, 24 Apr 2012 21:58:53 +0200 |
User-agent: |
Mutt/1.4.2.3i |
On Tue, Apr 24, 2012 at 09:23:09AM +0200, Felix wrote:
> "undefined" is intended to be contagious, so the early return has a
> reason. The "(not null)" should actually not match "undefined" -
> undefined is undefined and no assumptions should be made about the
> value it may represent. Also, any union type containing "*" should
> be generalized to "*".
I guess undefined is never supposed to match anything (except, perhaps,
itself). How about the attached patch, then?
I had to move up the (eq? t2 '*) check because otherwise you get
warnings like the following:
Warning: at toplevel:
assignment of value of type `(procedure ##sys#void (#!rest) *)' to toplevel
variable `##sys#void' does not match declared type `(procedure void (#!rest *)
undefined)'
Also having one '* check before the NOT check and one after doesn't
seem right. I can't think of an example or test that would trigger
failure or success in these differing cases though.
Furthermore, I was having some problems in my first attempts but then
I found out that the first two specializations for equal=? were just
wrong; they had the condition (or fixnum symbol char eof null undefined),
but simplify-type will just collapse that to a single 'undefined like
you said. That means these specializations were never applied!
Also, if undefined is taken out, the specialization is incorrect; if
one argument is a fixnum and the other a flonum, it would end up
comparing with eq?, but that's always #f (we have a test in
library-tests that failed when I did that). Hopefully the attached
patch fixes that properly, too. If the scrutiny fixed isn't accepted,
please consider pushing the types.db part of the patch anyway.
Cheers,
Peter
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth
scrutiny-undefined.patch
Description: Text document