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 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.
My sense is that we could make these schemes works in spec. space. Either by allowing bindings that have References as values or by adding new mechanisms such environment cloning. It actually sounds fun and perhaps even the "right thing" to do. However, I have some doubts concerning whether the added work and spec. complexity is really justified by the benefit. Maybe, but there are lots seemingly more important things to work on. With "body-swap" it concerns me a bit that is an arbitrary and variable number of closures may need to be updated each iteration (consider a body containing a while loop that spits out closures that capture init bindings.) 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. Allen _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
