On Jan 6, 2012, at 7:48 PM, Mark S. Miller wrote: > > > Then I would only expect two labels: ES6 and non-strict > > You're counting different beans from Mark's "modes" and from Allen's states. > > Hi Brendan, as I read it, Axel captures exactly the two modes I have in mind.
Ok, good to have fewer positions :-). > The reason the state machine matters is implementation (including the fine > spec, the normative implementation). Authors can think of writing non-strict > ES5 or lower, or ES5 strict -- or ES6 if they use a bit of novelty. Different > beans again. > > I'm not sure what informs your label count expectation. In writing JS for the > web over the next several years, you might have to worry quite a bit about > ES5 strict vs. ES6. You can't just assume ES6 works everywhere that ES5 > strict works. > > The issue is: What does it mean for a browser to be standards compliant once > it is fully conformant with ES6? Yes, of course there will be a long phase of > partial ES6 compliance as features are incrementally rolled out. Just as > there was with ES5. Still is. > But during this period, no one claims full conformance with ES6, so standards > compliance mean only compliance with ES5. To be standards compliant once one > is ES6 compliant, the state machine + ES6 keeps some portion of the ES5 spec > as a live normative spec because it is reachable from the state machine. The > only question is: Which portion is reachable? With Allen's plan, all of it. > With the one line revision Axel and I have in mind, the ES5-strict spec stops > being reachable as normative for ES6 compliant browsers. It is dead code that > can be considered garbage. Your post two above the one to which I'm replying proposes to have only ES5 non-strict and ES6, with "use strict"; (the string literal directive) enabling ES6. I don't a difference except in state-machine labels with what Allen proposes. Allen has 5&6, ES5, ES6, and Compat5. Relabel these to ES5-nonstrict-ES6-intersection ES5-nonstrict ES6 ES5-nonstrict-differs-from-ES6 Since ES5-strict is a subset of ES6, it doesn't require new states. Function declarations in blocks and (depending on implementation) const extensions fall into ES5-nonstrict-differs-from-ES6 as noted. That is, "ES5-nonstrict" must be read to include an implementations extensions that pre-date ES5, that are enabled without "use strict";, and of course which conflict with ES5 strict. You previously wrote: > For example, since legacy constrains us from making nested named function > declarations a triggering feature, if program #2 [one with "use strict"; and > conforming to ES5 strict] has a nested named function and the browser > rejected it, that browser would still conform to both the ES5 and ES6 spec. ES6 will normatively require block-nested function declarations to be supported, with certain semantics. So I don't agree that a conforming ES6 implementation could reject such functions in blocks. You continued: > The easy fix is to make "use strict"; a triggering condition. I agree that this follows from the state label definitions (whatever their names) and the state machine. Then you wrote: > 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. Here again I'm confused. the ES6 spec is not going to delegate to a separate and older edition, namely ES5. It will be self-contained. So there must be something in the ES6 spec that defines how to process "use strict"; *or* new ES6 syntax, and how that makes duplicate formals an early error, etc. etc. IOW ECMA-262 Ed. 6 must contain some kind of state machinery for specifying opt-in. > In the ES6 era, I hope to be able to say "ES5-strict is dead. Long live ES6!". Ok, I can adjust labels to agree with this. But it doesn't relieve the ES6 spec from talking about opt-in from ES5-nonstrict, so are we really just arguing about names or labels? If so, great -- those are important to get right. If I seemed to disagree on number of modes, it may be because I don't see how a conforming ES6 implementation could continue to reject extensions that ES5-strict rejects (e.g., functions in blocks). ES6 will require functions-in-blocks to work a certain way. Any implementation that supported an extension under ES5-strict where the semantics for the same syntax differ between the extension and ES6 will have to suffer (SpiderMonkey let and const fall into this category). But that is SpiderMonkey's headache, not ECMA-262's. > However, ES5-non-strict (or "non-strict", or "ES3") will continue to live for > the foreseeable future. It will probably outlive most of us. Yup. /be > > > > > /be > > > > > > ES6-only => (a subset of) ES6 > > ES5-only => only possible for non-strict constructs => non-strict > > ES5&ES6 => (a subset of) ES6 > > ES5~EAS6 => not possible (“The construct has identical syntax and static > > semantics in both ES5 and ES6, but differing semantics.”) > > > > -- > > Dr. Axel Rauschmayer > > a...@rauschma.de > > > > home: rauschma.de > > twitter: twitter.com/rauschma > > blog: 2ality.com > > > > > > > -- > Cheers, > --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
