On 4 February 2012 21:55, Brendan Eich bren...@mozilla.org wrote:
The argument is as follows:
for (let i = 0, a = some.array, n = a.length; i n; i++) { ... }
here we definitely want the a in a.length (n's initializer) to be scoped by
the head let -- to be the a declared by the second
On 4 February 2012 18:49, Brendan Eich bren...@mozilla.org wrote:
I agree we want to capture the first-iteration bindings in any closures in
those declarators' initializers.
This requires unrolling the loop once. Let's see how the desugaring from:
for (let d1 = e1, ... dN = eN; cond;
Andreas Rossberg wrote:
On 4 February 2012 21:55, Brendan Eichbren...@mozilla.org wrote:
The argument is as follows:
for (let i = 0, a = some.array, n = a.length; i n; i++) { ... }
here we definitely want the a in a.length (n's initializer) to be scoped by
the head let -- to be
Andreas Rossberg wrote:
On 4 February 2012 18:49, Brendan Eichbren...@mozilla.org wrote:
In other words, why isn't the following good enough?
{
let d1 = e1, ..., dN = eN;
const $loop = {|d1, ..., dN|
if (cond) {
body
update;
$loop(d1, ..., dN);
}
}
$loop(d1,
On 6 February 2012 16:28, Brendan Eich bren...@mozilla.org wrote:
Andreas Rossberg wrote:
Agreed. As long as we don't spec something weird, the extra effort for
implementations shouldn't be much more than that of an extra block
around the loop body.
To take Allen's best shot and re-fire it,
Andreas Rossberg wrote:
On 6 February 2012 16:28, Brendan Eichbren...@mozilla.org wrote:
Andreas Rossberg wrote:
Agreed. As long as we don't spec something weird, the extra effort for
implementations shouldn't be much more than that of an extra block
around the loop body.
To take
Brendan Eich wrote:
[Grant Husbands wrote:]
'Note' all closures (dynamically) created in (lexically) the loop
initializer.
Only in the initializer? Why should closures formed there be dynamically
scoped to the current iteration?
Because that directly serves the use cases that have
On Feb 6, 2012, at 7:59 AM, Brendan Eich wrote:
Andreas Rossberg wrote:
...
Yes, this is something Jon Zeppieri brought up as a reason not to do
fresh-binding-per-iteration in for(let;;) -- moving the initializer part out
of the loop loses the binding-per-iteration.
You've shown
On Thu, Feb 2, 2012 at 1:35 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
for (v of arr) // each element of an Array
for (v of set) // each value in a Set
for (k of map) // each key in a Map, following Python
Smalltalk defaults maps to the value and Ruby to the key/value pair.
Grant Husbands wrote:
But this is all beyond the spec.
I don't think it is. What Herby's idea and these formulations present
is a way for let-based loops to have modifications in closures
captured in the for-head that alter the loop variables in a way that's
visible to the current loop
Allen Wirfs-Brock wrote:
We're putting a lot of energy into trying to figure out how to fix for(let;;)
when it probably shouldn't even be the preferred form of numeric looping going forward.
If we can make for-in/for-of attractive enough then it is less clear why we need to fix
for(;;)
for
On Feb 6, 2012, at 11:24 AM, Brendan Eich wrote:
You make a good point: we should not overcomplicate for(let;;) at high cost.
I'm happy with Andreas's proposed 0th-iter scope desugaring, modulo nagging
doubts that are going away even as I type.
particularly, when somebody who really
Brendan Eich wrote:
Grant Husbands wrote:
But this is all beyond the spec.
I don't think it is. What Herby's idea and these formulations present
is a way for let-based loops to have modifications in closures
captured in the for-head that alter the loop variables in a way that's
visible to the
Herby Vojčík wrote:
I definitely think INIT should not have any special behaviour for 1st
and for subsequent iterations. The semantics of the loop is then much
more straightforward and less magical. So in case of these desugaring, I
am for 0th iteration. To be able to read loop as { INIT; for
On 02/03/2012 08:07 PM, Mark S. Miller wrote:
On Fri, Feb 3, 2012 at 12:58 PM, Waldemar Horwat walde...@google.com
mailto:walde...@google.com wrote:
On 02/02/2012 06:27 PM, Waldemar Horwat wrote:
[...]
Note that this is more complex than just having the parser switch modes for
the
Grant Husbands wrote:
Now, there are some advantages and disadvantages:
Thanks for expanding on your and Herby's proposals, it helps. A
disadvantage on its face of Herby's init-swap is that variables are
copied from iteration scope to iteration scope, *and* all contained
closures need their
On Mon, Feb 6, 2012 at 3:26 PM, Waldemar Horwat walde...@google.com wrote:
On 02/03/2012 08:07 PM, Mark S. Miller wrote:
On Fri, Feb 3, 2012 at 12:58 PM, Waldemar Horwat walde...@google.commailto:
walde...@google.com wrote:
On 02/02/2012 06:27 PM, Waldemar Horwat wrote:
[...]
On Feb 6, 2012, at 5:32 PM, Brendan Eich wrote:
Grant Husbands wrote:
Now, there are some advantages and disadvantages:
Thanks for expanding on your and Herby's proposals, it helps. A disadvantage
on its face of Herby's init-swap is that variables are copied from
iteration scope to
Allen Wirfs-Brock wrote:
For both, I need to think about whether it may be possible (and the impact) for
a closure activation (containing a generator?) to span a iteration boundary.
Generators close over their lexical environment, yes. And of course an
active generator can survive invoking
19 matches
Mail list logo
