excluding features from sloppy mode (was: the 1JS experiment has failed)
On Wed, Dec 26, 2012 at 2:58 PM, David Herman <dherman at mozilla.com> wrote:
On Dec 26, 2012, at 2:30 PM, Mark S. Miller <erights at google.com> wrote:
Sorry, I'd completely forgotten about those earlier options. I am arguing only the latter. Specifically "Any ES6 features that don't fit into non-strict mode without contortion, including "let" and nested "function", should be available only in strict mode."
Then I'm with Rick: your subject line was pretty inflammatory and not actually what you were arguing. This isn't a debate about 1JS. It's a narrower debate about whether some features should be available only in strict mode.
Just to clarify why I used that admittedly inflammatory title: When I had previously argued this point, specifically regarding "let", someone (I thought it was you) cited "1JS" as a reason to try bringing such ES6 features to non-strict (sloppy) mode. If 1JS implies that we should do so, then I reject the 1JS doctrine. If I misunderstood, then I withdraw putting this in terms of 1JS.
I think you did coin "1JS". What do you mean by it? Does it bear on the present issue or not?
[...]
So I guess I'd like to sit back a bit and hear others' opinions about this. But let's be clear that we're only talking about excluding some new features from sloppy mode, not about the ES6 opt-in.
Agreed.
I must admit, I'm a bit confused. My understanding of 1JS was that it meant no new modes or pragmas. That seems to have little bearing on whether a feature is restricted to strict mode or not, because that ship has already sailed and the cost is sunk.
Aside from 1JS is, I think, a different discussion about what belongs in strict mode, and what the cost is of putting a feature in strict mode vs. making it available in normal mode. Generally, the cost of making something available in normal mode is greater compatibility hurdles (as we see with function decls in block scope), while the cost of putting things in strict mode is in increasing the gap in semantics between code that is otherwise identical besides the leading "use strict" pragma.
Perhaps the second part is part of the 1JS discussion, but I think the discussion already seen today indicates there is two separate issues, one which is settled and agreed upon and one which is ongoing.
On Wed, Dec 26, 2012 at 3:53 PM, Brandon Benvie <brandon at brandonbenvie.com> wrote:
I must admit, I'm a bit confused. My understanding of 1JS was that it meant no new modes or pragmas. That seems to have little bearing on whether a feature is restricted to strict mode or not, because that ship has already sailed and the cost is sunk.
Aside from 1JS is, I think, a different discussion about what belongs in strict mode, and what the cost is of putting a feature in strict mode vs. making it available in normal mode. Generally, the cost of making something available in normal mode is greater compatibility hurdles (as we see with function decls in block scope), while the cost of putting things in strict mode is in increasing the gap in semantics between code that is otherwise identical besides the leading "use strict" pragma.
Perhaps the second part is part of the 1JS discussion, but I think the discussion already seen today indicates there is two separate issues, one which is settled and agreed upon and one which is ongoing.
Agreed. I had not meant to imply that I was reopening the earlier issue. Perhaps I had misunderstood the meaning of 1JS. But I don't much care what we call it. I just hope we can stop sacrificing other values for the sake of sloppy mode.
On Dec 26, 2012, at 15:35 , Mark S. Miller wrote:
On Wed, Dec 26, 2012 at 2:58 PM, David Herman <dherman at mozilla.com> wrote:
On Dec 26, 2012, at 2:30 PM, Mark S. Miller <erights at google.com> wrote:
Sorry, I'd completely forgotten about those earlier options. I am arguing only the latter. Specifically "Any ES6 features that don't fit into non-strict mode without contortion, including "let" and nested "function", should be available only in strict mode."
Then I'm with Rick: your subject line was pretty inflammatory and not actually what you were arguing. This isn't a debate about 1JS. It's a narrower debate about whether some features should be available only in strict mode.
Just to clarify why I used that admittedly inflammatory title: When I had previously argued this point, specifically regarding "let", someone (I thought it was you) cited "1JS" as a reason to try bringing such ES6 features to non-strict (sloppy) mode. If 1JS implies that we should do so, then I reject the 1JS doctrine. If I misunderstood, then I withdraw putting this in terms of 1JS.
I think you did coin "1JS". What do you mean by it? Does it bear on the present issue or not?
Dave's original email: esdiscuss/2011-December/019112
For TC39 members, there's a nice presentation in the archive: Ecma/TC39/2012/005.
The basic idea was that, instead of versioning through MIME types or pragmas, programs would opt into ES6 semantics by using modules. There was nothing about making all ES6 features available in all contexts.
Norbert
On Dec 26, 2012, at 3:35 PM, Mark S. Miller <erights at google.com> wrote:
I think you did coin "1JS". What do you mean by it? Does it bear on the present issue or not?
I coined the "just one JavaScript" here:
https://mail.mozilla.org/pipermail/es-discuss/2011-December/019112.html
And it got shortened to 1JS not long after (maybe in the same thread?). The key point was no (new) opt-in for ES6. If you read the message (see the "Modules as the opt-in for new semantics" section), you'll see that I actually proposed that anything that can't be made to work in legacy code can be left out of sloppy mode.
On Wed, Dec 26, 2012 at 4:59 PM, David Herman <dherman at mozilla.com> wrote:
On Dec 26, 2012, at 3:35 PM, Mark S. Miller <erights at google.com> wrote:
I think you did coin "1JS". What do you mean by it? Does it bear on the present issue or not?
I coined the "just one JavaScript" here:
https://mail.mozilla.org/pipermail/es-discuss/2011-December/019112.htmlAnd it got shortened to 1JS not long after (maybe in the same thread?). The key point was no (new) opt-in for ES6. If you read the message (see the "Modules as the opt-in for new semantics" section), you'll see that I actually proposed that anything that can't be made to work in legacy code can be left out of sloppy mode.
Excellent. Thanks for the clarification. Sorry again for the confusion.
On Dec 26, 2012, at 2:30 PM, Mark S. Miller <erights at google.com> wrote:
Then I'm with Rick: your subject line was pretty inflammatory and not actually what you were arguing. This isn't a debate about 1JS. It's a narrower debate about whether some features should be available only in strict mode. That's not something I feel as strongly about, but here's how I see it:
Strict mode, while providing some really helpful cleanups of JS, has created introduced serious and unavoidable complexity to programmers. The split has some pretty seriously pervasive differences, in particular the different
thisbinding for function calls.I believe the least miserable option for programmers to deal with this complexity is just to write code defensively assuming it could be used in strict contexts (e.g., by being concatenated with strict code), and to write all code as strict code. While this is a stick rather than a carrot, at least it's incentive for a good thing: i.e., using strict mode.
On the other hand, "default is non-strict" is still a huuuuge incentive in the other direction. It's perfectly plausible that for the foreseeable future, many programmers will continue not to use strict mode. If they don't know about strict mode, or don't want to use it for whatever reason, failing to support features like
letwill lead them to use older, worse features in place of better, new ones.Andreas has argued before that we should treat that as a feature rather than a bug. He argues that (a) the new features will be carrots to lead people to strict mode; and (b) the incompatibilities between strict and non-strict code are far simpler in total than all the micro-inconsistencies required to shoe-horn the new features into sloppy mode. But my concerns are that for (a) we don't actually know the carrots will be visible or tasty enough for programmers (I took my crystal ball to the pawn shop years ago), and for (b) the big-but-obvious inconsistencies will be universally, unavoidably tripped over. I'm just worried it's choosing "slap the developer in the face" instead of doing the work to iron out an imperfect but less obnoxious back-porting story.
So I guess I'd like to sit back a bit and hear others' opinions about this. But let's be clear that we're only talking about excluding some new features from sloppy mode, not about the ES6 opt-in.