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).
Yes.
> * 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,
/be
More information about the es-discuss
mailing list