On Fri, 2012-01-20 at 19:19 +0100, Andreas Rossberg wrote:
How is
function(x) { let x }
any different in this respect from
{ let x { let x } }
In the former, there is no part of the body in which the parameter is
visible (modulo arguments, of course). I can see how that might be
On 20 January 2012 20:51, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
This is a recurring discussion. The discussion always seems to resolve
(perhaps with some unhappy acquiesce) that we want to follow the C++/Java/C#
(and other similar language) precedent adjusted to deal with legacy var
Jon Zeppieri wrote:
Is there a version of this desugaring that deals with recursive
bindings in the initializer expression of the loop?
How about something like this?
(given for (let varName = initExpr; testExpr; updateExpr) { body } )
{
let varName = initExpr;
while(true) {
if
A couple of remarks/questions...
On 20 January 2012 01:40, Waldemar Horwat walde...@google.com wrote:
Allen: Do top-level let and const create properties of the global object?
DaveH (channeling Andreas): No, but functions do.
If that is referring to me then there might have been a
Andreas Rossberg wrote:
On 20 January 2012 01:40, Waldemar Horwatwalde...@google.com wrote:
Also, function (e) {let e;} should always be an error.
Is there a good reason to do this? It would be an unnecessary
irregularity with block scoping, and seems like overly nanny-ish (in
stark contrast
On 20 January 2012 09:22, Herby Vojčík he...@mailbox.sk wrote:
+1. I see no point why let e; should not shadow argument e here.
I do. It is a virtual certainty that this form was used accidentally by
the developer, which indicates a flaw in the developer's thinking --
probably due to
On 19 January 2012 23:02, Brendan Eich bren...@mozilla.org wrote:
Yes kids, this means we are going with MarkM's lambda desugaring from:
https://mail.mozilla.org/**pipermail/es-discuss/2008-**October/007819.htmlhttps://mail.mozilla.org/pipermail/es-discuss/2008-October/007819.html
So any
So any closures formed in the body of such a for(let...;...;...) loop will
capture the binding created afresh for that iteration.
Thank you, Lord! \o/Can I get a Hallelujah? \o/
for (i=0; i alerts.length; i++) {
setTimeout(function(i) { return function() { m.add(alerts[i]) }
On Jan 20, 2012, at 6:22 AM, Herby Vojčík wrote:
Andreas Rossberg wrote:
On 20 January 2012 01:40, Waldemar Horwatwalde...@google.com wrote:
Also, function (e) {let e;} should always be an error.
Is there a good reason to do this? It would be an unnecessary
irregularity with block
On Jan 20, 2012, at 7:13 AM, Wes Garland wrote:
On 20 January 2012 09:22, Herby Vojčík he...@mailbox.sk wrote:
+1. I see no point why let e; should not shadow argument e here.
I do. It is a virtual certainty that this form was used accidentally by the
developer, which indicates a flaw
Allen Wirfs-Brock wrote:
On Jan 20, 2012, at 6:22 AM, Herby Vojčík wrote:
+1. I see no point why let e; should not shadow argument e here.
In general, the binding rules for function parameters were decided at
the Nov. 2011 meeting (see Nov 16 meeting notes):
MarkM: Two-scope model (one
On Fri, Jan 20, 2012 at 9:57 AM, Herby Vojčík he...@mailbox.sk wrote:
Single scope, args are lets view is making sense of this. Ok, thanks.
Another case together with this one seems to force us into Single scope,
args are vars:
function foo(e) { var e ... }
The var e is currently
On 20 January 2012 18:26, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On 20 January 2012 01:40, Waldemar Horwatwalde...@google.com wrote:
Also, function (e) {let e;} should always be an error.
Is there a good reason to do this? It would be an unnecessary
irregularity with block scoping,
On 20 January 2012 18:28, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Jan 20, 2012, at 7:13 AM, Wes Garland wrote:
On 20 January 2012 09:22, Herby Vojčík he...@mailbox.sk wrote:
+1. I see no point why let e; should not shadow argument e here.
I do. It is a virtual certainty that
Mark S. Miller mailto:erig...@google.com
January 20, 2012 10:15 AM
On Fri, Jan 20, 2012 at 9:57 AM, Herby Vojčík he...@mailbox.sk
mailto:he...@mailbox.sk wrote:
Single scope, args are lets view is making sense of this. Ok,
thanks.
Another case together with this one seems to force
Andreas Rossberg mailto:rossb...@google.com
January 20, 2012 10:17 AM
Here is a simple model: a function expression introduces one local
scope(*), which contains the parameters and the var variables hoisted
from its body (as in ES5). The function is evaluated by evaluating its
body _as a block_
On Jan 20, 2012, at 10:22 AM, Brendan Eich wrote:
Mark S. Miller mailto:erig...@google.com
January 20, 2012 10:15 AM
On Fri, Jan 20, 2012 at 9:57 AM, Herby Vojčík he...@mailbox.sk
mailto:he...@mailbox.sk wrote:
Single scope, args are lets view is making sense of this. Ok,
On Jan 20, 2012, at 10:19 AM, Andreas Rossberg wrote:
On 20 January 2012 18:28, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Jan 20, 2012, at 7:13 AM, Wes Garland wrote:
On 20 January 2012 09:22, Herby Vojčík he...@mailbox.sk wrote:
+1. I see no point why let e; should not
On Fri, Jan 20, 2012 at 7:25 AM, Grant Husbands esdisc...@grant.x43.net wrote:
Jon Zeppieri wrote:
Is there a version of this desugaring that deals with recursive
bindings in the initializer expression of the loop?
How about something like this?
(given for (let varName = initExpr; testExpr;
On Fri, Jan 20, 2012 at 5:08 PM, Jon Zeppieri zeppi...@gmail.com wrote:
It's one thing if the difference
really isn't observable except in the case where a closure captures
the iteration variable (as Sam suggests), since it's hard to imagine
anyone wanting the current binding behavior in that
On 01/19/2012 10:51 PM, Jon Zeppieri wrote:
On Thu, Jan 19, 2012 at 11:02 PM, Brendan Eichbren...@mozilla.org wrote:
Yes kids, this means we are going with MarkM's lambda desugaring from:
https://mail.mozilla.org/pipermail/es-discuss/2008-October/007819.html
Is there a version of this
Given that this desugaring will only kick in if a closure leaves the loop
(right?), this is a case of automatically doing the right thing (and only if
it’s warranted).
Yes kids, this means we are going with MarkM's lambda desugaring from:
2012/1/19 Kevin Reid kpr...@switchb.org
On Jan 19, 2012, at 19:40, Waldemar Horwat wrote:
Waldemar: What about read-eval-print loops?
MarkM: Each eval inserts one more nested scope.
This is not what users of REPL want or expect.
Waldemar: What if someone does this:
let x = 3;
Axel Rauschmayer mailto:a...@rauschma.de
January 19, 2012 8:20 PM
Given that this desugaring will only kick in if a closure leaves the
loop (right?), this is a case of automatically doing the right thing
(and only if it’s warranted).
Right, it's not observable without a closure.
The
On Thu, Jan 19, 2012 at 8:20 PM, Axel Rauschmayer a...@rauschma.de wrote:
Given that this desugaring will only kick in if a closure leaves the loop
(right?), this is a case of automatically doing the right thing (and only if
it’s warranted).
Yes kids, this means we are going with MarkM's
The downside, if it is a downside, is that if you take a literal C/C++ point
of view, and change
let a = [];
for (let i = 0; i 10; i++) {
a.push(function () { return i; });
}
for (let j in a) {
assert(a[j]() === j);
}
into
let a = [];
{
let i = 0;
for (; i 10; i++) {
On Thu, Jan 19, 2012 at 11:02 PM, Brendan Eich bren...@mozilla.org wrote:
Yes kids, this means we are going with MarkM's lambda desugaring from:
https://mail.mozilla.org/pipermail/es-discuss/2008-October/007819.html
Is there a version of this desugaring that deals with recursive
bindings in
27 matches
Mail list logo
