David Herman wrote:
On Dec 26, 2012, at 3:35 PM, Mark S. Miller<[email protected]> wrote:
I think you did coin "1JS". What do you mean by it? Does it bear on
the present issue or not?
I coined the "just one JavaScript" here:
https://mail.mozilla.org/pipermail/es-discuss/2011-December/019112.html
And it got shortened to 1JS not long after (maybe in the same thread?). The key point was
no (new) opt-in for ES6. If you read the message (see the "Modules as the opt-in for
new semantics" section), you'll see that I actually proposed that anything that
can't be made to work in legacy code can be left out of sloppy mode.
Not arguing in reply, rather taking this opportunity to
expound/recollect a bit, bear with me!
The lingering, not-quite-resolved issue I see Mark raising depends on
the exact definition of "can be left out of sloppy mode" or (should that
be reworded?) "can be included in sloppy mode but only with some
incompatibility or contortion [but not binding-dependent parsing]".
Long before 1JS, in prototyping ES4 features in SpiderMonkey "JS1.7" and
up (which ended up in Rhino as well), and inspired by Opera's array
destructuring, we started adding new features without requiring opt-in
version selection. The new syntax was enough. This covered
destructuring, and it turned off sloppy-mode craziness that was hard to
implement or teach (e.g., destructuring parameters made duplicate formal
parameters an error in JS1.7+, prefiguring strict mode).
We ran into problems with 'let' and 'yield' used as identifiers, and
lacking function* syntax for generators, we did require opt-in by
version= for those two but nothing else.
With 1JS as you proposed it (and if my memory serves), 'module' was
enough to opt into new syntax (and it also implied "use strict"), but
there was room for other new syntax outside of module (and outside of
"use strict") to be its own opt-in.
Since then I think TC39 has moved along toward enabling opt-in by new
syntax where it's clean. New function head syntax (rest, default,
destructuring parameters; function* for generators, which reserves yield
in the body), at least.
We knew 'let' could be a problem. Also we knew function-in-block was a
breaking change. As you noted, and Brandon nicely separated in his reply
as well, we can certainly require "use strict" to have function-in-block
semantics. We may be left with no other choice.
Just to recap the last TC39 meeting, we agreed to try reserving 'let' in
sloppy mode. Mark wasn't happy about that, not so much because of
incompatibility due to let[x] = y; changing meaning, more -- this is my
interpretation, Mark should correct me -- because he wanted to promote
strict mode, not elaborate sloppy mode ("don't polish a turd") , and
keep each mode simpler by most measures.
I do not think the problems we anticipated with function-in-block and
'let' mean we retreat to requiring "use strict" for all new syntax
outside of implciitly-strict modules. This is my punch-line:
function-head new syntax in sloppy mode, including stricter error
checking (e.g. for duplicate formals), should stand. It is better for
the users, and probably even for the spec, to make such new syntax its
own opt-in.
So, case by case:
* arrow function syntax (which does not imply "use strict" in body prologue)
* class
* const
* default parameters
* destructuring
* rest parameters
* generators (function*, yield in function* body)
* comprehensions
* generator expressions
* module
all seem to work in 1JS via the "new syntax is its own opt-in" rule,
including any stricter/saner semantic checking.
I left out 'let' and function-in-block. Let's set those aside for a moment.
Anyone disagree that the bulleted syntactic extensions listed above
should be their own opt-in, and think instead that some or others or all
should appear only to strict code? (Mark, here's your chance! ;-)
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
