I had what I hope is an original thought on solving this. Bear with me.

In Brendan's world, how will people end up "accidentally" in sloppy mode? With classes and modules and maybe generators and more in strict mode, I see the biggest remaining contingent being <script>-loaded one-offs or "bootstrapping" application code. [1] (If anyone has a better way of describing this set, please jump in.)

What I realized is that today that is exactly the sort of code you wrap in an IIFE, i.e. (function () { }());. Of course those of us who are on the strict-train end up writing this as

(function () {
  "use strict";

  // actual code here
}());

i.e. this is our new boilerplate for <script> code [2].

Well, what if we resurrected the `do` expression idea [3], but with a strict twist? Then we could evangelize the use of

do {
  // actual code here
}

as the new <script> boilerplate. It's pretty easy to sell, even as a replacement for non-strict IIFEs. And it gets more people on the strict train. Between this and modules, people should end up in sloppy mode fairly rarely ([1] aside :-/).

Thoughts?


[1]: Possibly Node.js modules, assuming at best a backward-compatibility layer and at worst the failure of ES6 modules in the Node.js world. This proposal sadly has no solutions for that.
[2]: Microsoft has very awesomely made this the default for new JS files in Visual Studio 2012 :O
[3]: http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions

________________________________________
From: es-discuss-bounces at mozilla.org [es-discuss-bounces at mozilla.org] on behalf of Brendan Eich [brendan at mozilla.com]
Sent: Monday, December 31, 2012 16:38
To: Brandon Benvie
Cc: Mark S. Miller; es-discuss at mozilla.org
Subject: Re: excluding features from sloppy mode

Brandon Benvie wrote:
> The only motivation for me is in attempting to get rid of there even
> being two modes. I don't really care if it was strict or not strict,
> just that there's only one of them. Obviously the horse left the barn
> for ES5 long ago, but the desire to collapse down to one mode in as
> much code as possible is still motivating.

Indeed, this is a shared goal, happy to have it solved somehow. We're
just arguing about "better" before committing.

> I saw bundling as many carrots in with strict mode as a way to
> leverage developers into the single mode JS utopia of the future. I
> appreciate the arguments about the negatives of forcing the pragma
> incantation though.

Thanks.

> How about making ES6 features only available inside modules? I guess
> that's kind of a cop-out though, since you don't always need a module.
> I still yearn for that utopian JS future where there is no need for
> two modes.

Utopia means no-place.

If between some or all new body forms imputing strictness, and
evangelizing/teaching "use strict" or better means of opting in, we get
to a world akin to Perl 5 in its modern form (CPAN etc.), where strict
code predominates, that's good enough for me.

/be
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

I had what I hope is an original thought on solving this. Bear with me.

In Brendan's world, how will people end up "accidentally" in sloppy mode? With classes and modules and maybe generators and more in strict mode, I see the biggest remaining contingent being `<script>`-loaded one-offs or "bootstrapping" application code. \[1\] (If anyone has a better way of describing this set, please jump in.)

What I realized is that today that is exactly the sort of code you wrap in an IIFE, i.e. `(function () { }());`. Of course those of us who are on the strict-train end up writing this as

```js
(function () {
  "use strict";

  // actual code here
}());
```

i.e. this is our new boilerplate for `<script>` code [2].

Well, what if we resurrected the `do` expression idea [3], but with a strict twist? Then we could evangelize the use of

```js
do {
  // actual code here
}
```

as the new `<script>` boilerplate. It's pretty easy to sell, even as a replacement for non-strict IIFEs. And it gets more people on the strict train. Between this and modules, people should end up in sloppy mode fairly rarely ([1] aside :-/).

Thoughts?


1. Possibly Node.js modules, assuming at best a backward-compatibility layer and at worst the failure of ES6 modules in the Node.js world. This proposal sadly has no solutions for that.
2. Microsoft has very awesomely made this the default for new JS files in Visual Studio 2012 :O
3. http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions

________________________________________
From: es-discuss-bounces at mozilla.org [es-discuss-bounces at mozilla.org] on behalf of Brendan Eich [brendan at mozilla.com]
Sent: Monday, December 31, 2012 16:38
To: Brandon Benvie
Cc: Mark S. Miller; es-discuss at mozilla.org
Subject: Re: excluding features from sloppy mode

Brandon Benvie wrote:
> The only motivation for me is in attempting to get rid of there even
> being two modes. I don't really care if it was strict or not strict,
> just that there's only one of them. Obviously the horse left the barn
> for ES5 long ago, but the desire to collapse down to one mode in as
> much code as possible is still motivating.

Indeed, this is a shared goal, happy to have it solved somehow. We're
just arguing about "better" before committing.

> I saw bundling as many carrots in with strict mode as a way to
> leverage developers into the single mode JS utopia of the future. I
> appreciate the arguments about the negatives of forcing the pragma
> incantation though.

Thanks.

> How about making ES6 features only available inside modules? I guess
> that's kind of a cop-out though, since you don't always need a module.
> I still yearn for that utopian JS future where there is no need for
> two modes.

Utopia means no-place.

If between some or all new body forms imputing strictness, and
evangelizing/teaching "use strict" or better means of opting in, we get
to a world akin to Perl 5 in its modern form (CPAN etc.), where strict
code predominates, that's good enough for me.

/be
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss