lexical for-in/for-of loose end
herby at mailbox.sk
Sun Feb 5 03:15:08 PST 2012
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.
More information about the es-discuss