[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: |
Felix |
Subject: |
Re: [Chicken-hackers] [PATCH] Disjoint return types with undefined (or *?) mess up "not" typechecks |
Date: |
Tue, 24 Apr 2012 09:23:09 +0200 (CEST) |
From: Peter Bex <address@hidden>
Subject: [Chicken-hackers] [PATCH] Disjoint return types with undefined (or *?)
mess up "not" typechecks
Date: Sun, 22 Apr 2012 19:22:19 +0200
> Hi all,
>
> While debugging the other scrutinizer issue with empty lists, I found
> this one:
>
> (define (some-proc x y) (if (string->number y) (set-cdr! x x) x))
> (assert (null? (some-proc (list) "invalid number syntax")))
>
> This fails, because there's an early return in simplify in simplify-type
> in scrutinizer.scm which gets triggered whenever it encounters a
> "undefined" type. This means that a type of '(or * undefined) gets
> simplified to 'undefined, which means it matches the '(not null)
> specialisation for null (this is implicit, since it's defined as
> a predicate for the null type). Of course that's invalid as the
> string->number check is false for Y = "invalid number syntax",
> so SOME-PROC will simply return the X value it is passed, which
> is null.
>
> The attached patch is a big one, but it simply removes the early
> returns; the rest is just due to the indentation change.
>
> I wasn't 100% sure whether the early return on * is bad too, but
> it seems safer to omit any early returns.
"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 "*".
cheers,
felix