On Feb 4, 2012, at 8:01 AM, Jason Orendorff wrote:
> On Sat, Feb 4, 2012 at 8:02 AM, Jason Orendorff
> <[email protected]> wrote:
>> On Fri, Feb 3, 2012 at 7:26 PM, Allen Wirfs-Brock <[email protected]>
>> wrote:
>>> Under the scoping rules TC39 has agreed to, the initializer of a let/const
>>> is always shadowed by the binding it is initializing[...]
>>
>> That rule doesn't make sense in this context. There should be either
>> one V for the whole loop, or one V per iteration. Having both seems
>> perverse.
>
> I just realized—the loop variables have to be visible in the
> init-expressions if we want to support this:
>
> for (let a = getThings(), i = 0, n = a.length; i < n; i++)
>
> This is maybe not the best way to write "for (thing of getThings())",
> but people will write it, and so it probably ought to work. I think
> this is more important than escaping closures. This means that if such
> loops will have per-iteration bindings, they should have an additional
> set of bindings just for initialization-time—which seems ugly. Maybe
> it's not worth it.
That's what the initial
let V = INIT
I said you needed in your de-sugaring was intended to address
>
> There is also this:
>
> for (let i = 0; i < n; ) {
> setTimeout(...closure using i...);
> if (shouldAdvance())
> i++;
> }
>
> This will not work no matter what semantics we choose. However,
> per-iteration bindings risk encouraging people to hit this problem.
The
} finally {
%tmp = V
}
in your desugaring takes care of making sure that the the V value of the
previous iteration is available to the TEST expression
>
> These two issues give me pause.
>
> -j
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
