2012/1/10 Herby Vojčík he...@mailbox.sk:
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
On 9 January 2012 21:37, Gavin Barraclough barraclo...@apple.com 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
: 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://wiki.ecmascript.org/doku.php?id
-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 and the prototype chain is fallback
delegation mindset. Though I knew of Self and knew
should be allowed; and inability to do it is
indeed an error.
Herby
-Pôvodná správa- From: 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
On 6 January 2012 03:37, Allen Wirfs-Brock al...@wirfs-brock.com 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:
On Jan 9, 2012, at 2:49 AM, Andreas Rossberg wrote:
On 5 January 2012 20:10, Brendan Eich bren...@mozilla.com 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
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
On 9 January 2012 16:54, Brendan Eich bren...@mozilla.com 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,
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 bren...@mozilla.com wrote:
[...]
All cool with the above. Thanks.
I wrote in a previous reply that we aren't preserving ES5 as a spec
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 your
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://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake.
Right now, because of pressure from test262, we are 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
On Sat, Jan 7, 2012 at 11:05 PM, Brendan Eich bren...@mozilla.com 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,
On Sun, Jan 8, 2012 at 8:15 AM, Brendan Eich bren...@mozilla.com wrote:
On Jan 8, 2012, at 8:10 AM, Mark S. Miller wrote:
On Sat, Jan 7, 2012 at 11:05 PM, Brendan Eich bren...@mozilla.com wrote:
[...]
so are we really just arguing about names or labels? If so, great --
those are important
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
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 about
On Sun, Jan 8, 2012 at 10:32 AM, Brendan Eich bren...@mozilla.com 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.
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 doesn't need opt-in
Axel, thanks. This is the critical point, so no apologies needed for
belaboring.
Allen
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
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 increase
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
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
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 ES6
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 fewer
On Jan 7, 2012, at 11:05 PM, Brendan Eich wrote:
Allen has 56, 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 completion
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 required
On Jan 8, 2012, at 8:05 , Brendan Eich wrote:
Allen has 56, 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!
Isn’t
On Thu, Jan 5, 2012 at 11:47 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
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
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 outside
On Jan 6, 2012, at 12:00 AM, Mark S. Miller wrote:
On Thu, Jan 5, 2012 at 11:47 PM, Allen Wirfs-Brock al...@wirfs-brock.com
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
On Fri, Jan 6, 2012 at 12:24 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
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
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 describe an
-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
wouldn’t
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
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.
For
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 al...@wirfs-brock.comwrote:
On Jan 6, 2012, at 8:03 AM, Mark S. Miller wrote:
No sorry, I just spotted the flaw. The observable
(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 assignment
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
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
Rather, we should minimize the state machine and how we talk about it. We
could generalize it using Curr, Next, CurrNext, 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
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. For
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, CurrNext, and Curr-Next labels.
I’m awfully sorry for belaboring this point. But the labels and the quote
below don’t go
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 super set of ES5
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-strict
ES5
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
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
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.
On Fri, Jan 6, 2012 at 12:25 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
[...]
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.
On Fri, Jan 6, 2012 at 12:29 PM, Brendan Eich bren...@mozilla.com 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, CurrNext, and Curr-Next labels.
I’m awfully sorry
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
On 4 January 2012 21:27, Brendan Eich bren...@mozilla.com 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 --
On 4 January 2012 21:30, Brendan Eich bren...@mozilla.com 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...
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 become
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
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
toplevel, which
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
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 always been
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
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
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
On Thu, Jan 5, 2012 at 10:13 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
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
: Tuesday, January 03, 2012 1:24 PM
To: Allen Wirfs-Brock
Cc: Brendan Eich; es-discuss Steen
Subject: 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
On Jan 5, 2012, at 10:20 PM, Mark S. Miller wrote:
On Thu, Jan 5, 2012 at 10:13 PM, Allen Wirfs-Brock al...@wirfs-brock.com
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
On 3 January 2012 21:18, Brendan Eich bren...@mozilla.com wrote:
On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote:
On 3 January 2012 07:19, Brendan Eich bren...@mozilla.com wrote:
On Jan 2, 2012, at 6:07 AM, Andreas Rossberg wrote:
In other words, I think the main points of your proposal
On 3 January 2012 21:01, Brendan Eich bren...@mozilla.com wrote:
On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote:
On 3 January 2012 07:21, Brendan Eich bren...@mozilla.com wrote:
The top level is hard. The only way to be sure is to use pure lexical scope
(in Dave's proposal, use module
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)
On Wed, Jan 4, 2012 at 4:23 AM, Andreas Rossberg rossb...@google.comwrote:
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
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
On Wed, Jan 4, 2012 at 8:39 AM, Mark S. Miller erig...@google.com wrote:
On Wed, Jan 4, 2012 at 4:23 AM, Andreas Rossberg rossb...@google.comwrote:
[...]
Here's an interesting compromise I consider perfectly reasonable. We don't
*mandate* any ES6 code features be available in ES6
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
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 doesn't
make
On 4 January 2012 17:39, Mark S. Miller erig...@google.com 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
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,
On Jan 3, 2012, at 11:29 PM, Mark S. Miller wrote:
On Tue, Jan 3, 2012 at 10:18 PM, Brendan Eich bren...@mozilla.com 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
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
anonymous
On Jan 4, 2012, at 4:12 AM, Andreas Rossberg wrote:
On 3 January 2012 21:01, Brendan Eich bren...@mozilla.com wrote:
On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote:
On 3 January 2012 07:21, Brendan Eich bren...@mozilla.com wrote:
The top level is hard. The only way to be sure is to use
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, if
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 for
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 expression level
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
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 them either.
On Wed, Jan 4, 2012 at 9:24 AM, Andreas Rossberg rossb...@google.comwrote:
On 4 January 2012 17:39, Mark S. Miller erig...@google.com 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
On Wed, Jan 4, 2012 at 9:35 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
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
On Wed, Jan 4, 2012 at 12:16 PM, Brendan Eich bren...@mozilla.com 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
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 bren...@mozilla.com wrote:
[...]
- After Dave's posting I foresaw people wanting implicit opt-in with
other constructs, e.g. classes or uses of `import' -- and
On Wed, Jan 4, 2012 at 1:00 PM, Brendan Eich bren...@mozilla.com 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
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 ident? { is a synonym for use es6;
With JS
On Jan 4, 2012, at 4:12 PM, Mark S. Miller erig...@google.com 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
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
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
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
?? would work better than ? in JavaScript, because it wouldn’t clash with the
conditional operator in JavaScript
Wouldn't it be possible to use a single '?' for all of them (the conditional,
default and existential operators) and disambiguate between them according to
the way they're
On 3 January 2012 07:21, Brendan Eich bren...@mozilla.com wrote:
It's not obvious if the static scope is built up from sript element to
successive script element, either. Must I read all the scripts? The
conditionally generated ones too?
The top level is hard. The only way to be sure is to
On 3 January 2012 07:19, Brendan Eich bren...@mozilla.com 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
On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote:
On 3 January 2012 07:21, Brendan Eich bren...@mozilla.com wrote:
It's not obvious if the static scope is built up from sript element to
successive script element, either. Must I read all the scripts? The
conditionally generated ones too?
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 extended
,
comprehensions, generator expresions, quasiliterals, more.
Yes, but that is a totally independent choice.
There are several independent choices bundled into this new ES6 doesn't need
opt-in proposal, but the unifying theme is this: new features that pose no
backward incompatibility hardship
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 be able to
write
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 paranoia we
1 - 100 of 140 matches
Mail list logo
