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

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to