On 6 January 2012 03:37, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote: > Here is a possible set of rules for implicitly assigning ES5 or ES6 semantics > to a Program unit > > In an "ES6" implementation, all constructs that can occur in a valid program > fit into one of these categories: > ES6-only: The construct is based upon syntax or static semantics rules that > only exist in ES6. For example, a destructuring pattern > ES5-only: The construct is based upon syntax that or static semantics rules > that that are not in ES6. For example, use of a with statement t. > ES5&ES6: The construct has identical semantics in both ES5 and ES6. > ES5~EAS6: The construct has identical syntax and static semantics in both > ES5 and ES6, but differing semantics. For example, accessing a formal > parameter after an assignment to the corresponding element of the function's > arguments object. > > We can then use the following state machines to describes the processing of a > Program based upon the occurrence for these feature categories. Initially > start in State 5&6:
I think the state machine is over-complicating things. What it boils down to is that we are defining a new language, ES6-proper (or informally ES6 for short). It overlaps with ES5 but does not include it (e.g. throws out `with'). Then your "state machine" simply says, declaratively: - If a program is ES5 but not ES6, treat as ES5. - If a program is ES6 but not ES5, treat as ES6. - If a program is both ES5 and ES6, with identical semantics, treat as ES6 (although it doesn't matter). - If a program is both ES5 and ES6, with different semantics, treat as ES5 (for compatibility). - If a program is neither ES5 nor ES6, it's an error (obviously). I very much like that opt-in would be for whole programs only. I think that is good, and IMHO progress over some of the earlier discussion. But still, deciding what semantics a program has can depend on very minor syntactic details. This has several potential problems: 1. For eternity, we will require future programmers to remember what exact features were introduced with ES6, in order to be sure that they trigger the right (i.e. strict) semantics for their program. 2. The syntactic trigger in a given program may be hidden somewhere deep down the source code, which makes it very difficult to decide for the reader (and the compiler, which may have to do extra work in the parser to decide). 3. Apparently minor local modifications may accidentally change the semantics of the whole program. The obvious way to avoid all these issues is to always put an explicit trigger at the top. And I expect that style guides would recommend that. But that kind of defeats the purpose, doesn't it? I still haven't heard a convincing argument why it is advantageous to not make this explicit trigger mandatory. /Andreas _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
