Extensions in ES5 strict mode (was: No more modes?)
My thoughts for what they are worth:
The semantics for const in Harmony are likely to be silently different in Harmony from the semantics it has in non-strict current implementations. (In particular the current const is hoisted to the surrounding function, whereas the one in Harmony won't, so the shadowing will be different.)
Given this silent behavioural change it would be advantageous to flush out existing uses of const before Harmony arrives and gives it a new meaning.
Forbidding const in strict mode would seem to be a way to do that.
On Oct 13, 2010, at 11:56 PM, Erik Corry wrote:
The semantics for const in Harmony are likely to be silently different in Harmony from the semantics it has in non-strict current implementations. (In particular the current const is hoisted to the surrounding function, whereas the one in Harmony won't, so the shadowing will be different.)
Agreed so far. IIRC const in Opera is just a synonym for var.
Given this silent behavioural change it would be advantageous to flush out existing uses of const before Harmony arrives and gives it a new meaning.
Flush out means make developers find all such uses, and do what?
Forbidding const in strict mode would seem to be a way to do that.
If only I knew what "flush out" means. Users may or may not rewrite complex const-using code just to enable strict mode.
The problem is even more acute for let-based code -- Mozilla JS (Firefox FE and add-on code) uses let heavily. It's a sunk cost, arguably a "good sunk cost" (mostly future-proof, even with let becoming like let* not hoisted to block top). I doubt people will rewrite to var (which requires careful analysis to avoid collisions where there used to be shadowing). They simply won't use strict mode.
But const or let, the idea that "use strict" is so attractive it will cause re-sinking sunk costs seems farfetched to me. We'll find out, though, because I do agree we should make Firefox's strict mode ban let, const, and function in block for now. I hope JSC and V8 do likewise with their IE-workalike function-in-block extension.
On Oct 14, 2010, at 12:23 PM, Erik Corry wrote:
- okt. 2010 17.11 skrev Brendan Eich <brendan at mozilla.com>:
Flush out means make developers find all such uses, and do what?
Replace them with var, making whatever other changes are needed to keep the program running.
Most developers I know are not going to do this. At most they'll use SpiderMonkey's "strict option" and look for warnings.
Strict mode is not such a super-sweet carrot that people will rewrite to stop using 'let'. 'let' is pretty sweet too, and sunk costs being what they are (even if it's a sunk cost fallacy), inertia if nothing else favors the entrenched 'let' usage.
My point about the "strict option" was that we have a fallback. Here I'm just trying to point out that strict mode doesn't sell itself at any cost.
On Oct 13, 2010, at 5:35 PM, Brendan Eich wrote:
Here are my thoughts. Reactions, advice, alternatives I've missed all welcome:
No one can claim to have future-proof ("Harmony-compatible") let until we really draft it better. Same for const. At the last TC39 meeting I proposed we drop hoisting to block-top and go with Scheme let* or C++ declaration-scope semantics, and everyone agreed (with great relief). But we haven't draft-spec'ed or prototyped this at all. It needs to be more solid.
Everyone wants to promote "use strict" but with Firefox 4 betas supporting most but not all of it, and the (still being debugged) complete patch just landed on WebKit nightlies, it is premature to try to get developers slapping the directive on new code. This already bit back due to concatenation with old code, and with lack of validation. We do not want to risk creating pressure for quirks mode strict mode!
Firefox's let and const support could create quirks-mode pressure on other browsers. This happens, and not just on non-IE, lesser-market-share browsers (Mozilla gets pressure from WebKit all the time, mostly for the good!). So there' s a risk here. But:
Forbidding our let, const, and function-substatement extensions under "use strict" -- especially forbidding let and const -- will harm uptake of validated strict mode usage in Mozilla-specific JS (add-ons, our front end JS, middle-end JS components, etc.). Maybe that's ok, we can try to use our long-standing "strict option" (which gives warnings by default, and overlaps ES5 strict mode but is not the same as it). This harm has to count for something, even if hard to quantify -- the risk in 3 is hard to measure too (probably small).
You didn't mention 'yield', which ES5 strict makes a future reserved word, but which we implement in a possibly Harmonious way. We could play it safe in terms of future proofing, again at the risk of dampening "use strict" uptake in Mozilla-specific JS. Or we could gamble that we are already future-proof.
My tentative conclusion is that we should make ES5 strict forbid let, const, and function in block (or any substatement) in Firefox 4. I would hope (haven't tested it) that JSC will do likewise with function in block. Mozilla JS hackers can lean on the "strict option" and its warnings, which would deviate further from ES5 strict by not banning let, const, and function in block.
On yield, I'd like to let it ride. It's a good bet IMHO. But who knows?
(Collin Jackson added to this; I wrote the original version.)
On Oct 13, 2010, at 5:35 PM, Brendan Eich wrote: > On Oct 13, 2010, at 4:31 PM, Mark S. Miller wrote: >> * ES5/strict implementations as deployed in non-beta releases should obey <http://wiki.ecmascript.org/doku.php?id=conventions:recommendations_for_implementors>. If they don't, then either a separate opt-in will be necessary or we will have to retreat from some of the accepted harmony proposals. For example, if browsers deploy a harmony-incompatible semantics for "let", "const", and nested named functions, and if ES5/strict code comes to depend on those non-standard extensions, then without an additional opt-in it becomes impossible to deploy harmony without breaking that code. > > The point about let, const, and function in block is good but I'll take it up in a separate message. Here are my thoughts. Reactions, advice, alternatives I've missed all welcome: 1. No one can claim to have future-proof ("Harmony-compatible") let until we really draft it better. Same for const. At the last TC39 meeting I proposed we drop hoisting to block-top and go with Scheme let* or C++ declaration-scope semantics, and everyone agreed (with great relief). But we haven't draft-spec'ed or prototyped this at all. It needs to be more solid. 2. Everyone wants to promote "use strict" but with Firefox 4 betas supporting most but not all of it, and the (still being debugged) complete patch just landed on WebKit nightlies, it is premature to try to get developers slapping the directive on new code. This already bit back due to concatenation with old code, and with lack of validation. We do not want to risk creating pressure for quirks mode strict mode! 3. Firefox's let and const support could create quirks-mode pressure on other browsers. This happens, and not just on non-IE, lesser-market-share browsers (Mozilla gets pressure from WebKit all the time, mostly for the good!). So there' s a risk here. But: 4. Forbidding our let, const, and function-substatement extensions under "use strict" -- especially forbidding let and const -- will harm uptake of validated strict mode usage in Mozilla-specific JS (add-ons, our front end JS, middle-end JS components, etc.). Maybe that's ok, we can try to use our long-standing "strict option" (which gives warnings by default, and overlaps ES5 strict mode but is not the same as it). This harm has to count for something, even if hard to quantify -- the risk in 3 is hard to measure too (probably small). 5. You didn't mention 'yield', which ES5 strict makes a future reserved word, but which we implement in a possibly Harmonious way. We could play it safe in terms of future proofing, again at the risk of dampening "use strict" uptake in Mozilla-specific JS. Or we could gamble that we are already future-proof. My tentative conclusion is that we should make ES5 strict forbid let, const, and function in block (or any substatement) in Firefox 4. I would hope (haven't tested it) that JSC will do likewise with function in block. Mozilla JS hackers can lean on the "strict option" and its warnings, which would deviate further from ES5 strict by not banning let, const, and function in block. On yield, I'd like to let it ride. It's a good bet IMHO. But who knows? > http://wiki.ecmascript.org/doku.php?id=proposals:versioning (Collin Jackson added to this; I wrote the original version.) /be -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101013/3f0d5c20/attachment.html>