Re: excluding features from sloppy mode

2013-01-17 Thread Andreas Rossberg
On 16 January 2013 19:33, Brandon Benvie wrote: > Without using modules as the indicator, how do you know whether code is > intended to be run as ES6 or not? Do let and const count as ES6 > (retroactively applying to code using the old non-standard versions, which > are still currently supported b

Re: excluding features from sloppy mode

2013-01-16 Thread Brendan Eich
Oliver Hunt wrote: Even 10? If that's the case anything using const is inherently tied to jsc,v8,moz,opera behaviour. Yes, even IE10. Presumably the strictest of those _works_, but maybe i'm wrong? Opera equates const and var, last I heard. /be __

Re: excluding features from sloppy mode

2013-01-16 Thread Oliver Hunt
___ > From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on > behalf of Oliver Hunt [oli...@apple.com] > Sent: Wednesday, January 16, 2013 14:40 > To: Brendan Eich > Cc: Mark S. Miller; Mark Miller; es-discuss@mozilla.org > Subject: Re:

RE: excluding features from sloppy mode

2013-01-16 Thread Domenic Denicola
r; es-discuss@mozilla.org Subject: Re: excluding features from sloppy mode Even 10? If that's the case anything using const is inherently tied to jsc,v8,moz,opera behaviour. Presumably the strictest of those _works_, but maybe i'm wrong? We should probably just enumerate all the diff

Re: excluding features from sloppy mode

2013-01-16 Thread Oliver Hunt
Even 10? If that's the case anything using const is inherently tied to jsc,v8,moz,opera behaviour. Presumably the strictest of those _works_, but maybe i'm wrong? We should probably just enumerate all the differences and see which can be coalesced and which make "sense" in sloppy mode. Obviou

Re: excluding features from sloppy mode

2013-01-16 Thread Brendan Eich
Oliver Hunt wrote: let isn't really relevant in sloppy mode, unless we decide to take let over destructuring (which would make me really sad) You missed the last TC39 meeting, where we agreed (with some misgivings) to have both, but to break backward compat if any extant code indexes into let

Re: excluding features from sloppy mode

2013-01-16 Thread Oliver Hunt
On Jan 16, 2013, at 11:26 AM, Brandon Benvie wrote: > The incompatibilities between let/const as implemented in V8 and Spidermonkey > and how they're specified in ES6 are an additional factor: > > * Per iteration loop binding (V8 and Spidermonkey don't do this for > let/const). let isn't rea

Re: excluding features from sloppy mode

2013-01-16 Thread Brendan Eich
There's no const in IE, so we are pretty sure we can take the hit of breaking "Mozilla" (non-IE branches, also WebKit, maybe Opera) code that uses const. /be Brandon Benvie wrote: The incompatibilities between let/const as implemented in V8 and Spidermonkey and how they're specified in ES6 ar

Re: excluding features from sloppy mode

2013-01-16 Thread Brendan Eich
Oliver Hunt wrote: Note that this isn't a "opt-in", this is an attempt to try and minimise the differences between strict and sloppy modes. My ideal is that anything that can be unambiguously supported in sloppy mode should be. I'm still with you on this. /be ___

Re: excluding features from sloppy mode

2013-01-16 Thread Brandon Benvie
The incompatibilities between let/const as implemented in V8 and Spidermonkey and how they're specified in ES6 are an additional factor: * Per iteration loop binding (V8 and Spidermonkey don't do this for let/const). * TDZ. `x; const x = 10` works in V8 and Spidermonkey currently, specified to thr

Re: excluding features from sloppy mode

2013-01-16 Thread Oliver Hunt
let can't be used as an opt in (unfortunately :-( ) as it turns out let is used as a variable name in real world code. Gavin and I briefly toyed with the concept of having let be a contextually identified, but that's not doable if you have destructuring assignment in sloppy mode. My feeling is

Re: excluding features from sloppy mode

2013-01-16 Thread Kevin Smith
FWIW, after considering it for some time (there's a draft sitting around somewhere that I half-finished), I realize that point 4 ("All new syntax forms with code bodies are implicit strict") isn't going to work in seriousness. Why? Because if you list out the new syntactic forms with code bodies

Re: excluding features from sloppy mode

2013-01-16 Thread Brandon Benvie
Without using modules as the indicator, how do you know whether code is intended to be run as ES6 or not? Do let and const count as ES6 (retroactively applying to code using the old non-standard versions, which are still currently supported by V8 and Spidermonkey)? Does it apply to code that appear

Re: excluding features from sloppy mode

2013-01-16 Thread Andreas Rossberg
On 1 January 2013 07:09, Mark Miller wrote: > On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich wrote: >> >> Mark S. Miller wrote: >> I'm pretty happy with Kevin's compromise. Here it is again: >> >> (1) No opt-in required for new syntax, except: >> (2) No breaking changes to sloppy mode, and >> (3)

RE: excluding features from sloppy mode

2013-01-04 Thread Nathan Wall
Brendan Eich wrote: > Ease of teaching != successfully imparted knowledge at scale. Sorry, but > it's true. People don't use "use strict"; at top level enough, and > teaching them all will take time. Even then, because of the Law of Least > Effort, it'll be left out. > > This is the major objection

Re: excluding features from sloppy mode

2013-01-02 Thread Brendan Eich
if people are interested. -Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of Brendan Eich Sent: Saturday, December 29, 2012 7:10 PM To: Domenic Denicola Cc: Mark S. Miller; es-discuss@mozilla.org Subject: Re: excluding features from sloppy mod

RE: excluding features from sloppy mode

2013-01-02 Thread Brian Terlson
ember 29, 2012 7:10 PM > To: Domenic Denicola > Cc: Mark S. Miller; es-discuss@mozilla.org > Subject: Re: excluding features from sloppy mode > > Domenic Denicola wrote: > > Duplicate parameters are quite common in the following case: > > > > callSomething(function (

Re: excluding features from sloppy mode

2012-12-31 Thread Brendan Eich
Mark Miller wrote: On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich > wrote: Mark S. Miller wrote: As I understood Dave's clarification, 1JS is orthogonal to our decisions about how many of the new featu

Re: excluding features from sloppy mode

2012-12-31 Thread Mark Miller
On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=bren...@mozilla.com> > wrote: > Mark S. Miller wrote: > >> Thanks for clarifying the primacy of "the rule". It was not clear, and it >>> > does not match what Dave proposed that Mark reconfirmed as "1

Re: excluding features from sloppy mode

2012-12-31 Thread Brendan Eich
Domenic Denicola wrote: What I realized is thattoday that is exactly the sort of code you wrap in an IIFE, i.e. (function () { }());. Script concatenation does not wrap an IIFE around the whole concatenation, and cannot in general. /be ___ es-dis

Re: excluding features from sloppy mode

2012-12-31 Thread Brendan Eich
Mark S. Miller wrote: Thanks for clarifying the primacy of "the rule". It was not clear, and it > does not match what Dave proposed that Mark reconfirmed as "1JS". Although > Dave left some wiggle room in his first post, I want to say that my attempts > to make all new body-forms strict don't

Re: excluding features from sloppy mode

2012-12-31 Thread Brendan Eich
Kevin Smith wrote: The only place 'let' is contextually reserved in the quasi-consensus from the last TC39 meeting is at the start of a statement, when followed by an identifier, '{', or '['. Right - which makes "let" a "second class identifier" (sorry, made-up-term), since it can

Re: excluding features from sloppy mode

2012-12-31 Thread Mark S. Miller
On Mon, Dec 31, 2012 at 7:49 PM, Brendan Eich wrote: > Kevin Smith wrote: >> >> >> And again, ES5 failed to reserve 'module' in strict mode, and >> ES1-3 never reserved 'module', so ES6 must make 'module' only >> contextually reserved. We are already in "either it's an >> identifie

Re: excluding features from sloppy mode

2012-12-31 Thread Kevin Smith
> The only place 'let' is contextually reserved in the quasi-consensus from > the last TC39 meeting is at the start of a statement, when followed by an > identifier, '{', or '['. > Right - which makes "let" a "second class identifier" (sorry, made-up-term), since it can't be used in "let[x] = y".

Re: excluding features from sloppy mode

2012-12-31 Thread Brendan Eich
Kevin Smith wrote: And again, ES5 failed to reserve 'module' in strict mode, and ES1-3 never reserved 'module', so ES6 must make 'module' only contextually reserved. We are already in "either it's an identifier, or it isn't" default. If we can do it for 'module', why not for

Re: excluding features from sloppy mode

2012-12-31 Thread Kevin Smith
> And again, ES5 failed to reserve 'module' in strict mode, and ES1-3 never > reserved 'module', so ES6 must make 'module' only contextually reserved. We > are already in "either it's an identifier, or it isn't" default. If we can > do it for 'module', why not for 'let'? Easy: "module" is still a

Re: excluding features from sloppy mode

2012-12-31 Thread Brendan Eich
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

Re: excluding features from sloppy mode

2012-12-31 Thread Brandon Benvie
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 i

Re: excluding features from sloppy mode

2012-12-31 Thread Brendan Eich
Kevin Smith wrote: (b) ES6 sloppy mode cannot have "let". That's overstated, and as such it contradicts the tenuous consensus of the last TC39 meeting: to reserve 'let' contextually in sloppy mode and evangelize any let [x] = y code out there already (which we've yet to

Re: excluding features from sloppy mode

2012-12-31 Thread Kevin Smith
> (b) ES6 sloppy mode cannot have "let". >> > > That's overstated, and as such it contradicts the tenuous consensus of the > last TC39 meeting: to reserve 'let' contextually in sloppy mode and > evangelize any let [x] = y code out there already (which we've yet to find > -- 'let' is used as an iden

Re: excluding features from sloppy mode

2012-12-30 Thread Brendan Eich
Kevin Smith wrote: This is a bit long - bear with me... First, let me make one more argument as to why "new syntax, just use it" won't work: (a) In ES6, "let" is the preferred way to declare variables. Let's not be relativistic to the point of goo here. Block-scoped variables are "better"

Re: excluding features from sloppy mode

2012-12-30 Thread Kevin Smith
This is a bit long - bear with me... First, let me make one more argument as to why "new syntax, just use it" won't work: (a) In ES6, "let" is the preferred way to declare variables. Let's not be relativistic to the point of goo here. Block-scoped variables are "better". As such, "let" is of c

Re: excluding features from sloppy mode

2012-12-30 Thread Brendan Eich
Claus Reinke wrote: // suggestion Perhaps there is a way to make the automated upgrade problem solvable/cheap? Instead of ES6+ supporting sloppy mode and strict mode and mixtures of new features with sloppy mode indefinetly, how about turning the situation on its head: - ES6 engines default to

Re: excluding features from sloppy mode

2012-12-30 Thread Claus Reinke
Another thought: What will JavaScript code look like once 99% of browsers in use support ES6? Will we have a language with coherent semantics and a simple structure? That is: is there a way to drop some of the trickiness, long term? And which of the approaches gets us there? In the short term, w

Re: excluding features from sloppy mode

2012-12-30 Thread Claus Reinke
It would actually be nice to have that as a feature: If the variable name is `_` then it can be used multiple times. It’s a nice, self-descriptive way of saying that you don’t care about a parameter value. That underscore wildcard is the exact syntax used in functional languages, and very useful

Re: excluding features from sloppy mode

2012-12-30 Thread Brendan Eich
Axel Rauschmayer wrote: I made a list of the 10 biggest JS pitfalls and most of them will be gone under ES6. Much less to worry about, much easier to learn. Could you share your 10-biggest list? /be ___ es-discuss mailing list es-discuss@mozilla.org

Re: excluding features from sloppy mode

2012-12-30 Thread Axel Rauschmayer
>> - Pro 1JS: You can use new stuff everywhere. >> - Contra 1JS: You can’t use all of the new stuff. There are tricky >> exceptions and rules. > > Check me: I think the only exceptions that we have found are let and > function-in-block. At the last TC39 meeting, we resolved to try reserving let

Re: excluding features from sloppy mode

2012-12-30 Thread Brendan Eich
Brandon Benvie wrote: On Sunday, December 30, 2012, Mark S. Miller wrote: In the short term, while people are making the transition, the rule would be stated as above “If you want the new stuff, turn on strict mode or wrap a module around it.” Later, once ES6 is everywhere, it wo

Re: excluding features from sloppy mode

2012-12-30 Thread Brendan Eich
Axel Rauschmayer wrote: I agree. To me it comes down to cognitive load. A good way of measuring that is whether one can state a simple rule. For Andreas’ approach, it would be: “If you want the new stuff, turn on strict mode or wrap a module around it.” That is different from what TC39 has be

Re: excluding features from sloppy mode

2012-12-30 Thread Brandon Benvie
On Sunday, December 30, 2012, Mark S. Miller wrote: > > In the short term, while people are making the transition, the rule > would be stated as above “If you want the new stuff, turn on strict > mode or wrap a module around it.” Later, once ES6 is everywhere, it > would instead be stated as "Turn

Re: excluding features from sloppy mode

2012-12-30 Thread Mark S. Miller
On Sun, Dec 30, 2012 at 3:39 AM, Axel Rauschmayer wrote: > I agree. To me it comes down to cognitive load. A good way of measuring that > is whether one can state a simple rule. For Andreas’ approach, it would be: > “If you want the new stuff, turn on strict mode or wrap a module around it.” +1.

Re: excluding features from sloppy mode

2012-12-30 Thread Andreas Rossberg
On 30 December 2012 12:50, Axel Rauschmayer wrote: > It would actually be nice to have that as a feature: If the variable name is > `_` then it can be used multiple times. It’s a nice, self-descriptive way of > saying that you don’t care about a parameter value. That underscore wildcard is the ex

Re: excluding features from sloppy mode

2012-12-30 Thread Herby Vojčík
Axel Rauschmayer wrote: It would actually be nice to have that as a feature: If the variable name is `_` then it can be used multiple times. It’s a nice, self-descriptive way of saying that you don’t care about a parameter value. It is a valid identifier, one may actually use it. Better allow

Re: excluding features from sloppy mode

2012-12-30 Thread Andreas Rossberg
On 30 December 2012 11:58, Brendan Eich wrote: > Two separate things: > > 1. All new syntax with code bodies makes strict-by-fiat code bodies. > > 2. New parameter forms restrict duplicate parameters. > > Neither entails "various features locally chang[ing] the semantics of > unrelated constructs"

Re: excluding features from sloppy mode

2012-12-30 Thread Axel Rauschmayer
rday, December 29, 2012 22:10 >> To: Domenic Denicola >> Cc: Mark S. Miller; es-discuss@mozilla.org >> Subject: Re: excluding features from sloppy mode >> >> Domenic Denicola wrote: >>> Duplicate parameters are quite common in the following case: >>> &g

Re: excluding features from sloppy mode

2012-12-30 Thread Axel Rauschmayer
I agree. To me it comes down to cognitive load. A good way of measuring that is whether one can state a simple rule. For Andreas’ approach, it would be: “If you want the new stuff, turn on strict mode or wrap a module around it.” - Pro 1JS: You can use new stuff everywhere. - Contra 1JS: You can’t

Re: excluding features from sloppy mode

2012-12-30 Thread Brendan Eich
Andreas Rossberg wrote: There also is the sloppy-mode-arguments-object vs destructuring issue. Thanks, I forgot that one. It's a good point, since one cannot statically catch all 'arguments' uses in general. Years ago we implemented destructuring parameters in JS1.7-1.8, without restricting

Re: excluding features from sloppy mode

2012-12-30 Thread Brendan Eich
Andreas Rossberg wrote: On 29 December 2012 22:06, Brendan Eich wrote: Andreas Rossberg wrote: ES6+ will stay much longer (at least that's what we are working for). Consequently, what should take precedence are the expectations and needs of _future_ users of ES. Those who will come to ES6+ wit

Re: excluding features from sloppy mode

2012-12-30 Thread Herby Vojčík
Domenic Denicola wrote: From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan Eich Sent: Sunday, December 30, 2012 00:06 by yoking ES6 feature adoption to strict mode adoption, you multiply risks and reduce ES6 adoption. I'd like to lend a little

Re: excluding features from sloppy mode

2012-12-30 Thread Claus Reinke
Ease of teaching != successfully imparted knowledge at scale. Sorry, but it's true. People don't use "use strict"; at top level enough, and teaching them all will take time. Even then, because of the Law of Least Effort, it'll be left out. This is the major objection some of us keep raising, a

Re: excluding features from sloppy mode

2012-12-30 Thread Andreas Rossberg
On 30 December 2012 02:31, Mark S. Miller wrote: > > If duplicate formals are the only such case, then I agree that the > fear of micro-mode is a non-issue. Do we have an accurate record of > the scoping of default value expressions? How about the interaction of > head scope and top body scope? I

Re: excluding features from sloppy mode

2012-12-30 Thread Andreas Rossberg
On 29 December 2012 22:11, Brendan Eich wrote: > Andreas Rossberg wrote: >> >> On 29 December 2012 14:51, Axel Rauschmayer wrote: >>> >>> I’m sympathetic to both sides of this argument. How would you handle >>> things? >> >> >> Ideally? Backing out of the whole 1JS marketing maneuver? > > It's no

Re: excluding features from sloppy mode

2012-12-30 Thread Andreas Rossberg
On 29 December 2012 22:06, Brendan Eich wrote: > Andreas Rossberg wrote: >> ES6+ will stay much longer (at least that's what we are working for). >> Consequently, what should take precedence are the expectations and >> needs of _future_ users of ES. Those who will come to ES6+ without >> knowing n

Re: excluding features from sloppy mode

2012-12-29 Thread Brandon Benvie
I believe the only major factors in usage uptake for ES6 will be in the ever present need for backwards compatibility, and educating developers on what new tools exist. Imdo not believe having a "use strict" gatekeeper at the front of the ES6 bonanza would not be a motivating factor in turning peop

Re: excluding features from sloppy mode

2012-12-29 Thread Kevin Smith
> 1) All new syntax and breaking changes (where possible) are strict-mode >> only. >> 2) Modules and only modules are implicitly strict. >> > > (2) is not what (1) says, ignoring the mysterious "(where possible)" > loophole. > You're really sharp! Notice that I didn't specify in or out-of-line m

Re: excluding features from sloppy mode

2012-12-29 Thread Kevin Smith
> Ease of teaching != successfully imparted knowledge at scale. Sorry, but > it's true. People don't use "use strict"; at top level enough, and teaching > them all will take time. Even then, because of the Law of Least Effort, > it'll be left out. > > This is the major objection some of us keep rai

RE: excluding features from sloppy mode

2012-12-29 Thread Domenic Denicola
> From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] > On Behalf Of Brendan Eich > Sent: Sunday, December 30, 2012 00:06 > by yoking ES6 feature adoption to strict mode adoption, you multiply risks > and reduce ES6 adoption. I'd like to lend a little bit of defense to

RE: excluding features from sloppy mode

2012-12-29 Thread Domenic Denicola
Sent: Saturday, December 29, 2012 22:10 > To: Domenic Denicola > Cc: Mark S. Miller; es-discuss@mozilla.org > Subject: Re: excluding features from sloppy mode > > Domenic Denicola wrote: > > Duplicate parameters are quite common in the following case: > > > > callS

Re: excluding features from sloppy mode

2012-12-29 Thread Brendan Eich
Kevin Smith wrote: The more I think about this, the more convinced I get that all new syntax and breaking changes (where possible) should be strict-mode only ... 1) All new syntax and breaking changes (where possible) are strict-mode only. 2) Modules and only modules are implicitly strict. (

Re: excluding features from sloppy mode

2012-12-29 Thread Brendan Eich
Kevin Smith wrote: The more I think about this, the more convinced I get that all new syntax and breaking changes (where possible) should be strict-mode only. In retrospect, `let[x] = y;` changed everything. Here's why I think "1JS under strict" is the best solution: - How exactly would one

Re: excluding features from sloppy mode

2012-12-29 Thread Kevin Smith
The more I think about this, the more convinced I get that all new syntax and breaking changes (where possible) should be strict-mode only. In retrospect, `let[x] = y;` changed everything. Here's why I think "1JS under strict" is the best solution: - How exactly would one teach that classes, arr

Re: excluding features from sloppy mode

2012-12-29 Thread Brendan Eich
Domenic Denicola wrote: Duplicate parameters are quite common in the following case: callSomething(function (_, _, whatIActuallyCareAbout) {}); I've never seen that in JS. In ML, sure. Have you any links to cite? /be ___ es-discuss mailing list es

RE: excluding features from sloppy mode

2012-12-29 Thread Domenic Denicola
: es-discuss@mozilla.org<mailto:es-discuss@mozilla.org> Subject: Re: excluding features from sloppy mode Mark S. Miller wrote: > On Sat, Dec 29, 2012 at 1:26 PM, Brendan Eich wrote: >> Mark S. Miller wrote: >>> 2) Make a micro-mode, adding yet additional mode switching in order to &g

Re: excluding features from sloppy mode

2012-12-29 Thread Mark S. Miller
On Sat, Dec 29, 2012 at 5:16 PM, Brendan Eich wrote: > I'm prepared to give up on the ban of duplicate formals when destructuring > parameters are present, if that will get rid of your objection to > "micro-modes". I don't recall anything else like this case. We arrived at it > mainly to simplify

Re: excluding features from sloppy mode

2012-12-29 Thread Brendan Eich
Mark S. Miller wrote: On Sat, Dec 29, 2012 at 1:26 PM, Brendan Eich wrote: Mark S. Miller wrote: 2) Make a micro-mode, adding yet additional mode switching in order to supposedly avoid the complexity of dealing with one mode switch. No, you are using micro-mode as an epithet without actually

Re: excluding features from sloppy mode

2012-12-29 Thread Brandon Benvie
Put everything new in ES6 as implicit opt-in for strict mode? It certainly is the simplest of all options, both for implementors and users. It also removes the "big enough carrot" problem. Any individual feature may not be enough of a carrot to sway a user, and taken as one by one choice, might lea

Re: excluding features from sloppy mode

2012-12-29 Thread Kevin Smith
I gotta say, I'm in agreement with Mark (and even Andreas) here. 1JS, under all modes just isn't going to work (let[x] = y proves that). And keeping track of what's allowed under which mode (and why) could get complicated and difficult to explain. But what about this? One JS, Under strict mod

Re: excluding features from sloppy mode

2012-12-29 Thread Mark S. Miller
On Sat, Dec 29, 2012 at 1:26 PM, Brendan Eich wrote: > Mark S. Miller wrote: >> >> On Sat, Dec 29, 2012 at 1:06 PM, Brendan Eich wrote: >>> >>> Who ever proposed that? It seems a misunderstanding. No one is saying >>> that, >>> >>> e.g., destructuring formal parameters, or a rest parameter, shoul

Re: excluding features from sloppy mode

2012-12-29 Thread Brendan Eich
Mark S. Miller wrote: On Sat, Dec 29, 2012 at 1:06 PM, Brendan Eich wrote: Who ever proposed that? It seems a misunderstanding. No one is saying that, e.g., destructuring formal parameters, or a rest parameter, should flip the containing function into strict mode. Banning duplicate formals in n

Re: excluding features from sloppy mode

2012-12-29 Thread Mark S. Miller
On Sat, Dec 29, 2012 at 1:06 PM, Brendan Eich wrote: > Andreas Rossberg wrote: >> >> I haven't replied to this thread yet, because I feel that I already >> made all the same arguments repeatedly to no avail. ;) However, let >> me reiterate one particular observation, which is that IMHO much of >>

Re: excluding features from sloppy mode

2012-12-29 Thread Brendan Eich
Brendan Eich wrote: subtle mode mixtures, I don't buy this one either. We have ES5 sloppy and strict, they mix only statically, with well-defined rules based on "use strict"; (which is not a readability trump card to throw, as discussed). Any dynamic mixing is at the function call boundary.

Re: excluding features from sloppy mode

2012-12-29 Thread Brendan Eich
Andreas Rossberg wrote: On 29 December 2012 14:51, Axel Rauschmayer wrote: I’m sympathetic to both sides of this argument. How would you handle things? Ideally? Backing out of the whole 1JS marketing maneuver? It's not just marketing surface, but lack of version= substance. How do you prop

Re: excluding features from sloppy mode

2012-12-29 Thread Brendan Eich
Andreas Rossberg wrote: I haven't replied to this thread yet, because I feel that I already made all the same arguments repeatedly to no avail. ;) However, let me reiterate one particular observation, which is that IMHO much of the discussion (and decision making) around 1JS, modes, and opt-ins

Re: excluding features from sloppy mode

2012-12-29 Thread Andreas Rossberg
On 29 December 2012 14:51, Axel Rauschmayer wrote: > I’m sympathetic to both sides of this argument. How would you handle things? Ideally? Backing out of the whole 1JS marketing maneuver? In the long run, I see it as more harmful than helpful, as it inevitably leads to complexity creep, subtle mo

Re: excluding features from sloppy mode

2012-12-29 Thread Axel Rauschmayer
I’m sympathetic to both sides of this argument. How would you handle things? On Dec 29, 2012, at 14:47 , Andreas Rossberg wrote: > I haven't replied to this thread yet, because I feel that I already > made all the same arguments repeatedly to no avail. ;) However, let > me reiterate one particu

Re: excluding features from sloppy mode

2012-12-29 Thread Andreas Rossberg
I haven't replied to this thread yet, because I feel that I already made all the same arguments repeatedly to no avail. ;) However, let me reiterate one particular observation, which is that IMHO much of the discussion (and decision making) around 1JS, modes, and opt-ins is just mistargeted. Name

Re: excluding features from sloppy mode

2012-12-28 Thread Axel Rauschmayer
Add me to the list of people who are overjoyed when this AMD vs. CJS/Node.js travesty is over. That alone is a good answer if people ask: “What can ES6 modules do that current module systems can’t” – it will (most probably) be a common standard. > So are you in favor of class body as strict by

Re: excluding features from sloppy mode

2012-12-28 Thread Kevin Smith
> 1. Except for module. > Right. > 2. Non-locality of "use strict" in the medium-to-large makes for an > effectively invisible, or at least hard to see as in effect, switch. Mmmm.. maybe. > So are you in favor of class body as strict by default? > You mean as always strict? I wasn't when I

Re: excluding features from sloppy mode

2012-12-28 Thread Brendan Eich
Kevin Smith wrote: There's no invisible switch. You are assuming something not axiomatic: that new syntax head-forms other than module must inherit sloppy from outer code. That does not follow without more argumentation. I guess I'm saying that anything other than inheritance,

Re: excluding features from sloppy mode

2012-12-28 Thread Kevin Smith
> There's no invisible switch. You are assuming something not axiomatic: > that new syntax head-forms other than module must inherit sloppy from outer > code. That does not follow without more argumentation. > I guess I'm saying that anything other than inheritance, without the pragma, is an invis

Re: excluding features from sloppy mode

2012-12-28 Thread Brendan Eich
Kevin Smith wrote: The question really is, why have sloppy-mode classes at all? Who wants or needs them? Well, no one, really. But we shouldn't want big invisible switches or any new pragma-haunts either. There's no invisible switch. You are assuming something not axiomatic: that

Re: excluding features from sloppy mode

2012-12-28 Thread Kevin Smith
> The question really is, why have sloppy-mode classes at all? Who wants or > needs them? > Well, no one, really. But we shouldn't want big invisible switches or any new pragma-haunts either. You've said that my predictions are "wildly optimistic", and I'm going to have to push back. Let me, li

Re: excluding features from sloppy mode

2012-12-28 Thread Brendan Eich
David Herman wrote: On Dec 28, 2012, at 12:30 PM, Brendan Eich wrote: But even if*not*, it's not worth proliferating the number of cases that are implicitly strict. To answer that, you have to speculate on costs and benefits of strict mode for classes outside of modules, not talk about modu

Re: excluding features from sloppy mode

2012-12-28 Thread Brendan Eich
Brandon Benvie wrote: So I don't see what costs are associated with making new function forms implicitly strict. In fact, I see the reverse: by allowing them to have two modes, you *create* that very cost same cost. If these new forms only have one mode then they will be *simpler* than regular

Re: excluding features from sloppy mode

2012-12-28 Thread David Herman
On Dec 28, 2012, at 12:30 PM, Brendan Eich wrote: >> But even if*not*, it's not worth proliferating the number of cases that are >> implicitly strict. > > To answer that, you have to speculate on costs and benefits of strict mode > for classes outside of modules, not talk about modules more:

Re: excluding features from sloppy mode

2012-12-28 Thread Brandon Benvie
So to speculate, what are the costs and benefits? Earlier in this thread I said a cost of putting things in strict mode is in increasing the semantic gap between otherwise identical code (besides the pragma), and the cost of not doing so it in any compatibility constraints (such as block scope func

Re: excluding features from sloppy mode

2012-12-28 Thread Brendan Eich
David Herman wrote: OK, I've made that same argument recently, I'll take it. I guess what I can retain of that argument is that*if* modules succeed, then the implicit opt-in will have bought us little. That I agree with (already). But even if*not*, it's not worth proliferating the number o

Re: excluding features from sloppy mode

2012-12-28 Thread David Herman
On Dec 28, 2012, at 12:20 PM, Brendan Eich wrote: > I get nervous when speculations about future adoption ratios or incentives > for developers are made without enough data or table-stakes ante'ing (bolded > tripled *biggest* doesn't count as money!). OK, I've made that same argument recently,

Re: excluding features from sloppy mode

2012-12-28 Thread Brendan Eich
David Herman wrote: On Dec 28, 2012, at 3:01 AM, Kevin Smith wrote: I'm tellin' ya, no one's going to write any significant non-module code. : ) +9001 (to quote rwaldron) We should hold the line against any implicit opt-in beyond modules. Mark argues that classes are coarse-grained, but t

Re: excluding features from sloppy mode

2012-12-28 Thread David Herman
On Dec 28, 2012, at 3:01 AM, Kevin Smith wrote: > I'm tellin' ya, no one's going to write any significant non-module code. : ) +9001 (to quote rwaldron) We should hold the line against any implicit opt-in beyond modules. Mark argues that classes are coarse-grained, but they can easily be sign

Re: excluding features from sloppy mode

2012-12-28 Thread David Herman
On Dec 26, 2012, at 10:56 PM, Brendan Eich wrote: > It does not even contain the word "strict". IIRC (and I asked about this at > the last TC39 meeting and got verbal confirmation), the idea of module {...} > implying strict mode was latent, or intended. I'm not sure about out of line > module

Re: excluding features from sloppy mode

2012-12-28 Thread Kevin Smith
> I guess we'll see soon enough, but I think there's still going to be a big > battle between ES6 modules and node modules and amd/requireJS. Any early > adopter types have already probably invested in something, and because the > porting isn't always straightforward, I think many will stick with w

Re: excluding features from sloppy mode

2012-12-28 Thread Russell Leggett
On Fri, Dec 28, 2012 at 9:53 AM, Kevin Smith wrote: > > Sorry, I should have expanded further - that was my point. Node is a case >> where I can see classes being used without modules. I imagine native class >> support will hit v8 soon enough, and I could see people start using them >> without tr

Re: excluding features from sloppy mode

2012-12-28 Thread Kevin Smith
That implicit head and braces are in the library, though; so if node wanted > (and it would be possible somehow), it could replace it with module. Still > don't know if exporting / reentrant require could be handled without much > fuss. Possible, but not really clean or (I think) satisfactory, du

RE: excluding features from sloppy mode

2012-12-28 Thread François REMY
> Ah - true. They can put a "use strict" at the top if they want that. It’s also possible that Node.js will just enable strict mode by default (as soon as it’s faster than the non-strict mode, which should happen soon); when they will do so, it will mean that using the non-strict mode wil

Re: excluding features from sloppy mode

2012-12-28 Thread Herby Vojčík
Kevin Smith wrote: What about node code? Well, node modules are not ES6 modules. They are functions with an implicit head and braces. So implicit strict mode, applied to ES6 That implicit head and braces are in the library, though; so if node wanted (and it would be possible someho

Re: excluding features from sloppy mode

2012-12-28 Thread Kevin Smith
> Sorry, I should have expanded further - that was my point. Node is a case > where I can see classes being used without modules. I imagine native class > support will hit v8 soon enough, and I could see people start using them > without trying to switch to ES6 modules. > Ah - true. They can put

Re: excluding features from sloppy mode

2012-12-28 Thread Bill Frantz
On 12/27/12 at 11:36 PM, bren...@mozilla.com (Brendan Eich) wrote: To find the governing "use strict"; in a large program or (real bugs bit ES5 here) concatenation is not easy. I would want syntax coloring here. Perhaps a light blue background for strict mode and a light pink one for sloppy.

Re: excluding features from sloppy mode

2012-12-28 Thread Russell Leggett
On Fri, Dec 28, 2012 at 6:06 AM, Kevin Smith wrote: > > >> What about node code? >> > > Well, node modules are not ES6 modules. They are functions with an > implicit head and braces. So implicit strict mode, applied to ES6 modules, > would not apply to them. > Sorry, I should have expanded fur

Re: excluding features from sloppy mode

2012-12-28 Thread Kevin Smith
> > What about node code? > Well, node modules are not ES6 modules. They are functions with an implicit head and braces. So implicit strict mode, applied to ES6 modules, would not apply to them. { Kevin } ___ es-discuss mailing list es-discuss@mozilla

  1   2   >