Re: ES6 doesn't need opt-in
2012/1/10 Herby Vojčík he...@mailbox.sk: P.S.: I would bet 99% of developers thinks the model is in fact fallback delegation. :-/ It is simpler model that works most of the time. Always write locally, always read locally and then look up the prototype chain. I think that's a question of making a fallacy of equivocation. The localisation when reading from or writing to a property is a matter of the value contained in that slot. The access or write permission of that property is a matter of the actual slot. -- David liorean Andersson ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On 9 January 2012 21:37, Gavin Barraclough barraclo...@apple.com wrote: On Jan 9, 2012, at 2:59 AM, Andreas Rossberg wrote: I think the state machine is over-complicating things. What it boils down to is that we are defining a new language, ES6-proper (or informally ES6 for short). It overlaps with ES5 but does not include it (e.g. throws out `with'). Then your state machine simply says, declaratively: - If a program is ES5 but not ES6, treat as ES5. - If a program is ES6 but not ES5, treat as ES6. - If a program is both ES5 and ES6, with identical semantics, treat as ES6 (although it doesn't matter). - If a program is both ES5 and ES6, with different semantics, treat as ES5 (for compatibility). - If a program is neither ES5 nor ES6, it's an error (obviously). If the a program is both ES5 and ES6 with identical semantics, then presumably we could equally treat it as ES5 with no behavior change? If so, couldn't this be stated in a much simpler fashion: - If a program is ES5, treat as ES5. - If a program is not ES5 but is ES6, treat as ES6. - If a program is neither ES5 nor ES6, it's an error (obviously). Indeed, that is even more to the point. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
This is interesting issue. There is a subtle difference between prototype chain is the shared part Self mindset and the prototype chain is fallback delegation mindset. Though I knew of Self and knew it had an impact on Javascript creation, I had always an impression that in Javascript (having become ECMAScript) it was the latter, that is the philosophy is that child can override the default from prototype chain. So what is the actual philosophy of ES prototype chain? Herby -Pôvodná správa- From: Allen Wirfs-Brock Sent: Monday, January 09, 2012 9:41 PM To: Brendan Eich Cc: Mark S. Miller ; es-discuss Steen Subject: Re: ES6 doesn't need opt-in On Jan 8, 2012, at 10:32 AM, Brendan Eich wrote: On Jan 8, 2012, at 8:28 AM, Mark S. Miller wrote: ... The other change I hope fits into the same bucket is http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake. Right now, because of pressure from test262, we are in danger of having all browsers conform to this mistake, at which point it may be too late to fix it. Today, the diversity of actual browser behaviors means it is still possible to fix this mistake, much as the diversity of ways ES3 implementations were broken made it possible for ES5 to fix many mistakes. The [[CanPut]] check goes back to ES1, though. Recent-ish deviations in JSC and (because V8 was drafting off JSC) V8 don't nullify all that history. On the other hand, JSC and V8 are doing fine AFAIK. It's hard to make a real-world case where this matters, even with Object.create. And I see the ocap (not just SES) appeal of the fix. Just to be even clearer. This was not a mistake in ES5/5.1 and it is not a bug. It is a semantics, which as Brendan points out goes all the way back to ES1. It is also a behavior which makes complete sense from a prototypal inheritance perspective and can be found in the Self language. The basic idea is that the properties prototype object are shared parts of all of inheriting child object. Modifying such a shared part by a child, introduces a local change that is visible to that child (and its children) so this requires creation of a own property on the child. However, read-only properties can not modified (by normal means, eg assignment) so there is no need to create a own copy. Assigning to an inherited read-only property or a own read-only property should have the same affect (whether it is ignoring the assignment, throwing, etc.). Allowing assignment to an inherited read-only property would break the invariant that that a prototype's readonly property is an immutable value that is shared among all children of the prototype. If there was a mistake in designing ES5, it was allowing Object.defineOwnProperty to create child properties that over-ride inherited read-only data properties. This broke an invariant that previously existed in the language but this invariant was already violated by some pre-ES5 clause 15 objects, (eg the writability of the prototype property of some children of Function.prototype). However, I think the ES5 decision was probably the right one given the legacy clause 15 usages and the overall reflective nature of defineOwnProperty). Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Hello again! Sorry to reply my own post, but I came to the conclusion that Self-like shared part simply cannot work as an argument (and that not to be able to override read-only property from the prototype _is_, indeed, an error). If the shared part mind-set was the cornerstone of ES, then this: foo = { x:4 }; bar = Object.create(foo); bar.x = 5; return foo.x; would yield 5. After all, x is shared part of bar and foo. But every knows that it yield 4. bar has its own x holding 5, foo has his own holding 4. So as for this: === Allen Wirfs-Brock wrote === The basic idea is that the properties prototype object are shared parts of all of inheriting child object. Modifying such a shared part by a child, introduces a local change that is visible to that child (and its children) so this requires creation of a own property on the child. However, read-only properties can not modified ... === I can only reply with if the prototype is the shared part as per Self mindset, you cannot create own property at all. In previous example, x is the shared part. Above statement bar.x = 5 would change foo.x (since it is the shared x). So I think the model in Javascript is fallback delegation and creation of own property by Object.defineProperty is not an error; and creation of own property by assignment should be allowed; and inability to do it is indeed an error. Herby -Pôvodná správa- From: Herby Vojčík Sent: Tuesday, January 10, 2012 12:09 PM To: Allen Wirfs-Brock ; Brendan Eich Cc: Mark S. Miller ; es-discuss Steen Subject: Re: ES6 doesn't need opt-in This is interesting issue. There is a subtle difference between prototype chain is the shared part Self mindset and the prototype chain is fallback delegation mindset. Though I knew of Self and knew it had an impact on Javascript creation, I had always an impression that in Javascript (having become ECMAScript) it was the latter, that is the philosophy is that child can override the default from prototype chain. So what is the actual philosophy of ES prototype chain? Herby -Pôvodná správa- From: Allen Wirfs-Brock Sent: Monday, January 09, 2012 9:41 PM To: Brendan Eich Cc: Mark S. Miller ; es-discuss Steen Subject: Re: ES6 doesn't need opt-in ... Just to be even clearer. This was not a mistake in ES5/5.1 and it is not a bug. It is a semantics, which as Brendan points out goes all the way back to ES1. It is also a behavior which makes complete sense from a prototypal inheritance perspective and can be found in the Self language. The basic idea is that the properties prototype object are shared parts of all of inheriting child object. Modifying such a shared part by a child, introduces a local change that is visible to that child (and its children) so this requires creation of a own property on the child. However, read-only properties can not modified (by normal means, eg assignment) so there is no need to create a own copy. Assigning to an inherited read-only property or a own read-only property should have the same affect (whether it is ignoring the assignment, throwing, etc.). Allowing assignment to an inherited read-only property would break the invariant that that a prototype's readonly property is an immutable value that is shared among all children of the prototype. If there was a mistake in designing ES5, it was allowing Object.defineOwnProperty to create child properties that over-ride inherited read-only data properties. This broke an invariant that previously existed in the language but this invariant was already violated by some pre-ES5 clause 15 objects, (eg the writability of the prototype property of some children of Function.prototype). However, I think the ES5 decision was probably the right one given the legacy clause 15 usages and the overall reflective nature of defineOwnProperty). Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Tue, Jan 10, 2012 at 5:38 AM, Herby Vojčík he...@mailbox.sk wrote: Hello again! Sorry to reply my own post, but I came to the conclusion that Self-like shared part simply cannot work as an argument (and that not to be able to override read-only property from the prototype _is_, indeed, an error). If the shared part mind-set was the cornerstone of ES, then this: foo = { x:4 }; bar = Object.create(foo); bar.x = 5; return foo.x; would yield 5. After all, x is shared part of bar and foo. But every knows that it yield 4. bar has its own x holding 5, foo has his own holding 4. So as for this: === Allen Wirfs-Brock wrote === The basic idea is that the properties prototype object are shared parts of all of inheriting child object. In your example |foo| is not an inheriting child object. It is the parent. jjb Modifying such a shared part by a child, introduces a local change that is visible to that child (and its children) so this requires creation of a own property on the child. However, read-only properties can not modified ... === I can only reply with if the prototype is the shared part as per Self mindset, you cannot create own property at all. In previous example, x is the shared part. Above statement bar.x = 5 would change foo.x (since it is the shared x). So I think the model in Javascript is fallback delegation and creation of own property by Object.defineProperty is not an error; and creation of own property by assignment should be allowed; and inability to do it is indeed an error. Herby -Pôvodná správa- From: Herby Vojčík Sent: Tuesday, January 10, 2012 12:09 PM To: Allen Wirfs-Brock ; Brendan Eich Cc: Mark S. Miller ; es-discuss Steen Subject: Re: ES6 doesn't need opt-in This is interesting issue. There is a subtle difference between prototype chain is the shared part Self mindset and the prototype chain is fallback delegation mindset. Though I knew of Self and knew it had an impact on Javascript creation, I had always an impression that in Javascript (having become ECMAScript) it was the latter, that is the philosophy is that child can override the default from prototype chain. So what is the actual philosophy of ES prototype chain? Herby -Pôvodná správa- From: Allen Wirfs-Brock Sent: Monday, January 09, 2012 9:41 PM To: Brendan Eich Cc: Mark S. Miller ; es-discuss Steen Subject: Re: ES6 doesn't need opt-in ... Just to be even clearer. This was not a mistake in ES5/5.1 and it is not a bug. It is a semantics, which as Brendan points out goes all the way back to ES1. It is also a behavior which makes complete sense from a prototypal inheritance perspective and can be found in the Self language. The basic idea is that the properties prototype object are shared parts of all of inheriting child object. Modifying such a shared part by a child, introduces a local change that is visible to that child (and its children) so this requires creation of a own property on the child. However, read-only properties can not modified (by normal means, eg assignment) so there is no need to create a own copy. Assigning to an inherited read-only property or a own read-only property should have the same affect (whether it is ignoring the assignment, throwing, etc.). Allowing assignment to an inherited read-only property would break the invariant that that a prototype's readonly property is an immutable value that is shared among all children of the prototype. If there was a mistake in designing ES5, it was allowing Object.defineOwnProperty to create child properties that over-ride inherited read-only data properties. This broke an invariant that previously existed in the language but this invariant was already violated by some pre-ES5 clause 15 objects, (eg the writability of the prototype property of some children of Function.prototype). However, I think the ES5 decision was probably the right one given the legacy clause 15 usages and the overall reflective nature of defineOwnProperty). Allen __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On 6 January 2012 03:37, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Here is a possible set of rules for implicitly assigning ES5 or ES6 semantics to a Program unit In an ES6 implementation, all constructs that can occur in a valid program fit into one of these categories: ES6-only: The construct is based upon syntax or static semantics rules that only exist in ES6. For example, a destructuring pattern ES5-only: The construct is based upon syntax that or static semantics rules that that are not in ES6. For example, use of a with statement t. ES5ES6: The construct has identical semantics in both ES5 and ES6. ES5~EAS6: The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics. For example, accessing a formal parameter after an assignment to the corresponding element of the function's arguments object. We can then use the following state machines to describes the processing of a Program based upon the occurrence for these feature categories. Initially start in State 56: I think the state machine is over-complicating things. What it boils down to is that we are defining a new language, ES6-proper (or informally ES6 for short). It overlaps with ES5 but does not include it (e.g. throws out `with'). Then your state machine simply says, declaratively: - If a program is ES5 but not ES6, treat as ES5. - If a program is ES6 but not ES5, treat as ES6. - If a program is both ES5 and ES6, with identical semantics, treat as ES6 (although it doesn't matter). - If a program is both ES5 and ES6, with different semantics, treat as ES5 (for compatibility). - If a program is neither ES5 nor ES6, it's an error (obviously). I very much like that opt-in would be for whole programs only. I think that is good, and IMHO progress over some of the earlier discussion. But still, deciding what semantics a program has can depend on very minor syntactic details. This has several potential problems: 1. For eternity, we will require future programmers to remember what exact features were introduced with ES6, in order to be sure that they trigger the right (i.e. strict) semantics for their program. 2. The syntactic trigger in a given program may be hidden somewhere deep down the source code, which makes it very difficult to decide for the reader (and the compiler, which may have to do extra work in the parser to decide). 3. Apparently minor local modifications may accidentally change the semantics of the whole program. The obvious way to avoid all these issues is to always put an explicit trigger at the top. And I expect that style guides would recommend that. But that kind of defeats the purpose, doesn't it? I still haven't heard a convincing argument why it is advantageous to not make this explicit trigger mandatory. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 9, 2012, at 2:49 AM, Andreas Rossberg wrote: On 5 January 2012 20:10, Brendan Eich bren...@mozilla.com wrote: On Jan 5, 2012, at 6:31 AM, Andreas Rossberg wrote: Sorry, I still think that a growing set of subtle implicit rules for activating subtle semantic changes Not changes, new semantics for new syntax. I was referring to strict vs classic mode. The way I understood the discussion so far, certain syntax would implicitly opt into extended mode, and thereby also into strict mode -- locally, and from classic. That implies semantic changes for existing features. The question is how bad these will be for anyone writing JS naively, based on current and emerging (ES6) docs, without explicit opt-in. The answer entails at least: 1. ES5-strict semantic changes, e.g. arguments aliasing, without early errors. 2. Completion reform. 3. New early errors. I think 3 is a good thing and a non-problem. Some of us hope 2 is a matter of indifference to real-world code, but we don't know for sure. That leaves 1. No other semantic changes, right? The key idea of the state machine is not its exact spec (still being discussed) but that one JS should mean sane operation or early error, based on smooth upgrade to use non-conflicting new features (or conflicts, e.g. 'with' vs. 'module'). Why work harder on implicit opt-in? Yes, savvy users will put a pragma on line 1. Not all JS users are savvy and requiring them to become so asks too much. [The discussion seems to have changed direction again with Allen's state machine idea. That probably makes some of my comments obsolete. Sorry for lagging behind.] No problem. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 9, 2012, at 7:54 AM, Brendan Eich wrote: The question is how bad these will be for anyone writing JS naively, based on current and emerging (ES6) docs, without explicit opt-in. The answer entails at least: 1. ES5-strict semantic changes, e.g. arguments aliasing, without early errors. I should have written more, since without early errors is an assumption, not a requirement. Allen's state machine o.p discussed this more. From Allen's o.p.: ES5~EAS6: The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics. For example, accessing a formal parameter after an assignment to the corresponding element of the function's arguments object. This triggers different state transitions. I'm working on SpiderMonkey now, and we already must analyze for arguments[i] and formal parameter assignments to deoptimize nonstrict code. The main challenge is good error blame when the compiler detects a conflict requiring an early error. You want to blame both the (possibly much earlier) formal or arguments[i] assignment, and the later ES6 feature. I believe that all current optimizing JS engines have to do this kind of analysis. So I wonder if it wouldn't be easy (not sure how normative we make this) to deal with (1) with early errors. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On 9 January 2012 16:54, Brendan Eich bren...@mozilla.com wrote: The question is how bad these will be for anyone writing JS naively, based on current and emerging (ES6) docs, without explicit opt-in. The answer entails at least: 1. ES5-strict semantic changes, e.g. arguments aliasing, without early errors. 2. Completion reform. 3. New early errors. I think 3 is a good thing and a non-problem. Some of us hope 2 is a matter of indifference to real-world code, but we don't know for sure. That leaves 1. Yes, but (1) is not a trivial set -- e.g. receiver coercions, eval semantics, delete type errors, arguments aliasing, poisoning of caller/arguments, etc. No other semantic changes, right? The key idea of the state machine is not its exact spec (still being discussed) but that one JS should mean sane operation or early error, based on smooth upgrade to use non-conflicting new features (or conflicts, e.g. 'with' vs. 'module'). Why work harder on implicit opt-in? Yes, savvy users will put a pragma on line 1. Not all JS users are savvy and requiring them to become so asks too much. But it's especially the non-savvy ones that would be particularly well-advised to put in that pragma, so that they avoid nasty surprises beyond their grasp! /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 8, 2012, at 9:26 PM, Brendan Eich wrote: On Jan 8, 2012, at 4:53 PM, Mark S. Miller wrote: On Sun, Jan 8, 2012 at 10:32 AM, Brendan Eich bren...@mozilla.com wrote: [...] All cool with the above. Thanks. I wrote in a previous reply that we aren't preserving ES5 as a spec referenced from ES6. ES6 will be self-contained. So I still don't grok your concern here. Sorry, I missed that. In that case, I still don't understand what your plan for ES6 is. Does the ES6 spec include the state machine and an updated form of the ES5-non-strict portions of the ES5 spec, as referenced by that state machine? I defer to Allen, but one approach is to leave ES5-nonstrict as is, and combine strict and extended modes for the 6 in 56 and ES56. As you proposed! HTH, /be I've been thinking about this, but I'm not yet certain about a preferred approach. One alternative is to keep the current ES5 specification( both non-strict and strict) as a normative part of ECMA-262 and add a new part which is the complete specification for ES6. Essentially Ecma-262-6 part 1 would be the same as Ecma-262-5 (plus any errata level corrections) but excluding most of clause 15 (the builty-in library) and Ecma-262-9 part 2 would be a comprehensive specification for a language that starts with implicit ES5 strict mode (modulo completion reform and any other semantic changes) add new ES6 features and excludes ES5 non-strict features and semantics. Because of the shared heap, the new clause 15 would have to apply to both the part 1 and part 2 languages. The specification would have to include something like my state machine which determines whether the part 1 or part 2 language is to be used to process a Program. This approach has the advantage that it simplifies the specification of the new ES6 features and minimizes the risk of unintentionally changing the specification of ES-5 non-strict features that must exist somewhere in the specification. I'm finding various places where significant changes in specification technique is required to support new feature semantics and making sure that the rewritten specification also works for legacy (non-strict ES5). However, this approach has the disadvantage that implementors who what to share as much logic as possible between ES5 mode and ES6 mode many have to do their own analysis of the differences and commonalities. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 9, 2012, at 2:59 AM, Andreas Rossberg wrote: I think the state machine is over-complicating things. What it boils down to is that we are defining a new language, ES6-proper (or informally ES6 for short). It overlaps with ES5 but does not include it (e.g. throws out `with'). Then your state machine simply says, declaratively: - If a program is ES5 but not ES6, treat as ES5. - If a program is ES6 but not ES5, treat as ES6. - If a program is both ES5 and ES6, with identical semantics, treat as ES6 (although it doesn't matter). - If a program is both ES5 and ES6, with different semantics, treat as ES5 (for compatibility). - If a program is neither ES5 nor ES6, it's an error (obviously). If the a program is both ES5 and ES6 with identical semantics, then presumably we could equally treat it as ES5 with no behavior change? If so, couldn't this be stated in a much simpler fashion: - If a program is ES5, treat as ES5. - If a program is not ES5 but is ES6, treat as ES6. - If a program is neither ES5 nor ES6, it's an error (obviously). cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 8, 2012, at 10:32 AM, Brendan Eich wrote: On Jan 8, 2012, at 8:28 AM, Mark S. Miller wrote: ... The other change I hope fits into the same bucket is http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake. Right now, because of pressure from test262, we are in danger of having all browsers conform to this mistake, at which point it may be too late to fix it. Today, the diversity of actual browser behaviors means it is still possible to fix this mistake, much as the diversity of ways ES3 implementations were broken made it possible for ES5 to fix many mistakes. The [[CanPut]] check goes back to ES1, though. Recent-ish deviations in JSC and (because V8 was drafting off JSC) V8 don't nullify all that history. On the other hand, JSC and V8 are doing fine AFAIK. It's hard to make a real-world case where this matters, even with Object.create. And I see the ocap (not just SES) appeal of the fix. Just to be even clearer. This was not a mistake in ES5/5.1 and it is not a bug. It is a semantics, which as Brendan points out goes all the way back to ES1. It is also a behavior which makes complete sense from a prototypal inheritance perspective and can be found in the Self language. The basic idea is that the properties prototype object are shared parts of all of inheriting child object. Modifying such a shared part by a child, introduces a local change that is visible to that child (and its children) so this requires creation of a own property on the child. However, read-only properties can not modified (by normal means, eg assignment) so there is no need to create a own copy. Assigning to an inherited read-only property or a own read-only property should have the same affect (whether it is ignoring the assignment, throwing, etc.). Allowing assignment to an inherited read-only property would break the invariant that that a prototype's readonly property is an immutable value that is shared among all children of the prototype. If there was a mistake in designing ES5, it was allowing Object.defineOwnProperty to create child properties that over-ride inherited read-only data properties. This broke an invariant that previously existed in the language but this invariant was already violated by some pre-ES5 clause 15 objects, (eg the writability of the prototype property of some children of Function.prototype). However, I think the ES5 decision was probably the right one given the legacy clause 15 usages and the overall reflective nature of defineOwnProperty). Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
FTR (a broken record, sorry), I think we will do a big disservice to interoperation in practice (as enjoyed by future web devs) if we essentially fork the spec and mutate one copy (even excluding Clause 15) to be ES6. I'm still pretty sure implementations will not fork their non-library codebases. Mozilla's won't. So that means the spec will be the only unconsolidated implementation. Yes, new features (especially around parameters) may combine with old (arguments). Let's do the case analysis and see how bad this must be. I think it's strictly less bad on balance, weighing the cost to implementors, than forking. Forking the spec also raises the risk of more incompatible changes than those (few, almost none) that we intended. I'd rather bail on completion reform back to ES5 strict runtime semantics if that is what it takes to keep a consolidated/minimized spec. /be On Jan 9, 2012, at 12:09 PM, Allen Wirfs-Brock wrote: On Jan 8, 2012, at 9:26 PM, Brendan Eich wrote: On Jan 8, 2012, at 4:53 PM, Mark S. Miller wrote: On Sun, Jan 8, 2012 at 10:32 AM, Brendan Eich bren...@mozilla.com wrote: [...] All cool with the above. Thanks. I wrote in a previous reply that we aren't preserving ES5 as a spec referenced from ES6. ES6 will be self-contained. So I still don't grok your concern here. Sorry, I missed that. In that case, I still don't understand what your plan for ES6 is. Does the ES6 spec include the state machine and an updated form of the ES5-non-strict portions of the ES5 spec, as referenced by that state machine? I defer to Allen, but one approach is to leave ES5-nonstrict as is, and combine strict and extended modes for the 6 in 56 and ES56. As you proposed! HTH, /be I've been thinking about this, but I'm not yet certain about a preferred approach. One alternative is to keep the current ES5 specification( both non-strict and strict) as a normative part of ECMA-262 and add a new part which is the complete specification for ES6. Essentially Ecma-262-6 part 1 would be the same as Ecma-262-5 (plus any errata level corrections) but excluding most of clause 15 (the builty-in library) and Ecma-262-9 part 2 would be a comprehensive specification for a language that starts with implicit ES5 strict mode (modulo completion reform and any other semantic changes) add new ES6 features and excludes ES5 non-strict features and semantics. Because of the shared heap, the new clause 15 would have to apply to both the part 1 and part 2 languages. The specification would have to include something like my state machine which determines whether the part 1 or part 2 language is to be used to process a Program. This approach has the advantage that it simplifies the specification of the new ES6 features and minimizes the risk of unintentionally changing the specification of ES-5 non-strict features that must exist somewhere in the specification. I'm finding various places where significant changes in specification technique is required to support new feature semantics and making sure that the rewritten specification also works for legacy (non-strict ES5). However, this approach has the disadvantage that implementors who what to share as much logic as possible between ES5 mode and ES6 mode many have to do their own analysis of the differences and commonalities. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Sat, Jan 7, 2012 at 11:05 PM, Brendan Eich bren...@mozilla.com wrote: [...] so are we really just arguing about names or labels? If so, great -- those are important to get right. [...] While I agree it's important to get labels right, if that is indeed the only remaining issue here, that's wonderful. I'm mellow about labels others find attractive, as long as we agree on observables. I think there is an observable difference between what I'm advocating and what Allen is. Not as sure about your position. But it is possible I'm misunderstanding something and there is no observable difference. At this point, we've narrowed the issue enough that we should probably postpone this final step till we can engage verbally with lower latency -- at the upcoming meeting. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Sun, Jan 8, 2012 at 8:15 AM, Brendan Eich bren...@mozilla.com wrote: On Jan 8, 2012, at 8:10 AM, Mark S. Miller wrote: On Sat, Jan 7, 2012 at 11:05 PM, Brendan Eich bren...@mozilla.com wrote: [...] so are we really just arguing about names or labels? If so, great -- those are important to get right. [...] While I agree it's important to get labels right, if that is indeed the only remaining issue here, that's wonderful. I'm mellow about labels others find attractive, as long as we agree on observables. I think there is an observable difference between what I'm advocating and what Allen is. Not as sure about your position. I think the only open issue is whether use strict; opts into completion reform and any other semantic change that does not have a syntactic trigger. I'm ok with trying completion reform as an extension to use strict; in ES5+ implementations, ASAP -- more than ok, really. It would help prove completion reform is non-breaking. That is an example of the kind of issue I am concerned about -- and it is much more than a terminology difference. Any other cleanups we do in ES6 --- that we believe to be practically backward compatible with ES5-strict practice but not with the normative spec nor with test262 --- would fall into the same category as completion reform. So the status of things like we imagine completion reform to be, whether or not completion reform itself is one of those, is something we need to resolve. The other change I hope fits into the same bucket is http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake. Right now, because of pressure from test262, we are in danger of having all browsers conform to this mistake, at which point it may be too late to fix it. Today, the diversity of actual browser behaviors means it is still possible to fix this mistake, much as the diversity of ways ES3 implementations were broken made it possible for ES5 to fix many mistakes. And there is one further issue I think is worth clearing up in email here. What do we expect to be the normative status of the state machine itself and of the ES5 spec, after ES6 becomes official, for a browser that claims to be standards compliant, including ES6 compliant? AFAICT, no one has commented on this specifically, and we may be reading different assumptions into Allen's proposal. What I am assuming Allen's proposal means is that the state machine would also be normative, and therefore those parts of the ES5 spec that are reachable from this state machine would remain normative as well. As I understand ECMA rules, it would be at least unusual for the earlier edition of the spec to remain normative even for systems claiming conformance to the later edition of the same spec. (same by spec number, i.e., 262). -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 7, 2012, at 11:41 PM, Axel Rauschmayer wrote: Isn’t ES5.nonstrict the union of ES5.nonstrict-ES6-intersection and ES5.nonstrict-differs-from-ES6? If yes then ES5.nonstrict disappears and we might have a venn diagram intersecting ES5.nonstrict and ES6: ES5.nonstrict-only (=ES5.nonstrict-differs-from-ES6) ES5.nonstrict-ES6-intersection ES6-only (=ES6-differs-from-ES5.nonstrict) As Mark just wrote this depends on how we resolve some fine points (completion reform among them). This might be about to the question as to whether there should be a mode that combines ES6-differs-from-ES5.strict constructs with ES5.nonstrict. I don’t think there should be. Oh no, that's right out. We can't have 'let' be reserved conditionally without more complexity (we could just reserve it and see what breaks, but then that's not ES5-nonstrict is it :-P). /be___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 8, 2012, at 8:28 AM, Mark S. Miller wrote: I'm ok with trying completion reform as an extension to use strict; in ES5+ implementations, ASAP -- more than ok, really. It would help prove completion reform is non-breaking. That is an example of the kind of issue I am concerned about -- and it is much more than a terminology difference. Any other cleanups we do in ES6 --- that we believe to be practically backward compatible with ES5-strict practice but not with the normative spec nor with test262 --- would fall into the same category as completion reform. So the status of things like we imagine completion reform to be, whether or not completion reform itself is one of those, is something we need to resolve. Yes. This is not easy to resolve by a-prior reasoning, though. We might just do nothing incompatible, but we could also probably get away with completion reform and your fixing-override-mistake change. Some experimentation in nightly and even longer-lived/used builds is required. The other change I hope fits into the same bucket is http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake. Right now, because of pressure from test262, we are in danger of having all browsers conform to this mistake, at which point it may be too late to fix it. Today, the diversity of actual browser behaviors means it is still possible to fix this mistake, much as the diversity of ways ES3 implementations were broken made it possible for ES5 to fix many mistakes. The [[CanPut]] check goes back to ES1, though. Recent-ish deviations in JSC and (because V8 was drafting off JSC) V8 don't nullify all that history. On the other hand, JSC and V8 are doing fine AFAIK. It's hard to make a real-world case where this matters, even with Object.create. And I see the ocap (not just SES) appeal of the fix. And there is one further issue I think is worth clearing up in email here. What do we expect to be the normative status of the state machine itself and of the ES5 spec, after ES6 becomes official, for a browser that claims to be standards compliant, including ES6 compliant? AFAICT, no one has commented on this specifically, and we may be reading different assumptions into Allen's proposal. What I am assuming Allen's proposal means is that the state machine would also be normative, and therefore those parts of the ES5 spec that are reachable from this state machine would remain normative as well. As I understand ECMA rules, it would be at least unusual for the earlier edition of the spec to remain normative even for systems claiming conformance to the later edition of the same spec. (same by spec number, i.e., 262). I wrote in a previous reply that we aren't preserving ES5 as a spec referenced from ES6. ES6 will be self-contained. So I still don't grok your concern here. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Sun, Jan 8, 2012 at 10:32 AM, Brendan Eich bren...@mozilla.com wrote: [...] All cool with the above. Thanks. I wrote in a previous reply that we aren't preserving ES5 as a spec referenced from ES6. ES6 will be self-contained. So I still don't grok your concern here. Sorry, I missed that. In that case, I still don't understand what your plan for ES6 is. Does the ES6 spec include the state machine and an updated form of the ES5-non-strict portions of the ES5 spec, as referenced by that state machine? If not, what standards document governs how a future standards compliant browser is supposed to handle code which has non opted into anything, neither implicitly-explicitly nor explicitly? -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Hi, I think Allen had another point. What you are counting, are semantic modes of the code, that is, runtime. What Allen counts, are specification modes of the language, that is, compilation. These are different beans, as he said earlier. Things that Allen defines (afaict) are: - compilation targets ES5 ::= When run, the program will be interpreted according to ES5 spec. In particular, parts with use strict; will be interpreted with ES5 strict mode semantics and parts without it with ES5 non-strict mode semantics. In other words, it will be compiled according to ES5 spec. ES6 ::= When run, the program will be interpreted according to ES6 spec. In particular, parts with use strict; will be interpreted with ES6 (strict) mode semantics and part without it also with ES6 (strict) mode semantics. In other words, it will be compiled according to ES5 spec. - categories of the code elements with respect to compilation targets (they are event in the pre-compilation parsing state machine) Identical-in-both (ES5ES6), Valid-but-differs (ES5~ES6), Valid-only-in-ES5 (ES5-only), Valid-only-in-ES6 (ES6-only) - states and transitions of the pre-compilation parsing state machine 56, ES5, ES6, Compat5 states transitions for all of them with respect to events above (that is, categories) The output of the state machine is the compilation target (inferred directly from the state at which the state machine finishes: ES5, ES5, ES6 and ES5, respectively), eventually an early error that prevents compilation because of conflicting ES5-only and ES6-only code was detected while parsing. use strict; and its two modes are only important here, when the program is being compiled (when in state machine, it should imo trigger Identical-in-both event). He also recommends opt-ins to be sure to get ES5 target or ES6 target (unless there is conflict in code, of course) as the output of the state machine by citing pieces of code with no functionality but triggering Valid-only-in-ES5 or Valid-only-in-ES6 events in the parsing state machine, thereby fixing its state to ES5 or ES6. Herby -Pôvodná správa- From: Mark S. Miller Sent: Saturday, January 07, 2012 4:29 AM To: Axel Rauschmayer Cc: Brendan Eich ; es-discuss Steen Subject: Re: ES6 doesn't need opt-in Axel, thanks. This is the critical point, so no apologies needed for belaboring. Allen, what I mean is exactly what Axel says here. Look at it another way. Right now we have two normative modes: ES5 strict and ES5 non-strict. State machine aside, ES6 introduces a new single mode normative spec. If the state machine may delegate to any of these three normative specs we have three modes. If the state machine may only delegate to ES5-non-strict or ES6, i.e., if the ES5-strict spec becomes dead code as of conformance with state machine + ES6 spec, then we have two modes. To get this effect, we need only classify ES5's use strict; directive as ES6-only. If any objection to doing so has been stated, I missed it. Is there a reason not to do so? It's a one line change that leaves the rest of your proposal unperturbed and solves this problem. On Fri, Jan 6, 2012 at 12:09 PM, Axel Rauschmayer a...@rauschma.de wrote: Rather, we should minimize the state machine and how we talk about it. We could generalize it using Curr, Next, CurrNext, and Curr-Next labels. I’m awfully sorry for belaboring this point. But the labels and the quote below don’t go together. Quoting Brendan: - ES6 is a superset of ES5.strict. That's always been promised. Then I would only expect two labels: ES6 and non-strict ES6-only = (a subset of) ES6 ES5-only = only possible for non-strict constructs = non-strict ES5ES6 = (a subset of) ES6 ES5~EAS6 = not possible (“The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics.”) -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
if current construct is in ES6-only, abort current compilation and restart from beginning, starting in State ES6 Basically using any ES6 features makes it an ES6 program. Using any ES5-only feature makes it an ES5 program. Combining ES5-only and ES6 features results in an invalid program. If a Program can not be explicitly identified as either ES5 or ES6, it is treated as an ES5 program. Could you please clarify for me: if I get a single-file codebase, say jquery's 6k or so lines, will I have to scan the whole file for ES6-only features before I can even tell whether to apply ES6 or ES5 semantics? And will this problem increase by one level with every future version of ES? ES5 already has the var-hoisting oddity where I might have to scan the whole file before being able to decide whether a given variable occurrence is bound to a given variable declaration. I'm not alone in not wanting to see (another) such hazard (*). Btw, I'm really uncomfortable with implicit feature tracking - it works ok for people who follow all the relevant mailinglist discussions and spec versions, but it leaves in the dark all those who just code in JS and enter a situation where their code base might have to be interpreted according to any of a number of specs (most JS coders do not even read one version of the spec, but rely on blogs and books, which will equally show no explicit in-source sign of what spec version their examples refer to and whether they are out of date). Making feature-based versioning explicit (by pragma opt-in) doesn't solve all problems, but at least everybody knows what everyone else is talking about, and help can be offered (if you want ES6 semantics for let and yield, write 'use let,yield' or just 'use ES6', if you want JS1.8 semantics for these features, use ..; if you want to concatenate old and new code, protect the old code with 'use ES5' and the new code with 'use ES6'). By making feature-based versioning implicit (by feature use), only experts will be able to say wait, I remember that kind of issue - perhaps your engine has switched to another ES version. could you check whether your source has any yields in it, or perhaps destructuring, or perhaps a with, or perhaps a vat? yes, please check even seemingly unrelated parts of the source.. Also, what happened to the bold this version will break a few things, but we'll end up with a much cleaner language spec? I'm not saying you are wrong - if you can pull it off, great! But the new plan reminds me strongly of bad experiences in Haskell-land. Claus (*) At least one popular tool (jslint) has decided not to implement the resulting 2-pass complexity (find var declarations, then parse for real) but restricts the input language instead, and makes do with a single pass over the source and naïve scope-tracking. If I remember correctly, simply lifting jslint's unpopular vars-first restriction would lead to incorrect internal scope tracking (I don't know how jshint handles this, btw?). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 7, 2012, at 2:22 PM, Claus Reinke wrote: Could you please clarify for me: if I get a single-file codebase, say jquery's 6k or so lines, will I have to scan the whole file for ES6-only features before I can even tell whether to apply ES6 or ES5 semantics? And will this problem increase by one level with every future version of ES? Btw, I'm really uncomfortable with implicit feature tracking - it works ok for people who follow all the relevant mailinglist discussions and spec versions, but it leaves in the dark all those who just code in JS and enter a situation where their code base might have to be interpreted according to any of a number of specs (most JS coders do not even read one version of the spec, but rely on blogs and books, which will equally show no explicit in-source sign of what spec version their examples refer to and whether they are out of date). I share these concerns. Would the implicit opt-in proposal not mean that any programmer wanting to pick up JavaScript would need to learn the history of when different syntactic constructs came into the language specification in order to understand the semantics that a given script would be evaluated with? G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 7, 2012, at 8:00 PM, Gavin Barraclough wrote: Would the implicit opt-in proposal not mean that any programmer wanting to pick up JavaScript would need to learn the history of when different syntactic constructs came into the language specification in order to understand the semantics that a given script would be evaluated with? If there's new syntax somewhere, the consumer of the code may have to read and understand it. But let's be real: JQuery users *do not* read and understand that library's every line. They use its well-documented APIs. Remember, we are not proposing breaking semantic shifts of meaning for existing syntax. So the realistic worry is that you have code with arguments[i] aliasing a formal, and this is required for correct operation, and you then start using ES6 features (which imply ES5-strict), which breaks arguments aliasing. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 7, 2012, at 23:22 , Claus Reinke wrote: But the new plan reminds me strongly of bad experiences in Haskell-land. That sounds interesting. Is this documented somewhere? -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 7, 2012, at 8:39 PM, Brendan Eich wrote: Remember, we are not proposing breaking semantic shifts of meaning for existing syntax. So the realistic worry is that you have code with arguments[i] aliasing a formal, and this is required for correct operation, and you then start using ES6 features (which imply ES5-strict), which breaks arguments aliasing. Hmmm, I was thinking this proposal implied much more of a breaking change (e.g. removing the global object from scope), but if the change in semantics largely comes down to enabling ES5-strict then maybe this isn't so bad. If we are talking about implicitly enabling ES5-strict for the whole program, I would think there may be a quite a few more hazards to consider? (code that implicitly introduces variables onto the global object, assumes this conversion to global object value in function calls, uses callee/caller/arguments, etc). Still, I'm warming up to the idea considerably if the implicit opt-in is triggering no major breaking changes. G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 6, 2012, at 7:48 PM, Mark S. Miller wrote: Then I would only expect two labels: ES6 and non-strict You're counting different beans from Mark's modes and from Allen's states. Hi Brendan, as I read it, Axel captures exactly the two modes I have in mind. Ok, good to have fewer positions :-). The reason the state machine matters is implementation (including the fine spec, the normative implementation). Authors can think of writing non-strict ES5 or lower, or ES5 strict -- or ES6 if they use a bit of novelty. Different beans again. I'm not sure what informs your label count expectation. In writing JS for the web over the next several years, you might have to worry quite a bit about ES5 strict vs. ES6. You can't just assume ES6 works everywhere that ES5 strict works. The issue is: What does it mean for a browser to be standards compliant once it is fully conformant with ES6? Yes, of course there will be a long phase of partial ES6 compliance as features are incrementally rolled out. Just as there was with ES5. Still is. But during this period, no one claims full conformance with ES6, so standards compliance mean only compliance with ES5. To be standards compliant once one is ES6 compliant, the state machine + ES6 keeps some portion of the ES5 spec as a live normative spec because it is reachable from the state machine. The only question is: Which portion is reachable? With Allen's plan, all of it. With the one line revision Axel and I have in mind, the ES5-strict spec stops being reachable as normative for ES6 compliant browsers. It is dead code that can be considered garbage. Your post two above the one to which I'm replying proposes to have only ES5 non-strict and ES6, with use strict; (the string literal directive) enabling ES6. I don't a difference except in state-machine labels with what Allen proposes. Allen has 56, ES5, ES6, and Compat5. Relabel these to ES5-nonstrict-ES6-intersection ES5-nonstrict ES6 ES5-nonstrict-differs-from-ES6 Since ES5-strict is a subset of ES6, it doesn't require new states. Function declarations in blocks and (depending on implementation) const extensions fall into ES5-nonstrict-differs-from-ES6 as noted. That is, ES5-nonstrict must be read to include an implementations extensions that pre-date ES5, that are enabled without use strict;, and of course which conflict with ES5 strict. You previously wrote: For example, since legacy constrains us from making nested named function declarations a triggering feature, if program #2 [one with use strict; and conforming to ES5 strict] has a nested named function and the browser rejected it, that browser would still conform to both the ES5 and ES6 spec. ES6 will normatively require block-nested function declarations to be supported, with certain semantics. So I don't agree that a conforming ES6 implementation could reject such functions in blocks. You continued: The easy fix is to make use strict; a triggering condition. I agree that this follows from the state label definitions (whatever their names) and the state machine. Then you wrote: For non-strict code, by the state machine, the ES6 spec would still delegate to the ES5 spec. And the ES6 spec would otherwise be the same. But the strict portion of the ES5 spec would simply be dead code, because all of the conditions that would trigger it have already triggered the state machine into using the ES5 spec. Here again I'm confused. the ES6 spec is not going to delegate to a separate and older edition, namely ES5. It will be self-contained. So there must be something in the ES6 spec that defines how to process use strict; *or* new ES6 syntax, and how that makes duplicate formals an early error, etc. etc. IOW ECMA-262 Ed. 6 must contain some kind of state machinery for specifying opt-in. In the ES6 era, I hope to be able to say ES5-strict is dead. Long live ES6!. Ok, I can adjust labels to agree with this. But it doesn't relieve the ES6 spec from talking about opt-in from ES5-nonstrict, so are we really just arguing about names or labels? If so, great -- those are important to get right. If I seemed to disagree on number of modes, it may be because I don't see how a conforming ES6 implementation could continue to reject extensions that ES5-strict rejects (e.g., functions in blocks). ES6 will require functions-in-blocks to work a certain way. Any implementation that supported an extension under ES5-strict where the semantics for the same syntax differ between the extension and ES6 will have to suffer (SpiderMonkey let and const fall into this category). But that is SpiderMonkey's headache, not ECMA-262's. However, ES5-non-strict (or non-strict, or ES3) will continue to live for the foreseeable future. It will probably outlive most of us. Yup. /be /be ES6-only = (a subset of) ES6 ES5-only = only possible for non-strict constructs =
Re: ES6 doesn't need opt-in
On Jan 7, 2012, at 11:05 PM, Brendan Eich wrote: Allen has 56, ES5, ES6, and Compat5. Relabel these to ES5-nonstrict-ES6-intersection ES5-nonstrict ES6 ES5-nonstrict-differs-from-ES6 Since ES5-strict is a subset of ES6, it doesn't require new states. Again we wink at completion reform -- it changes semantics such that ES5-strict is not a subset of ES6 but we believe no code will notice (we could be wrong). We give up on typeof null and removing the global object. The free variable analysis based on global properties still gives early error on typo wins. That makes the subset relation technically false too but let's also wink at it by considering only strict programs that reach runtime under either an ES5 or an ES6 implementation. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 7, 2012, at 9:35 PM, Gavin Barraclough wrote: On Jan 7, 2012, at 8:39 PM, Brendan Eich wrote: Remember, we are not proposing breaking semantic shifts of meaning for existing syntax. So the realistic worry is that you have code with arguments[i] aliasing a formal, and this is required for correct operation, and you then start using ES6 features (which imply ES5-strict), which breaks arguments aliasing. Hmmm, I was thinking this proposal implied much more of a breaking change (e.g. removing the global object from scope), Nope, as dherman's o.p. said: giving up. But not the free variable analysis based on implicitly imported global object properties, for early errors on typos, of course. but if the change in semantics largely comes down to enabling ES5-strict then maybe this isn't so bad. If we are talking about implicitly enabling ES5-strict for the whole program, I would think there may be a quite a few more hazards to consider? (code that implicitly introduces variables onto the global object, assumes this conversion to global object value in function calls, uses callee/caller/arguments, etc). See Allen's state machine. It requires state transitions for the syntax whose meaning shifted from ES5 (non-strict, as Mark points out this is only part of ES5 so a misnamed label) to ES6. Still, I'm warming up to the idea considerably if the implicit opt-in is triggering no major breaking changes. The state machine won't trigger breaking runtime shifts but it will make early errors out of inconsistent combinations of ES5-nonstrict and ES6 features in a single program. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 8, 2012, at 8:05 , Brendan Eich wrote: Allen has 56, ES5, ES6, and Compat5. Relabel these to ES5-nonstrict-ES6-intersection ES5-nonstrict ES6 ES5-nonstrict-differs-from-ES6 Since ES5-strict is a subset of ES6, it doesn't require new states. I like these labels! Isn’t ES5.nonstrict the union of ES5.nonstrict-ES6-intersection and ES5.nonstrict-differs-from-ES6? If yes then ES5.nonstrict disappears and we might have a venn diagram intersecting ES5.nonstrict and ES6: ES5.nonstrict-only (=ES5.nonstrict-differs-from-ES6) ES5.nonstrict-ES6-intersection ES6-only (=ES6-differs-from-ES5.nonstrict) This might be about to the question as to whether there should be a mode that combines ES6-differs-from-ES5.strict constructs with ES5.nonstrict. I don’t think there should be. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Thu, Jan 5, 2012 at 11:47 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: 1) program using only ES3 features and no use strict; 2) program using only ES5 strict features and saying use strict; 3) program using ES6-only features. Do these three programs operate in three different modes? If not, do #1 and #2 operate in the same mode, or do #2 and #3 operate in the same mode? It isn't about modes. #1 and #2 are ES5 programs and are processed as such (applying/not the appropriately strictness as per ES5) . #3 is an ES6 program is processed as such (including using the strict semantics that are universal to ES6). Ok, is there any observable difference between what you would have future browsers do, vs the equivalent mechanisms except that program #2 is categorized as an ES6 program and processed as such? If there is no observable difference, good. Then it's only a matter of how we describe an agreed semantics. If there is an observable difference, how is this not three modes? -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 5, 2012, at 10:38 PM, Luke Hoban wrote: ... # Why ‘implicit explicit opt-in’ doesn’t seem reasonable # The prevalent alternatives presented in this thread are variations of “implicit explicit opt-in”, where use of some new syntax causes some part of the code inside or outside of it to start behaving differently (breaking changes). I think in practice this will be very confusing. Take this: var x = typeof null; module { var y = typeof null; x == y // false! } Note that my most resent postings were suggesting a different form of implicit explicit opt-in: use of new syntax causes all of the code in the same source file to potentially behave differently var x = typeof null; module { var y = typeof null; x == y // -true! } In practice, I agree that we don't want to make such a breaking change for typeof. But this approach would allow to make strict mode semantics be implicit for any source file that uses any new ES6 syntactic features. Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 6, 2012, at 12:00 AM, Mark S. Miller wrote: On Thu, Jan 5, 2012 at 11:47 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: 1) program using only ES3 features and no use strict; 2) program using only ES5 strict features and saying use strict; 3) program using ES6-only features. Do these three programs operate in three different modes? If not, do #1 and #2 operate in the same mode, or do #2 and #3 operate in the same mode? It isn't about modes. #1 and #2 are ES5 programs and are processed as such (applying/not the appropriately strictness as per ES5) . #3 is an ES6 program is processed as such (including using the strict semantics that are universal to ES6). Ok, is there any observable difference between what you would have future browsers do, vs the equivalent mechanisms except that program #2 is categorized as an ES6 program and processed as such? If there is no observable difference, good. Then it's only a matter of how we describe an agreed semantics. If there is an observable difference, how is this not three modes? There should be no observable difference. But the issue isn't how we described the (program) semantics. It is how we decide which semantics to apply. The tricky cases are thing like: function f(a) { arguments[0]=2; return a } print(f(1)); //2 if ES5, 1 if ES6 There is nothing in the source file that implies which specification to apply so for backwards computability a browser must default to interpreting such program as a ES5 program. Anything syntactically unique to ES5 (eg, use of a with statment) or ES6 (eg, use rest or spread) would force one interpretation or another Allen -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Fri, Jan 6, 2012 at 12:24 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: There should be no observable difference. But the issue isn't how we described the (program) semantics. It is how we decide which semantics to apply. Got it. It still gives the web only two modes, but has the huge benefit that the ES6 spec can avoid describing the semantics of non-strict code. Cool. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Ok, is there any observable difference between what you would have future browsers do, vs the equivalent mechanisms except that program #2 is categorized as an ES6 program and processed as such? If there is no observable difference, good. Then it's only a matter of how we describe an agreed semantics. If there is an observable difference, how is this not three modes? There should be no observable difference. But the issue isn't how we described the (program) semantics. It is how we decide which semantics to apply. The tricky cases are thing like: function f(a) { arguments[0]=2; return a } print(f(1)); //2 if ES5, 1 if ES6 There is nothing in the source file that implies which specification to apply so for backwards computability a browser must default to interpreting such program as a ES5 program. Anything syntactically unique to ES5 (eg, use of a with statment) or ES6 (eg, use rest or spread) would force one interpretation or another But what you are saying is that ES6 is not a superset of ES5.strict, right? I thought that there were only 2 semantics: 1. ES5.non-strict (which is a superset of all previous versions) [a.k.a. non-strict] 2. ES6 (which is a superset of ES5.strict) [a.k.a. strict] My understanding is that #1 would be the default and when one encounters anything ES6-specific (an “ES6 trigger”) or use strict then the semantics switches to #2. = encountering a with statement would be fine, because #1 is the default, anyway. = encountering a with statement and either an ES6 trigger or a use strict would be an error. As a human, I would want an ES6 trigger to appear as early as possible. I wouldn’t want to read through a file, encounter an ES6 trigger at the end and then have to revise the understanding of the code that I had so far. I like the whole-file-or-nothing approach for switching semantics that you proposed. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
-Pôvodná správa- From: Axel Rauschmayer Sent: Friday, January 06, 2012 12:11 PM To: Allen Wirfs-Brock Cc: Mark S. Miller ; Brendan Eich ; es-discuss Steen Subject: Re: ES6 doesn't need opt-in ... As a human, I would want an ES6 trigger to appear as early as possible. I wouldn’t want to read through a file, encounter an ES6 trigger at the end and then have to revise the understanding of the code that I had so far. I like the whole-file-or-nothing approach for switching semantics that you proposed. -- Dr. Axel Rauschmayer a...@rauschma.de === But you can! Allen has explicitly said put 'let ES6;' at the beginning if you want to force ES6. As a human, you can argue that it is humanly to actually do it. And when the code is such that it is really ES5ES6 the whole time and only at the end the ES6 feature is used, then what? It is so. I think the Mark Miller's has the huge benefit that the ES6 spec can avoid describing the semantics of non-strict code. Cool. is undepinning what the real value behind the Allen's state machine is. Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
No sorry, I just spotted the flaw. The observable difference is that a conforming browser is not required by the (ES5 + ES6) specs to provide any non-triggering ES6 features for program #2. In that case, we again have three mode. For example, since legacy constrains us from making nested named function declarations a triggering feature, if program #2 has a nested named function and the browser rejected it, that browser would still conform to both the ES5 and ES6 spec. The easy fix is to make use strict; a triggering condition. For non-strict code, by the state machine, the ES6 spec would still delegate to the ES5 spec. And the ES6 spec would otherwise be the same. But the strict portion of the ES5 spec would simply be dead code, because all of the conditions that would trigger it have already triggered the state machine into using the ES5 spec. On Fri, Jan 6, 2012 at 12:30 AM, Mark S. Miller erig...@google.com wrote: On Fri, Jan 6, 2012 at 12:24 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: There should be no observable difference. But the issue isn't how we described the (program) semantics. It is how we decide which semantics to apply. Got it. It still gives the web only two modes, but has the huge benefit that the ES6 spec can avoid describing the semantics of non-strict code. Cool. -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 6, 2012, at 8:03 AM, Mark S. Miller wrote: No sorry, I just spotted the flaw. The observable difference is that a conforming browser is not required by the (ES5 + ES6) specs to provide any non-triggering ES6 features for program #2. In that case, we again have three mode. For example, since legacy constrains us from making nested named function declarations a triggering feature, if program #2 has a nested named function and the browser rejected it, that browser would still conform to both the ES5 and ES6 spec. Implementations that currently support extensions to ES5 (and wish to continue to support them) must classify their extensions into one of the four categories I identified and then process them according to the state machine. Because no currently implementation of function declarations within blocks (that I'm aware of) matches the ES6 lexical scoping semantics, it would expect such function declarations to be classified as ES5~ES6. Then, according to the state machine, a program like: function f(g) { //not the following will produce inconsistent results among common browsers if (!g) { function g() {return 1} } else if (typeof g !== 'function') { function g() {return 2} } return g; } will be processed using the (implementation extended) ES5 specification and both f and g would presumably be non-strict functions. If you wanted the above to be processed as ES6 code you would need to add some ES6-only features such as: let ES6; or use some other forced opt-in such as a version in the MIME type. The above is exactly analogies to how any standard ES5~ES6 features would be treated. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
AFAICT, this agrees with my analysis of what your proposal means. How does this not result in three modes? On Fri, Jan 6, 2012 at 9:45 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Jan 6, 2012, at 8:03 AM, Mark S. Miller wrote: No sorry, I just spotted the flaw. The observable difference is that a conforming browser is not required by the (ES5 + ES6) specs to provide any non-triggering ES6 features for program #2. In that case, we again have three mode. For example, since legacy constrains us from making nested named function declarations a triggering feature, if program #2 has a nested named function and the browser rejected it, that browser would still conform to both the ES5 and ES6 spec. Implementations that currently support extensions to ES5 (and wish to continue to support them) must classify their extensions into one of the four categories I identified and then process them according to the state machine. Because no currently implementation of function declarations within blocks (that I'm aware of) matches the ES6 lexical scoping semantics, it would expect such function declarations to be classified as ES5~ES6. Then, according to the state machine, a program like: function f(g) { //not the following will produce inconsistent results among common browsers if (!g) { function g() {return 1} } else if (typeof g !== 'function') { function g() {return 2} } return g; } will be processed using the (implementation extended) ES5 specification and both f and g would presumably be non-strict functions. If you wanted the above to be processed as ES6 code you would need to add some ES6-only features such as: let ES6; or use some other forced opt-in such as a version in the MIME type. The above is exactly analogies to how any standard ES5~ES6 features would be treated. Allen -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
(This grew out of a conversation Allen and I had yesterday -- great to see it developed.) One thing to make clear: ES5~EAS6: The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics. For example, accessing a formal parameter after an assignment to the corresponding element of the function's arguments object. This is something we propose to do with completion reform, and also until this year for typeof null. It's clear we can't get away with changing typeof null == null. Even with full opt-in, it's a runtime migration hazard (one of the five fingers of fate). I withdraw it -- I'm the one who proposed it in lieu of an Object.isObject predicate -- but I do not think we should add Object.isObject either. Rather, we need to rethink reflection on types in light of not only null vs. object, but value types/proxies. I'd rather not rush that. In the mean time, and for lo these 16 years (heading toward 17!), developers have coped and can continue to do so with typeof x == object x === null or simpler (!x, x == null, other context-specialized combinations). In general, the latest new syntax is its own opt-in thinking, with Allen's state machine approach, means our five fingers of fate have to be small enough that we can get away with them. At least Mark and I believe completion reform (making the completion value depend on a statically decidable expression-statement) is the only such finger we can get away with folding right now. If you want to explicitly force ES6 processing put a: let ES6; Or (no quotes) use strict; I think we want this pragma supported, not only the string-literal expression-statement directive. at the top of the source file. If you want to explicitly force ES5 processing put a: with (5); at the top of the source file That will potentially deoptimize the top level for some engines, but maybe it doesn't matter. I don't expect it to catch on ;-). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 6, 2012, at 11:23 AM, Mark S. Miller wrote: AFAICT, this agrees with my analysis of what your proposal means. How does this not result in three modes? Counting modes is not productive, is it? All major implementations have extended ES5. It's likely extensions will continue to precede standardization. Do these make ongoing new modes? Rather, we should minimize the state machine and how we talk about it. We could generalize it using Curr, Next, CurrNext, and Curr-Next labels. /be On Fri, Jan 6, 2012 at 9:45 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jan 6, 2012, at 8:03 AM, Mark S. Miller wrote: No sorry, I just spotted the flaw. The observable difference is that a conforming browser is not required by the (ES5 + ES6) specs to provide any non-triggering ES6 features for program #2. In that case, we again have three mode. For example, since legacy constrains us from making nested named function declarations a triggering feature, if program #2 has a nested named function and the browser rejected it, that browser would still conform to both the ES5 and ES6 spec. Implementations that currently support extensions to ES5 (and wish to continue to support them) must classify their extensions into one of the four categories I identified and then process them according to the state machine. Because no currently implementation of function declarations within blocks (that I'm aware of) matches the ES6 lexical scoping semantics, it would expect such function declarations to be classified as ES5~ES6. Then, according to the state machine, a program like: function f(g) { //not the following will produce inconsistent results among common browsers if (!g) { function g() {return 1} } else if (typeof g !== 'function') { function g() {return 2} } return g; } will be processed using the (implementation extended) ES5 specification and both f and g would presumably be non-strict functions. If you wanted the above to be processed as ES6 code you would need to add some ES6-only features such as: let ES6; or use some other forced opt-in such as a version in the MIME type. The above is exactly analogies to how any standard ES5~ES6 features would be treated. Allen -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 6, 2012, at 11:23 AM, Mark S. Miller wrote: AFAICT, this agrees with my analysis of what your proposal means. How does this not result in three modes? I guess I don't understand exactly what you mean by a mode or why the number of modes is particularly interesting. From an implementation perspective, I suppose you consider each state in my FSM a mode in which case we have 4 processing modes. Or If you are using mode to classify the semantics of arguments and assignment to undeclared identifiers then there are two modes: strict and non-strict If you are using mode to classify what can occur in a StatementList there are three modes: ES5, ES5-strict, ES-6. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Rather, we should minimize the state machine and how we talk about it. We could generalize it using Curr, Next, CurrNext, and Curr-Next labels. I’m awfully sorry for belaboring this point. But the labels and the quote below don’t go together. Quoting Brendan: - ES6 is a superset of ES5.strict. That's always been promised. Then I would only expect two labels: ES6 and non-strict ES6-only = (a subset of) ES6 ES5-only = only possible for non-strict constructs = non-strict ES5ES6 = (a subset of) ES6 ES5~EAS6 = not possible (“The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics.”) -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 6, 2012, at 11:52 AM, Brendan Eich wrote: (This grew out of a conversation Allen and I had yesterday -- great to see it developed.) One thing to make clear: ES5~EAS6: The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics. For example, accessing a formal parameter after an assignment to the corresponding element of the function's arguments object. This is something we propose to do with completion reform, and also until this year for typeof null. It's clear we can't get away with changing typeof null == null. Even with full opt-in, it's a runtime migration hazard (one of the five fingers of fate). I withdraw it -- I'm the one who proposed it in lieu of an Object.isObject predicate -- but I do not think we should add Object.isObject either. Rather, we need to rethink reflection on types in light of not only null vs. object, but value types/proxies. I'd rather not rush that. In the mean time, and for lo these 16 years (heading toward 17!), developers have coped and can continue to do so with typeof x == object x === null or simpler (!x, x == null, other context-specialized combinations). In general, the latest new syntax is its own opt-in thinking, with Allen's state machine approach, means our five fingers of fate have to be small enough that we can get away with them. At least Mark and I believe completion reform (making the completion value depend on a statically decidable expression-statement) is the only such finger we can get away with folding right now. If you want to explicitly force ES6 processing put a: let ES6; Or (no quotes) use strict; I think we want this pragma supported, not only the string-literal expression-statement directive. If we end up with all of ES6 being a super set of ES5 strict, then I don't see a lot value in saying: use strict; I would think that: use ES6; //or use version 6; etc would better express the user intent. BTW, I would interpret this as meaning at least ES6 and still do feature driven version detection of future versions using an expanded state machine. at the top of the source file. If you want to explicitly force ES5 processing put a: with (5); at the top of the source file That will potentially deoptimize the top level for some engines, but maybe it doesn't matter. I don't expect it to catch on ;-). Other ES5 opt-ins at the top level include: var arguments; function ES5(yes,yes){}; These probably won't cause any deoptimization. However, I agree that it would be rare for someone to actually need to do this. The intent was more to emphasize that the way you force a particular spec-level interpretation is to code something that is unique to that spec-level. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 6, 2012, at 12:09 PM, Axel Rauschmayer wrote: Rather, we should minimize the state machine and how we talk about it. We could generalize it using Curr, Next, CurrNext, and Curr-Next labels. I’m awfully sorry for belaboring this point. But the labels and the quote below don’t go together. Quoting Brendan: - ES6 is a superset of ES5.strict. That's always been promised. Then I would only expect two labels: ES6 and non-strict You're counting different beans from Mark's modes and from Allen's states. The reason the state machine matters is implementation (including the fine spec, the normative implementation). Authors can think of writing non-strict ES5 or lower, or ES5 strict -- or ES6 if they use a bit of novelty. Different beans again. I'm not sure what informs your label count expectation. In writing JS for the web over the next several years, you might have to worry quite a bit about ES5 strict vs. ES6. You can't just assume ES6 works everywhere that ES5 strict works. /be ES6-only = (a subset of) ES6 ES5-only = only possible for non-strict constructs = non-strict ES5ES6 = (a subset of) ES6 ES5~EAS6 = not possible (“The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics.”) -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 6, 2012, at 12:25 PM, Allen Wirfs-Brock wrote: On Jan 6, 2012, at 11:52 AM, Brendan Eich wrote: Or (no quotes) use strict; I think we want this pragma supported, not only the string-literal expression-statement directive. If we end up with all of ES6 being a super set of ES5 strict, then I don't see a lot value in saying: use strict; The value is that the string literal is non-breaking in pre-ES5 implementations, which has been a source of real bugs (concatenation, too-early adoption). Explicit opt in via use strict; seems better to me than anything with a version number in it. More below. I would think that: use ES6; //or use version 6; etc would better express the user intent. BTW, I would interpret this as meaning at least ES6 and still do feature driven version detection of future versions using an expanded state machine. While the ECMA editions will be numbered (unpredictably!), and RFC4329 points toward post-hoc standardization of the ;version= MIME type parameter, I do not think we should embed version numbers in pragmas. We could, certainly. That was the plan of record until recently. It matches the ;version= progression we're likely to want anyway, to hide new code from being loaded by old browsers with inevitable syntax errors whose reporitng slows the futile loads even further. But I'd rather leave ;version= to the MIME type parameter, which is just a post-hoc reflection of ECMA's edition numbering. This reduces the tendency to think of versions, modes, and the like. It's a human factors thing. Versions suck, Hixie and Anne and others were right to push back on them, even if they didn't solve the forward compatibility problem (no one has) or are in denial about HTML5 (with 5) :-P. Other ES5 opt-ins at the top level include: var arguments; function ES5(yes,yes){}; These probably won't cause any deoptimization. However, I agree that it would be rare for someone to actually need to do this. The intent was more to emphasize that the way you force a particular spec-level interpretation is to code something that is unique to that spec-level. Sure. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Then I would only expect two labels: ES6 and non-strict You're counting different beans from Mark's modes and from Allen's states. The reason the state machine matters is implementation (including the fine spec, the normative implementation). Authors can think of writing non-strict ES5 or lower, or ES5 strict -- or ES6 if they use a bit of novelty. Different beans again. Ah, got it! You want ECMA-262 version 6 to allow an à la carte approach: implementors can choose between non-strict ES5, strict ES5, ES6, etc. I'm not sure what informs your label count expectation. In writing JS for the web over the next several years, you might have to worry quite a bit about ES5 strict vs. ES6. You can't just assume ES6 works everywhere that ES5 strict works. I was thinking about how to specify only (exclusively) an ES6 environment. You pretend to live in a “perfect ES6 world” and then only have two labels. There are two ways out of this world: - Non-ES6 environments for implementors: refer to ECMA-262 version 5.1. - Non-ES6 environments for developers: simulate ES6 (via static compilation, dynamic compilation, etc.). -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
The issue is *how* the spec and implementations decide what is supported, and when to raise an error on new syntax mixed (after) old non-strict code (e.g., 'with'). Ah, OK. I thought that one would be able to lump together ES5.non-strict and all prior ES versions on one hand and ES6 and ES5.strict on the other hand. But it makes sense that even if developers (engine users) are presented with something simple, implementors have to take care of many more details. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 6, 2012, at 1:35 PM, Axel Rauschmayer wrote: The issue is *how* the spec and implementations decide what is supported, and when to raise an error on new syntax mixed (after) old non-strict code (e.g., 'with'). Ah, OK. I thought that one would be able to lump together ES5.non-strict and all prior ES versions on one hand and ES6 and ES5.strict on the other hand. Notice that two of the four states contain possible outcome terminate with Error: invalid combination of ES5 and ES6 features These are the states labeled ES5 and ES6. It should be clear that you need more than two states to judge whether a given hunk of code is ES5 non-strict (or lower) -- the default unversioned script JS we know today -- or ES5-strict or higher. To have only two states in the machine, you would need version-based opt-in. But don't worry about counting states. Count minimal or even non-minimal modes if you like ;-). But it makes sense that even if developers (engine users) are presented with something simple, implementors have to take care of many more details. A point that I flog often. The few and skilled implementors should take some complexity on behalf of the whole user base, provided that complexity in implementation and specification saves the bulk of users enough by simplifying migration and adoption. IMHO we are onto something good here. The complexity for the implementors does not too bad (I'm looking at it right now for SpiderMonkey), and the user-facing wins are huge. /be___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Axel, thanks. This is the critical point, so no apologies needed for belaboring. Allen, what I mean is exactly what Axel says here. Look at it another way. Right now we have two normative modes: ES5 strict and ES5 non-strict. State machine aside, ES6 introduces a new single mode normative spec. If the state machine may delegate to any of these three normative specs we have three modes. If the state machine may only delegate to ES5-non-strict or ES6, i.e., if the ES5-strict spec becomes dead code as of conformance with state machine + ES6 spec, then we have two modes. To get this effect, we need only classify ES5's use strict; directive as ES6-only. If any objection to doing so has been stated, I missed it. Is there a reason not to do so? It's a one line change that leaves the rest of your proposal unperturbed and solves this problem. On Fri, Jan 6, 2012 at 12:09 PM, Axel Rauschmayer a...@rauschma.de wrote: Rather, we should minimize the state machine and how we talk about it. We could generalize it using Curr, Next, CurrNext, and Curr-Next labels. I’m awfully sorry for belaboring this point. But the labels and the quote below don’t go together. Quoting Brendan: - ES6 is a superset of ES5.strict. That's always been promised. Then I would only expect two labels: ES6 and non-strict ES6-only = (a subset of) ES6 ES5-only = only possible for non-strict constructs = non-strict ES5ES6 = (a subset of) ES6 ES5~EAS6 = not possible (“The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics.”) -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Fri, Jan 6, 2012 at 12:25 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: [...] Other ES5 opt-ins at the top level include: var arguments; function ES5(yes,yes){}; Please stop calling these ES5 opt-ins. They preclude the Program from being strict, and so are forcing ES5-not-strict. Non confusing names for this are: ES5-non-strict Non-strict ES3 By continuing to call this simply ES5 while precluding the program from being an ES5-strict program, you confuse the crucial issue I'm trying to clarify. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Fri, Jan 6, 2012 at 12:29 PM, Brendan Eich bren...@mozilla.com wrote: On Jan 6, 2012, at 12:09 PM, Axel Rauschmayer wrote: Rather, we should minimize the state machine and how we talk about it. We could generalize it using Curr, Next, CurrNext, and Curr-Next labels. I’m awfully sorry for belaboring this point. But the labels and the quote below don’t go together. Quoting Brendan: - ES6 is a superset of ES5.strict. That's always been promised. Then I would only expect two labels: ES6 and non-strict You're counting different beans from Mark's modes and from Allen's states. Hi Brendan, as I read it, Axel captures exactly the two modes I have in mind. The reason the state machine matters is implementation (including the fine spec, the normative implementation). Authors can think of writing non-strict ES5 or lower, or ES5 strict -- or ES6 if they use a bit of novelty. Different beans again. I'm not sure what informs your label count expectation. In writing JS for the web over the next several years, you might have to worry quite a bit about ES5 strict vs. ES6. You can't just assume ES6 works everywhere that ES5 strict works. The issue is: What does it mean for a browser to be standards compliant once it is fully conformant with ES6? Yes, of course there will be a long phase of partial ES6 compliance as features are incrementally rolled out. Just as there was with ES5. But during this period, no one claims full conformance with ES6, so standards compliance mean only compliance with ES5. To be standards compliant once one is ES6 compliant, the state machine + ES6 keeps some portion of the ES5 spec as a live normative spec because it is reachable from the state machine. The only question is: Which portion is reachable? With Allen's plan, all of it. With the one line revision Axel and I have in mind, the ES5-strict spec stops being reachable as normative for ES6 compliant browsers. It is dead code that can be considered garbage. In the ES6 era, I hope to be able to say ES5-strict is dead. Long live ES6!. However, ES5-non-strict (or non-strict, or ES3) will continue to live for the foreseeable future. It will probably outlive most of us. /be ES6-only = (a subset of) ES6 ES5-only = only possible for non-strict constructs = non-strict ES5ES6 = (a subset of) ES6 ES5~EAS6 = not possible (“The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics.”) -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Considering all that, I can't help feeling that having a separate mode is cleaner, simpler, and easier to use. I think it also has more potential for providing a robust foundation for future evolution of the language. This last point -language evolution- is something that Haskellers have quite a bit of experience with, and I've tried to raise the issue of feature-based language versioning here earlier [1,2]. In Haskell's beginning, there was the single language standard, and every implementation had a single flag for enabling all of its additional or experimental features (beyond the standard). But implementations come and go, and even the de-facto standard of most-widely-used implementation has changed over time. Even when several implementations agreed on a feature, they might disagree on some details (eg, a proven safe but restrictive variant versus a possibly unsafe but pragmatically better version). And the language committees have been notoriously slow in adopting experimental features into the language standard. So the situation became untenable, and the solution was feature-based language versioning (based on pragmas), in addition to named standards: By default, code is interpreted according to the most recent language standard but, for stability, code can explicitly opt into a specific version of the standard. Up to here, that is similar to Javascript, only that the version can be specified in code pragmas as well. On top of this default, language *extensions* can be selected individually, via pragmas. It is then up to the implementation to recognize whether or not the selected set of language extensions is supported. As in JS, language extensions tend to have recognizable syntax, too, so implementations can also warn intelligently about attempts to use features that have not been selected (or about conflicts that arise because of features that have been selected, such as stolen syntax). Useful language extensions can be adopted by other implementations (at which point they need to be specified, not just implemented), and later moved into one of the next language standards. Agreeing on the next language standard becomes more of gather-successful-features than redesign-everything-from-scratch, with shorter language update cycles as well. A feature missing a language update deadline becomes less of an issue, as it is still available as an extension. Features that do not work out in practice are easier to remove, as they have their own pragma (not mixed into a numeric language version). In the current phase of JS evolution, with an evolving new standard and partial implementations of new features, it would be especially helpful to identify which features a piece of code depends on and which features a given implementation supports. Being able to opt in to new features individually also puts a bound on upgrade work (e.g. opt into let, but not yield, or vice-versa), and helps to ensure that coders are aware of changes (if I opt into let, I expect let to be special; if I opt into ES.next because I want yield, I might be surprised by changes to let and scope and typeof and ..). Just a thought.. Claus [1] Should ES begin to standardise pragmas? https://mail.mozilla.org/pipermail/es-discuss/2011-April/013791.html [2] feature-based and compartment-based language versioning https://mail.mozilla.org/pipermail/es-discuss/2011-July/015755.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On 4 January 2012 21:27, Brendan Eich bren...@mozilla.com wrote: On Jan 4, 2012, at 4:12 AM, Andreas Rossberg wrote: Your (3) seemed to say use module was something distinct from (and also implicit in, so a part but not the whole of what is declared by) module declaration syntax. It's not -- as proposed, it's an alternative to explicit anonymous module{...} bracketing syntax that translates the block or body enclosing the pragma to an anonymous module. Yes, I understand that. My point was that you can reformulate all that, for (almost) equivalent effect, by saying that use module is _not_ a module definition, but basically the same mode pragma as before, Just to be clear: you mean |use version 6;| here by mode pragma as before? Yes. The only difference I can see with this description is its effect on the semantics of multi-part scripts. Dave's proposal has script window.foo = hi; /script script use module; alert(foo); /script desugar to script window.foo = hi; /script script module { alert(foo); // no early error, runs and alerts hi } /script which is not the same as what we were thinking of with no global object as top scope enabled by a version pragma: script window.foo = hi; /script script use version 6; alert(foo); // early error here! /script Right. That's (part of) what I was alluding to with my above remark. ;) /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On 4 January 2012 21:30, Brendan Eich bren...@mozilla.com wrote: In any case, even if we allow more features in classic mode Don't think of modes and you'll be grooving with the new proposal better ;-). Well, I'd say syntactic context is just a euphemism. Or maybe the other way round... /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 5, 2012, at 1:56 , Brendan Eich wrote: Better to dispense with modes or ordered versions altogether, which is the key idea of the proposal. So, simplified, the story is: - ES6 is a superset of ES5.strict. - Therefore, as soon as we have ES6, ES5.strict code bases automatically become ES6 code bases. - ES{3,5}.non-strict is neither a subset nor a superset of ES6, it has to be handled differently. If these modes (strict versus non-strict) exist, then I would want a per-file marker for strict code: - use strict; - use strict; - module { Compared to languages such as Java, JavaScript additionally faces the challenge that a developer can’t control what language version is implemented by the browser. How will that be handled? Sketching a solution would provide a more complete picture of how to migrate to ES6. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 11:38 PM, Mark S. Miller wrote: In your suggestion, when an occurrence of destructuring (or any other new syntax) is seen, what unit of code is then opting in to strict? Would it be the nearest enclosing function, module, class, generator, or Program? I think I'm warming to the idea. I think having the opt-in unit be the destructuring pattern and everything recursively contained within it would be a bad idea. In this regard, destructuring is a different category of opt-in by new syntax than is module, class, and generator. This first came up in the context of formal parameters that use destructuring (or default value initializers, or rest). In that case, the idea was that this would imply that the function with those parameters is a strict function. Whether the use of destructuring (or rest/spread) in declarations or expressions within the body of the function also implies a strict function is potentially a separate issue. However, I think we need to keep things as simple and consistent as possible so on that basis perhaps they should also imply a strict function. In neither case, were we thinking of restricting the strictness to just the destructuring pattern itself. A slightly different approach to this might be to say that the use of any new syntax implies that the immediately surrounding function or program is in strict mode. In other words, the default is strict mode unless the code exclusively uses ES5 syntactic constructs. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 5, 2012, at 6:31 AM, Andreas Rossberg wrote: explicit opt-in) No -- use strict; the string literal expression-statement is meaningless pre-ES5, ES5-strict in ES5, and redundant in Harmony code. You said earlier that we best rely on the meta tag for the script toplevel, which isn't exactly a No. ;) Trying to avoid scope creep. Also not dismissing RFC4329 ;version=6 parameter setting -- that works to hide new code from old browsers (I believe back to IE8 -- perhaps not the geriatric browsers). Now what do you say? Sorry, I still think that a growing set of subtle implicit rules for activating subtle semantic changes Not changes, new semantics for new syntax. The fingers of fate may allow completion reform (Mark and I think so). The interactions are not that hard, and making a mode-wall doesn't avoid solving all of them -- you still may have runtime (heap-based) interactions between old and new modes. We did JS1.7 this way, BTW. You had to opt in to get 'let' and 'yield', but that was for the compiler. We did not hold back other features, and there were no runtime (post-compile) version checks: brendan-eichs-computer-3:src.old brendaneich$ grep VERSION_1_7 *.c jsapi.c:{JSVERSION_1_7, 1.7}, jsparse.c: || (JSVERSION_NUMBER(cx) == JSVERSION_1_7 jsparse.c: ((JSVERSION_NUMBER(cx) == JSVERSION_1_7 jsparse.c:if (JSVERSION_NUMBER(cx) == JSVERSION_1_7) { jsparse.c:if (JSVERSION_NUMBER(cx) == JSVERSION_1_7) { (jsapi.c is just a string - enumerator mapping table; jsparse.c shows the compiler checks.) on a fine-grained level is far more confusing (and error-prone!) than helpful. In all sorts of ways. Our experience was that adding new features to the default version where there was no backward incompatibility was not confusing. We've been doing this since 2006. Not to say all the particulars are right, or that we anticipated all the combinations of ES5-strict and Harmony, of course! But I think you protest too much without evidence. I'm also concerned about the 3 and a half language modes that might result. With Dave's original proposal at least, the only opt-in was on module level. Dave mentioned generators, IIRC. We were thinking of classes too (talked about it privately). That precluded a number of highly undesirable combinations, e.g. extended mode nested into a with statement. You can use strict; in a with statement's body block. But see below, I agree the opt in has to be chunky, and is in the (not perfectly clear, complete, etc.) proposal for ES6 doesn't need [version] opt-in. Allen gave a couple of good examples we also ran into when trying to implement block scoping liberally in V8 -- in the end, we concluded that it doesn't make sense to allow opting into extended mode locally. Yes, this is one place where during the ES4 period, we made 'let' at top level of program and function bodies equate to 'var', which is no good (arguments aliasing, for one). But lesson learned. The idea is to opt in at least the enclosing function, if not the enclosing Program (non-terminal, so script element content) when unproblematic new syntax is parsed. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 5, 2012, at 9:30 AM, Allen Wirfs-Brock wrote: A slightly different approach to this might be to say that the use of any new syntax implies that the immediately surrounding function or program is in strict mode. I'm favoring program currently, even if the new syntax is used in just one (of N) functions declared or expressed in the program. We could be narrow and impute Harmony opt-in only to the nearest containing function (or failing that, program). That might help incremental migration, indeed, and it seems a more locally reasonable rule. But it may be that developers would benefit more from in-for-a-penny-in-for-a-pound. Hard to say without user testing. In other words, the default is strict mode unless the code exclusively uses ES5 syntactic constructs. Right, but we need to settle on the unit or scale of the code. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 5, 2012, at 8:30 AM, Axel Rauschmayer wrote: On Jan 5, 2012, at 1:56 , Brendan Eich wrote: Better to dispense with modes or ordered versions altogether, which is the key idea of the proposal. So, simplified, the story is: - ES6 is a superset of ES5.strict. That's always been promised. - ES{3,5}.non-strict is neither a subset nor a superset of ES6, it has to be handled differently. If these modes (strict versus non-strict) exist, then I would want a per-file marker for strict code: - use strict; This doesn't mean Harmony, though. Not now, in ES5 implementations -- it means only ES5-strict. And not in dowrev impls, where it means nothing (and semantics differ at runtime). - use strict; This is a good idea but it was not proposed by Dave to mean Harmony opt-in. Rather, |use module;| was, as a way to avoid bracing and indenting a top level hunk of code in an anonymous module {...} declaration. - module { Compared to languages such as Java, JavaScript additionally faces the challenge that a developer can’t control what language version is implemented by the browser. How will that be handled? Sketching a solution would provide a more complete picture of how to migrate to ES6. APIs can be object-detected. New syntax requires autoconf-style eval/Function tests. All doable, nothing mysterious, some try/catch pain required. I rather expect a boot-loader script will use more coarse-grained means of deciding what to fetch. We had proposed a way to reflect on the maximum supported version (__ECMASCRIPT_VERSION__, IIRC) but that was unsatisfying. More to do here. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Here is a possible set of rules for implicitly assigning ES5 or ES6 semantics to a Program unit In an ES6 implementation, all constructs that can occur in a valid program fit into one of these categories: ES6-only: The construct is based upon syntax or static semantics rules that only exist in ES6. For example, a destructuring pattern ES5-only: The construct is based upon syntax that or static semantics rules that that are not in ES6. For example, use of a with statement t. ES5ES6: The construct has identical semantics in both ES5 and ES6. ES5~EAS6: The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics. For example, accessing a formal parameter after an assignment to the corresponding element of the function's arguments object. We can then use the following state machines to describes the processing of a Program based upon the occurrence for these feature categories. Initially start in State 56: State 56 if current construct is in ES5ES6, process using intersection semantics, then goto State 56 if current construct is in ES5~ES6, process using ES5 semantics then, goto State Compat5 if current construct is in ES5-only, process using ES5 semantics then goto State ES5 if current construct is in ES6-only, process using ES6 semantics then goto State ES6 State ES5 if current construct is in ES5ES6, process using intersection semantics, then goto State ES5 if current construct is in ES5~ES6, process using ES5 semantics, then goto State ES5 if current construct is in ES5-only, process using ES5 semantics then goto State ES5 if current construct is in ES6-only, terminate with Error: invalid combination of ES5 and ES6 features State ES6 if current construct is in ES5ES6, process using intersection semantics, then goto State ES6 if current construct is in ES5~ES6, process using ES6 semantics, then goto State ES6 if current construct is in ES5-only, terminate with Error: invalid combination of ES5 and ES6 features if current construct is in ES6-only, process using ES6 semantics then goto State ES6 State Compat5 (or have an analogous Compat6 state, and restart to State ES5 when necessary) if current construct is in ES5ES6, process using intersection semantics, then goto State Compat5 if current construct is in ES5~ES6, process using ES5 semantics then, goto State Compat5 if current construct is in ES5-only, process using ES5 semantics then goto State ES5 if current construct is in ES6-only, abort current compilation and restart from beginning, starting in State ES6 Basically using any ES6 features makes it an ES6 program. Using any ES5-only feature makes it an ES5 program. Combining ES5-only and ES6 features results in an invalid program. If a Program can not be explicitly identified as either ES5 or ES6, it is treated as an ES5 program. If you want to explicitly force ES6 processing put a: let ES6; at the top of the source file. If you want to explicitly force ES5 processing put a: with (5); at the top of the source file Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Hi Allen, if ES5 had only one mode, I'd understand this. But I thought we were trying to arrive at two modes, ES6 non-strict, to be backwards compat with ES5-non-strict, and ES6 strict, to be backwards compat with ES5-strict. I am perfectly happy to call ES6 non-strict ES3, since ES5-non-strict really exists to be an ES3 compatibility mode, and was constrained to be backwards compatible from ES3. Likewise, I am happy to call the new ES6 strict simply ES6. Concretely, I am confused how your transition diagram is supposed to handle use strict;. Reading your state machine literally, since use strict; is accepted by ES5, if it is accepted by ES6 (as I think we all agree it would be), then it would leave us in state ES5ES6. Were you two base categories ES6 non-strict (or ES3) and ES6 strict (or ES6), then a use strict; would put us in your ES6 strict (or ES6) category, which is what I would have expected. On Thu, Jan 5, 2012 at 6:37 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: Here is a possible set of rules for implicitly assigning ES5 or ES6 semantics to a Program unit In an ES6 implementation, all constructs that can occur in a valid program fit into one of these categories: ES6-only: The construct is based upon syntax or static semantics rules that only exist in ES6. For example, a destructuring pattern ES5-only: The construct is based upon syntax that or static semantics rules that that are not in ES6. For example, use of a with statement t. ES5ES6: The construct has identical semantics in both ES5 and ES6. ES5~EAS6: The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics. For example, accessing a formal parameter after an assignment to the corresponding element of the function's arguments object. We can then use the following state machines to describes the processing of a Program based upon the occurrence for these feature categories. Initially start in State 56: State 56 if current construct is in ES5ES6, process using intersection semantics, then goto State 56 if current construct is in ES5~ES6, process using ES5 semantics then, goto State Compat5 if current construct is in ES5-only, process using ES5 semantics then goto State ES5 if current construct is in ES6-only, process using ES6 semantics then goto State ES6 State ES5 if current construct is in ES5ES6, process using intersection semantics, then goto State ES5 if current construct is in ES5~ES6, process using ES5 semantics, then goto State ES5 if current construct is in ES5-only, process using ES5 semantics then goto State ES5 if current construct is in ES6-only, terminate with Error: invalid combination of ES5 and ES6 features State ES6 if current construct is in ES5ES6, process using intersection semantics, then goto State ES6 if current construct is in ES5~ES6, process using ES6 semantics, then goto State ES6 if current construct is in ES5-only, terminate with Error: invalid combination of ES5 and ES6 features if current construct is in ES6-only, process using ES6 semantics then goto State ES6 State Compat5 (or have an analogous Compat6 state, and restart to State ES5 when necessary) if current construct is in ES5ES6, process using intersection semantics, then goto State Compat5 if current construct is in ES5~ES6, process using ES5 semantics then, goto State Compat5 if current construct is in ES5-only, process using ES5 semantics then goto State ES5 if current construct is in ES6-only, abort current compilation and restart from beginning, starting in State ES6 Basically using any ES6 features makes it an ES6 program. Using any ES5-only feature makes it an ES5 program. Combining ES5-only and ES6 features results in an invalid program. If a Program can not be explicitly identified as either ES5 or ES6, it is treated as an ES5 program. If you want to explicitly force ES6 processing put a: let ES6; at the top of the source file. If you want to explicitly force ES5 processing put a: with (5); at the top of the source file Allen -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 5, 2012, at 8:24 PM, Mark S. Miller wrote: Hi Allen, if ES5 had only one mode, I'd understand this. But I thought we were trying to arrive at two modes, ES6 non-strict, to be backwards compat with ES5-non-strict, and ES6 strict, to be backwards compat with ES5-strict. I am perfectly happy to call ES6 non-strict ES3, since ES5-non-strict really exists to be an ES3 compatibility mode, and was constrained to be backwards compatible from ES3. Likewise, I am happy to call the new ES6 strict simply ES6. When I talked about ES5 in my original post I meant full ES5 including both strict and non-strict modes. Since ES6 is supposed to be a strict super set of ES5 strict mode, anything in the ES5-only category must be an exclusively non-strict mode feature (for example, with). I suppose you could call that category ES3 but I decided to label it ES5-only to keep things focused on differences between ES5 and ES5. Concretely, I am confused how your transition diagram is supposed to handle use strict;. Reading your state machine literally, since use strict; is accepted by ES5, if it is accepted by ES6 (as I think we all agree it would be), then it would leave us in state ES5ES6. Were you two base categories ES6 non-strict (or ES3) and ES6 strict (or ES6), then a use strict; would put us in your ES6 strict (or ES6) category, which is what I would have expected. Yes, use strict is in the ES5ES6 category. A ES5 completely strict mode program would start in State 56 and stay in that state for its entire compilation. Only encountering use of a new ES6 feature would case a transition to State ES6. Looking at it another way, Both State ES5 and State 56 include support for both strict and non-strict ES5 code. State ES6 only allows strict code. Allen On Thu, Jan 5, 2012 at 6:37 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Here is a possible set of rules for implicitly assigning ES5 or ES6 semantics to a Program unit In an ES6 implementation, all constructs that can occur in a valid program fit into one of these categories: ES6-only: The construct is based upon syntax or static semantics rules that only exist in ES6. For example, a destructuring pattern ES5-only: The construct is based upon syntax that or static semantics rules that that are not in ES6. For example, use of a with statement t. ES5ES6: The construct has identical semantics in both ES5 and ES6. ES5~EAS6: The construct has identical syntax and static semantics in both ES5 and ES6, but differing semantics. For example, accessing a formal parameter after an assignment to the corresponding element of the function's arguments object. We can then use the following state machines to describes the processing of a Program based upon the occurrence for these feature categories. Initially start in State 56: State 56 if current construct is in ES5ES6, process using intersection semantics, then goto State 56 if current construct is in ES5~ES6, process using ES5 semantics then, goto State Compat5 if current construct is in ES5-only, process using ES5 semantics then goto State ES5 if current construct is in ES6-only, process using ES6 semantics then goto State ES6 State ES5 if current construct is in ES5ES6, process using intersection semantics, then goto State ES5 if current construct is in ES5~ES6, process using ES5 semantics, then goto State ES5 if current construct is in ES5-only, process using ES5 semantics then goto State ES5 if current construct is in ES6-only, terminate with Error: invalid combination of ES5 and ES6 features State ES6 if current construct is in ES5ES6, process using intersection semantics, then goto State ES6 if current construct is in ES5~ES6, process using ES6 semantics, then goto State ES6 if current construct is in ES5-only, terminate with Error: invalid combination of ES5 and ES6 features if current construct is in ES6-only, process using ES6 semantics then goto State ES6 State Compat5 (or have an analogous Compat6 state, and restart to State ES5 when necessary) if current construct is in ES5ES6, process using intersection semantics, then goto State Compat5 if current construct is in ES5~ES6, process using ES5 semantics then, goto State Compat5 if current construct is in ES5-only, process using ES5 semantics then goto State ES5 if current construct is in ES6-only, abort current compilation and restart from beginning, starting in State ES6 Basically using any ES6 features makes it an ES6 program. Using any ES5-only feature makes it an ES5 program. Combining ES5-only and ES6 features results in an invalid program. If a Program can not be explicitly identified as either ES5 or ES6, it is treated as an ES5 program. If you want to explicitly force ES6 processing put a: let ES6; at the top of the source
Re: ES6 doesn't need opt-in
On Thu, Jan 5, 2012 at 10:13 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Jan 5, 2012, at 8:24 PM, Mark S. Miller wrote: Hi Allen, if ES5 had only one mode, I'd understand this. But I thought we were trying to arrive at two modes, ES6 non-strict, to be backwards compat with ES5-non-strict, and ES6 strict, to be backwards compat with ES5-strict. I am perfectly happy to call ES6 non-strict ES3, since ES5-non-strict really exists to be an ES3 compatibility mode, and was constrained to be backwards compatible from ES3. Likewise, I am happy to call the new ES6 strict simply ES6. When I talked about ES5 in my original post I meant full ES5 including both strict and non-strict modes. Since ES6 is supposed to be a strict super set of ES5 strict mode, anything in the ES5-only category must be an exclusively non-strict mode feature (for example, with). I suppose you could call that category ES3 but I decided to label it ES5-only to keep things focused on differences between ES5 and ES5. Concretely, I am confused how your transition diagram is supposed to handle use strict;. Reading your state machine literally, since use strict; is accepted by ES5, if it is accepted by ES6 (as I think we all agree it would be), then it would leave us in state ES5ES6. Were you two base categories ES6 non-strict (or ES3) and ES6 strict (or ES6), then a use strict; would put us in your ES6 strict (or ES6) category, which is what I would have expected. Yes, use strict is in the ES5ES6 category. A ES5 completely strict mode program would start in State 56 and stay in that state for its entire compilation. Only encountering use of a new ES6 feature would case a transition to State ES6. Looking at it another way, Both State ES5 and State 56 include support for both strict and non-strict ES5 code. State ES6 only allows strict code. Them either I still don't understand, this proposal is broken, or we're talking about three modes. Take the following three programs: 1) program using only ES3 features and no use strict; 2) program using only ES5 strict features and saying use strict; 3) program using ES6-only features. Do these three programs operate in three different modes? If not, do #1 and #2 operate in the same mode, or do #2 and #3 operate in the same mode? Putting #1 and #2 into the same mode breaks ES5 code. So to avoid three modes, my conclusion is that #2 and #3 must be in the same mode. But that does not seem to be what you're saying. What am I misunderstanding? -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: ES6 doesn't need opt-in
think in practice this will be very confusing. Take this: var x = typeof null; module { var y = typeof null; x == y // false! } This is a refactoring hazard, much harder to find by code inspection than use strict, and just plain confusing. Alternatives like having a let inside a function body automatically opt the body into the sort of behaviour above feel ever more magic, and very hard to reason about thoroughly. Moreover, these breaking changes all come at conceptual cost for JavaScript developers. While we may think we are making things better by fixing typeof, we are actually just making the section on typeof in Doug's slide deck longer - he needs to describe both behaviours, and when to expect each. We already see this with strict mode - the answer to what does this JavaScript code do? now often has to be answered by well, if it's in strict mode... otherwise..., instead of a direct simple (even if not desired) answer. It is even worse in these implicit explicit opt-in models. In those cases, the answer becomes well, if it's inside a 'module', or in strict mode, or inside a function which contains anywhere inside it a 'let', or Breaking changes, especially if opted into through implicit explicit opt-in add to the total complexity of the language. Moreover, if there aren't breaking changes, there is no need for opt-in at all. # Conclusion # Let's avoid versioning by making (almost) no breaking changes. Luke From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Mark S. Miller Sent: Tuesday, January 03, 2012 1:24 PM To: Allen Wirfs-Brock Cc: Brendan Eich; es-discuss Steen Subject: Re: ES6 doesn't need opt-in Just Two Modes This is a long thread and I've been completely busy with other things so have not had time to do more than skim. So please understand if the post below misses some context. The following is a summary of some principles that Dave and just agreed to in a verbal conversation, but he hasn't had the chance to look at the following text before I send it, so it may not quite speak for our agreement -- I've substantially elaborated it since the text that Dave and I looked at together. Dave introduced this thread with the slogan just one JavaScript, so I'll introduce the following with the (much less catchy) slogan just two modes. * ES5's strict vs non-strict distinction remains the only mode distinction. ES6 thus has only the same two modes. * ES6 non-strict mode must be practically upwards compatible from ES5 non-strict mode. * ES6 strict mode must be practically upwards compatible from ES5 strict mode. * In ES6, one can opt-in to strict mode in at least the following two ways: use strict; // exactly as in ES5 or module ident? { in statement context. In other words, exactly as ES5 may begin strict mode at a function boundary to apply to everything recursively contained lexically within the function, in ES6 in addition, strict mode may also begin at a module boundary and apply to everything recursively within the module. Code recursively contained within a module is always strict; there's no way to write non-strict code within a module. But a module, like a function, may be embedded within a non-strict context. * Code that contains such a module construct may run on an ES5 system or may cause an early SyntaxError, depending on whether this ES5 implementation has been extended to recognize the module construct. An ES6 system must of course recognize the module construct. Thus, modules, as well as most other features of ES6, may be deployed incrementally, just as many features of ES5 were deployed incrementally in the transition from ES3 to ES5. * We give up typeof reform. * We do completion reform only if we judge it to be practically upward compatible, with a dispensation to ES5 implementations to implement it without penalty of being non-conformant. (Dave and I both expect it will in fact be practically upwards compatible.) * As with completion reform, if there are other cleanups we can make to ES5 that is practically upwards compatible, e.g., whose only incompatibility is with test262, we can consider these for ES6 and absolve ES5 systems that adopt these cleanups. * We obtain a clean top level scope only by using loaders, which is increasingly how I've been thinking of SES anyway. * The identifiers that are reserved in ES5 only in strict mode are: implements, interface, let, package, private, protected, public, static, yield ES6 features that use these keywords are available only in strict mode. Because ES5 reserved them, this is fully upwards compatible with ES5. For other ES6 features that do not depend on these keywords, whether or not they must also be available in ES6 non-strict code we need to take on a case by case basis. * In ES6, nested named function declaration must be accepted and have the agreed ES6
Re: ES6 doesn't need opt-in
On Jan 5, 2012, at 10:20 PM, Mark S. Miller wrote: On Thu, Jan 5, 2012 at 10:13 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jan 5, 2012, at 8:24 PM, Mark S. Miller wrote: Hi Allen, if ES5 had only one mode, I'd understand this. But I thought we were trying to arrive at two modes, ES6 non-strict, to be backwards compat with ES5-non-strict, and ES6 strict, to be backwards compat with ES5-strict. I am perfectly happy to call ES6 non-strict ES3, since ES5-non-strict really exists to be an ES3 compatibility mode, and was constrained to be backwards compatible from ES3. Likewise, I am happy to call the new ES6 strict simply ES6. When I talked about ES5 in my original post I meant full ES5 including both strict and non-strict modes. Since ES6 is supposed to be a strict super set of ES5 strict mode, anything in the ES5-only category must be an exclusively non-strict mode feature (for example, with). I suppose you could call that category ES3 but I decided to label it ES5-only to keep things focused on differences between ES5 and ES5. Concretely, I am confused how your transition diagram is supposed to handle use strict;. Reading your state machine literally, since use strict; is accepted by ES5, if it is accepted by ES6 (as I think we all agree it would be), then it would leave us in state ES5ES6. Were you two base categories ES6 non-strict (or ES3) and ES6 strict (or ES6), then a use strict; would put us in your ES6 strict (or ES6) category, which is what I would have expected. Yes, use strict is in the ES5ES6 category. A ES5 completely strict mode program would start in State 56 and stay in that state for its entire compilation. Only encountering use of a new ES6 feature would case a transition to State ES6. Looking at it another way, Both State ES5 and State 56 include support for both strict and non-strict ES5 code. State ES6 only allows strict code. Them either I still don't understand, this proposal is broken, or we're talking about three modes. Take the following three programs: My point wasn't to try to define modes. I think that is where we are miscommunicating. There are exactly two language specifications we have to deal with. The ES5 spec. and the ES6 spec. A given ES source program may conform to one, or the other, or both (or neither). The exercise I was working through is how do you determine whether to process a given source file according to the ES5 spec. or the ES6 spec., without explicitly preassociating the source file with one or another. That is what my state machine does. It starts assuming the source file is in the intersection, where it it doesn't matter which specification you apply. As soon as it see a feature that is unique to one or the other of the specification it clamps to that specification for the entire program. The extra states are to deal with the situation where the appropriate specification to use for a feature can not be directly inferable from the syntax of the feature. 1) program using only ES3 features and no use strict; 2) program using only ES5 strict features and saying use strict; 3) program using ES6-only features. Do these three programs operate in three different modes? If not, do #1 and #2 operate in the same mode, or do #2 and #3 operate in the same mode? It isn't about modes. #1 and #2 are ES5 programs and are processed as such (applying/not the appropriately strictness as per ES5) . #3 is an ES6 program is processed as such (including using the strict semantics that are universal to ES6). Putting #1 and #2 into the same mode breaks ES5 code. So to avoid three modes, my conclusion is that #2 and #3 must be in the same mode. But that does not seem to be what you're saying. What am I misunderstanding? -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On 3 January 2012 21:18, Brendan Eich bren...@mozilla.com wrote: On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote: On 3 January 2012 07:19, Brendan Eich bren...@mozilla.com wrote: On Jan 2, 2012, at 6:07 AM, Andreas Rossberg wrote: In other words, I think the main points of your proposal can essentially be rephrased to: 1) Rename use version 6 to use module. 2) Allow module declarations in classic mode. [...] 3) Make every module body start with an implicit use module. That's not right: use module; in a pragma turns the enclosing block or body into a module {...}, in a macro-like way. Then if the module {...} is illegal in the given context (i.e., not nested immediately in another module's body), you get the same error you'd get trying to write, e.g., if (cond) { module { /* stuff */ } } Hm, I don't follow. How is this related to point (3)? The body of a module always is a context where module declarations are allowed. Your (3) seemed to say use module was something distinct from (and also implicit in, so a part but not the whole of what is declared by) module declaration syntax. It's not -- as proposed, it's an alternative to explicit anonymous module{...} bracketing syntax that translates the block or body enclosing the pragma to an anonymous module. Yes, I understand that. My point was that you can reformulate all that, for (almost) equivalent effect, by saying that use module is _not_ a module definition, but basically the same mode pragma as before, except that it now is implicit with every module body. The only difference I can see with this description is its effect on the semantics of multi-part scripts. 4) Keep the semantics of the top-level scope unaltered, even in presence of a top-level use module. No, see above: that turns the verbatim top level into the ... part of module {...}. OK, I see, but then we effectively have opted out of the global object, at least as a carrier for the verbatim top-level declarations of the (current) script, haven't we? No. Dave wrote Short answer: giving up and You can still do it with a custom loader. That is, even in a module (declared at top level either implicitly via the |use module;| pragma or explicitly via module id? {...}), the proposal still keeps the global object on the scope chain. But the proposal does a free variable analysis based on importing the properties of the global at the start of the module's body, and any free variables are early errors. Those quotes from Dave's post are exactly the bits I couldn't make sense of properly. Because even before his proposal, I remember what you describe being an option we were still considering. Thanks for clarifying. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On 3 January 2012 21:01, Brendan Eich bren...@mozilla.com wrote: On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote: On 3 January 2012 07:21, Brendan Eich bren...@mozilla.com wrote: The top level is hard. The only way to be sure is to use pure lexical scope (in Dave's proposal, use module {...}). Ah, but wrapping into modules is incompatible with having multiple script parts. I don't know what you mean. Incompatible in the sense that you cannot transform multiple scripts into multiple anonymous modules? Yes. For multi-part scripts we need a way to switch the _proper_ top-level into extended mode. Or should I not be able to write (the relevant bits of) a multi-part script in extended mode at all? The proposal may have been unclear on this point: the top level would allow as much new syntax and semantics as can be tolerated backwards-compatibly. The hard cases are let, lexical scope in the free-variables-are-errors sense Dave described (extant globals at start of module body are imported), and any runtime shifts we want (completion reform, typeof null). I suspect there may be other subtle issues, e.g., what about `const' and local functions? [I see, Allen mentioned that already.] In any case, even if we allow more features in classic mode, that still doesn't give you the ability to use _all_ Harmony features for multi-part scripts. I think we need a proper story for this. [I just saw that later down the thread Mark proposed reusing strict mode as an opt-in for full Harmony. I reply to that separately.] /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Mark's reformulation of the proposal is somewhat different from how I initially interpreted it -- in particular, wrt tying (merging) extended mode to strict mode. But it seems like the logical conclusion. The main problem with the proposal (in both Dave's original form and with Mark's refinement) is that it essentially gives up the idea that Harmony builds on strict mode. It is not at all obvious to me what implications that will have. A few observations: - 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. - Providing Harmony features in classic mode decreases the incentive for users to upgrade to strict mode. Is that a good thing? - After Dave's posting I foresaw people wanting implicit opt-in with other constructs, e.g. classes or uses of `import' -- and voila, we're already there. But even with that, you still have to rely on explicit opt-in (via use strict?) for enabling some features elsewhere. As a result, we expect programmers to remember two separate, fairly random (for anybody not intimate with the history) lists of features that (1) require opt-in, and (2) imply opt-in. Style guides will probably suggest to put use strict on top of every Harmony program to escape the mess. - All this together (new features in old mode, implicit opt-in, explicit opt-in) makes it more subtle to see what piece of ES6 code is strict and which isn't. This is a disadvantage when reading code and a potential pitfall for refactoring (probably much worse than strict mode today). - Finally, not having a new mode restricts our ability to clean up the language beyond what's already in strict mode (see typeof). Considering all that, I can't help feeling that having a separate mode is cleaner, simpler, and easier to use. I think it also has more potential for providing a robust foundation for future evolution of the language. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Wed, Jan 4, 2012 at 4:23 AM, Andreas Rossberg rossb...@google.comwrote: Mark's reformulation of the proposal is somewhat different from how I initially interpreted it -- in particular, wrt tying (merging) extended mode to strict mode. But it seems like the logical conclusion. The main problem with the proposal (in both Dave's original form and with Mark's refinement) is that it essentially gives up the idea that Harmony builds on strict mode. It is not at all obvious to me what implications that will have. A few observations: - 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. - Providing Harmony features in classic mode decreases the incentive for users to upgrade to strict mode. Is that a good thing? Here's an interesting compromise I consider perfectly reasonable. We don't *mandate* any ES6 code features be available in ES6 non-strict mode. But we don't prohibit them either. For any ES6 features that have no dependence on mode, like destructuring, we mandate that they be present in strict code, and we make them normative optional (the new Appendix B category) in non-strict code. Implementors are free to implement them or not in non-strict mode, but if they implement them, it must mean the same thing as the mandated meaning in strict code. - After Dave's posting I foresaw people wanting implicit opt-in with other constructs, e.g. classes or uses of `import' -- and voila, we're already there. But even with that, you still have to rely on explicit opt-in (via use strict?) for enabling some features elsewhere. As a result, we expect programmers to remember two separate, fairly random (for anybody not intimate with the history) lists of features that (1) require opt-in, and (2) imply opt-in. Style guides will probably suggest to put use strict on top of every Harmony program to escape the mess. Every sane style guide will do so. And every linting tool should by default warn on the presence of any non-strict code. And every IDE should offer to make the code strict if it isn't already. - All this together (new features in old mode, implicit opt-in, explicit opt-in) makes it more subtle to see what piece of ES6 code is strict and which isn't. This is a disadvantage when reading code and a potential pitfall for refactoring (probably much worse than strict mode today). The only sensible refactoring of non-strict code is to make it strict. All other refactorings should start with that one. - Finally, not having a new mode restricts our ability to clean up the language beyond what's already in strict mode (see typeof). Considering all that, I can't help feeling that having a separate mode is cleaner, simpler, and easier to use. I think it also has more potential for providing a robust foundation for future evolution of the language. /Andreas -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 13:23 , Andreas Rossberg wrote: Considering all that, I can't help feeling that having a separate mode is cleaner, simpler, and easier to use. I think it also has more potential for providing a robust foundation for future evolution of the language. Taking a step back from modes: What will ES6 support for legacy browsers look like? - Wouldn’t you know per piece of code/file whether it is ES5 or ES6? And make that decision (all in or all out) per browser? I still don’t completely understand why/when it would be a mixed affair. I would write minimal setup code inline and then load a module as quickly as possible. - One possibility: several versions of each file: ES3, ES5, ES6. Are there ideas for how we could either statically keep the versions and let each browser load the appropriate one or how we could dynamically compile (either server-side or client-side, possibly including caching)? This multi-version scheme could even be applied to (the JS code embedded in) HTML files. Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Wed, Jan 4, 2012 at 8:39 AM, Mark S. Miller erig...@google.com wrote: On Wed, Jan 4, 2012 at 4:23 AM, Andreas Rossberg rossb...@google.comwrote: [...] Here's an interesting compromise I consider perfectly reasonable. We don't *mandate* any ES6 code features be available in ES6 non-strict mode. But we don't prohibit them either. For any ES6 features that have no dependence on mode, like destructuring, we mandate that they be present in strict code, and we make them normative optional (the new Appendix B category) in non-strict code. Implementors are free to implement them or not in non-strict mode, but if they implement them, it must mean the same thing as the mandated meaning in strict code. Except for nested named function definitions, which already have bizarre de facto behaviors in non-strict code that no one can fix. Perhaps there are more such conflicts in legacy non-standard features? If so, we probably need to exempt them as well. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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
Re: ES6 doesn't need opt-in
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
Re: ES6 doesn't need opt-in
On 4 January 2012 17:39, Mark S. Miller erig...@google.com wrote: Here's an interesting compromise I consider perfectly reasonable. We don't *mandate* any ES6 code features be available in ES6 non-strict mode. But we don't prohibit them either. For any ES6 features that have no dependence on mode, like destructuring, we mandate that they be present in strict code, and we make them normative optional (the new Appendix B category) in non-strict code. Implementors are free to implement them or not in non-strict mode, but if they implement them, it must mean the same thing as the mandated meaning in strict code. Hm, I don't understand what would be gained by that. You don't get rid of the spec complexity. And you risk reducing cross-browser compatibility, which is hardly a good thing. It doesn't really help the browser vendors either. I think for anything but legacy, we should avoid normative optional. - After Dave's posting I foresaw people wanting implicit opt-in with other constructs, e.g. classes or uses of `import' -- and voila, we're already there. But even with that, you still have to rely on explicit opt-in (via use strict?) for enabling some features elsewhere. As a result, we expect programmers to remember two separate, fairly random (for anybody not intimate with the history) lists of features that (1) require opt-in, and (2) imply opt-in. Style guides will probably suggest to put use strict on top of every Harmony program to escape the mess. Every sane style guide will do so. And every linting tool should by default warn on the presence of any non-strict code. And every IDE should offer to make the code strict if it isn't already. Well, I had hoped that with ES6 we have more elegant ways of opting into Harmony than something like the use strict kludge. I also thought that that was part of Dave's motivation. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 8:39 AM, Mark S. Miller wrote: ... Here's an interesting compromise I consider perfectly reasonable. We don't *mandate* any ES6 code features be available in ES6 non-strict mode. But we don't prohibit them either. For any ES6 features that have no dependence on mode, like destructuring, we mandate that they be present in strict code, and we make them normative optional (the new Appendix B category) in non-strict code. Implementors are free to implement them or not in non-strict mode, but if they implement them, it must mean the same thing as the mandated meaning in strict code. I don't think we every contemplated forbidding implementations from extending non-strict modes with versions of new features ES6 features. However, your assumptions that destructuring has has no mode dependencies is wrong and a good example of why it is not so trivial to include it in non-strict code. Here are some of the dependencies I've already run into WRT formal parameter destructuring: using 'arguments' (or 'eval') in a formal parameter destructuring pattern or as a rest parameter - currently forbidden by strict mode effect of multiple use of the same name - currently forbidden in strict mode but currently allowed in non-strict mode interaction between new formal parameter forms and non-strict mode arguments object how is declaration instantiation order for non-strict functions impacted by parameter default value expressions can the temporal dead-zone rules related to parameter default value expression evaluation in strict mode also apply to non-strict functions These tend to be subtle issues and the right answer is not always obvious. If different implementors decided to add the new formal parameter affordances to non-strict mode, without any guidance, they would likely come up with differing solutions to some of these issues and hence create imcompatabilities. BTW, The simplest way to work around these issues, that I've found, would be to say that any function that uses any new formal parameter syntax is implicitly a strict mode function. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 3, 2012, at 11:29 PM, Mark S. Miller wrote: On Tue, Jan 3, 2012 at 10:18 PM, Brendan Eich bren...@mozilla.com wrote: On Jan 3, 2012, at 9:52 PM, Mark S. Miller wrote: A good example. Since the class proposal uses private, public, static, by these principles, it would only be recognized in strict mode. If it appears in non-strict code, it would be a SyntaxError. That's a choice. I'm asking why it's the best one. Just because class syntax might involve new reserved identifiers doesn't require strict mode. The introductory keyword is class and the new keywords are all in the braced body. The idea is that the always-reserved 'class' keyword is opt-in enough -- no need for a use strict; string litearl (ignored by old browsers anyway!). opt-in enough, interesting. I'm not sure if this is what you meant, but it suggests a very attractive option I hadn't considered: treat class, like module, as yet another way to opt-in to strict mode. All code recursively inside a class would be strict. Yes, that's what I meant. Harmony ES5-strict ! ES5 ( means supserset, ! means neither super- nor subset). Any new Harmony syntax that presents no backward incompatibility *and* has a body opts the body into the new edition, a superset of ES5-strict. For class, you're right. I really like the idea of having it be another way to opt-in to strict mode. What other constructs might join class and module as new strict-mode opt-ins? As Dave mentioned, generators: function* Fibonacci() { let [a, b] = [0, 1]; for (;;) { yield a; [a, b] = [b, a+b]; } } Want to use let scoping outside a module? Again, just say use strict;. The string literal directive is meaningless in old browsers, and the other new syntax than let is guaranteed to fail with a syntax error in old engines, so what's the benefit of requiring the extra use strinct; again? Huh? In ES5, the following code is legal: var let = 88; The following code is not: function foo() { use strict; var let = 88; } Consider instead these examples: var let = 88; function foo() { use strict; let bar = 99; } My point was pre-ES5 implementations don't respect use strict, so the first line works while the second line fails with an early error due to unrecognized 'let'. As you note, ES5 implementations support the first and fail on the second with a different early error. Now, if ES6 implementations extend use strict to enable let, then suddenly both work. Therefore if authors face ES5 and ES6 implementations in the field, saying use strict is not enough to reliably use 'let'. True, ES5 implementations will fail with an early error -- just as they would on class or module declarations. But they'd fail on most 'let' declarations anyway, so why should use strict be required? This is the question: if 'let' can be used reliably only in ES6 implementations and it fails fast in pre-ES6 implementations, why insist on, or educate users to add, use strict -- especially when that is not meaningful to pre-ES5 browsers, and the only difference between pre-ES5 and ES5 browsers is what kind of early error (perhaps just the message detail) is thrown? I don't want to twist the grammar to turn let into a context sensitive reserved word so that somehow var let = 88; and use of let-scoping can co-exist in the same mode. This seems like too high a price to pay simply to avoid any of the strict mode opt ins. Agreed, that is a bridge too far and we've said so before. Gavin B. was asking again about it and I replied citing destructuring (let [x] = y; after another terminated statement) as one ambiguous case. Any code under active maintenance should opt-in to strict somehow anyway. You think so but developers are not doing it. Some have tried and been burned by concatenation without testing in ES5 implementations. Others don't like the performance effects (real but not necessarily biting them). use strict is not catching on, sorry to relate, and this is why I do not think we should yoke 'let' to it. If we don't need to predicate 'let' on use strict to avoid backward incompatibility (other than in details of early error thrown), then we should not. The destructuring ambiguity remains, but perhaps there is a solution. Still thinking about this... Non-strict mode is only for legacy that needs to keep working without any further human attention -- most of the web. This code already doesn't use let scoping, so what's the issue? There are two issues: 1. Needless use strict when new syntax (mostly or completely) is necessary and sufficient opt-in by itself. We agree this is the case for class and module -- also (I hope) for function*. 2. Lack of use strict adoption means coupling to it too much raises risk of ES6 non-adoption. Again, the criteria I care about is practically backwards compatible. If it works to simply make let an unconditional
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 4:12 AM, Andreas Rossberg wrote: Your (3) seemed to say use module was something distinct from (and also implicit in, so a part but not the whole of what is declared by) module declaration syntax. It's not -- as proposed, it's an alternative to explicit anonymous module{...} bracketing syntax that translates the block or body enclosing the pragma to an anonymous module. Yes, I understand that. My point was that you can reformulate all that, for (almost) equivalent effect, by saying that use module is _not_ a module definition, but basically the same mode pragma as before, Just to be clear: you mean |use version 6;| here by mode pragma as before? except that it now is implicit with every module body. Assuming you do, then there is a difference -- see below. The only difference I can see with this description is its effect on the semantics of multi-part scripts. Dave's proposal has script window.foo = hi; /script script use module; alert(foo); /script desugar to script window.foo = hi; /script script module { alert(foo); // no early error, runs and alerts hi } /script which is not the same as what we were thinking of with no global object as top scope enabled by a version pragma: script window.foo = hi; /script script use version 6; alert(foo); // early error here! /script /be___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 4:12 AM, Andreas Rossberg wrote: On 3 January 2012 21:01, Brendan Eich bren...@mozilla.com wrote: On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote: On 3 January 2012 07:21, Brendan Eich bren...@mozilla.com wrote: The top level is hard. The only way to be sure is to use pure lexical scope (in Dave's proposal, use module {...}). Ah, but wrapping into modules is incompatible with having multiple script parts. I don't know what you mean. Incompatible in the sense that you cannot transform multiple scripts into multiple anonymous modules? Yes. That's a feature, in the proposal. You want the old behavior? Use script without |use module;| or |module {...}|. There's your backward compatibility :-P. For multi-part scripts we need a way to switch the _proper_ top-level into extended mode. Or should I not be able to write (the relevant bits of) a multi-part script in extended mode at all? The proposal may have been unclear on this point: the top level would allow as much new syntax and semantics as can be tolerated backwards-compatibly. The hard cases are let, lexical scope in the free-variables-are-errors sense Dave described (extant globals at start of module body are imported), and any runtime shifts we want (completion reform, typeof null). I suspect there may be other subtle issues, e.g., what about `const' Not supported by IE, ever -- no intersection semantics (unlike block-contained functions). and local functions? [I see, Allen mentioned that already.] Right. Oh, the pain! Still I don't want to fall back to versioning if these are one of a few hard cases. In any case, even if we allow more features in classic mode Don't think of modes and you'll be grooving with the new proposal better ;-). that still doesn't give you the ability to use _all_ Harmony features for multi-part scripts. I think we need a proper story for this. Agreed, but this desire is best satisfied by markup, e.g. that meta tag idea we've alluded to throughout this thread. Saying you want this doesn't undermine the new-syntax-as-opt-in proposal. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 12:16 PM, Brendan Eich wrote: ... Any new Harmony syntax that presents no backward incompatibility *and* has a body opts the body into the new edition, a superset of ES5-strict. Including expression level bodies such a block lambda's or Dave's do { } expressions, if they are adopted?? Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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, this is a trade-off. It probably helps developers migrate, provided they choose sane combinations. For example, Allen (private correspondence) wondered if a function using the arguments object is evolved to have destructuring parameters: function f({a,b}, c) { arguments[0] = {a:3,b:4}; return [a, b] } f({a:1,b:2}, 3); I say anyone wanting deep aliasing (f returns [3, 4]) should suffer disappointment. I doubt developers want such deep aliasing, and no implementor does. We don't get to clean the slate with JS, so making mode walls between language versions may help implementors (by which I include spec writers) but that's about it. Authors are not helped, and mode walls probably hurt (we hear). I think we're better off working through the combinations, removing legacy (mis-)features as we go. For example, function f above, because it uses destructuring parameters, opts into the new language which *is* based on ES5-strict -- so there's no arguments aliasing at all! The general idea would be that any new syntax that doesn't create backward compatibility problems on its face opts the containing (or following, in the case of new syntax in function head) body into strict mode. By body I probably mean function or program body and not just braced block. - Providing Harmony features in classic mode decreases the incentive for users to upgrade to strict mode. Is that a good thing? See above -- Harmony ES5-strict in the proposal and so users do upgrade to strict mode. They just don't have to sprinkle use strict; string literals expression statements around. That's a win. - After Dave's posting I foresaw people wanting implicit opt-in with other constructs, e.g. classes or uses of `import' -- and voila, we're already there. But even with that, you still have to rely on explicit opt-in (via use strict?) for enabling some features elsewhere. Which features? As a result, we expect programmers to remember two separate, fairly random (for anybody not intimate with the history) lists of features that (1) require opt-in, and (2) imply opt-in. Style guides will probably suggest to put use strict on top of every Harmony program to escape the mess. If the new syntax implies strict mode in the containing body, then this goes away. - All this together (new features in old mode, Nope. ;-) implicit opt-in, Yup. explicit opt-in) No -- use strict; the string literal expression-statement is meaningless pre-ES5, ES5-strict in ES5, and redundant in Harmony code. (BTW I still think we want a real |use strict;| pragma, to choke old implementations.) Now what do you say? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 12:50 PM, Allen Wirfs-Brock wrote: On Jan 4, 2012, at 12:16 PM, Brendan Eich wrote: ... Any new Harmony syntax that presents no backward incompatibility *and* has a body opts the body into the new edition, a superset of ES5-strict. Including expression level bodies such a block lambda's or Dave's do { } expressions, if they are adopted?? Oh absolutely block lambda bodies are in Harmony ES5-strict mode, you betcha! Ditto generator bodies. Class bodies, we covered. Module bodies -- in the o.p. I like do {...} expressions, BTW -- tweeted about them today. They would be a wafer-thin (John Cleese pseudo-French accent) addition to ES.next. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 8:39 AM, Mark S. Miller wrote: Here's an interesting compromise I consider perfectly reasonable. We don't *mandate* any ES6 code features be available in ES6 non-strict mode. But we don't prohibit them either. For any ES6 features that have no dependence on mode, like destructuring, we mandate that they be present in strict code, and we make them normative optional (the new Appendix B category) in non-strict code. Too complicated. Why not just have one JavaScript (modulo ES5 strict mode, whether its selection was explicit or implicit)? Implementors are free to implement them or not in non-strict mode, but if they implement them, it must mean the same thing as the mandated meaning in strict code. We need interop on the web. If we let implementations vary as to whether, e.g., rest parameters require use strict, then I predict the implementations that *do not* require use strict will win, and we'll have to spec normative non-optional anyway. I'm very sure developers will not want use strict; as a requirement. That battle has been lost already with most developers (the war goes on, but let's not refight unnecessarily). Anyway, predictions aside, I do not agree we should require use strict if the syntax speaks for itself. My argument is not against strict mode (the basis of Harmony!) but rather against requiring use strict; directives to use new features that can be expressed without incompatible meaning shifts (only with guaranteed early errors in pre-Harmony implementations). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 9:35 AM, Allen Wirfs-Brock wrote: On Jan 4, 2012, at 8:39 AM, Mark S. Miller wrote: ... Here's an interesting compromise I consider perfectly reasonable. We don't *mandate* any ES6 code features be available in ES6 non-strict mode. But we don't prohibit them either. For any ES6 features that have no dependence on mode, like destructuring, we mandate that they be present in strict code, and we make them normative optional (the new Appendix B category) in non-strict code. Implementors are free to implement them or not in non-strict mode, but if they implement them, it must mean the same thing as the mandated meaning in strict code. I don't think we every contemplated forbidding implementations from extending non-strict modes with versions of new features ES6 features. However, your assumptions that destructuring has has no mode dependencies is wrong and a good example of why it is not so trivial to include it in non-strict code. Here are some of the dependencies I've already run into WRT formal parameter destructuring: using 'arguments' (or 'eval') in a formal parameter destructuring pattern or as a rest parameter - currently forbidden by strict mode Destructuring opts into strict mode or rather its successor, ES.next. Harmony rolls on this way. effect of multiple use of the same name - currently forbidden in strict mode but currently allowed in non-strict mode Not allowed by JS1.[78]* in SpiderMonkey or Rhino -- we prefigured ES5-strict on this, for sanity. When you use destructuring parameters in Firefox, you cannot have duplicate parameter names *anywhere* in the parameter list. js function f({a,b},a){} typein:1: SyntaxError: duplicate argument is mixed with destructuring pattern: typein:1: function f({a,b},a){} typein:1: ^ js function f(b,{a,b}){} typein:2: SyntaxError: duplicate argument is mixed with destructuring pattern: typein:2: function f(b,{a,b}){} typein:2: .^ js function f({a,a},c){} typein:3: SyntaxError: duplicate argument is mixed with destructuring pattern: typein:3: function f({a,a},c){} typein:3: ...^ interaction between new formal parameter forms and non-strict mode arguments object See above. Function is implicitly strict. how is declaration instantiation order for non-strict functions impacted by parameter default value expressions See above, again. can the temporal dead-zone rules related to parameter default value expression evaluation in strict mode also apply to non-strict functions Ditto. These tend to be subtle issues and the right answer is not always obvious. If different implementors decided to add the new formal parameter affordances to non-strict mode, without any guidance, they would likely come up with differing solutions to some of these issues and hence create imcompatabilities. We need a normative spec, of course! But we do not need to support new features in pre-strict-mode, indeed pre-ES6, combinations. New syntax is the opt-in! BTW, The simplest way to work around these issues, that I've found, would be to say that any function that uses any new formal parameter syntax is implicitly a strict mode function. Sorry, I should have read this far. I guess the proposal was unclear enough that people went down a bad path (at least you, probably Mark and Andreas). Sorry about that -- the intention (at least my view of it when reviewing Dave's draft proposal) was that new syntax opts in, and at a function granularity at least! /be___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Wed, Jan 4, 2012 at 9:24 AM, Andreas Rossberg rossb...@google.comwrote: On 4 January 2012 17:39, Mark S. Miller erig...@google.com wrote: [...] Style guides will probably suggest to put use strict on top of every Harmony program to escape the mess. Every sane style guide will do so. And every linting tool should by default warn on the presence of any non-strict code. And every IDE should offer to make the code strict if it isn't already. Well, I had hoped that with ES6 we have more elegant ways of opting into Harmony than something like the use strict kludge. I also thought that that was part of Dave's motivation. For style guides targeting ES6 only code, yes. They should simply advocate opting into strict mode in some way, and the preferred choice is unlikely to be use strict;. For ES5, or for any code that must work on pre-ES6 browsers, use strict; is of course the only way to opt in to strict mode. I was thinking in terms of styles guides that anyone might write in the next three years. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Wed, Jan 4, 2012 at 9:35 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Jan 4, 2012, at 8:39 AM, Mark S. Miller wrote: [...] BTW, The simplest way to work around these issues, that I've found, would be to say that any function that uses any new formal parameter syntax is implicitly a strict mode function. Good arguments -- both you and Andreas. I withdraw the suggestion that these be normative optional -- it indeed accomplished nothing useful. Instead, we simply do not forbid them in non-strict mode, which as you observe has always been the status quo. I accept that destructuring is problematic for reasons I've overlooked. No doubt others are too. For each one, the first solutions we should reach for are 1) leave them out of strict mode, or 2) (as you suggest) make its presence an implicit opt-in to strict mode (which amusingly does effectively forbid it from appearing in non-strict code). For destructuring, I think it is less suggestive notationally that it represents a boundary at which rules change, so I would rather simply omit it from non-strict mode. But either way would avoid these specification complexities, which I agree we should avoid. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Wed, Jan 4, 2012 at 12:16 PM, Brendan Eich bren...@mozilla.com wrote: And for classes. class is unconditionally reserved, so there's no issue. And for generators? I like the idea of generators as yet another strict opt-in, even though recognizing function* is technically an example of the previously-illegal token sequence approach. It does feel like an example of it readability wise. The eye rapidly learns to see function* as a keyword. The extra grammar complexity to recognize it is minimal. If yes for generators, then why not for comprehensions, rest/spread, destructuring (separate from the 'let' issue), for/of, and other new forms? I hadn't thought about comprehensions. As for rest/spread and destructuring, sure, if there's no complexity. However, Allen just pointed out that there would be complexity for allowing non-strict destructuring, so let's not. If we run across problems with the others, then probably not for those either. We've got enough important things to do that we shouldn't waste any time enhancing non-strict mode when doing so is non-trivial. /be -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Hi Brendan, I agree with most of your message, so only commenting on the remainder. On Wed, Jan 4, 2012 at 12:52 PM, Brendan Eich bren...@mozilla.com wrote: [...] - After Dave's posting I foresaw people wanting implicit opt-in with other constructs, e.g. classes or uses of `import' -- and voila, we're already there. But even with that, you still have to rely on explicit opt-in (via use strict?) for enabling some features elsewhere. Which features? Lexical scoping (top level aside of course). Encapsulated functions. Sane arguments. Poisoning of .caller, .callee, .arguments. Ability to write code that continues to run on old browsers and to run sanely on old ES5 browsers. Throw errors on failed assignment rather than silently continuing as if everything is fine. Throw exception on a failed delete. Throw on assigning to an undefined variable rather than having misspelling silently create a new global. Preventing an eval from corrupting its caller's scope. Need I go on? Compared to ES5 strict, ES5 non-strict is insane. Regarding adoption of strict, another audience we should keep in mind is people newly learning JavaScript. Would you rather teach them to say use strict; or teach them to program in a language without sane scope rules or encapsulated functions, and with silent errors? No -- use strict; the string literal expression-statement is meaningless pre-ES5, ES5-strict in ES5, and redundant in Harmony code. I don't see how it can be redundant in harmony code. Say I write a script, intending it to be harmony, but which doesn't begin with class, module, function*, or whatever else we decide is a new opt-in. But I want the code above the first, say module, to still obey harmony rules rather than non-strict rules. I would still need to say something else at the top of the script to ensure this. (BTW I still think we want a real |use strict;| pragma, to choke old implementations.) Yes. Crock suggested this in the old ES5 days and I think it is still a good idea: use strict; // still runs on old browsers, but non-strictly use strict; // causes an early error on old browsers. Had we adopting it into ES5, it would have this meaning clearly. It may still be a good idea, but consider the new complexity. Now the second form also causes an early error on old ES5 browsers, where the script might otherwise have been able to run strictly. Now what do you say? -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Wed, Jan 4, 2012 at 1:00 PM, Brendan Eich bren...@mozilla.com wrote: Anyway, predictions aside, I do not agree we should require use strict if the syntax speaks for itself. Is anyone saying that we should require this? I'm not. This sub-thread started with Dave's module as opt-in suggestion and you and I agreed earlier that class would also opt-in, so I'm not sure what you're arguing against. My argument is not against strict mode (the basis of Harmony!) but rather against requiring use strict; directives to use new features that can be expressed without incompatible meaning shifts (only with guaranteed early errors in pre-Harmony implementations). We're already agreeing that there should be multiple ways to opt-in to strict mode, with function* joining this happy set. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
I think I would prefer a simpler per-file approach. In light of having to do something like this again for ECMAScript.next.next how about the following? First line: - use strict; // before ES5: ignore; ES5: ES5.strict - use es6; // ES6: ES6 - module ident? { is a synonym for use es6; With JS language versions being such a prominent issue on the web, I wouldn’t mind seeing at first glance what kind of code I am looking at. My idea might be completely off, but whatever the final solution, it should be dead-simple to explain. On Jan 5, 2012, at 0:56 , Mark S. Miller wrote: (BTW I still think we want a real |use strict;| pragma, to choke old implementations.) Yes. Crock suggested this in the old ES5 days and I think it is still a good idea: use strict; // still runs on old browsers, but non-strictly use strict; // causes an early error on old browsers. Had we adopting it into ES5, it would have this meaning clearly. It may still be a good idea, but consider the new complexity. Now the second form also causes an early error on old ES5 browsers, where the script might otherwise have been able to run strictly. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 4, 2012, at 4:12 PM, Mark S. Miller erig...@google.com wrote: The problem I see is that the occurrence of some of these new features, like a light use of destructuring, may not be notationally obvious to readers. Maybe not, but for such users, strict mode may not be obviously a problem either. This may well be the shortest path to migration and adoption, esp. compared to version= lock-in. /be -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
How does |use es6| help for es7? It doesn't, especially if es7 has runtime-incompatible changes (i.e., is not a superset). Better to dispense with modes or ordered versions altogether, which is the key idea of the proposal. /be Sent from my iPad On Jan 4, 2012, at 4:45 PM, Axel Rauschmayer a...@rauschma.de wrote: I think I would prefer a simpler per-file approach. In light of having to do something like this again for ECMAScript.next.next how about the following? First line: - use strict; // before ES5: ignore; ES5: ES5.strict - use es6; // ES6: ES6 - module ident? { is a synonym for use es6; With JS language versions being such a prominent issue on the web, I wouldn’t mind seeing at first glance what kind of code I am looking at. My idea might be completely off, but whatever the final solution, it should be dead-simple to explain. On Jan 5, 2012, at 0:56 , Mark S. Miller wrote: (BTW I still think we want a real |use strict;| pragma, to choke old implementations.) Yes. Crock suggested this in the old ES5 days and I think it is still a good idea: use strict; // still runs on old browsers, but non-strictly use strict; // causes an early error on old browsers. Had we adopting it into ES5, it would have this meaning clearly. It may still be a good idea, but consider the new complexity. Now the second form also causes an early error on old ES5 browsers, where the script might otherwise have been able to run strictly. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
In your suggestion, when an occurrence of destructuring (or any other new syntax) is seen, what unit of code is then opting in to strict? Would it be the nearest enclosing function, module, class, generator, or Program? I think I'm warming to the idea. I think having the opt-in unit be the destructuring pattern and everything recursively contained within it would be a bad idea. In this regard, destructuring is a different category of opt-in by new syntax than is module, class, and generator. On Wed, Jan 4, 2012 at 4:53 PM, Brendan Eich bren...@mozilla.com wrote: On Jan 4, 2012, at 4:12 PM, Mark S. Miller erig...@google.com wrote: The problem I see is that the occurrence of some of these new features, like a light use of destructuring, may not be notationally obvious to readers. Maybe not, but for such users, strict mode may not be obviously a problem either. This may well be the shortest path to migration and adoption, esp. compared to version= lock-in. /be -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 2, 2012, at 11:45 PM, Axel Rauschmayer wrote: Prefix might work, too. ¿x? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On 3 January 2012 07:21, Brendan Eich bren...@mozilla.com wrote: It's not obvious if the static scope is built up from sript element to successive script element, either. Must I read all the scripts? The conditionally generated ones too? The top level is hard. The only way to be sure is to use pure lexical scope (in Dave's proposal, use module {...}). Ah, but wrapping into modules is incompatible with having multiple script parts. For multi-part scripts we need a way to switch the _proper_ top-level into extended mode. Or should I not be able to write (the relevant bits of) a multi-part script in extended mode at all? /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On 3 January 2012 07:19, Brendan Eich bren...@mozilla.com wrote: [Dave has been traveling, hope it's ok for me to jump in. /be] On Jan 2, 2012, at 6:07 AM, Andreas Rossberg wrote: In other words, I think the main points of your proposal can essentially be rephrased to: 1) Rename use version 6 to use module. 2) Allow module declarations in classic mode. [Replying to (1) and (2) here:] Not just module declarations -- all new syntax that is not backwards-incompatible: destructuring, rest/spread, for/of ,generators, comprehensions, generator expresions, quasiliterals, more. Yes, but that is a totally independent choice. We could do that regardless of Dave's proposal. And I agree, there probably is no good reason not to. Maybe we can even get let in? 3) Make every module body start with an implicit use module. That's not right: use module; in a pragma turns the enclosing block or body into a module {...}, in a macro-like way. Then if the module {...} is illegal in the given context (i.e., not nested immediately in another module's body), you get the same error you'd get trying to write, e.g., if (cond) { module { /* stuff */ } } Hm, I don't follow. How is this related to point (3)? The body of a module always is a context where module declarations are allowed. Isn't it rather a reply to my item (1) above? If so, my assumption always has been that use version 6 would only be allowed on the top-level, and not fine-grained in individual functions like use strict, since that would run havoc with lexical scoping. 4) Keep the semantics of the top-level scope unaltered, even in presence of a top-level use module. No, see above: that turns the verbatim top level into the ... part of module {...}. OK, I see, but then we effectively have opted out of the global object, at least as a carrier for the verbatim top-level declarations of the (current) script, haven't we? So I'm not sure how that even differs substantially from what we have been discussing so far regarding the global object. We could still decide to (or not to) remove the global object from the scope chain entirely in that case. I'm fine with (1) to (3), but (4) seems to be a separate design choice. With what I wrote above in mind, what do you think now? Since I'm no longer clear what change (relative to our, admittedly vague, recent discussion) Dave is actually proposing wrt the top-level, I don't know. Maybe there is no (4) at all, which I'd be fine with, of course. :) /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote: On 3 January 2012 07:21, Brendan Eich bren...@mozilla.com wrote: It's not obvious if the static scope is built up from sript element to successive script element, either. Must I read all the scripts? The conditionally generated ones too? The top level is hard. The only way to be sure is to use pure lexical scope (in Dave's proposal, use module {...}). Ah, but wrapping into modules is incompatible with having multiple script parts. I don't know what you mean. Incompatible in the sense that you cannot transform multiple scripts into multiple anonymous modules? For multi-part scripts we need a way to switch the _proper_ top-level into extended mode. Or should I not be able to write (the relevant bits of) a multi-part script in extended mode at all? The proposal may have been unclear on this point: the top level would allow as much new syntax and semantics as can be tolerated backwards-compatibly. The hard cases are let, lexical scope in the free-variables-are-errors sense Dave described (extant globals at start of module body are imported), and any runtime shifts we want (completion reform, typeof null). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 3, 2012, at 12:01 PM, Brendan Eich wrote: On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote: ... For multi-part scripts we need a way to switch the _proper_ top-level into extended mode. Or should I not be able to write (the relevant bits of) a multi-part script in extended mode at all? The proposal may have been unclear on this point: the top level would allow as much new syntax and semantics as can be tolerated backwards-compatibly. The hard cases are let, lexical scope in the free-variables-are-errors sense Dave described (extant globals at start of module body are imported), and any runtime shifts we want (completion reform, typeof null). I suspect there will also be issue related to legacy function declarations within blocks. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote: On 3 January 2012 07:19, Brendan Eich bren...@mozilla.com wrote: [Dave has been traveling, hope it's ok for me to jump in. /be] On Jan 2, 2012, at 6:07 AM, Andreas Rossberg wrote: In other words, I think the main points of your proposal can essentially be rephrased to: 1) Rename use version 6 to use module. 2) Allow module declarations in classic mode. [Replying to (1) and (2) here:] Not just module declarations -- all new syntax that is not backwards-incompatible: destructuring, rest/spread, for/of ,generators, comprehensions, generator expresions, quasiliterals, more. Yes, but that is a totally independent choice. There are several independent choices bundled into this new ES6 doesn't need opt-in proposal, but the unifying theme is this: new features that pose no backward incompatibility hardship and are contained or expressed by new syntax need only that new syntax as opt-in. We could do that regardless of Dave's proposal. And I agree, there probably is no good reason not to. Maybe we can even get let in? Maybe. We tried in 2006-2007 and ran into at least this: https://bugzilla.mozilla.org/show_bug.cgi?id=351515 where 'yield' was used as a parameter name. I dimly recall 'let' in the wild but may be misremembering. Perhaps out of paranoia we made both 'let' and 'yield' require version opt-in. The site that used 'yield' has since been updated to avoid using 'yield'. So we could try again to reserve 'let' unconditionally. Heaven knows I've been yapping about 'let' as the new 'var' long enough to warn most developers away from it! I discussed this on IRC briefly with Oliver, who seemed game. The only issue I see is that nightly builds (WebKit, Chrome, Firefox) don't get enough use to do other than find true positives. It would be good to find such 'let' usage in the wild, of course, but finding nothing won't give us a green light, just lack of a red light. 3) Make every module body start with an implicit use module. That's not right: use module; in a pragma turns the enclosing block or body into a module {...}, in a macro-like way. Then if the module {...} is illegal in the given context (i.e., not nested immediately in another module's body), you get the same error you'd get trying to write, e.g., if (cond) { module { /* stuff */ } } Hm, I don't follow. How is this related to point (3)? The body of a module always is a context where module declarations are allowed. Your (3) seemed to say use module was something distinct from (and also implicit in, so a part but not the whole of what is declared by) module declaration syntax. It's not -- as proposed, it's an alternative to explicit anonymous module{...} bracketing syntax that translates the block or body enclosing the pragma to an anonymous module. Isn't it rather a reply to my item (1) above? No, I wasn't talking about ES6 opt-in, only the meaning of the proposed use module; pragma. 4) Keep the semantics of the top-level scope unaltered, even in presence of a top-level use module. No, see above: that turns the verbatim top level into the ... part of module {...}. OK, I see, but then we effectively have opted out of the global object, at least as a carrier for the verbatim top-level declarations of the (current) script, haven't we? No. Dave wrote Short answer: giving up and You can still do it with a custom loader. That is, even in a module (declared at top level either implicitly via the |use module;| pragma or explicitly via module id? {...}), the proposal still keeps the global object on the scope chain. But the proposal does a free variable analysis based on importing the properties of the global at the start of the module's body, and any free variables are early errors. I'm fine with (1) to (3), but (4) seems to be a separate design choice. With what I wrote above in mind, what do you think now? Since I'm no longer clear what change (relative to our, admittedly vague, recent discussion) Dave is actually proposing wrt the top-level, I don't know. Maybe there is no (4) at all, which I'd be fine with, of course. :) No (4) as you wrote it. Semantics do change to throw early errors for free variables (typo'ed globals, e.g.). Semantics of the global object on the scope chain otherwise *do not* change with the default module loader. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 3, 2012, at 12:16 PM, Allen Wirfs-Brock wrote: On Jan 3, 2012, at 12:01 PM, Brendan Eich wrote: On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote: ... For multi-part scripts we need a way to switch the _proper_ top-level into extended mode. Or should I not be able to write (the relevant bits of) a multi-part script in extended mode at all? The proposal may have been unclear on this point: the top level would allow as much new syntax and semantics as can be tolerated backwards-compatibly. The hard cases are let, lexical scope in the free-variables-are-errors sense Dave described (extant globals at start of module body are imported), and any runtime shifts we want (completion reform, typeof null). I suspect there will also be issue related to legacy function declarations within blocks. Possibly, given the intersection semantics between IE and its followers and Firefox are such that you can use a function declared in a block after the block ends, if control flow reached the declaration. Legacy const is less of an issue since IE did not bite that apple. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 3, 2012, at 12:18 PM, Brendan Eich wrote: Maybe. We tried in 2006-2007 and ran into at least this: https://bugzilla.mozilla.org/show_bug.cgi?id=351515 where 'yield' was used as a parameter name. I dimly recall 'let' in the wild but may be misremembering. Perhaps out of paranoia we made both 'let' and 'yield' require version opt-in. The site that used 'yield' has since been updated to avoid using 'yield'. So we could try again to reserve 'let' unconditionally. Heaven knows I've been yapping about 'let' as the new 'var' long enough to warn most developers away from it! I discussed this on IRC briefly with Oliver, who seemed game. The only issue I see is that nightly builds (WebKit, Chrome, Firefox) don't get enough use to do other than find true positives. It would be good to find such 'let' usage in the wild, of course, but finding nothing won't give us a green light, just lack of a red light. Why unconditionally reserve let? - would it not make more sense to handle this in a contextual fashion if we can do so? – if so, we could introduce 'let' without any backwards compatibility risk, and retain the option to promote it to a keyword at a later date. G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
Just Two Modes This is a long thread and I've been completely busy with other things so have not had time to do more than skim. So please understand if the post below misses some context. The following is a summary of some principles that Dave and just agreed to in a verbal conversation, but he hasn't had the chance to look at the following text before I send it, so it may not quite speak for our agreement -- I've substantially elaborated it since the text that Dave and I looked at together. Dave introduced this thread with the slogan just one JavaScript, so I'll introduce the following with the (much less catchy) slogan just two modes. * ES5's strict vs non-strict distinction remains the only mode distinction. ES6 thus has only the same two modes. * ES6 non-strict mode must be practically upwards compatible from ES5 non-strict mode. * ES6 strict mode must be practically upwards compatible from ES5 strict mode. * In ES6, one can opt-in to strict mode in at least the following two ways: use strict; // exactly as in ES5 or module ident? { in statement context. In other words, exactly as ES5 may begin strict mode at a function boundary to apply to everything recursively contained lexically within the function, in ES6 in addition, strict mode may also begin at a module boundary and apply to everything recursively within the module. Code recursively contained within a module is always strict; there's no way to write non-strict code within a module. But a module, like a function, may be embedded within a non-strict context. * Code that contains such a module construct may run on an ES5 system or may cause an early SyntaxError, depending on whether this ES5 implementation has been extended to recognize the module construct. An ES6 system must of course recognize the module construct. Thus, modules, as well as most other features of ES6, may be deployed incrementally, just as many features of ES5 were deployed incrementally in the transition from ES3 to ES5. * We give up typeof reform. * We do completion reform only if we judge it to be practically upward compatible, with a dispensation to ES5 implementations to implement it without penalty of being non-conformant. (Dave and I both expect it will in fact be practically upwards compatible.) * As with completion reform, if there are other cleanups we can make to ES5 that is practically upwards compatible, e.g., whose only incompatibility is with test262, we can consider these for ES6 and absolve ES5 systems that adopt these cleanups. * We obtain a clean top level scope only by using loaders, which is increasingly how I've been thinking of SES anyway. * The identifiers that are reserved in ES5 only in strict mode are: implements, interface, let, package, private, protected, public, static, yield ES6 features that use these keywords are available only in strict mode. Because ES5 reserved them, this is fully upwards compatible with ES5. For other ES6 features that do not depend on these keywords, whether or not they must also be available in ES6 non-strict code we need to take on a case by case basis. * In ES6, nested named function declaration must be accepted and have the agreed ES6 semantics in strict code. As advised at http://wiki.ecmascript.org/doku.php?id=conventions:no_non_standard_strict_decls, all major browsers currently reject nested named function declaration in strict code, so accepting them with the agreed semantics in ES6-strict is fully upwards compatible.ES6 remains as silent as ES5 about whether nested named function declarations can appear in non-strict code or what their semantics is there. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss