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
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
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
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
+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
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
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
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
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) { ... }
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
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
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;
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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:
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
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. {...}
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)
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
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
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
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
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:
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
50 matches
Mail list logo
