Considering all that, I can't help feeling that having a separate mode is cleaner, simpler, and easier to use. I think it also has more potential for providing a robust foundation for future evolution of the language.
This last point -language evolution- is something that Haskellers have quite a bit of experience with, and I've tried to raise the issue of feature-based language versioning here earlier [1,2]. In Haskell's beginning, there was the single language standard, and every implementation had a single flag for enabling all of its additional or experimental features (beyond the standard). But implementations come and go, and even the de-facto standard of most-widely-used implementation has changed over time. Even when several implementations agreed on a feature, they might disagree on some details (eg, a proven safe but restrictive variant versus a possibly unsafe but pragmatically better version). And the language committees have been notoriously slow in adopting experimental features into the language standard. So the situation became untenable, and the solution was feature-based language versioning (based on pragmas), in addition to named standards: By default, code is interpreted according to the most recent language standard but, for stability, code can explicitly opt into a specific version of the standard. Up to here, that is similar to Javascript, only that the version can be specified in code pragmas as well. On top of this default, language *extensions* can be selected individually, via pragmas. It is then up to the implementation to recognize whether or not the selected set of language extensions is supported. As in JS, language extensions tend to have recognizable syntax, too, so implementations can also warn intelligently about attempts to use features that have not been selected (or about conflicts that arise because of features that have been selected, such as stolen syntax). Useful language extensions can be adopted by other implementations (at which point they need to be specified, not just implemented), and later moved into one of the next language standards. Agreeing on the next language standard becomes more of gather-successful-features than redesign-everything-from-scratch, with shorter language update cycles as well. A feature missing a language update deadline becomes less of an issue, as it is still available as an extension. Features that do not work out in practice are easier to remove, as they have their own pragma (not mixed into a numeric language version). In the current phase of JS evolution, with an evolving new standard and partial implementations of new features, it would be especially helpful to identify which features a piece of code depends on and which features a given implementation supports. Being able to opt in to new features individually also puts a bound on upgrade work (e.g. opt into let, but not yield, or vice-versa), and helps to ensure that coders are aware of changes (if I opt into let, I expect let to be special; if I opt into ES.next because I want yield, I might be surprised by changes to let and scope and typeof and ..). Just a thought.. Claus [1] Should ES begin to standardise pragmas? https://mail.mozilla.org/pipermail/es-discuss/2011-April/013791.html [2] feature-based and compartment-based language versioning https://mail.mozilla.org/pipermail/es-discuss/2011-July/015755.html _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
