Hi,
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,
compilation.
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,
categories)
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.
Herby
-----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
belaboring.
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 <a...@rauschma.de> 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
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
