No sorry, I just spotted the flaw. The observable difference is that a
conforming browser is not required by the (ES5 + ES6) specs to provide any
non-triggering ES6 features for program #2. In that case, we again have
three mode.
For example, since legacy constrains us from making nested named function
declarations a triggering feature, if program #2 has a nested named
function and the browser rejected it, that browser would still conform to
both the ES5 and ES6 spec.
The easy fix is to make "use strict"; a triggering condition. For
non-strict code, by the state machine, the ES6 spec would still delegate to
the ES5 spec. And the ES6 spec would otherwise be the same. But the strict
portion of the ES5 spec would simply be dead code, because all of the
conditions that would trigger it have already triggered the state machine
into using the ES5 spec.
On Fri, Jan 6, 2012 at 12:30 AM, Mark S. Miller <erig...@google.com> wrote:
> On Fri, Jan 6, 2012 at 12:24 AM, Allen Wirfs-Brock
> <al...@wirfs-brock.com>wrote:
>
>>
>> There should be no observable difference. But the issue isn't how we
>> described the (program) semantics. It is how we decide which semantics to
>> apply.
>>
>
> Got it. It still gives the web only two modes, but has the huge benefit
> that the ES6 spec can avoid describing the semantics of non-strict code.
> Cool.
>
> --
> Cheers,
> --MarkM
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
