ES6 doesn't need opt-in

Herby Vojčík herby at mailbox.sk
Wed Jan 4 09:18:56 PST 2012


Then, why not to put every feature on ES6 mode only and backporting them one 
by one, giving time for each backport to see if it really works and not 
putting effort to backport another one until the previous one is generally 
accepted as safe?

Herby

-----Pôvodná správa----- 
From: Allen Wirfs-Brock
Sent: Wednesday, January 04, 2012 6:08 PM
To: Andreas Rossberg
Cc: Mark S. Miller ; Brendan Eich ; es-discuss Steen
Subject: Re: ES6 doesn't need opt-in


On Jan 4, 2012, at 4:23 AM, Andreas Rossberg wrote:

> ...
>
> - Despite the superficial "fewer modes" mantra, it actually doesn't
> make the language simpler, but more complicated: instead of defining
> the semantics for Harmony features only for strict-mode programs, we
> now have to define many features for both modes (and mixed uses of
> both modes). I.e., there are more syntactic and semantic combinations
> to worry about.

Yes, I'm already seeing this as I look at the working draft of the ES6 
specification to see how I would have to modify it to support this new 
approach.  Rather than working in a small number of discrete modes, each of 
which implies a specific set of environmental semantic rules, I have to 
consider pairwise interactions between features that span modes.  Some 
initial issues I've had to look at are include the possibility of the 
presence of a local with scope when dealing with lexical declarations, 
impacts of being able to redeclare 'eval' or 'arguments',  and interactions 
between formal parameter destructuring and non-strict mode arguments 
objects.

If the impact was only on the spec. work this might not be a big deal, but 
these sorts of mode-crossing feature interactions are also visible to 
implementors and ES programmers and add practical and conceptual complexity 
that they will have to deal with.

There certainly are features (for example, is and isnt) which seem to have 
minimal impact in any mode.  But for others, there are complexities that go 
beyond just the syntactic compatibility issues.  Modes (whether via explicit 
or implicit opt-in) seem to help reduce this complexity.

I think Dave has pushed us down a useful path, but I also think we need to 
carefully semantic interactions as well as syntactic compatibility issues 
for each feature that we consider adding to "non-strict" code.  In some 
cases, it may make the language easier to understand and use if features are 
only available in "strict mode".

Allen



More information about the es-discuss mailing list