On Apr 19, 2014, at 5:57 PM, Sam Tobin-Hochstadt wrote:
> On Sat, Apr 19, 2014 at 4:45 PM, Matthias Felleisen
> 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)
On Sat, Apr 19, 2014 at 4:45 PM, Matthias Felleisen
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
t
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.
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 wr
>> (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, Ro
These seem correct to me. What were you expecting (and why?).
Robby
On Saturday, April 19, 2014, Gustavo Massaccesi 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 :).
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
On 2014-04-15 21:19:16 -0600, Neil Toronto wrote:
> Does TR not having to worry about # 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)
>
At Wed, 16 Apr 2014 09:02:44 -0400, Matthias Felleisen wrote:
>
> On Apr 15, 2014, at 9: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-form
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 @@
>
On Apr 15, 2014, at 9: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
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 grea
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 clas
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
14 matches
Mail list logo
