"Harmony is a super-set of ES5 strict"
On Fri, Feb 25, 2011 at 7:36 AM, David Bruant <bruant at enseirb-matmeca.fr> wrote:
Does it mean that the "use strict" directive is implicit whenever an ESHarmony feature is used? (this sounds wrong, but I'm asing the question anyway)
It means that the semantics of Harmony are based on ES5-strict, not ES5-unstrict, yes. There will be no with, |this| will not be coerced to an object wrapper, etc.
I don't know, tbh, what it means for things like Proxies which can be implemented in ES5 contexts and therefore be accessed by non-strict code, but I would expect that their semantics (values of |this|, f.e.) would match those of strict mode, however they were called.
Mike
On Feb 25, 2011, at 7:46 AM, Mike Shaver wrote:
On Fri, Feb 25, 2011 at 7:36 AM, David Bruant <bruant at enseirb-matmeca.fr> wrote:
Does it mean that the "use strict" directive is implicit whenever an ESHarmony feature is used? (this sounds wrong, but I'm asing the question anyway)
It means that the semantics of Harmony are based on ES5-strict, not ES5-unstrict, yes. There will be no with, |this| will not be coerced to an object wrapper, etc.
Right.
David, I wonder why you wrote that "(this sounds wrong)" about Harmony implying "use strict".
Harmony built on ES5-strict assumes the semantics without need for a "use strict" as Mike noted, but there is a question of whether use strict; (with or without quotes) should be allowed in Harmony. We are not proposing to build a stricter-strict or "new strict" mode.
I don't know, tbh, what it means for things like Proxies which can be implemented in ES5 contexts and therefore be accessed by non-strict code, but I would expect that their semantics (values of |this|, f.e.) would match those of strict mode, however they were called.
This is an issue in Firefox 4, I think it's just a bug: bugzilla.mozilla.org/show_bug.cgi?id=600693 (workaround is to "use strict" appropriately).
As far as the presence of new, detectible properties such as Proxy, no opt-in is needed and non-strict code can detect such additions. With modules you'll have to opt in, but proxies at least we prototyped as JSON and other additions were done: the old-fashioned way. No name collisions have been found yet.
On Feb 25, 2011, at 9:39 AM, Brendan Eich wrote:
As far as the presence of new, detectible properties such as Proxy, no opt-in is needed and non-strict code can detect such additions. With modules you'll have to opt in, but proxies at least we prototyped as JSON and other additions were done: the old-fashioned way. No name collisions have been found yet.
To be clear, module syntax requires Harmony opt-in. After that, the names you compose in any (lexical only -- no more global object at top of scope chain [you can still get to it but not via var!]) scope will be names you choose. You name the modules, so if you had a pre-existing "Proxy" binding and we had a standard MRL for Harmony Proxies, you could declare
module HarmonyProxy = "...";
Details of "..." TBD, I've used "@std:proxy" and the like in sketches.
Le 25/02/2011 18:39, Brendan Eich a écrit :
On Feb 25, 2011, at 7:46 AM, Mike Shaver wrote:
On Fri, Feb 25, 2011 at 7:36 AM, David Bruant <bruant at enseirb-matmeca.fr> wrote:
Does it mean that the "use strict" directive is implicit whenever an ESHarmony feature is used? (this sounds wrong, but I'm asing the question anyway) It means that the semantics of Harmony are based on ES5-strict, not ES5-unstrict, yes. There will be no with, |this| will not be coerced to an object wrapper, etc. Right.
David, I wonder why you wrote that "(this sounds wrong)" about Harmony implying "use strict".
Harmony built on ES5-strict assumes the semantics without need for a "use strict" as Mike noted, but there is a question of whether use strict; (with or without quotes) should be allowed in Harmony. We are not proposing to build a stricter-strict or "new strict" mode.
Being in implicit strict mode means that if someone writes some non-strict code (so basically every web developers as of today, besides very few people who are testing strict mode in FF4beta), this person cannot use Harmony features without having the guarantee that code that has previously been written is still valid.
So this person has two choices:
- Use ESHarmony features, but before that, he/she has to make sure that code already works in strict mode => This is relatively ok when strict mode makes code break right away
like for the new reserved keywords or throws a SyntaxError if you were using "with". This may lead to more subtle bugs if he/she was using octal literals or relying on the non-strict arguments object. Not to mention codes which rely on (function(){return this;}).call() to return the global object.
- Not use ESHarmony features
I would tend to be more in favor of disallowing Harmony features in non-strict code (without explicit "use strict" directive) to avoid surprises (I'm nuancing below). In order to favor explicit over implicit.
I don't know, tbh, what it means for things like Proxies which can be implemented in ES5 contexts and therefore be accessed by non-strict code, but I would expect that their semantics (values of |this|, f.e.) would match those of strict mode, however they were called. This is an issue in Firefox 4, I think it's just a bug: bugzilla.mozilla.org/show_bug.cgi?id=600693 (workaround is to "use strict" appropriately).
As far as the presence of new, detectible properties such as Proxy, no opt-in is needed and non-strict code can detect such additions. With modules you'll have to opt in, but proxies at least we prototyped as JSON and other additions were done: the old-fashioned way. No name collisions have been found yet.
Indeed, when I previously mentionned "Harmony features", these can actually be seen in two categories:
- break ECMAScript 5 strict code at a syntax level (all new syntactic sugar additions, modules...)
- doesn't (Proxy, WeakMap, Object extensions...). As mentionned, these may be detected, so there might be no need to imply strict mode here. Actually, since these things are new, they could be defined by Harmony with no mention of being in strict or non-strict mode. (I think that it's what you meant by "no/opt-in". I'm not a native English speaker, I'm not entirely sure of the meaning)
So I would be in favor of imposing explicit strict mode before being allowed to use ES5-syntax breaking features.
On 2/25/11 4:08 PM, David Bruant wrote:
I would tend to be more in favor of disallowing Harmony features in non-strict code (without explicit "use strict" directive) to avoid surprises (I'm nuancing below).
I was under the impression that Harmony features would only be allowed for scripts that opt in to them (via the type or language of the <script> tag or whatnot). Does that alleviate this concern?
On Feb 25, 2011, at 1:12 PM, Boris Zbarsky wrote:
On 2/25/11 4:08 PM, David Bruant wrote:
I would tend to be more in favor of disallowing Harmony features in non-strict code (without explicit "use strict" directive) to avoid surprises (I'm nuancing below).
I was under the impression that Harmony features would only be allowed for scripts that opt in to them (via the type or language of the <script> tag or whatnot). Does that alleviate this concern?
Yes, Harmony requires opt-in versioning, at least via <script type="application/ecmascript;version=6"> (for example). An in-language "use version 6" pragma has been discussed too, for fail-fast when code gets copied and pasted into the wrong container.
However, some cats are (at least partly) out of the bag in Firefox: let, const, yield. Both let and yield require different opt-in already (type="application/javascript;version=1.7").
Our let and const (especially) implementations are not Harmonious, and we still need to pin down precise semantics for Harmony, but they are close enough -- see Waldemar's post: www.mail-archive.com/[email protected]/msg05017.html -- and generally used correctly (in future-proof ways) by their fans.
We at Mozilla will bear the cost of shifting (mostly Firefox add-on) JS hackers over across any changes that do break let-, const-, and yield-using code. IOW, we renounce any potential de-facto standard in our let and const prototype implementations. We will break ourselves, and first, so that other implemntors don't have to reverse-engineer our prototypes (not that this is a credible problem: cross-browser JS code cannot use 'let' at all, and 'const' is not consistently implemented either).
The function-in-block semantics in Firefox are un-Harmonious enough that we ban those in Firefox 4's strict mode implementation.
Anyone writing cross-browser code will want to opt into Harmony, to shield downrev browsers from syntax errors.
On Feb 25, 2011, at 1:12 PM, Boris Zbarsky wrote:
On 2/25/11 4:08 PM, David Bruant wrote:
I would tend to be more in favor of disallowing Harmony features in non-strict code (without explicit "use strict" directive) to avoid surprises (I'm nuancing below).
I was under the impression that Harmony features would only be allowed for scripts that opt in to them (via the type or language of the <script> tag or whatnot). Does that alleviate this concern?
-Boris
The other subtlety is that this only applies only to the actual language features not to the behavior of objects. Any new property added to the existing built-in objects will most likely be visible to non-harmony code and function and objects defined using harmony features (including Proxy) can be passed to and accessed by non-harmony code. This is comparable to what happens in ES5 where non-strict code may call a strict mode function.
On 02/25/11 13:26, Brendan Eich wrote:
On Feb 25, 2011, at 1:12 PM, Boris Zbarsky wrote:
On 2/25/11 4:08 PM, David Bruant wrote:
I would tend to be more in favor of disallowing Harmony features in non-strict code (without explicit "use strict" directive) to avoid surprises (I'm nuancing below).
I was under the impression that Harmony features would only be allowed for scripts that opt in to them (via the type or language of the<script> tag or whatnot). Does that alleviate this concern?
Yes, Harmony requires opt-in versioning, at least via<script type="application/ecmascript;version=6"> (for example). An in-language "use version 6" pragma has been discussed too, for fail-fast when code gets copied and pasted into the wrong container.
However, some cats are (at least partly) out of the bag in Firefox: let, const, yield. Both let and yield require different opt-in already (type="application/javascript;version=1.7").
Our let and const (especially) implementations are not Harmonious, and we still need to pin down precise semantics for Harmony, but they are close enough -- see Waldemar's post: www.mail-archive.com/[email protected]/msg05017.html -- and generally used correctly (in future-proof ways) by their fans.
We at Mozilla will bear the cost of shifting (mostly Firefox add-on) JS hackers over across any changes that do break let-, const-, and yield-using code. IOW, we renounce any potential de-facto standard in our let and const prototype implementations. We will break ourselves, and first, so that other implemntors don't have to reverse-engineer our prototypes (not that this is a credible problem: cross-browser JS code cannot use 'let' at all, and 'const' is not consistently implemented either).
The function-in-block semantics in Firefox are un-Harmonious enough that we ban those in Firefox 4's strict mode implementation.
Anyone writing cross-browser code will want to opt into Harmony, to shield downrev browsers from syntax errors.
/be
If we're saying that Harmony is strict-only, settable by a <script> tag, what will indirect eval and the Function constructor do if the evaluated code doesn't start with a "use strict" directive?
Waldemar
On Mar 3, 2011, at 5:33 PM, Waldemar Horwat wrote:
If we're saying that Harmony is strict-only, settable by a <script> tag, what will indirect eval and the Function constructor do if the evaluated code doesn't start with a "use strict" directive?
Yeah, "strict-only" is probably not quite the right way to describe it. We discussed this a bit at the last face-to-face. Generally, Harmony still has to allow for the existence of non-Harmony code living and executing in the same heap. For example, a web page can contain
<script type="application/javascript">...</script>
<script type="application/javascript?version=HARMONY">...</script>
and the bindings of both can see each other. If I remember right, the semantics we've talked about is that indirect eval defaults to ES5 non-strict. So the answer to your question is: the indirect-eval'ed code is non-strict.
So I think it might be a little misleading to say Harmony is strict-only. It's a little more accurate to say that by default, Harmony code assumes the restrictions of ES5 strict mode and builds from there. However, it is possible to access and evaluate non-strict code via indirect eval, or -- in the browser setting, for example -- via access to code defined in non-Harmony.
On Mar 3, 2011, at 6:55 PM, David Herman wrote:
So I think it might be a little misleading to say Harmony is strict-only.
Who ever said that? :-P
I've written that Harmony is based on ES5 strict. But even ES5 strict code can call non-strict code. Same goes for Harmony. It's a big shared-heap world out there...
So I think it might be a little misleading to say Harmony is strict-only.
Who ever said that? :-P
Yikes... not playing who-said-what. For whatever reason, Waldemar got the impression that someone said it, and I'm correcting the misconception, that's all.
I've written that Harmony is based on ES5 strict. But even ES5 strict code can call non-strict code. Same goes for Harmony. It's a big shared-heap world out there...
Right.
I have once seen a presentation from Douglas Crockford where he was saying that new ECMAScript features would be developed on top of ES strict mode (sorry for not having the exact quote, I hope I'm not misinterpreting). I have re-read that "Harmony is a super-set of ES5 strict" (bugzilla.mozilla.org/show_bug.cgi?id=600693#c7)
And I am wondering what this means.
Does it mean that the "use strict" directive is implicit whenever an ESHarmony feature is used? (this sounds wrong, but I'm asing the question anyway)
Does it mean that ESHarmony features cannot be used if the "use strict" directive is absent? (so, for instance, having the Harmony Proxy object in non-strict environment may be considered as a bug)
Are there other meanings?