ES6 doesn't need opt-in

Claus Reinke claus.reinke at talk21.com
Thu Jan 5 02:11:29 PST 2012


> 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
 



More information about the es-discuss mailing list