if current construct is in ES6-only, abort current compilation and
restart from beginning, starting in State ES6
Basically using any ES6 features makes it an ES6 program. Using any
ES5-only feature makes it an ES5 program.
Combining ES5-only and ES6 features results in an invalid program.
If a Program can not be explicitly identified as either ES5 or ES6, it is
treated as an ES5 program.
Could you please clarify for me: if I get a single-file codebase,
say jquery's 6k or so lines, will I have to scan the whole file for
ES6-only features before I can even tell whether to apply ES6
or ES5 semantics? And will this problem increase by one level
with every future version of ES?
ES5 already has the var-"hoisting" oddity where I might have
to scan the whole file before being able to decide whether a
given variable occurrence is bound to a given variable declaration.
I'm not alone in not wanting to see (another) such hazard (*).
Btw, I'm really uncomfortable with implicit feature tracking -
it works ok for people who follow all the relevant mailinglist
discussions and spec versions, but it leaves in the dark all those
who "just code in JS" and enter a situation where their code base
might have to be interpreted according to any of a number of
specs (most JS coders do not even read one version of the spec,
but rely on blogs and books, which will equally show no explicit
in-source sign of what spec version their examples refer to and
whether they are out of date).
Making feature-based versioning explicit (by pragma opt-in)
doesn't solve all problems, but at least everybody knows what
everyone else is talking about, and help can be offered ("if you
want ES6 semantics for let and yield, write 'use let,yield' or just
'use ES6', if you want JS1.8 semantics for these features, use ..;
if you want to concatenate old and new code, protect the old
code with 'use ES5' and the new code with 'use ES6'").
By making feature-based versioning implicit (by feature use), only
experts will be able to say "wait, I remember that kind of issue -
perhaps your engine has switched to another ES version. could
you check whether your source has any yields in it, or perhaps
destructuring, or perhaps a with, or perhaps a vat? yes, please
check even seemingly unrelated parts of the source.".
Also, what happened to the bold "this version will break a few
things, but we'll end up with a much cleaner language spec"?
I'm not saying you are wrong - if you can pull it off, great! But the
new plan reminds me strongly of bad experiences in Haskell-land.
Claus
(*) At least one popular tool (jslint) has decided not to implement
the resulting 2-pass complexity (find var declarations, then parse
for real) but restricts the input language instead, and makes do
with a single pass over the source and naïve scope-tracking.
If I remember correctly, simply lifting jslint's unpopular vars-first
restriction would lead to incorrect internal scope tracking (I don't
know how jshint handles this, btw?).
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
