Re: Toplevel 'let' binding can be left permanently uninitialized after an error

TwiceMeta: Annul Previous till ThricePrevious. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Toplevel 'let' binding can be left permanently uninitialized after an error

Mmeta: Pparent edit code: This's subject is . On 29 November 2017 at 01:05, Joseph wrote: > You can still do `{x}`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

TwiceMeta: FourfoldPrevious edit code: This's subject is . ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

Mmeta: Pprevious edit code: This's subject is . ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

Mmeta: TwicePrevious edit code: This's subject is . ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

Mmeta:

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

Mmeta: Pprevious edit code: This' a reply to . ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Toplevel 'let' binding can be left permanently uninitialized after an error

On Wed, Nov 29, 2017 at 4:13 AM, pacer...@gmail.com wrote: > Re "..in subscope" and "..relevant"; As repl's can be fixed by > that---all snippets treated as curlybraced. > Hi everyone. For those of you who weren't on this list three years ago, here's the rest of the thread:

Re: Re: Toplevel 'let' binding can be left permanently uninitialized after an error

Re "..in subscope" and "..relevant"; As repl's can be fixed by that---all snippets treated as curlybraced. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

The spidermonkey REPL shell has a special cut-out for this: js> throw 0; let x; uncaught exception: 0 (Unable to print stack trace) Warning: According to the standard, after the above exception, Warning: the global bindings should be permanently uninitialized. Warning: We have non-standard-ly

Re: Re: Toplevel 'let' binding can be left permanently uninitialized after an error

And this is why I use `var` instead of `let` in REPLs. They're doing what they're supposed to do; it's just unintuitive. As a secondary proposal, I feel `let`/`const` in scripts should be allowed to shadow existing globals at the top level *provided* they are not declared in the same script. It'd

Re: Re: Toplevel 'let' binding can be left permanently uninitialized after an error

On Tue, Nov 28, 2017 at 7:31 PM, Joseph wrote: > > Re "x is irreparably hosed in your REPL"; you can still use it in subscope, eg <{let x=1;console.log(1)}>. Well yes, of course you can. You can also use it in nested functions. Or even whole other scripts, which is nearly as

Re: Re: Toplevel 'let' binding can be left permanently uninitialized after an error

Re "x is irreparably hosed in your REPL"; you can still use it in subscope, eg <{let x=1;console.log(1)}>. On 29 November 2017 at 01:30, T.J. Crowder wrote: > On Tue, Nov 28, 2017 at 5:05 PM, Joseph wrote: > > You can still do `{x}`. > > Can

Re: Re: Toplevel 'let' binding can be left permanently uninitialized after an error

On Tue, Nov 28, 2017 at 5:05 PM, Joseph wrote: > You can still do `{x}`. Can you expand on that? It doesn't seem to me you can. I mean, if even `x = 42;` won't work (https://jsfiddle.net/tw3ohac6/), I fail to see how anything else using `x` would work, including `{x}` (

Re: Re: Toplevel 'let' binding can be left permanently uninitialized after an error

You can still do `{x}`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

On 30 September 2014 22:38, David Herman dher...@mozilla.com wrote: On Sep 30, 2014, at 4:03 AM, Andreas Rossberg rossb...@google.com wrote: On 30 September 2014 12:52, Jason Orendorff jason.orendo...@gmail.com wrote: I just realized this has an unfortunate implication for REPLs. Suppose

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

On Mon, Sep 29, 2014 at 4:14 PM, Rick Waldron waldron.r...@gmail.com wrote: Can you clarify write? Does this mean assignment? Yes. Why would assignment throw? Assigning to an uninitialized variable is an error in ES6. A let-binding is initialized when its declaration is evaluated. So this is

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

I just realized this has an unfortunate implication for REPLs. Suppose you make this typo: js let x = Math.cso(a)// oops, TypeError, should be Math.cos Now x is irreparably hosed in your REPL. That seems bad. I guess we can fix this by making the REPL bend the rules of the language. But

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

On 30 September 2014 12:52, Jason Orendorff jason.orendo...@gmail.com wrote: I just realized this has an unfortunate implication for REPLs. Suppose you make this typo: js let x = Math.cso(a)// oops, TypeError, should be Math.cos Now x is irreparably hosed in your REPL. That seems

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

Likewise. E is also a scripting repl language with dynamic types and static scopes. We tried a variety of different ways to handle the top level repl and nested scopes were best. On Sep 30, 2014 4:04 AM, Andreas Rossberg rossb...@google.com wrote: On 30 September 2014 12:52, Jason Orendorff

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

On Tue, Sep 30, 2014 at 6:38 AM, Jason Orendorff jason.orendo...@gmail.com wrote: On Mon, Sep 29, 2014 at 4:14 PM, Rick Waldron waldron.r...@gmail.com wrote: Can you clarify write? Does this mean assignment? Yes. Why would assignment throw? Assigning to an uninitialized variable is an

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

On Sep 30, 2014, at 10:00 AM, Rick Waldron wrote: My original response questions were poorly asked. I understand the TDZ semantics, but I couldn't reproduce anything meaningful from your original example, because I don't have the SpiderMonkey build that includes the let updates

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

On Tue, Sep 30, 2014 at 1:08 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Sep 30, 2014, at 10:00 AM, Rick Waldron wrote: My original response questions were poorly asked. I understand the TDZ semantics, but I couldn't reproduce anything meaningful from your original example,

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

FYI, you can also see this behavior in Node.js (v0.11.14) node --harmony --strict-mode On Tue, Sep 30, 2014 at 1:24 PM, Rick Waldron waldron.r...@gmail.com wrote: On Tue, Sep 30, 2014 at 1:08 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Sep 30, 2014, at 10:00 AM, Rick Waldron

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

On Tue, Sep 30, 2014 at 2:08 PM, Brian Genisio briangeni...@gmail.com wrote: FYI, you can also see this behavior in Node.js (v0.11.14) node --harmony --strict-mode V8's support of let is far from spec compliant. Stuff under --harmony is incomplete, buggy and may have security holes. Do not

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

On Sep 30, 2014, at 4:03 AM, Andreas Rossberg rossb...@google.com wrote: On 30 September 2014 12:52, Jason Orendorff jason.orendo...@gmail.com wrote: I just realized this has an unfortunate implication for REPLs. Suppose you make this typo: js let x = Math.cso(a)// oops, TypeError,

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

On Tue, Sep 30, 2014 at 12:00 PM, Rick Waldron waldron.r...@gmail.com wrote: My original response questions were poorly asked. I understand the TDZ semantics, but I couldn't reproduce anything meaningful from your original example, because I don't have the SpiderMonkey build that includes the

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

David Herman wrote: I'm usually less concerned about REPLs, since they can decide for themselves what kind of context they want to execute in -- or even invent new non-standard non-terminals, frankly -- although in this case it's not quite clear what a let declaration*should* do in the REPL.

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

On Mon, Sep 29, 2014 at 4:17 PM, Jason Orendorff jason.orendo...@gmail.com wrote: SpiderMonkey hacker Jeff Walden noticed this. Consider a web page that loads and runs this script: throw 0; let x; This leaves the binding 'x' uninitialized. There's no way to get rid of a lexical

Re: Toplevel 'let' binding can be left permanently uninitialized after an error

TDZ On Sep 29, 2014, at 2:14 PM, Rick Waldron wrote: On Mon, Sep 29, 2014 at 4:17 PM, Jason Orendorff jason.orendo...@gmail.com wrote: SpiderMonkey hacker Jeff Walden noticed this. Consider a web page that loads and runs this script: throw 0; let x; This leaves the