lexical for-in/for-of loose end

[Herby Vojčík]

Grant Husbands wrote:
> 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.

I meant all that copying there and back and having two variables with 
the same name in two scopes and handling all combinations when to access 
which one. I wanted to take this away.

>> 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.

Well, references are all over the spec (or were in times of ES5). Yes, 
they are only "virtual" objects of the spec, they are not first-class 
and probably not even exist in the implementation; but I just reused 
them in my proposal. So that there will be loop-body-local variable 
_iter_record; 'i' inside body will be Ref(_iter_record, 'i'), and while 
the loop is running, _iter_record is _outer_shared_record, and when 
ending the iteration, _iter_record is assigned to _local_iter_record.

Of course if there are no closures, all this can be optimized away, or 
if eval is not used in them, only those variables that needs to be 
localized should be; but that's beyond scope.

(No, I am not proposing optimization, as Brendan said; I am proposing 
different approach with lazy fixing locals so that complications are not 
present while the loop is running, only when closures are run outside loop)

> 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.

If I understood correctly, this is what I proposed. Or maybe it only 
looks like it?

> 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.

This I did not understand.

> Regards,
> Grant.

Herby