On Jan 6, 2012, at 11:23 AM, Mark S. Miller wrote:
> AFAICT, this agrees with my analysis of what your proposal means. How does
> this not result in three modes?
Counting modes is not productive, is it? All major implementations have
extended ES5. It's likely extensions will continue to precede standardization.
Do these make ongoing new modes?
Rather, we should minimize the state machine and how we talk about it. We could
generalize it using Curr, Next, Curr&Next, and Curr-Next labels.
/be
>
> On Fri, Jan 6, 2012 at 9:45 AM, Allen Wirfs-Brock <al...@wirfs-brock.com>
> wrote:
>
> On Jan 6, 2012, at 8:03 AM, Mark S. Miller wrote:
>
> > 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.
>
> Implementations that currently support extensions to ES5 (and wish to
> continue to support them) must classify their extensions into one of the four
> categories I identified and then process them according to the state machine.
> Because no currently implementation of function declarations within blocks
> (that I'm aware of) matches the ES6 lexical scoping semantics, it would
> expect such function declarations to be classified as ES5~ES6. Then,
> according to the state machine, a program like:
>
> function f(g) {
> //not the following will produce inconsistent results among common browsers
> if (!g) {
> function g() {return 1}
> }
> else if (typeof g !== 'function') {
> function g() {return 2}
> }
> return g;
> }
>
> will be processed using the (implementation extended) ES5 specification and
> both f and g would presumably be non-strict functions. If you wanted the
> above to be processed as ES6 code you would need to add some ES6-only
> features such as: let ES6; or use some other forced opt-in such as a version
> in the MIME type.
>
> The above is exactly analogies to how any "standard" ES5~ES6 features would
> be treated.
>
> Allen
>
>
>
>
>
> --
> Cheers,
> --MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
