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)

Re: ES6 doesn't need opt-in

On 3 January 2012 21:01, Brendan Eich wrote: > On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote: >> On 3 January 2012 07:21, Brendan Eich 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 in

Re: ES6 doesn't need opt-in

On 3 January 2012 21:18, Brendan Eich wrote: > On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote: > >> On 3 January 2012 07:19, Brendan Eich 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 re

Re: ES6 doesn't need opt-in

On Tue, Jan 3, 2012 at 10:18 PM, Brendan Eich 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

Re: ES6 doesn't need opt-in

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 t

Re: ES6 doesn't need opt-in

On Tue, Jan 3, 2012 at 4:08 PM, Brendan Eich wrote: > On Jan 3, 2012, at 1:24 PM, Mark S. Miller wrote: > > >Just Two Modes > > V8 folks the other year had a catchier version: "no more modes". > I am happy with that ;). > > > > * ES6 non-strict mode must be practic

Re: ES6 doesn't need opt-in

On Jan 3, 2012, at 4:58 PM, Brendan Eich wrote: >> ... > > No, compare to ArrayLiteral: > > ArrayLiteral : // See 11.1.4 >[ Elisionopt ] >[ ElementList ] >[ ElementList , Elisionopt ] > > ElementList : // See 11.1.4 >Elisionopt AssignmentExpression >ElementList , Elisionop

Re: ES6 doesn't need opt-in

Ah, I see! - Thanks. On Jan 3, 2012, at 4:58 PM, Brendan Eich wrote: > On Jan 3, 2012, at 4:50 PM, Gavin Barraclough wrote: > >> On Jan 3, 2012, at 4:42 PM, Brendan Eich wrote: >> >>> On Jan 3, 2012, at 4:38 PM, Allen Wirfs-Brock wrote: >>> > ArrayBindingPattern : > [ Elision Binding

Re: ES6 doesn't need opt-in

On Jan 3, 2012, at 4:50 PM, Gavin Barraclough wrote: > On Jan 3, 2012, at 4:42 PM, Brendan Eich wrote: > >> On Jan 3, 2012, at 4:38 PM, Allen Wirfs-Brock wrote: >> ArrayBindingPattern : [ Elision BindingRestElement ] [ BindingElementList , Elision BindingRestElement ] >>> >

Re: ES6 doesn't need opt-in

On Jan 3, 2012, at 4:42 PM, Brendan Eich wrote: > On Jan 3, 2012, at 4:38 PM, Allen Wirfs-Brock wrote: > >>> ArrayBindingPattern : >>> [ Elision BindingRestElement ] >>> [ BindingElementList , Elision BindingRestElement ] >> >> It's a grammar bug. Thanks for the proof reading... > > T

Re: ES6 doesn't need opt-in

On Jan 3, 2012, at 4:42 PM, Brendan Eich wrote: > On Jan 3, 2012, at 4:38 PM, Allen Wirfs-Brock wrote: > >>> ArrayBindingPattern : >>> [ Elision BindingRestElement ] >>> [ BindingElementList , Elision BindingRestElement ] >> >> It's a grammar bug. Thanks for the proof reading... > > Th

Re: ES6 doesn't need opt-in

On Jan 3, 2012, at 4:38 PM, Allen Wirfs-Brock wrote: >> ArrayBindingPattern : >> [ Elision BindingRestElement ] >> [ BindingElementList , Elision BindingRestElement ] > > It's a grammar bug. Thanks for the proof reading... The final cited above is the bug, right? The first right-han

Re: ES6 doesn't need opt-in

On Jan 3, 2012, at 4:31 PM, Gavin Barraclough wrote: > On Jan 3, 2012, at 3:27 PM, Brendan Eich wrote: > >> You're proposing that we require 'let' be only at the start of statements? >> If so, then destructuring is problematic: >> >> foo(); >> let [x] = y; >> >> Did that last line destructur

Re: ES6 doesn't need opt-in

On Jan 3, 2012, at 4:31 PM, Gavin Barraclough wrote: > On Jan 3, 2012, at 3:27 PM, Brendan Eich wrote: > >> You're proposing that we require 'let' be only at the start of statements? >> If so, then destructuring is problematic: >> >> foo(); >> let [x] = y; >> >> Did that last line destructu

Re: ES6 doesn't need opt-in

On Jan 3, 2012, at 3:27 PM, Brendan Eich wrote: > You're proposing that we require 'let' be only at the start of statements? If > so, then destructuring is problematic: > > foo(); > let [x] = y; > > Did that last line destructure the property named '0' of the object denoted > by y into a l

Re: ES6 doesn't need opt-in

On Jan 3, 2012, at 1:24 PM, Mark S. Miller wrote: >Just Two Modes V8 folks the other year had a catchier version: "no more modes". > * ES6 non-strict mode must be practically upwards compatible from ES5 > non-strict mode. This is the part that's not clearly agreed

Re: ES6 doesn't need opt-in

On Jan 3, 2012, at 12:28 PM, Gavin Barraclough wrote: > 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'

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 ve

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 parano

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 b

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 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 >>>

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

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 wrote: >> It's not obvious if the static scope is built up from element to >> successive

Re: ES6 doesn't need opt-in

On 3 January 2012 07:19, Brendan Eich 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

Re: ES6 doesn't need opt-in

On 3 January 2012 07:21, Brendan Eich wrote: > It's not obvious if the static scope is built up from element to > successive

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

Re: ES6 doesn't need opt-in

> Right. Maybe the operator should have a different name. "isDefined"? "has a > value" expressed as an operator name? > > isDefined x > > would be syntactic sugar for > > typeof x !== "undefined" && x !== null > > The expression would not throw an exception if x hasn’t been declared.

Re: ES6 doesn't need opt-in

On Jan 1, 2012, at 5:12 AM, David Bruant wrote: > Moreover, the concept of static scoping and "just look at the code to see if > a variable is declared" is not that obvious for newcomers to the language or > newcomers to programming. It's not obvious if the static scope is built up from elemen

Re: ES6 doesn't need opt-in

[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 classi

Re: ES6 doesn't need opt-in

>>({ define: typeof define === "function" >>? define // browser >>: function(F) { F(require,exports,module) } }). // Node.js >>define(function (require, exports, module) { >>// Node.js module code goes here >>}); > Sure, but in that case the test > typeof d

Re: ES6 doesn't need opt-in

Hey Dave, I'm definitely in favour of removing the opt-in (or at least commonly removing the need to opt-in), and support the goal of one JS. Since most of the new syntax only relies on reserved words and, as Brendon stated, yield is only valid in function* constructs, the only problem so far

Re: ES6 doesn't need opt-in

It sure would be nice to put away with additional language modes. However: Pragmatically, I don't see how wrapping your program into a module is more convenient then putting a `use' directive on top. And your additional proposal for "use module" is kind of admitting that it's actually worse, isn't

Re: ES6 doesn't need opt-in

While I like the idea of not having multiple versions of ES very much, I fear that this proposal comes with a danger similar to the problems people have with concatenated source files and the "use strict" pragma. While modules nicely solve the problem of tools doing the wrong thing during some buil

Re: ES6 doesn't need opt-in

On Sun, Jan 1, 2012 at 9:45 AM, Axel Rauschmayer wrote: >({ define: typeof define === "function" >>? define // browser >>: function(F) { F(require,exports,module) } }). // Node.js >>define(function (require, exports, module) { >>// Node.js module code goes here >

Re: ES6 doesn't need opt-in

> Same as... > ( "globalUnknown" in this ) // anywhere > ( "globalUnknown" in window ) // browser > ( "globalUnknown" in global ) // node > ( "globalUnknown" in self ) // workerglobalscope > > But this is _so_ common that it might warrant an upgrade I’m not 100% sure but I w

Re: ES6 doesn't need opt-in

On Sun, Jan 1, 2012 at 12:45 PM, Axel Rauschmayer wrote: > ({ define: typeof define === "function" >>? define // browser >>: function(F) { F(require,exports,module) } }). // Node.js >>define(function (require, exports, module) { >>// Node.js module code goes here

Re: ES6 doesn't need opt-in

>({ define: typeof define === "function" >? define // browser >: function(F) { F(require,exports,module) } }). // Node.js >define(function (require, exports, module) { >// Node.js module code goes here >}); > > Ok, thanks for the example. Here the test > ty

Re: ES6 doesn't need opt-in

> I was challenging Axel's characterization of how JS devs use typeof, since it > leads him to conclude that we need to add a bunch of new language features. > In code I see, devs don't use typeof for checking a value is null or > undefined, so don't base new language features on this use case.

Re: ES6 doesn't need opt-in

On Sun, Jan 1, 2012 at 9:09 AM, Axel Rauschmayer wrote: > > Maybe I am confused. Here is what I was imagining: > > var w = 1; // w is declared and defined. typeof gives 'number' > > var x; // x is declared, but is undefined. typeof gives 'undefined' > > y = 4; // y is not declared, is a g

Re: ES6 doesn't need opt-in

> Maybe I am confused. Here is what I was imagining: > var w = 1; // w is declared and defined. typeof gives 'number' > var x; // x is declared, but is undefined. typeof gives 'undefined' > y = 4; // y is not declared, is a global.typeof gives 'number' >// z is not declared

Re: ES6 doesn't need opt-in

On Sun, Jan 1, 2012 at 6:32 AM, Dean Landolt wrote: > > > On Sun, Jan 1, 2012 at 12:12 AM, John J Barton < > johnjbar...@johnjbarton.com> wrote: > >> >> >> On Sat, Dec 31, 2011 at 7:53 PM, Axel Rauschmayer wrote: >> >>> 1. We want sane isObject and isNull predicates, ideally using typeof. >>> Lac

Re: ES6 doesn't need opt-in

On Sun, Jan 1, 2012 at 5:12 AM, David Bruant wrote: > Le 01/01/2012 06:12, John J Barton a écrit : > > On Sat, Dec 31, 2011 at 7:53 PM, Axel Rauschmayer wrote: > > >> >> 1. Checking whether a variable has been declared. >> Problematic: verbose and conflated with checking for a declared >> v

Re: ES6 doesn't need opt-in

On Sun, Jan 1, 2012 at 12:12 AM, John J Barton wrote: > > > On Sat, Dec 31, 2011 at 7:53 PM, Axel Rauschmayer wrote: > >> 1. We want sane isObject and isNull predicates, ideally using typeof. >> Lack of them continues to bite people, as the web contains code that >> wrongly assumes typeof x == "ob

Re: ES6 doesn't need opt-in

Le 01/01/2012 06:12, John J Barton a écrit : > On Sat, Dec 31, 2011 at 7:53 PM, Axel Rauschmayer > wrote: > > > > 1. Checking whether a variable has been declared. > Problematic: verbose and conflated with checking for a > declared variable having the val

Re: ES6 doesn't need opt-in

On Sat, Dec 31, 2011 at 7:53 PM, Axel Rauschmayer wrote: > 1. We want sane isObject and isNull predicates, ideally using typeof. Lack > of them continues to bite people, as the web contains code that wrongly > assumes typeof x == "object" => x.foo won't throw on null x. > > > What are the use cas

Re: ES6 doesn't need opt-in

umber line. /be - Original Message - From: "Axel Rauschmayer" To: "David Herman" Cc: "es-discuss Steen" Sent: Saturday, December 31, 2011 7:16:06 PM Subject: Re: ES6 doesn't need opt-in Each new feature can be considered independently. Anything t

Re: ES6 doesn't need opt-in

> 1. We want sane isObject and isNull predicates, ideally using typeof. Lack of > them continues to bite people, as the web contains code that wrongly assumes > typeof x == "object" => x.foo won't throw on null x. What are the use cases for typeof? Offhand, I see five and for most of them, othe

Re: ES6 doesn't need opt-in

> Each new feature can be considered independently. Anything that is only > allowed within modules becomes a carrot to lead programmers to the improved > semantics, but whenever we can compatibly make something available to global > code, we should do so. No point needlessly depriving programmer

Re: ES6 doesn't need opt-in

From: "David Herman" > On Dec 31, 2011, at 6:08 PM, Oliver Hunt wrote: > > >> # What about eliminating the window from the scope chain? > >> > >> Short answer: giving up. > > > > I think we can drop the global object from the scope chain in ES. In the > > context of the browser we need to com

Re: ES6 doesn't need opt-in

On Dec 31, 2011, at 6:08 PM, Oliver Hunt wrote: >> # What about eliminating the window from the scope chain? >> >> Short answer: giving up. > > I think we can drop the global object from the scope chain in ES. In the > context of the browser we need to come up with a way to trigger it. Maybe.

Re: ES6 doesn't need opt-in

On Dec 31, 2011, at 5:46 PM, David Herman wrote: > Happy new year, everyone. I've got some good news. > > There's been grumbling lately about the ES6 version opt-in [1]. The > detractors are not right about everything, but it's true that both the MIME > type opt-in: > > >... >

<    1   2