Re: [racket-dev] Catching the undefined value

2014-04-19 Thread Gustavo Massaccesi
I found another problem with the optimizer and the new undefined behavior. (letrec ([x (if #t 8 x)]) x) ;==8 I also consider this correct in a strange sense :). Gustavo Welcome to Racket v6.0.1.4. (letrec ([x x]) x) x: undefined; cannot use before initialization context...: C:\Program

Re: [racket-dev] Catching the undefined value

2014-04-19 Thread Robby Findler
These seem correct to me. What were you expecting (and why?). Robby On Saturday, April 19, 2014, Gustavo Massaccesi gust...@oma.org.ar wrote: I found another problem with the optimizer and the new undefined behavior. (letrec ([x (if #t 8 x)]) x) ;==8 I also consider this correct in a

Re: [racket-dev] Catching the undefined value

2014-04-19 Thread Gustavo Massaccesi
(letrec ([x (if #t 8 x)]) x) ;==8 It was a mistake. I thought that the “x: undefined; ...” error was an expansion-time error, not a run-time error. (I expected an error, because the x in the else part is “undefined”, even if it’s never accessed.) Gustavo On Sat, Apr 19, 2014 at 1:02 PM,

Re: [racket-dev] Catching the undefined value

2014-04-19 Thread Robby Findler
Ah. There are other approaches to this problem that result in compile-time errors for such programs. Maybe the TR guys will adopt one or figure out a better one! But for regular ole Racket, we're stuck with a runtime error, I'm afraid. Robby On Sat, Apr 19, 2014 at 2:04 PM, Gustavo Massaccesi

Re: [racket-dev] Catching the undefined value

2014-04-19 Thread Matthias Felleisen
Morally TR ought to report the type of this x as empty set, which would inform you that the else branch is unreachable: (letrec ([x : Integer (if #t 0 x)]) x) One day we may wish to augment syntax check in TR so that programmers can read of the reconstructed types for interior

Re: [racket-dev] Catching the undefined value

2014-04-19 Thread Sam Tobin-Hochstadt
On Sat, Apr 19, 2014 at 4:45 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Morally TR ought to report the type of this x as empty set, which would inform you that the else branch is unreachable: (letrec ([x : Integer (if #t 0 x)]) x) I don't think that's right -- the else branch is

Re: [racket-dev] Catching the undefined value

2014-04-19 Thread Matthias Felleisen
On Apr 19, 2014, at 5:57 PM, Sam Tobin-Hochstadt wrote: On Sat, Apr 19, 2014 at 4:45 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Morally TR ought to report the type of this x as empty set, which would inform you that the else branch is unreachable: (letrec ([x : Integer (if #t 0

Re: [racket-dev] Catching the undefined value

2014-04-16 Thread Matthias Felleisen
Ah, too bad: pkgs/racket-pkgs/racket-test/tests/racket/optimize.rktl ~~~ --- OLD/pkgs/racket-pkgs/racket-test/tests/racket/optimize.rktl +++ NEW/pkgs/racket-pkgs/racket-test/tests/racket/optimize.rktl @@ -3416,5 +3416,16 @@

Re: [racket-dev] Catching the undefined value

2014-04-16 Thread Matthew Flatt
At Wed, 16 Apr 2014 09:02:44 -0400, Matthias Felleisen wrote: On Apr 15, 2014, at 9:29 PM, Asumu Takikawa as...@ccs.neu.edu wrote: On 2014-04-15 18:13:31 -0400, claire alvis wrote: The push below includes changes to letrec expressions, internal definitions, units, classes, and certain

Re: [racket-dev] Catching the undefined value

2014-04-16 Thread Asumu Takikawa
On 2014-04-15 21:19:16 -0600, Neil Toronto wrote: Does TR not having to worry about #undefined mean that the following program will typecheck? #lang typed/racket (define-type (Lazy-Listof A) (Promise (Pair A (Lazy-Listof A (let () (define: lazy-zeros : (Lazy-Listof Zero)

Re: [racket-dev] Catching the undefined value

2014-04-15 Thread Asumu Takikawa
On 2014-04-15 18:13:31 -0400, claire alvis wrote: The push below includes changes to letrec expressions, internal definitions, units, classes, and certain ill-formed shared expressions so that they no longer leak the `undefined' value. This is great! (especially happy that TR, even with

Re: [racket-dev] Catching the undefined value

2014-04-15 Thread Neil Toronto
On 04/15/2014 07:29 PM, Asumu Takikawa wrote: On 2014-04-15 18:13:31 -0400, claire alvis wrote: The push below includes changes to letrec expressions, internal definitions, units, classes, and certain ill-formed shared expressions so that they no longer leak the `undefined' value. This is