Re: excluding features from sloppy mode

> 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 modules. > > At this point, best thing is to summon Dave. S

Re: excluding features from sloppy mode

Kevin Smith wrote: Indeed, it goes against Dave's original proposal that module opt into strict mode, which avoids some problems with sloppy mode in modules, e.g. implicitly created globals by assignment to free names. Does this mean any script loaded as a module? import somet

Re: excluding features from sloppy mode

> You're not in marketing, are you :-P. > No - and if I had any marketing sense I'd have a much better day job : ) Indeed, it goes against Dave's original proposal that module opt into > strict mode, which avoids some problems with sloppy mode in modules, e.g. > implicitly created globals by assi

Re: excluding features from sloppy mode

Kevin Smith wrote: First, maybe the "1JS" term is a bit confusing and should be retired. You're not in marketing, are you :-P. (I wasn't for most of my career but ended up doing it 50-50 with talent scouting/coaching/nagging. Sucks to be me! :-P) 1JS is too short and tweet-sweet to die. I

Re: Real World Func Decl in Block Scope Breakages

Brendan Eich wrote: 1. We have time and (among the bigs involved in ES6) "money" try evangelization. Evangelization can be crowd-sourced too, and can be more effective when done that way. Left out a word there ahem. /be ___ es-discuss mailing lis

Re: excluding features from sloppy mode

First, maybe the "1JS" term is a bit confusing and should be retired. I think a few simple rules are in order: 1) No opt-in required for new syntax, except: 2) No breaking changes for sloppy mode. 3) No implicit opt-in to strict mode. Everyone agrees on rule #1. Rule #2 implies no "let" declara

Re: Real World Func Decl in Block Scope Breakages

Brendan Eich wrote: Brandon Benvie wrote: Unless I'm mistaken on how Spidermonkey handles function declarations in block scope, almost none of those examples will work correctly in Firefox. Most of them will work in every other major browser, but not in Firefox. No, that's not so. The ancien

Re: Changing [[Prototype]]

On Dec 24, 2012, at 2:17 AM, David Bruant wrote: > The ability to change the [[Prototype]] of an object is orthogonal to the > __proto__ problem. If it's necessary for DOM objects to change the > [[Prototype]] for backward-compat or security reasons, it can do so, I guess. > __proto__ is about

Re: excluding features from sloppy mode

Brendan Eich wrote: Axel Rauschmayer wrote: * const Already reserved (in some sense, even if equated to var in Opera), no opt-in required. This identifier was reserved in ES1. But for const = const is opt-in for and , right? Not sure that that makes much of a difference, though.

Re: Changing [[Prototype]]

On Dec 24, 2012, at 1:48 AM, Anne van Kesteren wrote: > I thought I'd give a heads up as over on www-...@w3.org we're > discussing two cases where we likely need to change the prototype > chain of objects: document.open() and methods that do the equivalent > of document.adoptNode() (including tha

Re: excluding features from sloppy mode

Axel Rauschmayer wrote: * const Already reserved (in some sense, even if equated to var in Opera), no opt-in required. This identifier was reserved in ES1. But for const = const is opt-in for and , right? Not sure that that makes much of a difference, though. How could it matter

Re: excluding features from sloppy mode

Mark S. Miller wrote: On Wed, Dec 26, 2012 at 5:54 PM, Brendan Eich wrote: Just to recap the last TC39 meeting, we agreed to try reserving 'let' in sloppy mode. Mark wasn't happy about that, not so much because of incompatibility due to let[x] = y; changing meaning, more -- this is my interpret

Re: excluding features from sloppy mode

>> * const > > Already reserved (in some sense, even if equated to var in Opera), no opt-in > required. This identifier was reserved in ES1. But for const = const is opt-in for and , right? Not sure that that makes much of a difference, though. -- Dr. Axel Rauschmayer a...@rauschma.de

Re: excluding features from sloppy mode

Brendan Eich wrote: So, case by case: * arrow function syntax (which does not imply "use strict" in body prologue) * class * const * default parameters * destructuring * rest parameters * generators (function*, yield in function* body) * comprehensions * generator expressions * module I lef

Re: excluding features from sloppy mode

Axel Rauschmayer wrote: So, case by case: * arrow function syntax (which does not imply "use strict" in body prologue) * class * const * default parameters * destructuring * rest parameters * generators (function*, yield in function* body) * comprehensions * generator expressions * module all

Re: Object model reformation?

Axel Rauschmayer wrote: http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation Is the object model reformation (OMR) still on the table for ES6? It never was -- it missed the cutoff by over five months. The reason I’m asking is that I recently remembered a technique from th

Re: On dropping @names

On Dec 26, 2012, at 8:36 PM, David Herman wrote: > - JS is dynamically scoped, so having an implicit dummy value isn't a problem > for the type system. Holy misnomers, batman. I meant dynamically typed. May Bob Harper have mercy on my soul. [1] Dave [1] He won't. He'll still be mad at me aft

Re: On dropping @names

On Dec 26, 2012, at 7:40 PM, Brendan Eich wrote: >> Many also believe that hoisting is an excellent feature, not a weirdness. > > For functions, I can defend hoisting, although if I had had more time, I > might have done a let ... in ... or BCPL'ish equivalent form that groups the > recursive

Object model reformation?

http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation Is the object model reformation (OMR) still on the table for ES6? The reason I’m asking is that I recently remembered a technique from the Java collections API: you could wrap any collection in a read-only “view”. That made

Re: excluding features from sloppy mode

> So, case by case: > > * arrow function syntax (which does not imply "use strict" in body prologue) > * class > * const > * default parameters > * destructuring > * rest parameters > * generators (function*, yield in function* body) > * comprehensions > * generator expressions > * module > > all

Re: The 1JS experiment has failed. Let's return to plan A.

> As an aside, ES itself can't self-host its own builtins in strict mode > because of the (two of the very few) semantic differences that exist between > strict mode and non-strict mode: non-strict thrower properties (which I've > come to consider an annoying blight that punishes developers in o

Re: excluding features from sloppy mode

On Wed, Dec 26, 2012 at 5:54 PM, Brendan Eich wrote: > David Herman wrote: >> >> On Dec 26, 2012, at 3:35 PM, Mark S. Miller 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: >> >> >> h

Re: On dropping @names

Rick Waldron wrote: On Wednesday, December 26, 2012, Brandon Benvie wrote: I guess to sum up what I think Domenic was saying: people hoist var declarations so that their code acts the way the engine is going to execute it in order to prevent a mismatch between expectations and re

Re: excluding features from sloppy mode (was: the 1JS experiment has failed)

On Wed, Dec 26, 2012 at 4:59 PM, David Herman wrote: > On Dec 26, 2012, at 3:35 PM, Mark S. Miller 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/e

Re: On dropping @names

When you use var.,.well we know the result. I think we should basically name using hoisted var as "Crockford's js" because he has a patent on hoisting var declarations, and if you're using var and not hoisting you're "doing it wrong"[citation]. If you are, in es6, using var and hoisting, you're doi

Re: On dropping @names

On Wednesday, December 26, 2012, Brandon Benvie wrote: > I guess to sum up what I think Domenic was saying: people hoist var > declarations so that their code acts the way the engine is going to execute > it in order to prevent a mismatch between expectations and result. If there > wasn't a reason

Re: Real World Func Decl in Block Scope Breakages

if I run this code in the tools > web developer > web console, I get a result of undefined and no error `if (false) { function x(){ console.log('worked') } } x();` On Wed, Dec 26, 2012 at 9:06 PM, Brendan Eich wrote: > Brandon Benvie wrote: > >> My tests basically indicate what you said, but wi

Re: Real World Func Decl in Block Scope Breakages

Brandon Benvie wrote: My tests basically indicate what you said, but with a minor distinction. They don't fail outright, as in throw an error. They just fail silently. As in, it's ok to call the identifier, but it's not going to do anything. No, something else is wrong. Can you show such a (r

Re: Real World Func Decl in Block Scope Breakages

My tests basically indicate what you said, but with a minor distinction. They don't fail outright, as in throw an error. They just fail silently. As in, it's ok to call the identifier, but it's not going to do anything. This is a curious Schrodinger's cat kind of intermediate state, where it doesn'

Re: Real World Func Decl in Block Scope Breakages

Brandon Benvie wrote: Unless I'm mistaken on how Spidermonkey handles function declarations in block scope, almost none of those examples will work correctly in Firefox. Most of them will work in every other major browser, but not in Firefox. No, that's not so. The ancient (pre-ES3) SpiderMon

Re: Real World Func Decl in Block Scope Breakages

Brandon Benvie wrote: This appears to be correct. A number of the examples can be boiled down to the following test: if (false) { No, the working examples in Brian's snippets rather test an always-true condition. That means they work in Firefox too. /be function x(){

Re: excluding features from sloppy mode

David Herman wrote: On Dec 26, 2012, at 3:35 PM, Mark S. Miller 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

Re: The 1JS experiment has failed. Let's return to plan A.

Er I meant ThrowTypeError. On Wed, Dec 26, 2012 at 8:52 PM, Brandon Benvie wrote: > As an aside, ES itself can't self-host its own builtins in strict mode > because of the (two of the very few) semantic differences that exist > between strict mode and non-strict mode: non-strict thrower properti

Re: The 1JS experiment has failed. Let's return to plan A.

As an aside, ES itself can't self-host its own builtins in strict mode because of the (two of the very few) semantic differences that exist between strict mode and non-strict mode: non-strict thrower properties (which I've come to consider an annoying blight that punishes developers in order to inf

Re: On dropping @names

I guess to sum up what I think Domenic was saying: people hoist var declarations so that their code acts the way the engine is going to execute it in order to prevent a mismatch between expectations and result. If there wasn't a reason to do that (AKA TDZ-UBI) then it wouldn't be done, because it's

Re: The 1JS experiment has failed. Let's return to plan A.

Mark S. Miller wrote: On Wed, Dec 26, 2012 at 2:58 PM, Brendan Eich wrote: Mark, you cite some issues we need to work through, but opt-in via pragma syntax beyond "use strict" is not one of them. Sorry for the confusion. As I just clarified in my response to Dave, I am not suggesting any of t

RE: On dropping @names

> From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] > On Behalf Of David Herman > Sent: Wednesday, December 26, 2012 19:50 > I imagine your reply is: don't do that transformation; place your `let` > declarations as late as possible before they are going to be used. I

Re: excluding features from sloppy mode (was: the 1JS experiment has failed)

On Dec 26, 2012, at 3:35 PM, Mark S. Miller 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

Re: excluding features from sloppy mode (was: the 1JS experiment has failed)

On Dec 26, 2012, at 15:35 , Mark S. Miller wrote: > On Wed, Dec 26, 2012 at 2:58 PM, David Herman wrote: >> On Dec 26, 2012, at 2:30 PM, Mark S. Miller wrote: >> >>> Sorry, I'd completely forgotten about those earlier options. I am >>> arguing only the latter. Specifically "Any ES6 features th

Re: On dropping @names

On Dec 11, 2012, at 2:45 AM, Andreas Rossberg wrote: Late to the party, sorry. First, let's be clear there are a couple possible semantics that could be called "temporal dead zone." At this point I'm not sure what various people had in mind; I suspect different people may have understood it di

RE: Real World Func Decl in Block Scope Breakages

Sorry, missed one question in there: > -Original Message- > From: es-discuss-boun...@mozilla.org [mailto:es-discuss- > boun...@mozilla.org] On Behalf Of Brian Terlson > Sent: Wednesday, December 26, 2012 4:13 PM > To: Brendan Eich > Cc: Charles McCathie Nevile; es-discuss@mozilla.org > Su

RE: Real World Func Decl in Block Scope Breakages

Hi Brendan, Responses inline. > -Original Message- > From: Brendan Eich [mailto:bren...@mozilla.com] > Sent: Wednesday, December 26, 2012 3:27 PM > To: Brian Terlson > Cc: es-discuss@mozilla.org; Charles McCathie Nevile > Subject: Re: Real World Func Decl in Block Scope Breakages > > Bri

Re: excluding features from sloppy mode (was: the 1JS experiment has failed)

On Wed, Dec 26, 2012 at 3:53 PM, Brandon Benvie 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 t

Re: excluding features from sloppy mode (was: the 1JS experiment has failed)

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 discus

Re: excluding features from sloppy mode (was: the 1JS experiment has failed)

On Wed, Dec 26, 2012 at 2:58 PM, David Herman wrote: > On Dec 26, 2012, at 2:30 PM, Mark S. Miller 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, in

Re: Real World Func Decl in Block Scope Breakages

Brian Terlson wrote: 20 sites, however, will likely be broken by this change in some way. There is also a chance that the tool used to identify breakages has missed some code that will breka. Below are some examples of code on the web today that will be broken. For each I include a snippet of

Re: The 1JS experiment has failed. Let's return to plan A.

On Wed, Dec 26, 2012 at 2:58 PM, Brendan Eich wrote: > Mark, you cite some issues we need to work through, but opt-in via pragma > syntax beyond "use strict" is not one of them. Sorry for the confusion. As I just clarified in my response to Dave, I am not suggesting any of those previous MIME typ

Re: Real World Func Decl in Block Scope Breakages

Unless I'm mistaken on how Spidermonkey handles function declarations in block scope, almost none of those examples will work correctly in Firefox. Most of them will work in every other major browser, but not in Firefox. The question of whether the sites are actually broken in Firefox will mostly c

Re: Dynamically changing of loader global

Le 26/12/2012 23:14, David Herman a écrit : On Dec 24, 2012, at 2:34 PM, David Bruant wrote: I've reading the loader API [1] and I was wondering if it was possible to dynamically change the global. I think it is by doing the following, but tell me if I'm wrong: That wasn't the intention. It

Re: excluding features from sloppy mode (was: the 1JS experiment has failed)

On Dec 26, 2012, at 2:30 PM, Mark S. Miller 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 o

Re: The 1JS experiment has failed. Let's return to plan A.

Mark, you cite some issues we need to work through, but opt-in via pragma syntax beyond "use strict" is not one of them. What's more, the big-picture claim in your Subject line ("has failed" especially) is not true. In an overriding sense, 1JS can't fail, because versioning is an anti-pattern

Re: The 1JS experiment has failed. Let's return to plan A.

On Wednesday, December 26, 2012, Mark S. Miller wrote: > Hi Rick, I cited four "features". Unless I misread, 2 of them both concerned block scoped functions and I assumed you were referring to the let[0]=1; which was discussed and consensus on further research towards Luke's resolution was agree

RE: Real World Func Decl in Block Scope Breakages

Most of the snippets fall into either column 5 or 10 in the output table on this site[1] (which is down, hence cached copy, hopefully it works for you guys). These are mostly interoperable across browser. 1. http://cc.bingj.com/cache.aspx?q=new-es5-strict-mode-requirement-function-statements-no

Re: Real World Func Decl in Block Scope Breakages

Perhaps, but the mobile web is WebKitty. The ES6 semantics is incompatible with Chrome and Safari's behavior here. Dave On Dec 26, 2012, at 2:37 PM, Brandon Benvie wrote: > This appears to be correct. A number of the examples can be boiled down to > the following test: > > if (false) { >

Re: Real World Func Decl in Block Scope Breakages

This appears to be correct. A number of the examples can be boiled down to the following test: if (false) { function x(){ console.log('worked'); } } x(); In Chrome, IE, Opera, and Safari 'worked' will be logged. In Firefox it will silently fail. On Wed, De

Re: The 1JS experiment has failed. Let's return to plan A.

On Wed, Dec 26, 2012 at 2:27 PM, David Herman wrote: > Well, before I start arguing with you, I'd like to know what argument you're > making. ;-) > > Are you saying we should go back to having a MIME-type (and/or pragma) > opt-in? Your subject line suggests that. Or are you saying we should simp

Re: The 1JS experiment has failed. Let's return to plan A.

Hi Rick, I cited four "features". Blocked scoped functions are simply the straw that makes the condition of the camel's back more obvious. As for the greater good, we're all working for that. We just differ on which path leads there. On Wed, Dec 26, 2012 at 2:25 PM, Rick Waldron wrote: > > > On

Re: The 1JS experiment has failed. Let's return to plan A.

Well, before I start arguing with you, I'd like to know what argument you're making. ;-) Are you saying we should go back to having a MIME-type (and/or pragma) opt-in? Your subject line suggests that. Or are you saying we should simply not support some of the new features in non-strict code? Be

Re: Real World Func Decl in Block Scope Breakages

On Dec 26, 2012, at 2:02 PM, David Herman wrote: > Hi Brian, > > Thanks for the data. > > My understanding of the consensus was that block-local functions would only > have the new semantics within strict code (which includes module code), so > there would be no breakage of existing content.

Re: Dynamically changing of loader global

On Dec 24, 2012, at 2:34 PM, David Bruant wrote: > I've reading the loader API [1] and I was wondering if it was possible to > dynamically change the global. I think it is by doing the following, but tell > me if I'm wrong: That wasn't the intention. It probably wasn't written out since the fu

Re: '@std' and non-method versions of various methods?

On Dec 24, 2012, at 1:21 PM, Brandon Benvie wrote: > While seemingly out of date (though looks to have been updated recently), the > modules_standard proposal is still listed as ostensibly part of harmony > (ES6). For the most part it simply lists all the standard builtins from > chapter 15 bu

The 1JS experiment has failed. Let's return to plan A.

Hi Brian, thanks for accumulating this data! Between * this data, * Apple's decision as recorded at , * the new function syntax micro-modes, * and the "let" issues already discussed, I reiterate that we should stop trying to twist the language to s

Re: Real World Func Decl in Block Scope Breakages

Hi Brian, Thanks for the data. My understanding of the consensus was that block-local functions would only have the new semantics within strict code (which includes module code), so there would be no breakage of existing content. That said, if we felt the breakage was acceptable, in the long r

Real World Func Decl in Block Scope Breakages

I have some data on patterns and sites that may break due to the proposed change to semantics of function decls in block scope. I am not advocating for any changes here but merely dumping some data I've gathered. I will continue gathering data about this breaking change and potentially others (e

Re: Dynamically changing of loader global

Le 25/12/2012 23:01, Brandon Benvie a écrit : I updated my Loader implementation to allow dynamically modifying the options since it seems like a potentially good idea worth investigating, and also seems like it might be indicated as the desired functionality based on global and baseURL being s