[Chicken-hackers] [RE-POST] Fwd: Re: [PATCH] Disjoint return types with undefined (or *?) mess up "not" typechecks

[Peter Bex]

Hi all,

This is a re-post of an older message that seems to have been forgotten.
This bug still exists.  Original thread can be found here:
http://lists.nongnu.org/archive/html/chicken-hackers/2012-04/msg00053.html

----- Forwarded message from Peter Bex <address@hidden> -----

From: Peter Bex <address@hidden>
Subject: Re: [Chicken-hackers] [PATCH] Disjoint return types with undefined
        (or *?) mess up "not" typechecks
To: address@hidden
Date: Tue, 24 Apr 2012 21:58:53 +0200

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

----- End forwarded message -----

scrutiny.patch
Description: Text document