TwiceMeta:
Annul Previous till ThricePrevious.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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
TwiceMeta:
FourfoldPrevious edit code:
This's subject is .
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Mmeta:
Pprevious edit code:
This's subject is .
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Mmeta:
TwicePrevious edit code:
This's subject is .
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Mmeta:
edit code:
This's subject is .
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Mmeta:
edit code:
This' a reply to
.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Mmeta:
Pprevious edit code:
This' a reply to
.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
here's the rest
of the thread:
https://esdiscuss.org/topic/toplevel-let-binding-can-be-left-permanently-
uninitialized-after-an-error
Ever-deeper-nested-blocks is one possible behavior for a repl, and it does
solve this problem by allowing you to shadow your broken `let x` with a
fresh one, after a ty
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
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 ini
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
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 relevant.
-- T.J. Cr
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 you expand on that? It doesn't seem to me you can. I
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}` (
https://jsfiddle.net/tw3oh
You can still do `{x}`.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 30 September 2014 22:38, David Herman wrote:
> On Sep 30, 2014, at 4:03 AM, Andreas Rossberg wrote:
>
>> On 30 September 2014 12:52, Jason Orendorff
>> wrote:
>>> I just realized this has an unfortunate implication for REPLs. Suppose
>>> you make this typo:
>>>
>>>js> let x = Math.cso(a)
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.
On Tue, Sep 30, 2014 at 12:00 PM, 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 (presum
On Sep 30, 2014, at 4:03 AM, Andreas Rossberg wrote:
> On 30 September 2014 12:52, Jason Orendorff 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 i
On Tue, Sep 30, 2014 at 2:08 PM, Brian Genisio
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 use!
--
erik
_
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
wrote:
>
>
> On Tue, Sep 30, 2014 at 1:08 PM, Allen Wirfs-Brock
> wrote:
>
>>
>> On Sep 30, 2014, at 10:00 AM, Rick Waldron wrote:
>>
>>
>> My original response
On Tue, Sep 30, 2014 at 1:08 PM, Allen Wirfs-Brock
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, because I don't have
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 (pres
On Tue, Sep 30, 2014 at 6:38 AM, Jason Orendorff
wrote:
> On Mon, Sep 29, 2014 at 4:14 PM, Rick Waldron
> 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 in
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" wrote:
> On 30 September 2014 12:52, Jason Orendorff
> wrote:
> > I just
On 30 September 2014 12:52, Jason Orendorff 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 bad.
No surprise. One
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
On Mon, Sep 29, 2014 at 4:14 PM, Rick Waldron 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 OK:
let x; //
TDZ
On Sep 29, 2014, at 2:14 PM, Rick Waldron wrote:
>
>
> On Mon, Sep 29, 2014 at 4:17 PM, Jason Orendorff
> 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' uninitial
On Mon, Sep 29, 2014 at 4:17 PM, Jason Orendorff
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 binding or to initia
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 binding or to initialize it later. The binding is just
permanently hosed; any attempt to rea
32 matches
Mail list logo
