Re: lexical for-in/for-of loose end
Allen Wirfs-Brock <
allen@...>
2012-02-04 22:19:45 GMT
On Feb 4, 2012, at 12:55 PM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>> On Feb 4, 2012, at 9:49 AM, Brendan Eich wrote:
>>> I agree we want to capture the first-iteration bindings in any closures in those declarators' initializers.
>>
>> It isn't clear to me why capture first-iteration is abstractly any better than "capture a hidden second
x". In both cases, in most iterations of the loop, evaluation of any such captures is going to reference the
"wrong" binding.
>
> The argument is as follows:
>
> for (let i = 0, a = some.array, n = a.length; i < n; i++) { ... }
>
> here we definitely want the a in a.length (n's initializer) to be scoped by the head let -- to be the a
declared by the second declarator.
>
> Now consider a bit of eta conversion:
>
> for (let i = 0, a = some.array, n = (function(){return a})().length; i < n; i++) { ... }
>
> It would be quite wrong for the a captured by the anonymous function expression to be other than the a
binding declared and initialized immediately to the left.
Yes, I support the general principal that that initializers of bindings capture to the left. But the
problem here is that conceptually the let is defining multiple bindings (one per iteration). I don't
think many people are actually going to understanding the details of the proposed semantics and their
implications. Since most uses won't involve closure capture, any of the proposed semantics that have per
iteration bindings with forward value propagation are just going to do the "right thing". That is good.
However, I doubt that someone who actually codes a function in a for(let;;) initializer is going to be
thinking, "of course, this only captures the first iteration bindings".
> It would be bad for the eta conversion to break equivalence (use a block-lambda instead of a function
expression for full TCP).
With the TDZ alternative I proposed, there would still be equivalence for:
for(let x=x;;)...;
and
for(let x={|| x}();;)...;
Both throw for accessing an initialized variable.
But you're right that equivalence is lost for
for(let x=n, y=x;;)...;
and
for(let x=n, y={|| x}();;)...;
Whether this is better or worse than the "wrong capture" issue complete depends upon the actual programmer intent.
>
>
>> From a user perspective, the main advantage I see for capture first iteration is that it has a slightly
smaller window of wrongness. The captures evaluated in the first iteration will reference the
correction binding, while latter iterations reference the wrong binding.
> Users expect and even (now that they know, and Dart raises the ante) demand that each iteration gets fresh
let bindings. Any who do capture an initial binding in a closure must know, or will learn, that it's just the
first one, which fits the model.
For the latter, I strongly suspect that they won't know and will be WTF surprised when they encounter it. The
saving grace is that this will probably be very rare, although its possible that the introduction of block
lambdas might somewhat change that. Just don't know...
> If this were really a footgun (I don't believe it is without actual evidence from the field) we could try to
ban closures capturing the initial bindings. That ad-hoc restriction would be quite a wart. It doesn't
seem warranted.
>
My TDZ solution is such a restriction. But I don't see how it is any more ad hoc than any of the other changes we
are talking about here in order to give for(;;) per iteration bindings. Its wartiness actually seems
small and is restricted to a situation where the programmer probably is actually expecting C=style per
loop rather than per iteration binding.
>> From an implementation perspective, it is probably a bit simpler to not have the extra hidden binding for capture.
>
> I don't think so. The unrolling I showed was to use a tail-recursive block-lambda helper. But real
implementations will do closure analysis and optimization (flat AKA display closures, e.g.) and use
branch instructions for loops, jumps for breaks, etc. Having the first binding rib open a bit earlier than
subsequent ribs is (I think) a small or zero-cost issue.
My comment wasn't about the bind to first unrolling. It was about the "extra hidden binding" alternative in
the first list of alternatives and is probably also applicable to by TDZ alternative.
>
>> I really don't like the first iteration is different semantics
>
> Different how?
Different from subsequent iterations...
Take Jason's example
for (let i = 0; i < n; ) {
setTimeout(...closure using i...);
if (shouldAdvance())
i++;
}
If somebody decided to abstract the increment:
for (let i = 0; advance={|| i++}; i < n; ) {
setTimeout(...closure using i...);
if (shouldAdvance())
advance();
}
advance does what is intended if called on the first iteration, but not on subsequent one iterations. I'd
soon get an error when I ran this than having it get stuck in a loop.
> Making the first iteration's binding initialization capture guaranteed errors would be different
semantics. Capturing the first iteration's bindings from closures in their initializers is not
"different" any more than having initializers is "different". The initialization part of the for loop is
already special. It's not like the update part.
>
>> and think we should think about the above alternative.
>
> Eta equivalence matters. Given that we want n = a.length to use the a declared to the left in the same
for-head declaration, I don't see how we can make closures in a right-ward initializer capture some outer binding.
>
> Capturing an error-only binding would need evidence of the footgun not being useful for shooting other
things. We don't have such evidence, not by a long shot.
Well, we don't have a lot of evidence for any of this discussion. Does any C-syntax language currently
implement for(;;) in the manner that is being proposed?
>
>> However, such closure capture is very rare (could use of block lambda based patterns change that??)
>
> I don't think so -- equivalences are stronger, not weaker or different, with block-lambdas vs.
functions, due to TCP.
That was the point I have had in mind. While function expressions in for(;;) initializers are now rare, that
might change with the use of block-lambdas
>
>> so it may come down to judgements about implementation costs. Is capture first going to be significantly
easier to implement than my alternative scoping? The answer is obvious to me.
>
> Did you mean "isn't"?
yes
>
>> In either case an implementation is like to special case loops with closure capture in their initializers.
>
> Varying a sketch Jason posted to the SpiderMonkey internals list:
>
> for (let V = INIT; TEST; UPD) STMT
>
> compiles to
>
> enterblock <V>
> INIT
> goto L2
> L1: STMT
> reenterblock
> UPD
> L2: TEST
> iftrue L1
> leaveblock
>
> This is very close to how SpiderMonkey compiles for(let;;) already -- the only new instruction is
reenterblock, which exits the current block and does the equivalent of enterblock <V> again.
>
> <V> is an immediate operand, in SpiderMonkey a block object literal created by the compiler. It holds all
the bindings and their stack offsets, however many declarators with or without destructuring occur
after let.
>
> I claim implementation is not the driver here. User expectations, esp. savvy users who might make some
practical or theoretical (testing) use of eta conversion, matter more.
Actually, I'm more concerned about un-savy users who won't really understand the full semantics,
whatever we decide they are.
Allen
RSS Feed