lexical for-in/for-of loose end

Brendan Eich brendan at mozilla.org
Mon Feb 6 17:32:47 PST 2012

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 [[Scope]] adjusted every iteration.

For the code you evaluate "Herby's body-swap" against, the "flat 
closure" (Chez Scheme "display closure") formation is indeed good 
optimization. The closure passed to setTimeout post-dominates the only 
live (from its point of view) assignments to i, so copying i's value 
into the closure allows very fast access and no scope entrainment at all.

A harder case would mutate upvars after the closure is evaluated, so 
that it must capture references not values. In any case, the scope would 
need to be cloned on each iteration where closures formed, and those 
closures' [[Scope]] internal properties updated.

Allen should comment on whether this attempt to square the circle 
(kidding, mostly) might fly in the spec. Implementors while secondary 
should weigh in too.

> * Herby's body-swap gives an apparent desugaring with just one scope
> for the loop variables

Yes, that is tempting. Kudoes to you and Herby for pushing this. Great 
use of es-discuss.

> * Herby's init-swap might need to be concerned about shape changes
> (due to eval or such).


> * Both of them pretty much require some form of scope cloning or scope
> modification that does not match anything currently in the spec.

This is another one for Allen.

> * Both of them make closures in the init and in the rest see a
> consistent world, for as long as is possible, while still giving body
> closures unique copies per iteration.

Is there any inconsistency observable after "as long as possible"? I 
can't find one.

> Sorry for the long email, but I thought the detail could help iron out
> any of the remaining (lesser) misunderstandings.

No need to apologize. My warnings about DWIM are general, and you and 
Herby have proposed specific solutions. Worth going over in detail. 
Thanks again,


More information about the es-discuss mailing list