On Jan 5, 2012, at 10:20 PM, Mark S. Miller wrote: > > > On Thu, Jan 5, 2012 at 10:13 PM, Allen Wirfs-Brock <al...@wirfs-brock.com> > wrote: > > On Jan 5, 2012, at 8:24 PM, Mark S. Miller wrote: > >> Hi Allen, if ES5 had only one mode, I'd understand this. But I thought we >> were trying to arrive at two modes, ES6 non-strict, to be backwards compat >> with ES5-non-strict, and ES6 strict, to be backwards compat with ES5-strict. >> I am perfectly happy to call ES6 non-strict "ES3", since ES5-non-strict >> really exists to be an ES3 compatibility mode, and was constrained to be >> backwards compatible from ES3. Likewise, I am happy to call the new ES6 >> strict simply "ES6". >> > > When I talked about "ES5" in my original post I meant full ES5 including both > strict and non-strict modes. Since ES6 is supposed to be a strict super set > of ES5 strict mode, anything in the ES5-only category must be an exclusively > non-strict mode feature (for example, with). I suppose you could call that > category "ES3" but I decided to label it "ES5-only" to keep things focused > on differences between ES5 and ES5. > >> Concretely, I am confused how your transition diagram is supposed to handle >> "use strict";. Reading your state machine literally, since "use strict"; is >> accepted by ES5, if it is accepted by ES6 (as I think we all agree it would >> be), then it would leave us in state ES5&ES6. Were you two base categories >> "ES6 non-strict" (or ES3) and "ES6 strict" (or ES6), then a "use strict"; >> would put us in your ES6 strict (or ES6) category, which is what I would >> have expected. > > Yes, "use strict" is in the ES5&ES6 category. A ES5 completely strict mode > program would start in State 5&6 and stay in that state for its entire > "compilation". Only encountering use of a new ES6 feature would case a > transition to State ES6. Looking at it another way, Both State ES5 and State > 5&6 include support for both strict and non-strict ES5 code. State ES6 only > allows strict code. > > Them either I still don't understand, this proposal is broken, or we're > talking about three modes. Take the following three programs:
My point wasn't to try to define modes. I think that is where we are miscommunicating. There are exactly two language specifications we have to deal with. The ES5 spec. and the ES6 spec. A given ES source program may conform to one, or the other, or both (or neither). The exercise I was working through is how do you determine whether to process a given source file according to the ES5 spec. or the ES6 spec., without explicitly preassociating the source file with one or another. That is what my state machine does. It starts assuming the source file is in the intersection, where it it doesn't matter which specification you apply. As soon as it see a feature that is unique to one or the other of the specification it clamps to that specification for the entire program. The extra states are to deal with the situation where the appropriate specification to use for a feature can not be directly inferable from the syntax of the feature. > > 1) program using only ES3 features and no "use strict"; > > 2) program using only ES5 strict features and saying "use strict"; > > 3) program using ES6-only features. > > Do these three programs operate in three different modes? If not, do #1 and > #2 operate in the same mode, or do #2 and #3 operate in the same mode? It isn't about "modes". #1 and #2 are ES5 programs and are processed as such (applying/not the appropriately strictness as per ES5) . #3 is an ES6 program is processed as such (including using the strict semantics that are universal to ES6). > > Putting #1 and #2 into the same mode breaks ES5 code. So to avoid three > modes, my conclusion is that #2 and #3 must be in the same mode. But that > does not seem to be what you're saying. What am I misunderstanding? > > > -- > Cheers, > --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
