Re: [racket-dev] Catching the undefined value
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 Files\Racket-6.0.1.4\collects\racket\private\misc.rkt:87:7 (letrec ([x 5]) x) 5 (letrec ([x (if #t 8 x)]) x) 8 (letrec ([x (if #f 8 x)]) x) x: undefined; cannot use before initialization context...: C:\Program Files\Racket-6.0.1.4\collects\racket\private\misc.rkt:87:7 On Wed, Apr 16, 2014 at 10:09 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: 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 @@ (read (open-input-bytes (get-output-bytes o)) ;; +;; Check that an unsufe opertion's argument is +;; not optimized away if it's a use of +;; a variable before definition: + +(err/rt-test (let () + (unsafe-fx+ x 1) + (define x 3) + x) + exn:fail:contract:variable?) + +;; :-) On Apr 16, 2014, at 9:02 AM, Matthias Felleisen matth...@ccs.neu.edu 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 ill-formed shared expressions so that they no longer leak the `undefined' value. This is great! (especially happy that TR, even with classes, doesn't have to worry about #undefined anymore) BTW, I found this weird behavior: Welcome to Racket v6.0.1.3. - (require racket/unsafe/ops) - (let () (+ x 3) (define x 3) 5) ; x: variable used before its definition [,bt for context] - (let () (unsafe-fx+ x 3) (define x 3) 5) 5 I consider this correct in a strange sense. Interestingly enough, (let () (displayln (unsafe-fx+ x 3)) (define x 3) 5) x: variable used before its definition context...: /Users/matthias/plt/racket/collects/racket/private/misc.rkt:87:7 which is good too. I don't know how Claire and Matthew did this, but it's good :-) _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Catching the undefined value
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 strange sense :). Gustavo Welcome to Racket v6.0.1.4. (letrec ([x x]) x) x: undefined; cannot use before initialization context...: C:\Program Files\Racket-6.0.1.4\collects\racket\private\misc.rkt:87:7 (letrec ([x 5]) x) 5 (letrec ([x (if #t 8 x)]) x) 8 (letrec ([x (if #f 8 x)]) x) x: undefined; cannot use before initialization context...: C:\Program Files\Racket-6.0.1.4\collects\racket\private\misc.rkt:87:7 On Wed, Apr 16, 2014 at 10:09 AM, Matthias Felleisen matth...@ccs.neu.edu javascript:; wrote: 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 @@ (read (open-input-bytes (get-output-bytes o)) ;; +;; Check that an unsufe opertion's argument is +;; not optimized away if it's a use of +;; a variable before definition: + +(err/rt-test (let () + (unsafe-fx+ x 1) + (define x 3) + x) + exn:fail:contract:variable?) + +;; :-) On Apr 16, 2014, at 9:02 AM, Matthias Felleisen matth...@ccs.neu.edujavascript:; wrote: On Apr 15, 2014, at 9:29 PM, Asumu Takikawa as...@ccs.neu.edujavascript:; 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 great! (especially happy that TR, even with classes, doesn't have to worry about #undefined anymore) BTW, I found this weird behavior: Welcome to Racket v6.0.1.3. - (require racket/unsafe/ops) - (let () (+ x 3) (define x 3) 5) ; x: variable used before its definition [,bt for context] - (let () (unsafe-fx+ x 3) (define x 3) 5) 5 I consider this correct in a strange sense. Interestingly enough, (let () (displayln (unsafe-fx+ x 3)) (define x 3) 5) x: variable used before its definition context...: /Users/matthias/plt/racket/collects/racket/private/misc.rkt:87:7 which is good too. I don't know how Claire and Matthew did this, but it's good :-) _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Catching the undefined value
(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, Robby Findler ro...@eecs.northwestern.edu wrote: 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 strange sense :). Gustavo Welcome to Racket v6.0.1.4. (letrec ([x x]) x) x: undefined; cannot use before initialization context...: C:\Program Files\Racket-6.0.1.4\collects\racket\private\misc.rkt:87:7 (letrec ([x 5]) x) 5 (letrec ([x (if #t 8 x)]) x) 8 (letrec ([x (if #f 8 x)]) x) x: undefined; cannot use before initialization context...: C:\Program Files\Racket-6.0.1.4\collects\racket\private\misc.rkt:87:7 On Wed, Apr 16, 2014 at 10:09 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: 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 @@ (read (open-input-bytes (get-output-bytes o)) ;; +;; Check that an unsufe opertion's argument is +;; not optimized away if it's a use of +;; a variable before definition: + +(err/rt-test (let () + (unsafe-fx+ x 1) + (define x 3) + x) + exn:fail:contract:variable?) + +;; :-) On Apr 16, 2014, at 9:02 AM, Matthias Felleisen matth...@ccs.neu.edu 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 ill-formed shared expressions so that they no longer leak the `undefined' value. This is great! (especially happy that TR, even with classes, doesn't have to worry about #undefined anymore) BTW, I found this weird behavior: Welcome to Racket v6.0.1.3. - (require racket/unsafe/ops) - (let () (+ x 3) (define x 3) 5) ; x: variable used before its definition [,bt for context] - (let () (unsafe-fx+ x 3) (define x 3) 5) 5 I consider this correct in a strange sense. Interestingly enough, (let () (displayln (unsafe-fx+ x 3)) (define x 3) 5) x: variable used before its definition context...: /Users/matthias/plt/racket/collects/racket/private/misc.rkt:87:7 which is good too. I don't know how Claire and Matthew did this, but it's good :-) _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Catching the undefined value
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 gust...@oma.org.ar wrote: (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, Robby Findler ro...@eecs.northwestern.edu wrote: 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 strange sense :). Gustavo Welcome to Racket v6.0.1.4. (letrec ([x x]) x) x: undefined; cannot use before initialization context...: C:\Program Files\Racket-6.0.1.4\collects\racket\private\misc.rkt:87:7 (letrec ([x 5]) x) 5 (letrec ([x (if #t 8 x)]) x) 8 (letrec ([x (if #f 8 x)]) x) x: undefined; cannot use before initialization context...: C:\Program Files\Racket-6.0.1.4\collects\racket\private\misc.rkt:87:7 On Wed, Apr 16, 2014 at 10:09 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: 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 @@ (read (open-input-bytes (get-output-bytes o)) ;; +;; Check that an unsufe opertion's argument is +;; not optimized away if it's a use of +;; a variable before definition: + +(err/rt-test (let () + (unsafe-fx+ x 1) + (define x 3) + x) + exn:fail:contract:variable?) + +;; :-) On Apr 16, 2014, at 9:02 AM, Matthias Felleisen matth...@ccs.neu.edu 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 ill-formed shared expressions so that they no longer leak the `undefined' value. This is great! (especially happy that TR, even with classes, doesn't have to worry about #undefined anymore) BTW, I found this weird behavior: Welcome to Racket v6.0.1.3. - (require racket/unsafe/ops) - (let () (+ x 3) (define x 3) 5) ; x: variable used before its definition [,bt for context] - (let () (unsafe-fx+ x 3) (define x 3) 5) 5 I consider this correct in a strange sense. Interestingly enough, (let () (displayln (unsafe-fx+ x 3)) (define x 3) 5) x: variable used before its definition context...: /Users/matthias/plt/racket/collects/racket/private/misc.rkt:87:7 which is good too. I don't know how Claire and Matthew did this, but it's good :-) _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Catching the undefined value
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 expressions. -- Matthias On Apr 19, 2014, at 3:26 PM, Robby Findler wrote: 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 gust...@oma.org.ar wrote: (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, Robby Findler ro...@eecs.northwestern.edu wrote: 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 strange sense :). Gustavo Welcome to Racket v6.0.1.4. (letrec ([x x]) x) x: undefined; cannot use before initialization context...: C:\Program Files\Racket-6.0.1.4\collects\racket\private\misc.rkt:87:7 (letrec ([x 5]) x) 5 (letrec ([x (if #t 8 x)]) x) 8 (letrec ([x (if #f 8 x)]) x) x: undefined; cannot use before initialization context...: C:\Program Files\Racket-6.0.1.4\collects\racket\private\misc.rkt:87:7 On Wed, Apr 16, 2014 at 10:09 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: 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 @@ (read (open-input-bytes (get-output-bytes o)) ;; +;; Check that an unsufe opertion's argument is +;; not optimized away if it's a use of +;; a variable before definition: + +(err/rt-test (let () + (unsafe-fx+ x 1) + (define x 3) + x) + exn:fail:contract:variable?) + +;; :-) On Apr 16, 2014, at 9:02 AM, Matthias Felleisen matth...@ccs.neu.edu 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 ill-formed shared expressions so that they no longer leak the `undefined' value. This is great! (especially happy that TR, even with classes, doesn't have to worry about #undefined anymore) BTW, I found this weird behavior: Welcome to Racket v6.0.1.3. - (require racket/unsafe/ops) - (let () (+ x 3) (define x 3) 5) ; x: variable used before its definition [,bt for context] - (let () (unsafe-fx+ x 3) (define x 3) 5) 5 I consider this correct in a strange sense. Interestingly enough, (let () (displayln (unsafe-fx+ x 3)) (define x 3) 5) x: variable used before its definition context...: /Users/matthias/plt/racket/collects/racket/private/misc.rkt:87:7 which is good too. I don't know how Claire and Matthew did this, but it's good :-) _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Catching the undefined value
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 unreachable, but that's not a fact about the type of `x` in particular, any more than it's a fact about the type of `+` if it was used in the else branch. One day we may wish to augment syntax check in TR so that programmers can read of the reconstructed types for interior expressions. Definitely. Sam On Apr 19, 2014, at 3:26 PM, Robby Findler wrote: 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 gust...@oma.org.ar wrote: (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, Robby Findler ro...@eecs.northwestern.edu wrote: 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 strange sense :). Gustavo Welcome to Racket v6.0.1.4. (letrec ([x x]) x) x: undefined; cannot use before initialization context...: C:\Program Files\Racket-6.0.1.4\collects\racket\private\misc.rkt:87:7 (letrec ([x 5]) x) 5 (letrec ([x (if #t 8 x)]) x) 8 (letrec ([x (if #f 8 x)]) x) x: undefined; cannot use before initialization context...: C:\Program Files\Racket-6.0.1.4\collects\racket\private\misc.rkt:87:7 On Wed, Apr 16, 2014 at 10:09 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: 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 @@ (read (open-input-bytes (get-output-bytes o)) ;; +;; Check that an unsufe opertion's argument is +;; not optimized away if it's a use of +;; a variable before definition: + +(err/rt-test (let () + (unsafe-fx+ x 1) + (define x 3) + x) + exn:fail:contract:variable?) + +;; :-) On Apr 16, 2014, at 9:02 AM, Matthias Felleisen matth...@ccs.neu.edu 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 ill-formed shared expressions so that they no longer leak the `undefined' value. This is great! (especially happy that TR, even with classes, doesn't have to worry about #undefined anymore) BTW, I found this weird behavior: Welcome to Racket v6.0.1.3. - (require racket/unsafe/ops) - (let () (+ x 3) (define x 3) 5) ; x: variable used before its definition [,bt for context] - (let () (unsafe-fx+ x 3) (define x 3) 5) 5 I consider this correct in a strange sense. Interestingly enough, (let () (displayln (unsafe-fx+ x 3)) (define x 3) 5) x: variable used before its definition context...: /Users/matthias/plt/racket/collects/racket/private/misc.rkt:87:7 which is good too. I don't know how Claire and Matthew did this, but it's good :-) _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Catching the undefined value
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 x)]) x) I don't think that's right -- the else branch is unreachable, but that's not a fact about the type of `x` in particular, any more than it's a fact about the type of `+` if it was used in the else branch. Correct! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Catching the undefined value
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 @@ (read (open-input-bytes (get-output-bytes o)) ;; +;; Check that an unsufe opertion's argument is +;; not optimized away if it's a use of +;; a variable before definition: + +(err/rt-test (let () + (unsafe-fx+ x 1) + (define x 3) + x) + exn:fail:contract:variable?) + +;; :-) On Apr 16, 2014, at 9:02 AM, Matthias Felleisen matth...@ccs.neu.edu 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 ill-formed shared expressions so that they no longer leak the `undefined' value. This is great! (especially happy that TR, even with classes, doesn't have to worry about #undefined anymore) BTW, I found this weird behavior: Welcome to Racket v6.0.1.3. - (require racket/unsafe/ops) - (let () (+ x 3) (define x 3) 5) ; x: variable used before its definition [,bt for context] - (let () (unsafe-fx+ x 3) (define x 3) 5) 5 I consider this correct in a strange sense. Interestingly enough, (let () (displayln (unsafe-fx+ x 3)) (define x 3) 5) x: variable used before its definition context...: /Users/matthias/plt/racket/collects/racket/private/misc.rkt:87:7 which is good too. I don't know how Claire and Matthew did this, but it's good :-) _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Catching the undefined value
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 ill-formed shared expressions so that they no longer leak the `undefined' value. This is great! (especially happy that TR, even with classes, doesn't have to worry about #undefined anymore) BTW, I found this weird behavior: Welcome to Racket v6.0.1.3. - (require racket/unsafe/ops) - (let () (+ x 3) (define x 3) 5) ; x: variable used before its definition [,bt for context] - (let () (unsafe-fx+ x 3) (define x 3) 5) 5 I consider this correct in a strange sense. Interestingly enough, (let () (displayln (unsafe-fx+ x 3)) (define x 3) 5) x: variable used before its definition context...: /Users/matthias/plt/racket/collects/racket/private/misc.rkt:87:7 which is good too. I don't know how Claire and Matthew did this, but it's good :-) I've pushed a repair for Asumu's example. The part of the optimizer that throws out unsafe operations with unused results could be triggered before the letrec-fixing pass, and the optimization wasn't as conservative as it needs to be at that point about local variables. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Catching the undefined value
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) (delay (cons 0 lazy-zeros))) lazy-zeros) Yes, that should be the case. Here's an interaction from my pull request branch for removing undefined handling in TR: Welcome to Racket v6.0.1.3. - (define-type (Lazy-Listof A) (Promise (Pair A (Lazy-Listof A - (let () (define: lazy-zeros : (Lazy-Listof Zero) (delay (cons 0 lazy-zeros))) lazy-zeros) - : (Lazy-Listof Zero) #promise:lazy-zeros That's assuming there aren't any design problems with that PR that come up in code review. BTW, I was happy to see that the type `Lazy-Listof' could be defined like that when coming up with the example. :D Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Catching the undefined value
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. If a variable bound to the undefined value is referenced at runtime, an exception is raised. We are aware that these changes are not backwards compatible. We've deliberately put them in the development branch to get a sense of how much of a problem that is. Internal libraries that depend on having `undefined' as an initialization value now import the racket/unsafe/undefined library but should always keep it from leaking. The unsafe library provides the internal `unsafe-undefined' value and the internal function `check-not-unsafe-undefined' that errors if given the `unsafe-undefined' value but otherwise acts like the identity function. We extremely discourage the external use of racket/unsafe/undefined and it will not play nicely with anything that uses letrec. Programs that cannot be refactored to not use `undefined' should instead use the better undefined value from the racket/undefined collect. This `undefined' value can still leak out of shared expressions when using mutable pairs. For those interested in the implementation details: - A new compiler pass wraps check-not-unsafe-undefined around any letrec-bound variable references that could possibly leak the undefined value. It runs a simple analysis to determine which variable references need such checks. From the benchmarks we've run, it looks like a relatively low number of variable references actually need checks. However, these checks do have the potential to disable certain optimizations such as inlining of variables with checked references. - The change to classes is more experimental. Any instance of a class that could possibly reference a field before it is assigned is chaperoned. The chaperone watches for a reference to the internal undefined value. The class macro performs its own analysis to determine which classes need to be chaperoned. TL;DR you should not see unsafe-undefined ever again, but you may still see the better undefined when using (libraries that use) racket/undefined. Claire On Tue, Apr 15, 2014 at 5:38 PM, mfl...@racket-lang.org wrote: mflatt has updated `master' from 69984fb231 to a283f3d804. http://git.racket-lang.org/plt/69984fb231..a283f3d804 =[ 19 Commits ]= ~~ 72c958d Claire Alvis claire.al...@gmail.com 2013-05-07 09:36 : | all necessary changes to check references to uninitialized letrec variables | | includes a new pass, letrec_check, two new primitives, and | changes to packages that grabbed the letrec undefined value _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Catching the undefined value
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 classes, doesn't have to worry about #undefined anymore) BTW, I found this weird behavior: Welcome to Racket v6.0.1.3. - (require racket/unsafe/ops) - (let () (+ x 3) (define x 3) 5) ; x: variable used before its definition [,bt for context] - (let () (unsafe-fx+ x 3) (define x 3) 5) 5 Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Catching the undefined value
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 great! (especially happy that TR, even with classes, doesn't have to worry about #undefined anymore) 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) (delay (cons 0 lazy-zeros))) lazy-zeros) Currently, `lazy-zeros' has the type (U Undefined (Lazy-Listof A)) within its definition, but only because it's in an internal definition context. This has come up in a few different guises while I've programmed in TR. BTW, I was happy to see that the type `Lazy-Listof' could be defined like that when coming up with the example. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
