Re: Harmony is a super-set of ES5 strict
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 thescript tag or whatnot). Does that alleviate this concern? Yes, Harmony requires opt-in versioning, at least viascript 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: http://www.mail-archive.com/es-discuss@mozilla.org/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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony is a super-set of ES5 strict
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. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony is a super-set of ES5 strict
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... /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony is a super-set of ES5 strict
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. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Harmony is a super-set of ES5 strict
Hi, 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 (https://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? David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony is a super-set of ES5 strict
On Fri, Feb 25, 2011 at 7:36 AM, David Bruant bru...@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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony is a super-set of ES5 strict
On Feb 25, 2011, at 7:46 AM, Mike Shaver wrote: On Fri, Feb 25, 2011 at 7:36 AM, David Bruant bru...@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: https://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. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony is a super-set of ES5 strict
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. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony is a super-set of ES5 strict
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony is a super-set of ES5 strict
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: http://www.mail-archive.com/es-discuss@mozilla.org/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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony is a super-set of ES5 strict
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. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
