Re: ES6 doesn't need opt-in

2012/1/10 Herby Vojčík : > P.S.: I would bet 99% of developers thinks the model is in fact "fallback > delegation". :-/ It is simpler model that works most of the time. Always > write locally, always read locally and then look up the prototype chain. I think that's a question of making a fallacy o

Re: ES6 doesn't need opt-in

e chain. -Pôvodná správa- From: Herby Vojčík Sent: Tuesday, January 10, 2012 6:39 PM To: John J Barton Cc: Mark S. Miller ; Brendan Eich ; es-discuss Steen Subject: Re: ES6 doesn't need opt-in ... So, to sum, either we have "self shared part" mental model, in which foo.x i

Re: ES6 doesn't need opt-in

". Let someone like Allen or Brendan tells exactly what is the mental model, then. It seems none of simple, consistent models of "shared part" or "fallback delegate" is true. -Pôvodná správa- From: John J Barton Sent: Tuesday, January 10, 2012 5:54 PM To: Herby Vojč

Re: ES6 doesn't need opt-in

the latter, that is the philosophy is that child > can override the default from prototype chain. > > So what is the actual philosophy of ES prototype chain? > > Herby > > -Pôvodná správa- From: Allen Wirfs-Brock > Sent: Monday, January 09, 2012 9:41 PM > To: Brenda

Re: ES6 doesn't need opt-in

On 9 January 2012 21:41, Allen Wirfs-Brock wrote: > > On Jan 8, 2012, at 10:32 AM, Brendan Eich wrote: > > On Jan 8, 2012, at 8:28 AM, Mark S. Miller wrote: > ... > > The other change I hope fits into the same bucket is > . >

Re: ES6 doesn't need opt-in

m: Herby Vojčík Sent: Tuesday, January 10, 2012 12:09 PM To: Allen Wirfs-Brock ; Brendan Eich Cc: Mark S. Miller ; es-discuss Steen Subject: Re: ES6 doesn't need opt-in This is interesting issue. There is a subtle difference between "prototype chain is the shared part" Self mindset

Re: ES6 doesn't need opt-in

PM To: Brendan Eich Cc: Mark S. Miller ; es-discuss Steen Subject: Re: ES6 doesn't need opt-in On Jan 8, 2012, at 10:32 AM, Brendan Eich wrote: On Jan 8, 2012, at 8:28 AM, Mark S. Miller wrote: ... The other change I hope fits into the same bucket is <http://wik

Re: ES6 doesn't need opt-in

On 9 January 2012 21:37, Gavin Barraclough wrote: > On Jan 9, 2012, at 2:59 AM, Andreas Rossberg wrote: >> >> I think the state machine is over-complicating things. What it boils >> down to is that we are defining a new language, ES6-proper (or >> informally ES6 for short). It overlaps with ES5 bu

Re: ES6 doesn't need opt-in

FTR (a broken record, sorry), I think we will do a big disservice to interoperation in practice (as enjoyed by future web devs) if we essentially fork the spec and mutate one copy (even excluding Clause 15) to be ES6. I'm still pretty sure implementations will not fork their non-library codebas

Re: ES6 doesn't need opt-in

On Jan 8, 2012, at 10:32 AM, Brendan Eich wrote: > On Jan 8, 2012, at 8:28 AM, Mark S. Miller wrote: > ... > >> The other change I hope fits into the same bucket is >> . >> Right now, because of pressure from test262, we

Re: ES6 doesn't need opt-in

On Jan 9, 2012, at 2:59 AM, Andreas Rossberg wrote: > I think the state machine is over-complicating things. What it boils > down to is that we are defining a new language, ES6-proper (or > informally ES6 for short). It overlaps with ES5 but does not include > it (e.g. throws out `with'). Then you

Re: ES6 doesn't need opt-in

On Jan 8, 2012, at 9:26 PM, Brendan Eich wrote: > On Jan 8, 2012, at 4:53 PM, Mark S. Miller wrote: > >> On Sun, Jan 8, 2012 at 10:32 AM, Brendan Eich wrote: >> [...] >> >> All cool with the above. Thanks. >> >> I wrote in a previous reply that we aren't preserving ES5 as a spec >> reference

Re: ES6 doesn't need opt-in

On Jan 9, 2012, at 9:28 AM, Andreas Rossberg wrote: > On 9 January 2012 16:54, Brendan Eich wrote: >> The question is how bad these will be for anyone writing JS naively, based >> on current and emerging (ES6) docs, without explicit opt-in. >> >> The answer entails at least: >> >> 1. ES5-stric

Re: ES6 doesn't need opt-in

On 9 January 2012 16:54, Brendan Eich wrote: > The question is how bad these will be for anyone writing JS naively, based on > current and emerging (ES6) docs, without explicit opt-in. > > The answer entails at least: > > 1. ES5-strict semantic changes, e.g. arguments aliasing, without early erro

Re: ES6 doesn't need opt-in

On Jan 9, 2012, at 7:54 AM, Brendan Eich wrote: > The question is how bad these will be for anyone writing JS naively, based on > current and emerging (ES6) docs, without explicit opt-in. > > The answer entails at least: > > 1. ES5-strict semantic changes, e.g. arguments aliasing, without early

Re: ES6 doesn't need opt-in

On Jan 9, 2012, at 2:49 AM, Andreas Rossberg wrote: > On 5 January 2012 20:10, Brendan Eich wrote: >> On Jan 5, 2012, at 6:31 AM, Andreas Rossberg wrote: >>> Sorry, I still think that a growing set of subtle implicit rules for >>> activating subtle semantic changes >> >> Not changes, new semanti

Re: ES6 doesn't need opt-in

But the new plan reminds me strongly of bad experiences in Haskell-land. That sounds interesting. Is this documented somewhere? Not really documented, more my experience from having followed various Haskell lists and forums for over 15 years now (*). I have often seen the pattern where a langu

Re: ES6 doesn't need opt-in

On 6 January 2012 03:37, Allen Wirfs-Brock wrote: > Here is a possible set of rules for implicitly assigning ES5 or ES6 semantics > to a Program unit > > In an "ES6" implementation, all constructs that can occur in a valid program > fit into one of these categories: > ES6-only:  The construct is

Re: ES6 doesn't need opt-in

On 5 January 2012 20:10, Brendan Eich wrote: > On Jan 5, 2012, at 6:31 AM, Andreas Rossberg wrote: >> Sorry, I still think that a growing set of subtle implicit rules for >> activating subtle semantic changes > > Not changes, new semantics for new syntax. I was referring to strict vs classic mode

Re: ES6 doesn't need opt-in

On Jan 8, 2012, at 4:53 PM, Mark S. Miller wrote: > On Sun, Jan 8, 2012 at 10:32 AM, Brendan Eich wrote: > [...] > > All cool with the above. Thanks. > > I wrote in a previous reply that we aren't preserving ES5 as a spec > referenced from ES6. ES6 will be self-contained. So I still don't grok

Re: ES6 doesn't need opt-in

On Sun, Jan 8, 2012 at 10:32 AM, Brendan Eich wrote: [...] All cool with the above. Thanks. I wrote in a previous reply that we aren't preserving ES5 as a spec > referenced from ES6. ES6 will be self-contained. So I still don't grok your > concern here. > Sorry, I missed that. In that case, I s

Re: ES6 doesn't need opt-in

On Jan 8, 2012, at 8:28 AM, Mark S. Miller wrote: > I'm ok with trying completion reform as an extension to "use strict"; in ES5+ > implementations, ASAP -- more than ok, really. It would help prove completion > reform is non-breaking. > > That is an example of the kind of issue I am concerned

Re: ES6 doesn't need opt-in

On Jan 7, 2012, at 11:41 PM, Axel Rauschmayer wrote: > Isn’t ES5.nonstrict the union of ES5.nonstrict-ES6-intersection and > ES5.nonstrict-differs-from-ES6? If yes then ES5.nonstrict disappears and we > might have a venn diagram intersecting ES5.nonstrict and ES6: > ES5.nonstrict-only (=ES

Re: ES6 doesn't need opt-in

On Sun, Jan 8, 2012 at 8:15 AM, Brendan Eich wrote: > On Jan 8, 2012, at 8:10 AM, Mark S. Miller wrote: > > On Sat, Jan 7, 2012 at 11:05 PM, Brendan Eich wrote: > [...] > >> so are we really just arguing about names or labels? If so, great -- >> those are important to get right. >> > [...] > >

Re: ES6 doesn't need opt-in

On Jan 8, 2012, at 8:10 AM, Mark S. Miller wrote: > On Sat, Jan 7, 2012 at 11:05 PM, Brendan Eich wrote: > [...] > so are we really just arguing about names or labels? If so, great -- those > are important to get right. > [...] > > While I agree it's important to get labels right, if that is i

Re: ES6 doesn't need opt-in

On Sat, Jan 7, 2012 at 11:05 PM, Brendan Eich wrote: [...] > so are we really just arguing about names or labels? If so, great -- > those are important to get right. > [...] While I agree it's important to get labels right, if that is indeed the only remaining issue here, that's wonderful. I'm

Re: ES6 doesn't need opt-in

On Jan 8, 2012, at 8:05 , Brendan Eich wrote: > Allen has 5&6, ES5, ES6, and Compat5. Relabel these to > > ES5-nonstrict-ES6-intersection > ES5-nonstrict > ES6 > ES5-nonstrict-differs-from-ES6 > > Since ES5-strict is a subset of ES6, it doesn't require new states. I like these labels!

Re: ES6 doesn't need opt-in

On Jan 7, 2012, at 9:35 PM, Gavin Barraclough wrote: > On Jan 7, 2012, at 8:39 PM, Brendan Eich wrote: >> Remember, we are not proposing breaking semantic shifts of meaning for >> existing syntax. So the realistic worry is that you have code with >> arguments[i] aliasing a formal, and this is re

Re: ES6 doesn't need opt-in

On Jan 7, 2012, at 11:05 PM, Brendan Eich wrote: > Allen has 5&6, ES5, ES6, and Compat5. Relabel these to > > ES5-nonstrict-ES6-intersection > ES5-nonstrict > ES6 > ES5-nonstrict-differs-from-ES6 > > Since ES5-strict is a subset of ES6, it doesn't require new states. Again we wink at co

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 7:48 PM, Mark S. Miller wrote: > > > Then I would only expect two labels: ES6 and non-strict > > You're counting different beans from Mark's "modes" and from Allen's states. > > Hi Brendan, as I read it, Axel captures exactly the two modes I have in mind. Ok, good to have fe

Re: ES6 doesn't need opt-in

On Jan 7, 2012, at 8:39 PM, Brendan Eich wrote: > Remember, we are not proposing breaking semantic shifts of meaning for > existing syntax. So the realistic worry is that you have code with > arguments[i] aliasing a formal, and this is required for correct operation, > and you then start using E

Re: ES6 doesn't need opt-in

On Jan 7, 2012, at 23:22 , Claus Reinke wrote: > But the new plan reminds me strongly of bad experiences in Haskell-land. That sounds interesting. Is this documented somewhere? -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com _

Re: ES6 doesn't need opt-in

On Jan 7, 2012, at 8:00 PM, Gavin Barraclough wrote: > Would the implicit opt-in proposal not mean that any programmer wanting to > pick up JavaScript would need to learn the history of when different > syntactic constructs came into the language specification in order to > understand the seman

Re: ES6 doesn't need opt-in

On Jan 7, 2012, at 2:22 PM, Claus Reinke wrote: > Could you please clarify for me: if I get a single-file codebase, > say jquery's 6k or so lines, will I have to scan the whole file for > ES6-only features before I can even tell whether to apply ES6 > or ES5 semantics? And will this problem increa

Re: ES6 doesn't need opt-in

if current construct is in ES6-only, abort current compilation and restart from beginning, starting in State ES6 Basically using any ES6 features makes it an ES6 program. Using any ES5-only feature makes it an ES5 program. Combining ES5-only and ES6 features results in an invalid program.

Re: ES6 doesn't need opt-in

-only-in-ES5" or "Valid-only-in-ES6" events in the parsing state machine, thereby fixing its state to ES5 or ES6. Herby -Pôvodná správa- From: Mark S. Miller Sent: Saturday, January 07, 2012 4:29 AM To: Axel Rauschmayer Cc: Brendan Eich ; es-discuss Steen Subject: Re: ES6 d

Re: ES6 doesn't need opt-in

On Fri, Jan 6, 2012 at 12:29 PM, Brendan Eich wrote: > On Jan 6, 2012, at 12:09 PM, Axel Rauschmayer wrote: > > >> Rather, we should minimize the state machine and how we talk about it. > We could generalize it using Curr, Next, Curr&Next, and Curr-Next labels. > > > > I’m awfully sorry for belab

Re: ES6 doesn't need opt-in

On Fri, Jan 6, 2012 at 12:25 PM, Allen Wirfs-Brock wrote: [...] > Other ES5 opt-ins at the top level include: > > var arguments; > > function ES5(yes,yes){}; > Please stop calling these ES5 opt-ins. They preclude the Program from being strict, and so are forcing ES5-not-strict. Non confusing name

Re: ES6 doesn't need opt-in

Axel, thanks. This is the critical point, so no apologies needed for belaboring. Allen, what I mean is exactly what Axel says here. Look at it another way. Right now we have two normative modes: ES5 strict and ES5 non-strict. State machine aside, ES6 introduces a new single mode normative spec. If

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 1:35 PM, Axel Rauschmayer wrote: >> The issue is *how* the spec and implementations decide what is supported, >> and when to raise an error on new syntax mixed (after) old non-strict code >> (e.g., 'with'). > > > Ah, OK. I thought that one would be able to lump together ES5.

Re: ES6 doesn't need opt-in

> The issue is *how* the spec and implementations decide what is supported, and > when to raise an error on new syntax mixed (after) old non-strict code (e.g., > 'with'). Ah, OK. I thought that one would be able to lump together ES5.non-strict and all prior ES versions on one hand and ES6 and

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 1:03 PM, Axel Rauschmayer wrote: >>> Then I would only expect two labels: ES6 and non-strict >> >> You're counting different beans from Mark's "modes" and from Allen's states. >> >> The reason the state machine matters is implementation (including the fine >> spec, the normat

Re: ES6 doesn't need opt-in

>> Then I would only expect two labels: ES6 and non-strict > > You're counting different beans from Mark's "modes" and from Allen's states. > > The reason the state machine matters is implementation (including the fine > spec, the normative implementation). Authors can think of writing non-stric

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 12:25 PM, Allen Wirfs-Brock wrote: > On Jan 6, 2012, at 11:52 AM, Brendan Eich wrote: > >> Or (no quotes) >> >> use strict; >> >> I think we want this pragma supported, not only the string-literal >> expression-statement "directive". > > If we end up with all of ES6 being a

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 12:09 PM, Axel Rauschmayer wrote: >> Rather, we should minimize the state machine and how we talk about it. We >> could generalize it using Curr, Next, Curr&Next, and Curr-Next labels. > > I’m awfully sorry for belaboring this point. But the labels and the quote > below don’t

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 11:52 AM, Brendan Eich wrote: > (This grew out of a conversation Allen and I had yesterday -- great to see it > developed.) > > One thing to make clear: > >> ES5~EAS6: The construct has identical syntax and static semantics in both >> ES5 and ES6, but differing semantics.

Re: ES6 doesn't need opt-in

> Rather, we should minimize the state machine and how we talk about it. We > could generalize it using Curr, Next, Curr&Next, and Curr-Next labels. I’m awfully sorry for belaboring this point. But the labels and the quote below don’t go together. Quoting Brendan: >> - ES6 is a superset of ES5

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 11:23 AM, Mark S. Miller wrote: > AFAICT, this agrees with my analysis of what your proposal means. How does > this not result in three modes? I guess I don't understand exactly what you mean by a "mode" or why the number of modes is particularly interesting. >From an imple

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 11:23 AM, Mark S. Miller wrote: > AFAICT, this agrees with my analysis of what your proposal means. How does > this not result in three modes? Counting modes is not productive, is it? All major implementations have extended ES5. It's likely extensions will continue to precede

Re: ES6 doesn't need opt-in

(This grew out of a conversation Allen and I had yesterday -- great to see it developed.) One thing to make clear: > ES5~EAS6: The construct has identical syntax and static semantics in both > ES5 and ES6, but differing semantics. For example, accessing a formal > parameter after an assignme

Re: ES6 doesn't need opt-in

AFAICT, this agrees with my analysis of what your proposal means. How does this not result in three modes? On Fri, Jan 6, 2012 at 9:45 AM, Allen Wirfs-Brock wrote: > > On Jan 6, 2012, at 8:03 AM, Mark S. Miller wrote: > > > No sorry, I just spotted the flaw. The observable difference is that a >

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 8:03 AM, Mark S. Miller wrote: > No sorry, I just spotted the flaw. The observable difference is that a > conforming browser is not required by the (ES5 + ES6) specs to provide any > non-triggering ES6 features for program #2. In that case, we again have three > mode. > > F

Re: ES6 doesn't need opt-in

No sorry, I just spotted the flaw. The observable difference is that a conforming browser is not required by the (ES5 + ES6) specs to provide any non-triggering ES6 features for program #2. In that case, we again have three mode. For example, since legacy constrains us from making nested named fun

Re: ES6 doesn't need opt-in

-Pôvodná správa- From: Axel Rauschmayer Sent: Friday, January 06, 2012 12:11 PM To: Allen Wirfs-Brock Cc: Mark S. Miller ; Brendan Eich ; es-discuss Steen Subject: Re: ES6 doesn't need opt-in ... As a human, I would want an ES6 trigger to appear as early as possible. I wou

Re: ES6 doesn't need opt-in

>> Ok, is there any observable difference between what you would have future >> browsers do, vs the equivalent mechanisms except that program #2 is >> categorized as an ES6 program and processed as such? >> >> If there is no observable difference, good. Then it's only a matter of how >> we desc

Re: ES6 doesn't need opt-in

On Fri, Jan 6, 2012 at 12:24 AM, Allen Wirfs-Brock wrote: > > There should be no observable difference. But the issue isn't how we > described the (program) semantics. It is how we decide which semantics to > apply. > Got it. It still gives the web only two modes, but has the huge benefit that

Re: ES6 doesn't need opt-in

On Jan 6, 2012, at 12:00 AM, Mark S. Miller wrote: > On Thu, Jan 5, 2012 at 11:47 PM, Allen Wirfs-Brock > wrote: >> >> 1) program using only ES3 features and no "use strict"; >> >> 2) program using only ES5 strict features and saying "use strict"; >> >> 3) program using ES6-only

Re: ES6 doesn't need opt-in

On Jan 5, 2012, at 10:38 PM, Luke Hoban wrote: > ... > # Why ‘implicit explicit opt-in’ doesn’t seem reasonable # > > The prevalent alternatives presented in this thread are variations of > “implicit explicit opt-in”, where use of some new syntax causes some part of > the code inside or outs

Re: ES6 doesn't need opt-in

On Thu, Jan 5, 2012 at 11:47 PM, Allen Wirfs-Brock wrote: > > 1) program using only ES3 features and no "use strict"; > > 2) program using only ES5 strict features and saying "use strict"; > > 3) program using ES6-only features. > > Do these three programs operate in three different mo

Re: ES6 doesn't need opt-in

On Jan 5, 2012, at 10:20 PM, Mark S. Miller wrote: > > > On Thu, Jan 5, 2012 at 10:13 PM, Allen Wirfs-Brock > wrote: > > On Jan 5, 2012, at 8:24 PM, Mark S. Miller wrote: > >> Hi Allen, if ES5 had only one mode, I'd understand this. But I thought we >> were trying to arrive at two modes, E

RE: ES6 doesn't need opt-in

Jumping in late, and possibly repeating some already covered ground, but this is clearly an important topic. Looking at all the proposals on these threads, I have to throw support behind Mark's proposal below, or a close variant of it as discussed below and in some of the other branches (I thin

Re: ES6 doesn't need opt-in

On Thu, Jan 5, 2012 at 10:13 PM, Allen Wirfs-Brock wrote: > > On Jan 5, 2012, at 8:24 PM, Mark S. Miller wrote: > > Hi Allen, if ES5 had only one mode, I'd understand this. But I thought we > were trying to arrive at two modes, ES6 non-strict, to be backwards compat > with ES5-non-strict, and ES6

Re: ES6 doesn't need opt-in

On Jan 5, 2012, at 8:24 PM, Mark S. Miller wrote: > Hi Allen, if ES5 had only one mode, I'd understand this. But I thought we > were trying to arrive at two modes, ES6 non-strict, to be backwards compat > with ES5-non-strict, and ES6 strict, to be backwards compat with ES5-strict. > I am perfe

Re: ES6 doesn't need opt-in

Hi Allen, if ES5 had only one mode, I'd understand this. But I thought we were trying to arrive at two modes, ES6 non-strict, to be backwards compat with ES5-non-strict, and ES6 strict, to be backwards compat with ES5-strict. I am perfectly happy to call ES6 non-strict "ES3", since ES5-non-strict r

Re: ES6 doesn't need opt-in

Here is a possible set of rules for implicitly assigning ES5 or ES6 semantics to a Program unit In an "ES6" implementation, all constructs that can occur in a valid program fit into one of these categories: ES6-only: The construct is based upon syntax or static semantics rules that only exist

Re: ES6 doesn't need opt-in

On Jan 5, 2012, at 8:30 AM, Axel Rauschmayer wrote: > On Jan 5, 2012, at 1:56 , Brendan Eich wrote: > >> Better to dispense with modes or ordered versions altogether, which is the >> key idea of the proposal. > > > So, simplified, the story is: > > - ES6 is a superset of ES5.strict. That's a

Re: ES6 doesn't need opt-in

On Jan 5, 2012, at 11:10 AM, Brendan Eich wrote: >> That precluded a number of highly undesirable >> combinations, e.g. extended mode nested into a "with" statement. > > You can "use strict"; in a with statement's body block. Sorry to be unclear, I meant examples such as this: js> with ({p:1})

Re: ES6 doesn't need opt-in

On Jan 5, 2012, at 9:30 AM, Allen Wirfs-Brock wrote: > A slightly different approach to this might be to say that the use of any new > syntax implies that the immediately surrounding function or program is in > strict mode. I'm favoring program currently, even if the new syntax is used in just

Re: ES6 doesn't need opt-in

On Jan 5, 2012, at 6:31 AM, Andreas Rossberg wrote: >>> explicit opt-in) >> >> No -- "use strict"; the string literal expression-statement is meaningless >> pre-ES5, ES5-strict in ES5, and redundant in Harmony code. > > You said earlier that we best rely on the meta tag for the script > topleve

Re: ES6 doesn't need opt-in

On Jan 4, 2012, at 11:38 PM, Mark S. Miller wrote: > In your suggestion, when an occurrence of destructuring (or any other new > syntax) is seen, what unit of code is then opting in to strict? Would it be > the nearest enclosing function, module, class, generator, or Program? I think > I'm war

Re: ES6 doesn't need opt-in

On Jan 5, 2012, at 1:56 , Brendan Eich wrote: > Better to dispense with modes or ordered versions altogether, which is the > key idea of the proposal. So, simplified, the story is: - ES6 is a superset of ES5.strict. - Therefore, as soon as we have ES6, ES5.strict code bases automatically becom

Re: ES6 doesn't need opt-in

On 4 January 2012 21:52, Brendan Eich wrote: > On Jan 4, 2012, at 4:23 AM, Andreas Rossberg wrote: > >> - Despite the superficial "fewer modes" mantra, it actually doesn't >> make the language simpler, but more complicated: instead of defining >> the semantics for Harmony features only for strict-

Re: ES6 doesn't need opt-in

On 4 January 2012 21:30, Brendan Eich wrote: >> In any case, even if we allow more features in classic mode > > Don't think of modes and you'll be grooving with the new proposal better ;-). Well, I'd say "syntactic context" is just a euphemism. Or maybe the other way round... /Andreas __

Re: ES6 doesn't need opt-in

On 4 January 2012 21:27, Brendan Eich wrote: > On Jan 4, 2012, at 4:12 AM, Andreas Rossberg wrote: >>> >>> Your (3) seemed to say "use module" was something distinct from (and also >>> implicit in, so a part but not the whole of what is declared by) module >>> declaration syntax. It's not -- as pr

Re: ES6 doesn't need opt-in

Considering all that, I can't help feeling that having a separate mode is cleaner, simpler, and easier to use. I think it also has more potential for providing a robust foundation for future evolution of the language. This last point -language evolution- is something that Haskellers have quite a

Re: ES6 doesn't need opt-in

In your suggestion, when an occurrence of destructuring (or any other new syntax) is seen, what unit of code is then opting in to strict? Would it be the nearest enclosing function, module, class, generator, or Program? I think I'm warming to the idea. I think having the opt-in unit be the destruc

Re: ES6 doesn't need opt-in

How does |use es6| help for es7? It doesn't, especially if es7 has runtime-incompatible changes (i.e., is not a superset). Better to dispense with modes or ordered versions altogether, which is the key idea of the proposal. /be Sent from my iPad On Jan 4, 2012, at 4:45 PM, Axel Rauschmayer w

Re: ES6 doesn't need opt-in

On Jan 4, 2012, at 4:12 PM, "Mark S. Miller" wrote: > The problem I see is that the occurrence of some of these new features, like > a light use of destructuring, may not be notationally obvious to readers. Maybe not, but for such users, strict mode may not be obviously a problem either. This

Re: ES6 doesn't need opt-in

I think I would prefer a simpler per-file approach. In light of having to do something like this again for ECMAScript.next.next how about the following? First line: - "use strict"; // before ES5: ignore; ES5: ES5.strict - use es6; // ES6: ES6 - module ? { is a synonym for use es6; With JS langu

Re: ES6 doesn't need opt-in

On Wed, Jan 4, 2012 at 1:07 PM, Brendan Eich wrote: [...] > See above. Function is implicitly strict. > I looked about and didn't see whatever I was supposed to notice. I would *love* for Function to be implicitly strict. But I have no idea how to do that without breaking the web. Function is a

Re: ES6 doesn't need opt-in

On Wed, Jan 4, 2012 at 1:00 PM, Brendan Eich wrote: > > Anyway, predictions aside, I do not agree we should require "use strict" > if the syntax speaks for itself. > Is anyone saying that we should require this? I'm not. This sub-thread started with Dave's "module" as opt-in suggestion and you a

Re: ES6 doesn't need opt-in

Hi Brendan, I agree with most of your message, so only commenting on the remainder. On Wed, Jan 4, 2012 at 12:52 PM, Brendan Eich wrote: [...] > > - After Dave's posting I foresaw people wanting implicit opt-in with > > other constructs, e.g. classes or uses of `import' -- and voila, we're > > a

Re: ES6 doesn't need opt-in

On Wed, Jan 4, 2012 at 12:16 PM, Brendan Eich wrote: > > And for classes. > "class" is unconditionally reserved, so there's no issue. > And for generators? > I like the idea of generators as yet another strict opt-in, even though recognizing "function*" is technically an example of the "prev

Re: ES6 doesn't need opt-in

On Wed, Jan 4, 2012 at 9:35 AM, Allen Wirfs-Brock wrote: > On Jan 4, 2012, at 8:39 AM, Mark S. Miller wrote: > [...] > BTW, The simplest way to work around these issues, that I've found, would > be to say that any function that uses any new formal parameter syntax is > implicitly a strict mode f

Re: ES6 doesn't need opt-in

On Wed, Jan 4, 2012 at 9:24 AM, Andreas Rossberg wrote: > On 4 January 2012 17:39, Mark S. Miller wrote: > [...] > >> Style guides will probably > >> suggest to put "use strict" on top of every Harmony program to escape > >> the mess. > > > > Every sane style guide will do so. And every linting

Re: ES6 doesn't need opt-in

On Jan 4, 2012, at 9:35 AM, Allen Wirfs-Brock wrote: > On Jan 4, 2012, at 8:39 AM, Mark S. Miller wrote: > >> ... >> >> Here's an interesting compromise I consider perfectly reasonable. We don't >> *mandate* any ES6 code features be available in ES6 non-strict mode. But we >> don't prohibit th

Re: ES6 doesn't need opt-in

On Jan 4, 2012, at 8:39 AM, Mark S. Miller wrote: > Here's an interesting compromise I consider perfectly reasonable. We don't > *mandate* any ES6 code features be available in ES6 non-strict mode. But we > don't prohibit them either. For any ES6 features that have no dependence on > mode, like

Re: ES6 doesn't need opt-in

On Jan 4, 2012, at 12:50 PM, Allen Wirfs-Brock wrote: > On Jan 4, 2012, at 12:16 PM, Brendan Eich wrote: > >> ... >> >> Any new Harmony syntax that presents no backward incompatibility *and* has a >> body opts the body into the new edition, a superset of ES5-strict. >> > > Including expressio

Re: ES6 doesn't need opt-in

On Jan 4, 2012, at 4:23 AM, Andreas Rossberg wrote: > - Despite the superficial "fewer modes" mantra, it actually doesn't > make the language simpler, but more complicated: instead of defining > the semantics for Harmony features only for strict-mode programs, we > now have to define many features

Re: ES6 doesn't need opt-in

On Jan 4, 2012, at 12:16 PM, Brendan Eich wrote: > ... > > Any new Harmony syntax that presents no backward incompatibility *and* has a > body opts the body into the new edition, a superset of ES5-strict. > Including expression level bodies such a block lambda's or Dave's do { } expressions,

Re: ES6 doesn't need opt-in

On Jan 4, 2012, at 4:12 AM, Andreas Rossberg wrote: > 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 Da

Re: ES6 doesn't need opt-in

On Jan 4, 2012, at 4:12 AM, Andreas Rossberg wrote: >> Your (3) seemed to say "use module" was something distinct from (and also >> implicit in, so a part but not the whole of what is declared by) module >> declaration syntax. It's not -- as proposed, it's an alternative to explicit >> anonymou

Re: ES6 doesn't need opt-in

On Jan 3, 2012, at 11:29 PM, Mark S. Miller wrote: > 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 s

Re: ES6 doesn't need opt-in

On Jan 4, 2012, at 8:39 AM, Mark S. Miller wrote: > ... > > Here's an interesting compromise I consider perfectly reasonable. We don't > *mandate* any ES6 code features be available in ES6 non-strict mode. But we > don't prohibit them either. For any ES6 features that have no dependence on >

Re: ES6 doesn't need opt-in

On 4 January 2012 17:39, Mark S. Miller wrote: > Here's an interesting compromise I consider perfectly reasonable. We don't > *mandate* any ES6 code features be available in ES6 non-strict mode. But we > don't prohibit them either. For any ES6 features that have no dependence on > mode, like destr

Re: ES6 doesn't need opt-in

Wirfs-Brock Sent: Wednesday, January 04, 2012 6:08 PM To: Andreas Rossberg Cc: Mark S. Miller ; Brendan Eich ; es-discuss Steen Subject: Re: ES6 doesn't need opt-in On Jan 4, 2012, at 4:23 AM, Andreas Rossberg wrote: ... - Despite the superficial "fewer modes" mantra, it actually d

Re: ES6 doesn't need opt-in

On Jan 4, 2012, at 4:23 AM, Andreas Rossberg wrote: > ... > > - Despite the superficial "fewer modes" mantra, it actually doesn't > make the language simpler, but more complicated: instead of defining > the semantics for Harmony features only for strict-mode programs, we > now have to define man

Re: ES6 doesn't need opt-in

On Wed, Jan 4, 2012 at 8:39 AM, Mark S. Miller wrote: > On Wed, Jan 4, 2012 at 4:23 AM, Andreas Rossberg wrote: > >> >> [...] > Here's an interesting compromise I consider perfectly reasonable. We don't > *mandate* any ES6 code features be available in ES6 non-strict mode. But we > don't prohibi

Re: ES6 doesn't need opt-in

On Jan 4, 2012, at 13:23 , Andreas Rossberg wrote: > Considering all that, I can't help feeling that having a separate mode > is cleaner, simpler, and easier to use. I think it also has more > potential for providing a robust foundation for future evolution of > the language. Taking a step back

Re: ES6 doesn't need opt-in

On Wed, Jan 4, 2012 at 4:23 AM, Andreas Rossberg wrote: > 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

  1   2   >