ES6 doesn't need opt-in

Herby Vojčík herby at
Sat Jan 7 00:02:51 PST 2012


I think Allen had another point. What you are counting, are semantic modes 
of the code, that is, runtime.
What Allen counts, are specification modes of the language, that is, 
These are different beans, as he said earlier.

Things that Allen defines (afaict) are:

- compilation targets

ES5 ::= "When run, the program will be interpreted according to ES5 spec. In 
particular, parts with "use strict"; will be interpreted with ES5 strict 
mode semantics and parts without it with ES5 non-strict mode semantics. In 
other words, it will be compiled according to ES5 spec."

ES6 ::= "When run, the program will be interpreted according to ES6 spec. In 
particular, parts with "use strict"; will be interpreted with ES6 (strict) 
mode semantics and part without it also with ES6 (strict) mode semantics. 
In other words, it will be compiled according to ES5 spec."

- categories of the code elements with respect to compilation targets (they 
are event in the pre-compilation parsing state machine)

Identical-in-both (ES5&ES6), Valid-but-differs (ES5~ES6), Valid-only-in-ES5 
(ES5-only), Valid-only-in-ES6 (ES6-only)

- states and transitions of the pre-compilation parsing state machine

5&6, ES5, ES6, Compat5 states
transitions for all of them with respect to events above (that is, 

The output of the state machine is the compilation target (inferred directly 
from the state at which the state machine finishes: ES5, ES5, ES6 and ES5, 
respectively), eventually an early error that prevents compilation because 
of conflicting ES5-only and ES6-only code was detected while parsing.

"use strict"; and its two modes are only important here, when the program is 
being compiled (when in state machine, it should imo trigger 
"Identical-in-both" event).

He also recommends opt-ins to be sure to get ES5 target or ES6 target 
(unless there is conflict in code, of course) as the output of the state 
machine by citing pieces of code with no functionality but triggering 
"Valid-only-in-ES5" or "Valid-only-in-ES6" events in the parsing state 
machine, thereby fixing its state to ES5 or ES6.


-----Pôvodná správa----- 
From: Mark S. Miller
Sent: Saturday, January 07, 2012 4:29 AM
To: Axel Rauschmayer
Cc: Brendan Eich ; es-discuss Steen
Subject: Re: ES6 doesn't need opt-in

Axel, thanks. This is the critical point, so no apologies needed for 
Allen, what I mean is exactly what Axel says here.

Look at it another way. Right now we have two normative modes: ES5 strict 
and ES5 non-strict. State machine aside, ES6 introduces a new single mode 
normative spec. If the state machine may delegate to any of these three 
normative specs we have three modes. If the state machine may only delegate 
to ES5-non-strict or ES6, i.e., if the ES5-strict spec becomes dead code as 
of conformance with state machine + ES6 spec, then we have two modes.

To get this effect, we need only classify ES5's "use strict"; directive as 
ES6-only. If any objection to doing so has been stated, I missed it. Is 
there a reason not to do so? It's a one line change that leaves the rest of 
your proposal unperturbed and solves this problem.

On Fri, Jan 6, 2012 at 12:09 PM, Axel Rauschmayer <axel at> wrote:

> Rather, we should minimize the state machine and how we talk about it. We 
> could generalize it using Curr, Next, Curr&Next, and Curr-Next labels.

I’m awfully sorry for belaboring this point. But the labels and the quote 
below don’t go together.

Quoting Brendan:

>> - ES6 is a superset of ES5.strict.
> That's always been promised.

Then I would only expect two labels: ES6 and non-strict

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
axel at



es-discuss mailing list
es-discuss at 

More information about the es-discuss mailing list