chicken-hackers
[Top][All Lists]
Advanced

[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

Attachment: scrutiny-undefined.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]