On Jan 5, 2012, at 6:31 AM, Andreas Rossberg wrote:
>>> explicit opt-in)
>>
>> No -- "use strict"; the string literal expression-statement is meaningless
>> pre-ES5, ES5-strict in ES5, and redundant in Harmony code.
>
> You said earlier that we best rely on the meta tag for the script
> toplevel, which isn't exactly a No. ;)
Trying to avoid scope creep. Also not dismissing RFC4329 ;version=6 parameter
setting -- that works to hide new code from old browsers (I believe back to IE8
-- perhaps not the geriatric browsers).
>> Now what do you say?
>
> Sorry, I still think that a growing set of subtle implicit rules for
> activating subtle semantic changes
Not changes, new semantics for new syntax. The fingers of fate may allow
completion reform (Mark and I think so). The interactions are not that hard,
and making a mode-wall doesn't avoid solving all of them -- you still may have
runtime (heap-based) interactions between old and new modes.
We did JS1.7 this way, BTW. You had to opt in to get 'let' and 'yield', but
that was for the compiler. We did not hold back other features, and there were
no runtime (post-compile) version checks:
brendan-eichs-computer-3:src.old brendaneich$ grep VERSION_1_7 *.c
jsapi.c: {JSVERSION_1_7, "1.7"},
jsparse.c: || (JSVERSION_NUMBER(cx) == JSVERSION_1_7 &&
jsparse.c: ((JSVERSION_NUMBER(cx) == JSVERSION_1_7 &&
jsparse.c: if (JSVERSION_NUMBER(cx) == JSVERSION_1_7) {
jsparse.c: if (JSVERSION_NUMBER(cx) == JSVERSION_1_7) {
(jsapi.c is just a string <-> enumerator mapping table; jsparse.c shows the
compiler checks.)
> on a fine-grained level is far more
> confusing (and error-prone!) than helpful. In all sorts of ways.
Our experience was that adding new features to the default version where there
was no backward incompatibility was not confusing. We've been doing this since
2006. Not to say all the particulars are right, or that we anticipated all the
combinations of ES5-strict and Harmony, of course! But I think you protest too
much without evidence.
> I'm also concerned about the 3 and a half language modes that might
> result. With Dave's original proposal at least, the only opt-in was on
> module level.
Dave mentioned generators, IIRC. We were thinking of classes too (talked about
it privately).
> That precluded a number of highly undesirable
> combinations, e.g. extended mode nested into a "with" statement.
You can "use strict"; in a with statement's body block. But see below, I agree
the opt in has to be "chunky", and is in the (not perfectly clear, complete,
etc.) proposal for "ES6 doesn't need [version] opt-in".
> Allen
> gave a couple of good examples we also ran into when trying to
> implement block scoping liberally in V8 -- in the end, we concluded
> that it doesn't make sense to allow opting into extended mode locally.
Yes, this is one place where during the ES4 period, we made 'let' at top level
of program and function bodies equate to 'var', which is no good (arguments
aliasing, for one). But lesson learned.
The idea is to opt in at least the enclosing function, if not the enclosing
Program (non-terminal, so <script> element content) when unproblematic new
syntax is parsed.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
