lexical for-in/for-of loose end

Grant Husbands esdiscuss at grant.x43.net
Sat Feb 4 19:01:03 PST 2012

Herby Vojčík wrote:
> It looks to me that all those schemes and desugaring are very complicated

The full problem is complicated, so that's to be expected.

> What is bad with scenario of reusing the same variable and isolating it as
> local only for the async closures?

Your proposal depends on being able to reassign variable pointers, but
they don't necessarily exist. Though I haven't written a JS engine, I
believe they are allowed to have variables directly in an activation
record (or environment instance) without any (pointer) indirection, so
they'd have no mechanism for performing the operation you describe.

However, though I haven't read it, I believe that the spec talks a
great deal about these activation records and environments, so
specifying a mechanism involving those might give you more chance of
finding common ground.

For what you're talking about, I think this might be an equivalent
proposal that's more spec-friendly:
'Note' all closures (dynamically) created in (lexically) the loop
initializer. Each time you start an iteration, update all the loop
variable activation record pointers within those to point at the
current iteration's activation record (which should, with care, have
the same shape).

Or, here's one that copies the other way (and is probably cleaner):
'Note' all closures (dynamically) created in (lexically,
post-desugaring) the loop body. Each time you end an iteration, update
all the loop variable activation record pointers to point at a new
clone of that activation record.

In each case, you require a list of not-necessarily-predictable size
to note the closures in. That's not a big problem; it's just something
you need to be aware of.


More information about the es-discuss mailing list