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 _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
