Grant Husbands wrote:
But this is all beyond the spec.
I don't think it is. What Herby's idea and these formulations present
is a way for let-based loops to have modifications in closures
captured in the for-head that alter the loop variables in a way that's
visible to the current loop iteration.
And read back changes from the current iteration.
Yes, I see that a new (novel!) observable semantic model is being
proposed here, not an optimization. At first it seemed Herby was
proposing just the usual optimizations.
I still do not think it's wise to specify in terms of such
pointer-updating reference semantics, not for the body closures that
want to capture loop control variables. But only if closures in the
for-head capture loop variables? That would be Allen's "DWIM" (Do What I
mean) semantics.
DWIM is tempting. Perl is full of it and it can be convenient at first.
It often blows back, badly, due to ambiguity.
As such, choosing whether or
not to use these formulations affects the spec.
Agreed, with caution about bending the body closure model around this
prematurely. If we pull it off, probably the body closures can do the
same "optimization" -- but it's not clear we can pull it off.
I agree that it may indeed be too large a feature, given that
desugarings can cover the vast majority of use-cases well enough. I
just thought it worth following the logic through.
Gotcha.
It is tempting to try for this, since it would let a C++-knowing hacker
write a loop like the one you show below, and have it work -- while the
common var-capture pigeon-hole problem would be solved too for
let-bindings captured by body-closures.
> Still trying to be sure you intended a unique and dynamic scope for the
> initializer (first part) of for(let;;).
In the first version, depending on the definition of "dynamic", yes.
In the second version, no, though instead closures inside the loop
body get a similarly 'dynamic' scope.
Here's a longer, still informal version of the second.
Given a loop of this form:
for (let i = 0, inc = function(){i++}; i<N; inc()) { ... }
We want the loop to run to completion while ensuring that each closure
within the body gets a copy of 'i' as it existed in the loop iteration
in which the closure was created. One way to do that is to keep track
of the closures that get created during a loop iteration and, at the
end of the loop iteration, give those closures a new environment
([[Scope]]) which is a copy of the old one, but with a clone of the
current loop body environment record replacing the original.
[snip]
Probably the biggest issue with the above spec is that it assumes
envRec inside an environment is reference-like, which it could easily
not be in current implementations, so this variant would also
introduce an extra indirection in at least some circumstances.
This is a big issue, I agree.
I support the two main destructurings under consideration right now
more than I support the above, though.
Any preference for 0th over 1st iteration scope for closures in INIT
binding initializer expressions?
You and Allen remind me that the whole head needs thought:
for (INIT; TEST; NEXT) BODY
If we do what Andreas suggests, 0th iteration scope for INIT, then TEST
must use BODY scope for the iteration that follows if TEST evaluates
truthy. And NEXT must use a new scope for the next iteration too,
preparing for TEST.
enterblock <V>
INIT
reenterblock // Andreas's suggested 0th iteration scope for INIT
goto L2
L1: BODY
reenterblock
NEXT
L2: TEST
iftrue L1
leaveblock
This is not going to give TEST and NEXT the "DWIM" semantics. Sorry, I'm
sure you get this, I'm just spelling it out to be sure everyone
(including me) gets it.
Is this a problem? I don't know. INIT may want the DWIM semantics, but
TEST and NEXT before it for 2nd through Nth iterations really are more
like parts of the BODY. Why should they form closures that magically
reference "current iteration scope" when called later?
DWIM always falls to ambiguity. What did you mean? I dunno, just do it! :-P
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
