loop unrolling and completion values in ES6

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Apr 8 14:59:41 UTC 2015

> On Apr 7, 2015, at 10:09 AM, Alan Schmitt <alan.schmitt at polytechnique.org> wrote:
> Hi Allen,
> On 2015-04-06 02:08, Allen Wirfs-Brock <allen at wirfs-brock.com> writes:
>> Alan,
>> I freed up a couple minutes for a quick look at this. I want to spend some
>> more time look at it deeper as this is an area where I made some fixes just
>> a couple weeks ago and I want to review them again to make sure everything is
>> as intended.
>> But, for now a quick answer to your question is:  yes there is an intentional difference.
>> For blocks that are not part of loops (and top level StatementLists) we wanted
>> to preserve the legacy completion values described in the NOTE at the end of
>> 13.1.13. this requires preserving empty completion values originating from
>> stand-alone blocks. However, we also wanted all control flow statements to
>> always produce a non-emptry completion value.
> I understand. In fact, it seems that this particular behavior did not
> change between ES 5 and ES 6: block evaluation guarantees the last value
> computed is returned, whereas loops don’t.

Well, they do for normal loop completions (according to the spec.) but not for breaks.  I this the latter is a bug.  In particular, I think it is pretty obvious that:
   eval(“ {0; while (true) {1; break}; 2}”)
should evaluate to 1

It is a little less obvious for:
   eval(“{0; L: while (true) {1; while (true) {2; break L; 3}; 4}; 5}”)

but, I think that consistency with the first case requires this to evaluate to 2.

So, it’s arguably a bug that the ES6 spec. hasn’t changed in that regard relative to ES3/5.  This is something that I can fix before submitting the final draft to Ecma net week.

> According to my tests,
> neither V8 nor SpiderMonkey have this behavior:
> var c; a: { c = 1; while(true) { if (c) { c=0; } else { break a; } } }
> returns 0 in both, whereas the spec says it should be 1 (caveat:
> I tested in a current Chrome and Firefox browsers, I don't know if it's
> the correct environment to do such tests).

Doesn’t seem to match either ES3/5 specs or current ES6 drafts. I don’t know if this is old, non-conferment behavior or new attempts to implement “completion reform” that didn’t take the actual (evolving) ES6 spec. into account.

> Does this inconsistency matter?

Probably.  In ES6 we are trying to “reform” completion values so, among other things, program transformaions do have to worry too much about breaking the specified  specified completions values. 


More information about the es-discuss mailing list