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
?? operator (was: ES6 doesn't need opt-in)
?? would work better than ? in JavaScript, because it wouldn’t clash with the conditional operator in JavaScript Wouldn't it be possible to use a single '?' for all of them (the conditional, default and existential operators) and disambiguate between them according to the way they're used? It seems to me like their syntax is different enough to allow it - the default operator would have no `: ElseExpression` following it and the existential operator is not followed by anything. I don’t think it would be worth it. You’d save one character and it would still be confusing to humans. Also, should they be allowed on all expressions or just identifiers? It would be quite useful on arbitrary expression, like `func() ?? default` or `if ( (res = func())? ) /* do more stuff with `res` */`. Absolutely. P.S. Are CoffeeScript's `func? arg` and `obj?.prop` too extreme? The former is part of Crockford’s proposal [1]. The latter is very useful indeed. [1] http://wiki.ecmascript.org/doku.php?id=strawman:default_operator -- 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 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
