loop unrolling and completion values in ES6

[Allen Wirfs-Brock]

> On Apr 10, 2015, at 3:18 AM, Alan Schmitt <alan.schmitt at polytechnique.org> wrote:
> 
> Hello,
> 
>> ...
> 
> Here is a proposal to solve this.
> 
> 
> We define an abstract operation UpdateCompletion with two arguments,
> a completion and a (possibly empty) value, such as:
> 
> 1. Return UpdateCompletion(s, v).
> 
> Is a shorthand that is defined as follows:
> 
> 1. If s.[[type]] is throw or if s.[[value]] is not empty, return
>   Completion(s).
> 2. Return Completion{[[type]]:s.[[type]],[[value]]:v,[[target]]:s.[[target]]}.
> 
> 
> We next update the spec:
> 
> - 13.1.13: replace steps 4 to 6 with
>  4. Return UpdateCompletion(s,sl.[[value]]).
> 
>  This does not change the behavior.
> 
> - 13.6.1.6: replace step 2.b with
>  b. If LoopContinues(stmt, labelSet) is false, return UpdateCompletion(stmt,V).
> 
>  This changes the behavior: completion values from previous iterations
>  are patched in the abrupt completion.
> 
> - 13.6.2.6: replace step 2.f with
>  f. If LoopContinues(stmt, labelSet) is false, return UpdateCompletion(stmt,V).
> 
>  Same change.
> 
> - 13.6.3.8: replace step 4.c with
>  c. If LoopContinues(result, labelSet) is false, return UpdateCompletion(result,V).
> 
>  Same change.

yes, that all looks good

> 
> 
> I'm much less confident about 13.6.4.13 (evaluation of ForIn/Of).
> I would replace step 5.n with:
>  n. If LoopContinues(status,labelSet) is false then
>     i.  let status = UpdateCompletion(status,V).
>     ii. Return IteratorClose(iterator,status).

yes, although I’ll probably make it

  k.  Let result be the result of evaluating stmt.
  l.   Set the running execution context …
  m. If LoopContinues(result,labelSet) is false, return IteratorClose(iterator,UpdateCompletion(result, V)
  n.   If result.[[value]] is not empty, let V = result.[[value]].

so that if follow the same pattern as the other loops.
> 
> This would ensure that if the "return" method of the iterator is
> undefined or if it does not throw, and if we get out of the loop through
> a break at the beginning of the loop body, then the last value computed
> is in the completion record.
> 
> 
> Regarding Switch, I think we can make the following changes:
> - 13.11.9, both evaluations. Replace 4.b.iii with
>    iii. If R is an abrupt completion, return UpdateCompletion(R,V).

yes
> 
>  In the second evaluation (CaseBlock : { CaseClausesopt DefaultClause
>  CaseClausesopt }), also replace 7.a.ii.3 with
>    3. If R is an abrupt completion, return UpdateCompletion(R,V).
>  and 11 with
>    11. If R is an abrupt completion, return UpdateCompletion(R,V).
>  and 12.c with
>    c. If R is an abrupt completion, return UpdateCompletion(R,V).
> 
yes, again

> This does not change the semantics, assuming that throw completion
> records never contain the empty value. I think it is the case:

yes, I probably should assert that somewhere.  But I probably won’t worry about that addition for the ES6 test.

And thanks for bringing up the loop unrolling perspective.  It really helps clarify the desired semantics for these cases.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150410/bed0b8a1/attachment.html>