Re: eval of let, etc. Was: Re: restrictions on let declarations
On 15 February 2014 06:10, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: On Feb 14, 2014, at 11:38 AM, Jeremy Martin wrote: On further reflection, #3 does feel like trying to rewrite the past. For better or worse, non-strict mode allows declarations to persist past the eval(). And while strict mode provides a license-to-kill on behavior like that, I don't really see strong justification for that kind of surprise factor for let in non-strict mode. If you're not using strict mode AND you're using eval(), the damage is arguably already done (or at least the danger already exists). Changing the behavior of let in this case feels like removing an arbitrary* foot-gun when we're already in the armory, so to speak. * Granted it's not completely arbitrary, since `let` is new whereas `var` is not, but hopefully you get my point. Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. Strongly seconded. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
So, #3 appears to be the winner. Given that, can we also agree that this is throws (or at least that the delete does nothing): eval (let x=5; delete x;); (bug https://bugs.ecmascript.org/show_bug.cgi?id= ) Allen On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote: I'm also fine with 3. On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin jmar...@gmail.com wrote: Happy to concede to #3 on my end. Just wanted to be clear that it seems to be optimizing for future happiness vs. least surprising behavior (which isn't a bad thing). On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro jo...@jorgechamorro.com wrote: On 17/02/2014, at 13:42, Andreas Rossberg wrote: On 15 February 2014 06:10, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. Strongly seconded. And even thirded. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
In this context, there are two things you might mean by throws: a) That this delete is an early error within the evaled program, and therefore throws before any of the code in the evaled program executes. b) That the delete is a dynamic error that happens when the delete executes, and therefore that the evaled code prior to the delete has executed before the error is thrown. -1 on #b. Assuming you mean #a, between #a and silence, I'm torn. Here are pros and cons: pro #a: The program is wrong. Silence fails to bring it to anyone's attention, making the mistake less likely to be fixed. And making it more likely the program's execution deviates from author's intent. con #a: Silence on sloppy wrong programs are least surprise, and is arguably the most vivid different between sloppy and strict. I doubt there's any sensible choices other than #a and silence. On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: So, #3 appears to be the winner. Given that, can we also agree that this is throws (or at least that the delete does nothing): eval (let x=5; delete x;); (bug https://bugs.ecmascript.org/show_bug.cgi?id= ) Allen On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote: I'm also fine with 3. On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin jmar...@gmail.com wrote: Happy to concede to #3 on my end. Just wanted to be clear that it seems to be optimizing for future happiness vs. least surprising behavior (which isn't a bad thing). On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro jo...@jorgechamorro.com wrote: On 17/02/2014, at 13:42, Andreas Rossberg wrote: On 15 February 2014 06:10, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. Strongly seconded. And even thirded. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-runtime-semantics-evaluation A better statement of the question would be can we agree that lexical bindings created by eval are always non-deletable binding. Where or not is throws which the various modes is already determined by the existing spec. for delete based upon whether or not the binding is deletable. Allen On Feb 17, 2014, at 1:16 PM, Mark S. Miller wrote: In this context, there are two things you might mean by throws: a) That this delete is an early error within the evaled program, and therefore throws before any of the code in the evaled program executes. b) That the delete is a dynamic error that happens when the delete executes, and therefore that the evaled code prior to the delete has executed before the error is thrown. -1 on #b. Assuming you mean #a, between #a and silence, I'm torn. Here are pros and cons: pro #a: The program is wrong. Silence fails to bring it to anyone's attention, making the mistake less likely to be fixed. And making it more likely the program's execution deviates from author's intent. con #a: Silence on sloppy wrong programs are least surprise, and is arguably the most vivid different between sloppy and strict. I doubt there's any sensible choices other than #a and silence. On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: So, #3 appears to be the winner. Given that, can we also agree that this is throws (or at least that the delete does nothing): eval (let x=5; delete x;); (bug https://bugs.ecmascript.org/show_bug.cgi?id= ) Allen On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote: I'm also fine with 3. On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin jmar...@gmail.com wrote: Happy to concede to #3 on my end. Just wanted to be clear that it seems to be optimizing for future happiness vs. least surprising behavior (which isn't a bad thing). On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro jo...@jorgechamorro.com wrote: On 17/02/2014, at 13:42, Andreas Rossberg wrote: On 15 February 2014 06:10, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. Strongly seconded. And even thirded. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
+1. On Mon, Feb 17, 2014 at 2:06 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-runtime-semantics-evaluation A better statement of the question would be can we agree that lexical bindings created by eval are always non-deletable binding. Where or not is throws which the various modes is already determined by the existing spec. for delete based upon whether or not the binding is deletable. Allen On Feb 17, 2014, at 1:16 PM, Mark S. Miller wrote: In this context, there are two things you might mean by throws: a) That this delete is an early error within the evaled program, and therefore throws before any of the code in the evaled program executes. b) That the delete is a dynamic error that happens when the delete executes, and therefore that the evaled code prior to the delete has executed before the error is thrown. -1 on #b. Assuming you mean #a, between #a and silence, I'm torn. Here are pros and cons: pro #a: The program is wrong. Silence fails to bring it to anyone's attention, making the mistake less likely to be fixed. And making it more likely the program's execution deviates from author's intent. con #a: Silence on sloppy wrong programs are least surprise, and is arguably the most vivid different between sloppy and strict. I doubt there's any sensible choices other than #a and silence. On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: So, #3 appears to be the winner. Given that, can we also agree that this is throws (or at least that the delete does nothing): eval (let x=5; delete x;); (bug https://bugs.ecmascript.org/show_bug.cgi?id= ) Allen On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote: I'm also fine with 3. On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin jmar...@gmail.com wrote: Happy to concede to #3 on my end. Just wanted to be clear that it seems to be optimizing for future happiness vs. least surprising behavior (which isn't a bad thing). On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro jo...@jorgechamorro.com wrote: On 17/02/2014, at 13:42, Andreas Rossberg wrote: On 15 February 2014 06:10, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. Strongly seconded. And even thirded. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
I'm getting vary. Does that mean that you want to change the semantics since ES5.1? On Mon Feb 17 2014 at 5:12:24 PM, Mark S. Miller erig...@google.com wrote: +1. On Mon, Feb 17, 2014 at 2:06 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-runtime-semantics-evaluation A better statement of the question would be can we agree that lexical bindings created by eval are always non-deletable binding. Where or not is throws which the various modes is already determined by the existing spec. for delete based upon whether or not the binding is deletable. Allen On Feb 17, 2014, at 1:16 PM, Mark S. Miller wrote: In this context, there are two things you might mean by throws: a) That this delete is an early error within the evaled program, and therefore throws before any of the code in the evaled program executes. b) That the delete is a dynamic error that happens when the delete executes, and therefore that the evaled code prior to the delete has executed before the error is thrown. -1 on #b. Assuming you mean #a, between #a and silence, I'm torn. Here are pros and cons: pro #a: The program is wrong. Silence fails to bring it to anyone's attention, making the mistake less likely to be fixed. And making it more likely the program's execution deviates from author's intent. con #a: Silence on sloppy wrong programs are least surprise, and is arguably the most vivid different between sloppy and strict. I doubt there's any sensible choices other than #a and silence. On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: So, #3 appears to be the winner. Given that, can we also agree that this is throws (or at least that the delete does nothing): eval (let x=5; delete x;); (bug https://bugs.ecmascript.org/show_bug.cgi?id= ) Allen On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote: I'm also fine with 3. On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin jmar...@gmail.com wrote: Happy to concede to #3 on my end. Just wanted to be clear that it seems to be optimizing for future happiness vs. least surprising behavior (which isn't a bad thing). On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro jo...@jorgechamorro.comwrote: On 17/02/2014, at 13:42, Andreas Rossberg wrote: On 15 February 2014 06:10, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. Strongly seconded. And even thirded. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
No, absolutely not. By lexical, I took Allen to mean the new reliably block-local binding forms: let, const, class On Mon, Feb 17, 2014 at 2:17 PM, Erik Arvidsson erik.arvids...@gmail.comwrote: I'm getting vary. Does that mean that you want to change the semantics since ES5.1? On Mon Feb 17 2014 at 5:12:24 PM, Mark S. Miller erig...@google.com wrote: +1. On Mon, Feb 17, 2014 at 2:06 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-runtime-semantics-evaluation A better statement of the question would be can we agree that lexical bindings created by eval are always non-deletable binding. Where or not is throws which the various modes is already determined by the existing spec. for delete based upon whether or not the binding is deletable. Allen On Feb 17, 2014, at 1:16 PM, Mark S. Miller wrote: In this context, there are two things you might mean by throws: a) That this delete is an early error within the evaled program, and therefore throws before any of the code in the evaled program executes. b) That the delete is a dynamic error that happens when the delete executes, and therefore that the evaled code prior to the delete has executed before the error is thrown. -1 on #b. Assuming you mean #a, between #a and silence, I'm torn. Here are pros and cons: pro #a: The program is wrong. Silence fails to bring it to anyone's attention, making the mistake less likely to be fixed. And making it more likely the program's execution deviates from author's intent. con #a: Silence on sloppy wrong programs are least surprise, and is arguably the most vivid different between sloppy and strict. I doubt there's any sensible choices other than #a and silence. On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: So, #3 appears to be the winner. Given that, can we also agree that this is throws (or at least that the delete does nothing): eval (let x=5; delete x;); (bug https://bugs.ecmascript.org/show_bug.cgi?id= ) Allen On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote: I'm also fine with 3. On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin jmar...@gmail.com wrote: Happy to concede to #3 on my end. Just wanted to be clear that it seems to be optimizing for future happiness vs. least surprising behavior (which isn't a bad thing). On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro jo...@jorgechamorro.com wrote: On 17/02/2014, at 13:42, Andreas Rossberg wrote: On 15 February 2014 06:10, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. Strongly seconded. And even thirded. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
Right, let/const/class Allen On Feb 17, 2014, at 2:19 PM, Mark Miller wrote: No, absolutely not. By lexical, I took Allen to mean the new reliably block-local binding forms: let, const, class On Mon, Feb 17, 2014 at 2:17 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: I'm getting vary. Does that mean that you want to change the semantics since ES5.1? On Mon Feb 17 2014 at 5:12:24 PM, Mark S. Miller erig...@google.com wrote: +1. On Mon, Feb 17, 2014 at 2:06 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-runtime-semantics-evaluation A better statement of the question would be can we agree that lexical bindings created by eval are always non-deletable binding. Where or not is throws which the various modes is already determined by the existing spec. for delete based upon whether or not the binding is deletable. Allen On Feb 17, 2014, at 1:16 PM, Mark S. Miller wrote: In this context, there are two things you might mean by throws: a) That this delete is an early error within the evaled program, and therefore throws before any of the code in the evaled program executes. b) That the delete is a dynamic error that happens when the delete executes, and therefore that the evaled code prior to the delete has executed before the error is thrown. -1 on #b. Assuming you mean #a, between #a and silence, I'm torn. Here are pros and cons: pro #a: The program is wrong. Silence fails to bring it to anyone's attention, making the mistake less likely to be fixed. And making it more likely the program's execution deviates from author's intent. con #a: Silence on sloppy wrong programs are least surprise, and is arguably the most vivid different between sloppy and strict. I doubt there's any sensible choices other than #a and silence. On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: So, #3 appears to be the winner. Given that, can we also agree that this is throws (or at least that the delete does nothing): eval (let x=5; delete x;); (bug https://bugs.ecmascript.org/show_bug.cgi?id= ) Allen On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote: I'm also fine with 3. On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin jmar...@gmail.com wrote: Happy to concede to #3 on my end. Just wanted to be clear that it seems to be optimizing for future happiness vs. least surprising behavior (which isn't a bad thing). On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro jo...@jorgechamorro.com wrote: On 17/02/2014, at 13:42, Andreas Rossberg wrote: On 15 February 2014 06:10, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. Strongly seconded. And even thirded. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
On 30/01/2014, at 17:13, Brendan Eich wrote:
John Barton wrote:
On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
John Lenz wrote:
Generally, I've always thought of:
if (x) ... as equivalent to if (x) { ... }
let and const (and class) are block-scoped. {...} in your if (x)
{...} is a block. An unbraced consequent is not a block, and you
can't have a conditional let binding.
The restriction avoids nonsense such as
let x = 0; { if (y) let x = 42; alert(x); }
What pray tell is going on here, in your model?
I'm with John: the alert should say 0 and I can't see why that is not
obvious.
Interesting!
You don't want the alert to show undefined, so the extent of the inner
binding in your model is the unbraced consequent of the if.
That is not block scope in any plain sense.
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
On 31/01/2014, at 03:11, Brendan Eich wrote:
OMG LETS MAKE USELESS LETS EVERYWHERE LOLJSSUXZ0RZ! Um, no.
:-)
--
( Jorge )();
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
On 30/01/2014, at 17:13, Brendan Eich wrote: / // // Interesting! // // You don't want the alert to show undefined, so the extent of the inner binding in your model is the unbraced consequent of the if. // // That is not block scope in any plain sense. / How about this? let x= 0; if (1) eval(let x= 42; alert(x);); //Is this in its own block? alert(x); `eval()` hasn't yet been updated to work with the new lexical declaration forms, but I hope the example from above will be evaluated in a new block. See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug report. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
eval of let, etc. Was: Re: restrictions on let declarations
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical declaration
forms, but I hope the example from above will be evaluated in a new block.
See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug report.
Goood point and this is something I need to specify in the next couple weeks so
let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new environment
that is immediately nested within the current LexicalEnvironment. The scoping
behavior is essentially the same as if the eval code was the body of an iife
that occurred at the same place as the eval call. Bindings introduced by the
eval code disappear after completion of the eval.
In non-strict mode, each eval instantiates all declarations in the current
VariableEnvironment; that is the most immediately enclosing function or global
environment. Bindings introduced by the eval code remain accessible from that
VariableEnvironment after completion of the eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact same way.
Each eval takes place in its own environment and no bindings survive the
completion of the eval.
For ES6, non-strict evals of code containing only var or function declarations
must have exactly the ES5 behavior in order to maintain compatibility. But
what about eval code that contains new declaration forms (let/const/class)
exclusively or in combination with var/function declarations? Three
possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly contains
any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics for var/function
declarations but place let/const/class bindings into a per eval environment:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // ReferenceError: localToEval is not defined
)();
It would certainly be possible to specify #1, but I don't like it. Other than
for the global environment it would be cleaner if the new block scope-able
declarations were never dynamically added to the environment.
I think either #2 or #3 is plausible. #2 is a simpler story but introduces a
refactoring hazard. If you have some existing eval code that defines some
global functions or variables, then simply adding a let/const/class
declaration to the eval code ruins those global declarations.
I prefer the simplicity of #2, but I also worry about the WTF impact it might
have on evolving existing code.
Can we get away with #2, or are we going to have to go with #3? Are there
other alternatives?
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically
considered a block, the let binding would survive past the completion of
the eval in non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
I'm not necessarily arguing for that behavior, but weighing in since that's
the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical declaration
forms, but I hope the example from above will be evaluated in a new block.
See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
report.
Goood point and this is something I need to specify in the next couple
weeks so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new
environment that is immediately nested within the current
LexicalEnvironment. The scoping behavior is essentially the same as if the
eval code was the body of an iife that occurred at the same place as the
eval call. Bindings introduced by the eval code disappear after completion
of the eval.
In non-strict mode, each eval instantiates all declarations in the current
VariableEnvironment; that is the most immediately enclosing function or
global environment. Bindings introduced by the eval code remain accessible
from that VariableEnvironment after completion of the eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact same
way. Each eval takes place in its own environment and no bindings survive
the completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration
forms (let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly
contains any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics for var/function
declarations but place let/const/class bindings into a per eval environment:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
It would certainly be possible to specify #1, but I don't like it. Other
than for the global environment it would be cleaner if the new block
scope-able declarations were never dynamically added to the environment.
I think either #2 or #3 is plausible. #2 is a simpler story but
introduces a refactoring hazard. If you have some existing eval code that
defines some global functions or variables, then simply adding a
let/const/class declaration to the eval code ruins those global
declarations.
I prefer the simplicity of #2, but I also worry about the WTF impact it
might have on evolving existing code.
Can we get away with #2, or are we going to have to go with #3? Are there
other alternatives?
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
On Fri, Feb 14, 2014 at 7:40 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
[...]
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly
contains any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics for var/function
declarations but place let/const/class bindings into a per eval environment:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
It would certainly be possible to specify #1, but I don't like it. Other
than for the global environment it would be cleaner if the new block
scope-able declarations were never dynamically added to the environment.
I think either #2 or #3 is plausible. #2 is a simpler story but
introduces a refactoring hazard. If you have some existing eval code that
defines some global functions or variables, then simply adding a
let/const/class declaration to the eval code ruins those global
declarations.
I prefer the simplicity of #2, but I also worry about the WTF impact it
might have on evolving existing code.
Can we get away with #2, or are we going to have to go with #3? Are there
other alternatives?
I actually prefer #3. Given only knowledge of ES5 and of the rest of ES6, I
find it least surprising. vars hoist out of blocks. In non-strict code,
functions leak out of blocks in ways that are hard to explain. I can
understand non-strict direct eval as being block-like, in that var and
function leak out of them, but all the reliably block-local declarations
stay within the direct eval.
Also, I buy the refactoring issue. It's like the problem with micro-modes:
bizarre and unexpected non-local influences.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
I agree that this is in some sense the least surprising. But it is so
unpleasant that I think we should instead opt for the additional surprise
of #3 -- that a direct sloppy eval is block-like, even though there aren't
any curlies.
On Fri, Feb 14, 2014 at 8:03 AM, Jeremy Martin jmar...@gmail.com wrote:
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically
considered a block, the let binding would survive past the completion of
the eval in non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
I'm not necessarily arguing for that behavior, but weighing in since
that's the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical declaration
forms, but I hope the example from above will be evaluated in a new block.
See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
report.
Goood point and this is something I need to specify in the next couple
weeks so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new
environment that is immediately nested within the current
LexicalEnvironment. The scoping behavior is essentially the same as if the
eval code was the body of an iife that occurred at the same place as the
eval call. Bindings introduced by the eval code disappear after completion
of the eval.
In non-strict mode, each eval instantiates all declarations in the
current VariableEnvironment; that is the most immediately enclosing
function or global environment. Bindings introduced by the eval code
remain accessible from that VariableEnvironment after completion of the
eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact
same way. Each eval takes place in its own environment and no bindings
survive the completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration
forms (let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly
contains any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics for var/function
declarations but place let/const/class bindings into a per eval environment:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
It would certainly be possible to specify #1, but I don't like it. Other
than for the global environment it would be cleaner if the new block
scope-able declarations were never dynamically added to the environment.
I think either #2 or #3 is plausible. #2 is a simpler story but
introduces a refactoring hazard. If you have some existing eval code that
defines some global functions or variables, then simply adding a
let/const/class declaration to the eval code ruins those global
declarations.
I prefer the simplicity of #2, but I also worry about the WTF impact it
might have on evolving existing code.
Can we get away with #2, or are we going to have to go with #3? Are
there other alternatives?
Allen
Re: eval of let, etc. Was: Re: restrictions on let declarations
How about Keyword 'let' not allowed without 'use strict' or in a module. ?
On Fri, Feb 14, 2014 at 8:18 AM, Mark S. Miller erig...@google.com wrote:
I agree that this is in some sense the least surprising. But it is so
unpleasant that I think we should instead opt for the additional surprise
of #3 -- that a direct sloppy eval is block-like, even though there aren't
any curlies.
On Fri, Feb 14, 2014 at 8:03 AM, Jeremy Martin jmar...@gmail.com wrote:
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically
considered a block, the let binding would survive past the completion of
the eval in non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is
not defined
)();
I'm not necessarily arguing for that behavior, but weighing in since
that's the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical
declaration forms, but I hope the example from above will be evaluated in a
new block. See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a
related bug report.
Goood point and this is something I need to specify in the next couple
weeks so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new
environment that is immediately nested within the current
LexicalEnvironment. The scoping behavior is essentially the same as if the
eval code was the body of an iife that occurred at the same place as the
eval call. Bindings introduced by the eval code disappear after completion
of the eval.
In non-strict mode, each eval instantiates all declarations in the
current VariableEnvironment; that is the most immediately enclosing
function or global environment. Bindings introduced by the eval code
remain accessible from that VariableEnvironment after completion of the
eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact
same way. Each eval takes place in its own environment and no bindings
survive the completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration
forms (let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly
contains any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics for var/function
declarations but place let/const/class bindings into a per eval environment:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
It would certainly be possible to specify #1, but I don't like it. Other
than for the global environment it would be cleaner if the new block
scope-able declarations were never dynamically added to the environment.
I think either #2 or #3 is plausible. #2 is a simpler story but
introduces a refactoring hazard. If you have some existing eval code that
defines some global functions or variables, then simply adding a
let/const/class declaration to the eval code ruins those global
declarations.
I prefer the simplicity of #2, but I also worry about the WTF impact it
might have on
Re: eval of let, etc. Was: Re: restrictions on let declarations
Mark S. Miller wrote: I actually prefer #3. Given only knowledge of ES5 and of the rest of ES6, I find it least surprising. vars hoist out of blocks. In non-strict code, functions leak out of blocks in ways that are hard to explain. I can understand non-strict direct eval as being block-like, in that var and function leak out of them, but all the reliably block-local declarations stay within the direct eval. Also, I buy the refactoring issue. It's like the problem with micro-modes: bizarre and unexpected non-local influences. Yes, agree on #3 being best. My recollection from past TC39 meetings and discussion here is that #2 will not fly. We do not want some let buried in a large string to eval to contaminate the whole eval'ed program such that vars in it are confined, where they weren't before. Just amplifying your refactoring point, but also noting your micro-mode/non-local comment. This is not going to win consensus. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
On Fri, Feb 14, 2014 at 8:26 AM, John Barton johnjbar...@google.com wrote:
How about Keyword 'let' not allowed without 'use strict' or in a module.
?
I wish. I argued strongly that sloppy mode be maintained only to continue
to serve the purpose of being an ES3 compatibility mode, and that we stop
adding new ES6 language features to it. In particular, that we not add
let since we could not even specify that let be *simply* a declaration
keyword in sloppy mode. Instead, TC39 decided that let in sloppy mode is
sometimes a variable, and sometimes indicates a let declaration. This is
long decided and TC39 is not going to revisit the admission of let into
sloppy mode.
For this and many other reasons, new code should consider sloppy mode to be
WTF toxic waste, to be avoided under all normal circumstances.
Nevertheless, we still need to settle outstanding questions as
non-toxically as possible, given the toxic waste we've already dumped into
sloppy mode. Hence this thread.
On Fri, Feb 14, 2014 at 8:18 AM, Mark S. Miller erig...@google.comwrote:
I agree that this is in some sense the least surprising. But it is so
unpleasant that I think we should instead opt for the additional surprise
of #3 -- that a direct sloppy eval is block-like, even though there aren't
any curlies.
On Fri, Feb 14, 2014 at 8:03 AM, Jeremy Martin jmar...@gmail.com wrote:
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically
considered a block, the let binding would survive past the completion of
the eval in non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is
not defined
)();
I'm not necessarily arguing for that behavior, but weighing in since
that's the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical
declaration forms, but I hope the example from above will be evaluated in a
new block. See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a
related bug report.
Goood point and this is something I need to specify in the next couple
weeks so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new
environment that is immediately nested within the current
LexicalEnvironment. The scoping behavior is essentially the same as if the
eval code was the body of an iife that occurred at the same place as the
eval call. Bindings introduced by the eval code disappear after completion
of the eval.
In non-strict mode, each eval instantiates all declarations in the
current VariableEnvironment; that is the most immediately enclosing
function or global environment. Bindings introduced by the eval code
remain accessible from that VariableEnvironment after completion of the
eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact
same way. Each eval takes place in its own environment and no bindings
survive the completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration
forms (let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly
contains any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics
Re: eval of let, etc. Was: Re: restrictions on let declarations
As far as I can see, your #4 and my #1 are exactly the same. How do you think
they differ?
Allen
On Feb 14, 2014, at 8:03 AM, Jeremy Martin wrote:
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically considered
a block, the let binding would survive past the completion of the eval in
non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
I'm not necessarily arguing for that behavior, but weighing in since that's
the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical declaration
forms, but I hope the example from above will be evaluated in a new block.
See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
report.
Goood point and this is something I need to specify in the next couple weeks
so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new environment
that is immediately nested within the current LexicalEnvironment. The scoping
behavior is essentially the same as if the eval code was the body of an iife
that occurred at the same place as the eval call. Bindings introduced by the
eval code disappear after completion of the eval.
In non-strict mode, each eval instantiates all declarations in the current
VariableEnvironment; that is the most immediately enclosing function or
global environment. Bindings introduced by the eval code remain accessible
from that VariableEnvironment after completion of the eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact same
way. Each eval takes place in its own environment and no bindings survive the
completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration forms
(let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly contains
any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics for var/function
declarations but place let/const/class bindings into a per eval environment:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // ReferenceError: localToEval is not defined
)();
It would certainly be possible to specify #1, but I don't like it. Other than
for the global environment it would be cleaner if the new block scope-able
declarations were never dynamically added to the environment.
I think either #2 or #3 is plausible. #2 is a simpler story but introduces a
refactoring hazard. If you have some existing eval code that defines some
global functions or variables, then simply adding a let/const/class
declaration to the eval code ruins those global declarations.
I prefer the simplicity of #2, but I also worry about the WTF impact it might
have on evolving existing code.
Can we get away with #2, or are we going to have to go with #3? Are there
other alternatives?
Allen
___
es-discuss mailing list
Re: eval of let, etc. Was: Re: restrictions on let declarations
As far as I can see, your #4 and my #1 are exactly the same. How do you
think they differ?
Actually, on a second read, I don't think they are. I was perhaps more
explicit regarding strict mode, but I think the behavior there was already
clear enough to everyone. :)
On Fri, Feb 14, 2014 at 12:14 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
As far as I can see, your #4 and my #1 are exactly the same. How do you
think they differ?
Allen
On Feb 14, 2014, at 8:03 AM, Jeremy Martin wrote:
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically
considered a block, the let binding would survive past the completion of
the eval in non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
I'm not necessarily arguing for that behavior, but weighing in since
that's the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical declaration
forms, but I hope the example from above will be evaluated in a new block.
See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
report.
Goood point and this is something I need to specify in the next couple
weeks so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new
environment that is immediately nested within the current
LexicalEnvironment. The scoping behavior is essentially the same as if the
eval code was the body of an iife that occurred at the same place as the
eval call. Bindings introduced by the eval code disappear after completion
of the eval.
In non-strict mode, each eval instantiates all declarations in the
current VariableEnvironment; that is the most immediately enclosing
function or global environment. Bindings introduced by the eval code
remain accessible from that VariableEnvironment after completion of the
eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact
same way. Each eval takes place in its own environment and no bindings
survive the completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration
forms (let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly
contains any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics for var/function
declarations but place let/const/class bindings into a per eval environment:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
It would certainly be possible to specify #1, but I don't like it. Other
than for the global environment it would be cleaner if the new block
scope-able declarations were never dynamically added to the environment.
I think either #2 or #3 is plausible. #2 is a simpler story but
introduces a refactoring hazard. If you have some existing eval code that
defines some global functions or variables, then simply adding a
let/const/class declaration to the eval code ruins those global
declarations.
I prefer the simplicity of #2, but I also
Re: eval of let, etc. Was: Re: restrictions on let declarations
1 or 3. We have already shot down similiar situations to 2 before. I don't
think it is worth bringing this up again.
1 is the least surprise. It is just bad practice, but so is eval and non
strict mode in the first place.
3 is fine if you think as if there was a block around the whole thing
(except for functions in block in non strict mode).
On Fri Feb 14 2014 at 1:42:13 PM, Jeremy Martin jmar...@gmail.com wrote:
As far as I can see, your #4 and my #1 are exactly the same. How do
you think they differ?
Actually, on a second read, I don't think they are. I was perhaps more
explicit regarding strict mode, but I think the behavior there was already
clear enough to everyone. :)
On Fri, Feb 14, 2014 at 12:14 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
As far as I can see, your #4 and my #1 are exactly the same. How do you
think they differ?
Allen
On Feb 14, 2014, at 8:03 AM, Jeremy Martin wrote:
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically
considered a block, the let binding would survive past the completion of
the eval in non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
I'm not necessarily arguing for that behavior, but weighing in since
that's the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical declaration
forms, but I hope the example from above will be evaluated in a new block.
See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
report.
Goood point and this is something I need to specify in the next couple
weeks so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new
environment that is immediately nested within the current
LexicalEnvironment. The scoping behavior is essentially the same as if the
eval code was the body of an iife that occurred at the same place as the
eval call. Bindings introduced by the eval code disappear after completion
of the eval.
In non-strict mode, each eval instantiates all declarations in the current
VariableEnvironment; that is the most immediately enclosing function or
global environment. Bindings introduced by the eval code remain accessible
from that VariableEnvironment after completion of the eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact same
way. Each eval takes place in its own environment and no bindings survive
the completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration
forms (let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
2) Use the strict mode binding semantics if the eval code directly
contains any of the new declaration forms:
(function() {
eval(
var answer=42;
let forceSeprateEnvironment = true;
);
console.log(answer); // ReferenceError: answer is not defined
})();
3) Combination. use ES5 non-strict binding semantics for var/function
declarations but place let/const/class bindings into a per eval environment:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // ReferenceError: localToEval is not
defined
)();
It would certainly be possible to specify #1, but I don't like it. Other
than for the global environment it would be
Re: eval of let, etc. Was: Re: restrictions on let declarations
On further reflection, #3 does feel like trying to rewrite the past. For
better or worse, non-strict mode allows declarations to persist past the
eval(). And while strict mode provides a license-to-kill on behavior like
that, I don't really see strong justification for that kind of surprise
factor for let in non-strict mode.
If you're not using strict mode AND you're using eval(), the damage is
arguably already done (or at least the danger already exists). Changing
the behavior of let in this case feels like removing an arbitrary* foot-gun
when we're already in the armory, so to speak.
* Granted it's not completely arbitrary, since `let` is new whereas `var`
is not, but hopefully you get my point...
On Fri, Feb 14, 2014 at 2:23 PM, Erik Arvidsson erik.arvids...@gmail.comwrote:
1 or 3. We have already shot down similiar situations to 2 before. I don't
think it is worth bringing this up again.
1 is the least surprise. It is just bad practice, but so is eval and non
strict mode in the first place.
3 is fine if you think as if there was a block around the whole thing
(except for functions in block in non strict mode).
On Fri Feb 14 2014 at 1:42:13 PM, Jeremy Martin jmar...@gmail.com wrote:
As far as I can see, your #4 and my #1 are exactly the same. How do
you think they differ?
Actually, on a second read, I don't think they are. I was perhaps more
explicit regarding strict mode, but I think the behavior there was already
clear enough to everyone. :)
On Fri, Feb 14, 2014 at 12:14 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
As far as I can see, your #4 and my #1 are exactly the same. How do you
think they differ?
Allen
On Feb 14, 2014, at 8:03 AM, Jeremy Martin wrote:
I rather hate to say it, but I would've actually expected:
4) Given that the eval'd string doesn't create anything typically
considered a block, the let binding would survive past the completion of
the eval in non-strict mode:
(function() {
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // 42
console.log(localToEval); // true
)();
(function() {
use strict;
eval(
var answer=42;
let localToEval = true;
);
console.log(answer); // ReferenceError: answer is not defined
console.log(localToEval); // ReferenceError: localToEval is
not defined
)();
I'm not necessarily arguing for that behavior, but weighing in since
that's the behavior I would have expected based on existing ES5
strict/non-strict/eval and ES6 let semantics...
On Fri, Feb 14, 2014 at 10:40 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Feb 14, 2014, at 5:49 AM, André Bargull wrote:
How about this?
let x= 0;
if (1) eval(let x= 42; alert(x);); //Is this in its own block?
alert(x);
`eval()` hasn't yet been updated to work with the new lexical declaration
forms, but I hope the example from above will be evaluated in a new block.
See https://bugs.ecmascript.org/show_bug.cgi?id=1788 for a related bug
report.
Goood point and this is something I need to specify in the next couple
weeks so let's look at the alternatives.
First a quick refresher on ES5 era eval.
In ES5, the binding behavior of direct eval differs between strict and
non-strict modes.
In strict mode, each eval instantiates all declarations in a new
environment that is immediately nested within the current
LexicalEnvironment. The scoping behavior is essentially the same as if the
eval code was the body of an iife that occurred at the same place as the
eval call. Bindings introduced by the eval code disappear after completion
of the eval.
In non-strict mode, each eval instantiates all declarations in the
current VariableEnvironment; that is the most immediately enclosing
function or global environment. Bindings introduced by the eval code
remain accessible from that VariableEnvironment after completion of the
eval.
For example:
(function() {
use strict;
eval(var answer=42);
console.log(answer); // ReferenceError: answer is not defined
})();
(function() {
eval(var answer=42);
console.log(answer); // 42
})();
For ES6, it makes sense for strict mode evals to behave in this exact
same way. Each eval takes place in its own environment and no bindings
survive the completion of the eval.
For ES6, non-strict evals of code containing only var or function
declarations must have exactly the ES5 behavior in order to maintain
compatibility. But what about eval code that contains new declaration
forms (let/const/class) exclusively or in combination with var/function
declarations? Three possibilities come to mind:
1) Extend the ES5 semantics to include the new declaration forms. For
example:
(function() {
eval(let answer=42);
console.log(answer); // 42
})();
Re: eval of let, etc. Was: Re: restrictions on let declarations
On Feb 14, 2014, at 11:38 AM, Jeremy Martin wrote: On further reflection, #3 does feel like trying to rewrite the past. For better or worse, non-strict mode allows declarations to persist past the eval(). And while strict mode provides a license-to-kill on behavior like that, I don't really see strong justification for that kind of surprise factor for let in non-strict mode. If you're not using strict mode AND you're using eval(), the damage is arguably already done (or at least the danger already exists). Changing the behavior of let in this case feels like removing an arbitrary* foot-gun when we're already in the armory, so to speak. * Granted it's not completely arbitrary, since `let` is new whereas `var` is not, but hopefully you get my point. Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
Allen Wirfs-Brock wrote: the various forms of eval are already micro-mode, so I'm not sure if those points are very relevant. No, the various forms of eval do not have non-local effects of the kind your #2 did! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
Allen Wirfs-Brock wrote: On Feb 14, 2014, at 11:38 AM, Jeremy Martin wrote: On further reflection, #3 does feel like trying to rewrite the past. For better or worse, non-strict mode allows declarations to persist past the eval(). And while strict mode provides a license-to-kill on behavior like that, I don't really see strong justification for that kind of surprise factor for let in non-strict mode. If you're not using strict mode AND you're using eval(), the damage is arguably already done (or at least the danger already exists). Changing the behavior of let in this case feels like removing an arbitrary* foot-gun when we're already in the armory, so to speak. * Granted it's not completely arbitrary, since `let` is new whereas `var` is not, but hopefully you get my point. Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
It seems unfortunate that let and const have different usage rules from
var. It seem strange that var is considered a statement and not
declaration as per:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-statements-and-declarations
Generally, I've always thought of:
if (x) ... as equivalent to if (x) { ... }
Does this restriction on let/const enable anything?
On Wed, Jan 29, 2014 at 10:31 PM, Erik Arvidsson
erik.arvids...@gmail.comwrote:
It falls out of the grammar.
IfStatement can only contain Statement which does not include Declaration
without going through a BlockStatement.
On Wed, Jan 29, 2014 at 9:57 PM, John Lenz concavel...@gmail.com wrote:
I have some old notes that says that let can't be used in some
context where a var could like:
if (a) let x = 2;
In my perusal of the spec I don't see that this is the case now. Can
someone confirm that for me?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
John Lenz wrote:
Generally, I've always thought of:
if (x) ... as equivalent to if (x) { ... }
let and const (and class) are block-scoped. {...} in your if (x) {...}
is a block. An unbraced consequent is not a block, and you can't have a
conditional let binding.
The restriction avoids nonsense such as
let x = 0; { if (y) let x = 42; alert(x); }
What pray tell is going on here, in your model?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich bren...@mozilla.com wrote:
John Lenz wrote:
Generally, I've always thought of:
if (x) ... as equivalent to if (x) { ... }
let and const (and class) are block-scoped. {...} in your if (x) {...}
is a block. An unbraced consequent is not a block, and you can't have a
conditional let binding.
The restriction avoids nonsense such as
let x = 0; { if (y) let x = 42; alert(x); }
What pray tell is going on here, in your model?
I'm with John: the alert should say 0 and I can't see why that is not
obvious.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
On Jan 30, 2014, at 7:43 AM, John Lenz wrote:
It seems unfortunate that let and const have different usage rules from
var. It seem strange that var is considered a statement and not
declaration as per:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-statements-and-declarations
Generally, I've always thought of:
if (x) ... as equivalent to if (x) { ... }
Does this restriction on let/const enable anything?
The anomaly is that 'var' was considered a statement in ES1. But note that the
only other declaration in the language ('function') at that time was not a
statement. See http://www.wirfs-brock.com/allen/draft-ES5.1/#sec-14
Declarations have global static impact within their containing scope (function
or block). It generally doesn't make any sense to use them in a conditional
context without an explicitly surrounding block that constrains their scope.
So all new declarative forms in ES6 are treated similarly to function. They
are declarations but not statements. Var must remain a statement for legacy
compatability.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
On Thu, Jan 30, 2014 at 10:59 AM, John Barton johnjbar...@google.comwrote:
On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich bren...@mozilla.com wrote:
John Lenz wrote:
Generally, I've always thought of:
if (x) ... as equivalent to if (x) { ... }
let and const (and class) are block-scoped. {...} in your if (x) {...}
is a block. An unbraced consequent is not a block, and you can't have a
conditional let binding.
The restriction avoids nonsense such as
let x = 0; { if (y) let x = 42; alert(x); }
What pray tell is going on here, in your model?
I'm with John: the alert should say 0 and I can't see why that is not
obvious.
It's not obvious at all -- what happens when you drop the initial `let x =
0;` and you just have `{ if (y) let x = 42; alert(x); }` -- now what
happens? Is x declared or not?
To my mind `if (y) let x = 42;` reads like it's own 1-line noop block -- at
least, that's what I'd expect of the scope. So while it could be allowed in
that sense, it'd only serve as a footgun when y is true.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
John Barton wrote:
On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
John Lenz wrote:
Generally, I've always thought of:
if (x) ... as equivalent to if (x) { ... }
let and const (and class) are block-scoped. {...} in your if (x)
{...} is a block. An unbraced consequent is not a block, and you
can't have a conditional let binding.
The restriction avoids nonsense such as
let x = 0; { if (y) let x = 42; alert(x); }
What pray tell is going on here, in your model?
I'm with John: the alert should say 0 and I can't see why that is not
obvious.
Interesting!
You don't want the alert to show undefined, so the extent of the inner
binding in your model is the unbraced consequent of the if.
That is not block scope in any plain sense.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
On Jan 30, 2014, at 8:07 AM, Dean Landolt d...@deanlandolt.com wrote:
On Thu, Jan 30, 2014 at 10:59 AM, John Barton johnjbar...@google.com wrote:
On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich bren...@mozilla.com wrote:
John Lenz wrote:
Generally, I've always thought of:
if (x) ... as equivalent to if (x) { ... }
let and const (and class) are block-scoped. {...} in your if (x) {...} is a
block. An unbraced consequent is not a block, and you can't have a
conditional let binding.
The restriction avoids nonsense such as
let x = 0; { if (y) let x = 42; alert(x); }
What pray tell is going on here, in your model?
I'm with John: the alert should say 0 and I can't see why that is not obvious.
It's not obvious at all -- what happens when you drop the initial `let x =
0;` and you just have `{ if (y) let x = 42; alert(x); }` -- now what happens?
Is x declared or not?
To my mind `if (y) let x = 42;` reads like it's own 1-line noop block -- at
least, that's what I'd expect of the scope. So while it could be allowed in
that sense, it'd only serve as a footgun when y is true.
This is exactly foot gun the language restriction is intended to avoid.
Most modern [Obj-]C[++] will warn on this (well, s/let/int/)
You might be getting confused because of the bizarro var hoisting semantics of
var
if (y) let x = “nope; alert(x)
Results in an unusable binding of x, and so this would throw (the foot gun
occurs if you’re shadowing x, that’s another shadow that i think C compilers
will warn on), e.g..
y = true; let x = “whoops”; if (y) let x = “nope; alert(x) // “whoops
The var case
y = true; var x = “whoops”; if (y) var x = “nope; alert(x); // “nope
is actually interpreted as
var x; y= true; x = “whoops”; if (y) x = “nope”; alert(x); // “nope
That craziness is the whole point of block scoping let. More interestingly
if (window.SomeCrazyDomFeature) var foo = true;
is a common web idiom as it brings foo into scope for everything, so makes
later if (foo) “ statements safe. Anyone trying to do this with a |let| would
get incorrect (from their PoV) behaviour. Again that’s why we error out.
Give that this is the behaviour of every other block scoped language i don’t
see why this is confusing.
—Oliver
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
In my model
if (y) let x = 42
is equivalent to
if (y) {
let x = 42
}
and it is clear x in alert(x) is 0;
On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich bren...@mozilla.com wrote:
John Lenz wrote:
Generally, I've always thought of:
if (x) ... as equivalent to if (x) { ... }
let and const (and class) are block-scoped. {...} in your if (x) {...}
is a block. An unbraced consequent is not a block, and you can't have a
conditional let binding.
The restriction avoids nonsense such as
let x = 0; { if (y) let x = 42; alert(x); }
What pray tell is going on here, in your model?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
On Thu, Jan 30, 2014 at 10:59 AM, John Barton That craziness is the whole point of block scoping let. ... Give that this is the behaviour of every other block scoped language i don’t see why this is confusing. It's not `let` vs `var` that concerns us, it's that the statement following an if condition is not equivalent to a block. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
How did let x in for-loops land:
for (let x = 1; x 10 ; i++) {
// is x a fresh binding for every iteration?
}
This wouldn't be block scoping either.
On Thu, Jan 30, 2014 at 8:13 AM, Brendan Eich bren...@mozilla.com wrote:
John Barton wrote:
On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich bren...@mozilla.commailto:
bren...@mozilla.com wrote:
John Lenz wrote:
Generally, I've always thought of:
if (x) ... as equivalent to if (x) { ... }
let and const (and class) are block-scoped. {...} in your if (x)
{...} is a block. An unbraced consequent is not a block, and you
can't have a conditional let binding.
The restriction avoids nonsense such as
let x = 0; { if (y) let x = 42; alert(x); }
What pray tell is going on here, in your model?
I'm with John: the alert should say 0 and I can't see why that is not
obvious.
Interesting!
You don't want the alert to show undefined, so the extent of the inner
binding in your model is the unbraced consequent of the if.
That is not block scope in any plain sense.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
On Thu, Jan 30, 2014 at 8:26 AM, John Lenz concavel...@gmail.com wrote:
In my model
if (y) let x = 42
is equivalent to
if (y) {
let x = 42
}
Yes, everyone here understands your model. This is a question of
taste. There are competing senses of what is intuitive at play.
-j
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
On Thu, Jan 30, 2014 at 11:39 AM, John Lenz concavel...@gmail.com wrote:
How did let x in for-loops land:
for (let x = 1; x 10 ; i++) {
// is x a fresh binding for every iteration?
Yes.
}
This wouldn't be block scoping either.
See:
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-11/nov-20.md#consensusresolution-6
Rick
On Thu, Jan 30, 2014 at 8:13 AM, Brendan Eich bren...@mozilla.com wrote:
John Barton wrote:
On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich bren...@mozilla.commailto:
bren...@mozilla.com wrote:
John Lenz wrote:
Generally, I've always thought of:
if (x) ... as equivalent to if (x) { ... }
let and const (and class) are block-scoped. {...} in your if (x)
{...} is a block. An unbraced consequent is not a block, and you
can't have a conditional let binding.
The restriction avoids nonsense such as
let x = 0; { if (y) let x = 42; alert(x); }
What pray tell is going on here, in your model?
I'm with John: the alert should say 0 and I can't see why that is not
obvious.
Interesting!
You don't want the alert to show undefined, so the extent of the inner
binding in your model is the unbraced consequent of the if.
That is not block scope in any plain sense.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
John Lenz wrote:
In my model
if (y) let x = 42
is equivalent to
if (y) {
let x = 42
}
and it is clear x in alert(x) is 0;
It is as clear as those invisible braces in your model's input :-P.
Come on, this is silly. var has quirks, but we are not propagating
them to other forms, making implicit blocks where no braces exist, etc.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
John Lenz wrote:
How did let x in for-loops land:
for (let x = 1; x 10 ; i++) {
// is x a fresh binding for every iteration?
}
This wouldn't be block scoping either.
It is -- special forms that have heads can bind in bodies. We see this
with formal parameters to functions, also with the defunct let blocks
and let expressions of ES4. ML has similar forms.
We made this block scoping, and how! Turns out Dart did the same. Each
iteration gets a fresh binding. If there's a closure in the first part
of the for(;;) head that captures the loop variable, it gets a 0th
iteration binding.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
On Thu, Jan 30, 2014 at 12:10 PM, Brendan Eich bren...@mozilla.com wrote:
John Lenz wrote:
How did let x in for-loops land:
for (let x = 1; x 10 ; i++) {
// is x a fresh binding for every iteration?
}
This wouldn't be block scoping either.
It is -- special forms that have heads can bind in bodies. We see this
with formal parameters to functions, also with the defunct let blocks and
let expressions of ES4. ML has similar forms.
We made this block scoping, and how! Turns out Dart did the same. Each
iteration gets a fresh binding. If there's a closure in the first part of
the for(;;) head that captures the loop variable, it gets a 0th iteration
binding.
Also, there was very positive interest in Waldemar's proposed if-scoped
let, here:
https://mail.mozilla.org/pipermail/es-discuss/2013-December/035077.html
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
On Thu, Jan 30, 2014 at 8:59 AM, Brendan Eich bren...@mozilla.com wrote:
John Lenz wrote:
In my model
if (y) let x = 42
is equivalent to
if (y) {
let x = 42
}
and it is clear x in alert(x) is 0;
It is as clear as those invisible braces in your model's input :-P.
Come on, this is silly.
Not silly. Can you suggest any on-line that most JS developers can
understand discussing how these two forms differ?
Here are some that describe them as equivalent:
http://en.wikipedia.org/wiki/JavaScript_syntax#If_..._else
http://msdn.microsoft.com/en-us/library/kw1tezhk(v=vs.94).aspx
http://programmers.stackexchange.com/questions/16528/single-statement-if-block-braces-or-no
http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Flanguage%2Fref%2Fclrc08csor.htm
http://msdn.microsoft.com/en-us/library/ms173143.aspx
and so on across multiple languages. Whether or not you think these forms
should be different, programmers don't expect them to differ.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
On Thu, Jan 30, 2014 at 12:24 PM, Brendan Eich bren...@mozilla.com wrote: Rick Waldron wrote: It is -- special forms that have heads can bind in bodies. We see this with formal parameters to functions, also with the defunct let blocks and let expressions of ES4. ML has similar forms. We made this block scoping, and how! Turns out Dart did the same. Each iteration gets a fresh binding. If there's a closure in the first part of the for(;;) head that captures the loop variable, it gets a 0th iteration binding. Also, there was very positive interest in Waldemar's proposed if-scoped let, here: https://mail.mozilla.org/pipermail/es-discuss/2013- December/035077.html Nick Krempel proposed that upthread, just for the record. Yes, my mistake--I had looked in December archives and found what I thought was the OP. This is the correct OP from November: https://mail.mozilla.org/pipermail/es-discuss/2013-November/035060.html Rick Yeah, it's good. It comes from C++ but goes back to Algol, IIRC. Another precedent for block-scoped bindings that are declared in heads. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
John Barton wrote: Not silly. Can you suggest any on-line that most JS developers can understand discussing how these two forms differ? Here are some that describe them as equivalent: http://en.wikipedia.org/wiki/JavaScript_syntax#If_..._else http://msdn.microsoft.com/en-us/library/kw1tezhk(v=vs.94).aspx http://msdn.microsoft.com/en-us/library/kw1tezhk%28v=vs.94%29.aspx http://programmers.stackexchange.com/questions/16528/single-statement-if-block-braces-or-no http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Flanguage%2Fref%2Fclrc08csor.htm http://msdn.microsoft.com/en-us/library/ms173143.aspx and so on across multiple languages. Whether or not you think these forms should be different, programmers don't expect them to differ. This is all beside the point, since the unbraced let as consequent of if cannot make a useful binding (if you use comma-separated multiple declarators, you still can't use any of the values that initialize the bindings except in later useless-outside-the-single-declaration consequent). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
I don't argue that it isn't a useless let. I do point out that in sloppy mode, that other declaration are allow in practices by browsers. Chrome allows function, const, and var in the body of an if without block. It does seems like an unnecessary restriction, and with it I'll need to make sure that Closure Compiler doesn't introduce these when stripping blocks, not a big deal just one more thing to deal with. I was just hoping that the restriction was enabling something and not just noise. On Thu, Jan 30, 2014 at 11:00 AM, Brendan Eich bren...@mozilla.com wrote: John Barton wrote: Not silly. Can you suggest any on-line that most JS developers can understand discussing how these two forms differ? Here are some that describe them as equivalent: http://en.wikipedia.org/wiki/JavaScript_syntax#If_..._else http://msdn.microsoft.com/en-us/library/kw1tezhk(v=vs.94).aspx http://msdn.microsoft.com/en-us/library/kw1tezhk%28v=vs.94%29.aspx http://programmers.stackexchange.com/questions/16528/single-statement-if- block-braces-or-no http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/ index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Flanguage%2Fref%2Fclrc08csor.htm http://msdn.microsoft.com/en-us/library/ms173143.aspx and so on across multiple languages. Whether or not you think these forms should be different, programmers don't expect them to differ. This is all beside the point, since the unbraced let as consequent of if cannot make a useful binding (if you use comma-separated multiple declarators, you still can't use any of the values that initialize the bindings except in later useless-outside-the-single-declaration consequent). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
On Jan 30, 2014, at 11:27 AM, John Lenz concavel...@gmail.com wrote: I don't argue that it isn't a useless let. I do point out that in sloppy mode, that other declaration are allow in practices by browsers. Chrome allows function, const, and var in the body of an if without block. That’s because they _have_ to be allowed as these constructs are used on millions (billions?) of web pages. Disallowing that behaviour would break the web and we can’t do that. Introducing new constructs that expose the same coding problems is not worth it - maybe we would want to change something in the future but we would already have been burned by existing content using this code incorrectly. —Oliver It does seems like an unnecessary restriction, and with it I'll need to make sure that Closure Compiler doesn't introduce these when stripping blocks, not a big deal just one more thing to deal with. I was just hoping that the restriction was enabling something and not just noise. On Thu, Jan 30, 2014 at 11:00 AM, Brendan Eich bren...@mozilla.com wrote: John Barton wrote: Not silly. Can you suggest any on-line that most JS developers can understand discussing how these two forms differ? Here are some that describe them as equivalent: http://en.wikipedia.org/wiki/JavaScript_syntax#If_..._else http://msdn.microsoft.com/en-us/library/kw1tezhk(v=vs.94).aspx http://msdn.microsoft.com/en-us/library/kw1tezhk%28v=vs.94%29.aspx http://programmers.stackexchange.com/questions/16528/single-statement-if-block-braces-or-no http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Flanguage%2Fref%2Fclrc08csor.htm http://msdn.microsoft.com/en-us/library/ms173143.aspx and so on across multiple languages. Whether or not you think these forms should be different, programmers don't expect them to differ. This is all beside the point, since the unbraced let as consequent of if cannot make a useful binding (if you use comma-separated multiple declarators, you still can't use any of the values that initialize the bindings except in later useless-outside-the-single-declaration consequent). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
On Thu, Jan 30, 2014 at 2:27 PM, John Lenz concavel...@gmail.com wrote: I don't argue that it isn't a useless let. I do point out that in sloppy mode, that other declaration are allow in practices by browsers. Chrome allows function, const, and var in the body of an if without block. Did you mean to include const? Only IE11 has implemented const and let with the proper semantics (with the exception of the for loop let binding mistake, which will be corrected). Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
Yes, that was my point, that is has to be allowed currently and this is a change. Using what incorrectly? Existing const and function implementations? Or if scoped declarations? On Thu, Jan 30, 2014 at 11:35 AM, Oliver Hunt oli...@apple.com wrote: On Jan 30, 2014, at 11:27 AM, John Lenz concavel...@gmail.com wrote: I don't argue that it isn't a useless let. I do point out that in sloppy mode, that other declaration are allow in practices by browsers. Chrome allows function, const, and var in the body of an if without block. That's because they _have_ to be allowed as these constructs are used on millions (billions?) of web pages. Disallowing that behaviour would break the web and we can't do that. Introducing new constructs that expose the same coding problems is not worth it - maybe we would want to change something in the future but we would already have been burned by existing content using this code incorrectly. --Oliver It does seems like an unnecessary restriction, and with it I'll need to make sure that Closure Compiler doesn't introduce these when stripping blocks, not a big deal just one more thing to deal with. I was just hoping that the restriction was enabling something and not just noise. On Thu, Jan 30, 2014 at 11:00 AM, Brendan Eich bren...@mozilla.comwrote: John Barton wrote: Not silly. Can you suggest any on-line that most JS developers can understand discussing how these two forms differ? Here are some that describe them as equivalent: http://en.wikipedia.org/wiki/JavaScript_syntax#If_..._else http://msdn.microsoft.com/en-us/library/kw1tezhk(v=vs.94).aspx http://msdn.microsoft.com/en-us/library/kw1tezhk%28v=vs.94%29.aspx http://programmers.stackexchange.com/questions/ 16528/single-statement-if-block-braces-or-no http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/ index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Flanguage%2Fref%2Fclrc08csor.htm http://msdn.microsoft.com/en-us/library/ms173143.aspx and so on across multiple languages. Whether or not you think these forms should be different, programmers don't expect them to differ. This is all beside the point, since the unbraced let as consequent of if cannot make a useful binding (if you use comma-separated multiple declarators, you still can't use any of the values that initialize the bindings except in later useless-outside-the-single-declaration consequent). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
On Thu, Jan 30, 2014 at 2:59 PM, John Lenz concavel...@gmail.com wrote: Yes, that was my point, that is has to be allowed currently and this is a change. But let and const aren't the same as var and function, they have different syntax with different static and runtime semantics. New forms are allowed to have new rules, especially ones that make writing code with the new forms more intuitive and less error prone. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
John Lenz wrote: I don't argue that it isn't a useless let. I do point out that in sloppy mode, that other declaration are allow in practices by browsers. Chrome allows function, const, and var in the body of an if without block. But those aren't useless. They are quirky, but they do not bind in the consequent only, which is exactly what you and John said you wanted for if(x)let y=z. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
restrictions on let declarations
I have some old notes that says that let can't be used in some context where a var could like: if (a) let x = 2; In my perusal of the spec I don't see that this is the case now. Can someone confirm that for me? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
It falls out of the grammar. IfStatement can only contain Statement which does not include Declaration without going through a BlockStatement. On Wed, Jan 29, 2014 at 9:57 PM, John Lenz concavel...@gmail.com wrote: I have some old notes that says that let can't be used in some context where a var could like: if (a) let x = 2; In my perusal of the spec I don't see that this is the case now. Can someone confirm that for me? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
