Re: ES6 doesn't need opt-in

[liorean]

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 of equivocation. The
localisation when reading from or writing to a property is a matter of
the value contained in that slot. The access or write permission of
that property is a matter of the actual slot.

-- 
David "liorean" Andersson
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Herby Vojčík]

Hello,

so I looked up the spec. I never remembered the exact [[Put]], [[Get]] 
machinery but now it is obvious that ES has in fact "amalgamate" mental 
model of "shared-part always-use-setter-for-assignment having shadowing 
default setter" (well, I figured that out before looking at spec by just 
reverse engineering actual state, but then I looked up). So, really, 
http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake is 
not an error. But so is not the Object.defineProperty that is able to create 
own property. Assignment is assignment, setting own property is different, 
low-level thing. At least as I see it.


Herby

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.


-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
is shared part of bar.x, but then you _cannot_ have "own" shadowing
preoperties and plain "bar.x = 5" behaviour of current implementations is
inconsistent;
or we have "own overlaying properties with property chain search" (which I
dubbed "fallback delegation") mental model, in which bar.x = 5 make perfect
sense, but alas not only in writable foo.x scenario, but every time (even if
foo.x does not exist or if foo.x is read-only), so prohibiting it for
read-only foo.x is inconstitency.

So, we have inconsistency anyway, the question is which one to fix (and I am
pretty sure not the first one).

Herby

P.S.: Yes, you can construct a complicated mental model amalgamate, like
"shared part with explicit allowance for per-child-subtree-shadowing". 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.


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Herby Vojčík]

===
In your example |foo| is not an inheriting child object. It is the parent.

jjb
===

Yes. It is correct. This is what the subdiscussion is about, is it not? 
Allen said it is not an error to prohibit bar.x = 5 if foo.x is read-only 
and argument that foo.x (foo is parent, bar is child) is shared part.


And I'm saying it is falsy to argument with "x is shared part of bar through 
parent foo" because then bar.x - 5 must change foo.x but it does not. 
Creating "own" properties is breaking "shared part". Since there are "own" 
shadowing properites, the model must not be "shared part", but something 
other, which allows "own", shadowing properties. In such a model it makes 
perfect sense to allow bar.x = 5 without regard to foo.x readonliness. 
Prohibiting it is in fact something that is inconsistent with the mental 
model.


So, to sum, either we have "self shared part" mental model, in which foo.x 
is shared part of bar.x, but then you _cannot_ have "own" shadowing 
preoperties and plain "bar.x = 5" behaviour of current implementations is 
inconsistent;
or we have "own overlaying properties with property chain search" (which I 
dubbed "fallback delegation") mental model, in which bar.x = 5 make perfect 
sense, but alas not only in writable foo.x scenario, but every time (even if 
foo.x does not exist or if foo.x is read-only), so prohibiting it for 
read-only foo.x is inconstitency.


So, we have inconsistency anyway, the question is which one to fix (and I am 
pretty sure not the first one).


Herby

P.S.: Yes, you can construct a complicated mental model amalgamate, like 
"shared part with explicit allowance for per-child-subtree-shadowing". 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čík
Cc: Allen Wirfs-Brock ; Brendan Eich ; Mark S. Miller ; es-discuss Steen
Subject: Re: ES6 doesn't need opt-in




On Tue, Jan 10, 2012 at 5:38 AM, Herby Vojčík  wrote:
Hello again!

Sorry to reply my own post, but I came to the conclusion that "Self-like 
shared part" simply cannot work as an argument (and that not to be able to 
override read-only property from the prototype _is_, indeed, an error).


If the "shared part" mind-set was the cornerstone of ES, then this:

foo = { x:4 };
bar = Object.create(foo);
bar.x = 5;
return foo.x;

would yield 5. After all, x is shared part of bar and foo.

But every knows that it yield 4. bar has its own x holding 5, foo has his 
own holding 4.

So as for this:

=== Allen Wirfs-Brock wrote ===

The basic idea is that the properties prototype object are shared parts of
all of inheriting child object.


In your example |foo| is not an inheriting child object. It is the parent.

jjb



Modifying such a shared part by a child,
introduces a local change that is visible to that child (and its children)
so this requires creation of a "own" property on the child. However,
read-only properties can not modified  ...
===

I can only reply with "if the prototype is the shared part as per Self 
mindset, you cannot create "own" property at all". In previous example, x is 
the shared part. Above statement bar.x = 5 would change foo.x (since it is 
the shared x).


So I think the model in Javascript is "fallback delegation" and creation of 
own property by Object.defineProperty is not an error; and creation of own 
property by assignment 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. 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 it had an impact on
Javascript creation, I had always an impression that in Javascript (having
become ECMAScript) it was 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: Brendan Eich
Cc: Mark S. Miller ; es-discuss Steen
Subject: Re: ES6 doesn't need opt-in

...


Just to be even clearer.  This was not a mistake in ES5/5.1 and it is not a
bug.  It is a semantics, which as Brendan points out goes all the way back
to ES1.  It is also a behavior which makes complete sense from a prototypal
inheritance perspective and can be fo

Re: ES6 doesn't need opt-in

[John J Barton]

On Tue, Jan 10, 2012 at 5:38 AM, Herby Vojčík  wrote:

> Hello again!
>
> Sorry to reply my own post, but I came to the conclusion that "Self-like
> shared part" simply cannot work as an argument (and that not to be able to
> override read-only property from the prototype _is_, indeed, an error).
>
> If the "shared part" mind-set was the cornerstone of ES, then this:
>
> foo = { x:4 };
> bar = Object.create(foo);
> bar.x = 5;
> return foo.x;
>
> would yield 5. After all, x is shared part of bar and foo.
>
> But every knows that it yield 4. bar has its own x holding 5, foo has his
> own holding 4.
> So as for this:
>
> === Allen Wirfs-Brock wrote ===
>
> The basic idea is that the properties prototype object are shared parts of
> all of inheriting child object.
>

In your example |foo| is not an inheriting child object. It is the parent.

jjb



> Modifying such a shared part by a child,
> introduces a local change that is visible to that child (and its children)
> so this requires creation of a "own" property on the child. However,
> read-only properties can not modified  ...
> ===
>
> I can only reply with "if the prototype is the shared part as per Self
> mindset, you cannot create "own" property at all". In previous example, x
> is the shared part. Above statement bar.x = 5 would change foo.x (since it
> is the shared x).
>
> So I think the model in Javascript is "fallback delegation" and creation
> of own property by Object.defineProperty is not an error; and creation of
> own property by assignment 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. 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 it had an impact on
> Javascript creation, I had always an impression that in Javascript (having
> become ECMAScript) it was 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: Brendan Eich
> Cc: Mark S. Miller ; es-discuss Steen
> Subject: Re: ES6 doesn't need opt-in
>
> ...
>
>
> Just to be even clearer.  This was not a mistake in ES5/5.1 and it is not a
> bug.  It is a semantics, which as Brendan points out goes all the way back
> to ES1.  It is also a behavior which makes complete sense from a prototypal
> inheritance perspective and can be found in the Self language.
>
> The basic idea is that the properties prototype object are shared parts of
> all of inheriting child object.  Modifying such a shared part by a child,
> introduces a local change that is visible to that child (and its children)
> so this requires creation of a "own" property on the child. However,
> read-only properties can not modified (by normal means, eg assignment) so
> there is no need to create a "own" copy.  Assigning to an inherited
> read-only property or a "own" read-only property should have the same
> affect
> (whether it is ignoring the assignment, throwing, etc.).  Allowing
> assignment to an inherited read-only property would break the invariant
> that
> that a prototype's readonly property is an immutable value that is  shared
> among all children of the prototype.
>
> If there was a mistake in designing ES5, it was allowing
> Object.defineOwnProperty to create child properties that over-ride
> inherited
> read-only data properties.  This broke an invariant that previously existed
> in the language but this invariant  was already violated by some pre-ES5
> clause 15 objects, (eg the writability of the prototype property of some
> children of Function.prototype).  However, I think the ES5 decision was
> probably the right one given the legacy clause 15 usages and the overall
> reflective nature of defineOwnProperty).
>
> Allen
>
> __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Andreas Rossberg]

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
> .
> Right now, because of pressure from test262, we are in danger of having all
> browsers conform to this mistake, at which point it may be too late to fix
> it. Today, the diversity of actual browser behaviors means it is still
> possible to fix this mistake, much as the diversity of ways ES3
> implementations were broken made it possible for ES5 to fix many mistakes.
>
>
> The [[CanPut]] check goes back to ES1, though. Recent-ish deviations in JSC
> and (because V8 was drafting off JSC) V8 don't nullify all that history.
>
> On the other hand, JSC and V8 are doing fine AFAIK. It's hard to make a
> real-world case where this matters, even with Object.create. And I see the
> ocap (not just SES) appeal of the fix.
>
>
> Just to be even clearer.  This was not a mistake in ES5/5.1 and it is not a
> bug.  It is a semantics, which as Brendan points out goes all the way back
> to ES1.  It is also a behavior which makes complete sense from a prototypal
> inheritance perspective and can be found in the Self language.

I admit being almost completely ignorant about the history, but I
always found this behaviour more than weird. In an ideal world,
shouldn't lookup and immutability be two orthogonal mechanisms? That
is, either all assignments override (data properties), or none.

> The basic idea is that the properties prototype object are shared parts of
> all of inheriting child object.  Modifying such a shared part by a child,
> introduces a local change that is visible to that child (and its children)
> so this requires creation of a "own" property on the child. However,
> read-only properties can not modified (by normal means, eg assignment) so
> there is no need to create a "own" copy.  Assigning to an inherited
> read-only property or a "own" read-only property should have the same affect
> (whether it is ignoring the assignment, throwing, etc.).  Allowing
> assignment to an inherited read-only property would break the invariant that
> that a prototype's readonly property is an immutable value that is  shared
> among all children of the prototype.

Can you elaborate why you are making a special case for immutable
properties? Allowing overriding of a writeable property likewise
breaks the sharing "invariant". Why should it apply to read-only
properties specifically?

Your argument, if I understand it correctly, is that immutability is
part of the contract of a prototype, and that contract should be
inherited by children. Informally, that contract says:

  Reading this property, through the prototype or any of its children,
always returns the same value. Writing to it is an error.

But what is the corresponding contract of a mutable property? AFAICT, it is:

  Reading this property, through the prototype or any of its children,
always returns the last value that has been written to it.

And that is broken by overriding in the same way as the contract for
immutable properties.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Herby Vojčík]

Hello again!

Sorry to reply my own post, but I came to the conclusion that "Self-like 
shared part" simply cannot work as an argument (and that not to be able to 
override read-only property from the prototype _is_, indeed, an error).


If the "shared part" mind-set was the cornerstone of ES, then this:

foo = { x:4 };
bar = Object.create(foo);
bar.x = 5;
return foo.x;

would yield 5. After all, x is shared part of bar and foo.

But every knows that it yield 4. bar has its own x holding 5, foo has his 
own holding 4.

So as for this:

=== Allen Wirfs-Brock wrote ===
The basic idea is that the properties prototype object are shared parts of
all of inheriting child object.  Modifying such a shared part by a child,
introduces a local change that is visible to that child (and its children)
so this requires creation of a "own" property on the child. However,
read-only properties can not modified  ...
===

I can only reply with "if the prototype is the shared part as per Self 
mindset, you cannot create "own" property at all". In previous example, x is 
the shared part. Above statement bar.x = 5 would change foo.x (since it is 
the shared x).


So I think the model in Javascript is "fallback delegation" and creation of 
own property by Object.defineProperty is not an error; and creation of own 
property by assignment 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. 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 it had an impact on
Javascript creation, I had always an impression that in Javascript (having
become ECMAScript) it was 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: Brendan Eich
Cc: Mark S. Miller ; es-discuss Steen
Subject: Re: ES6 doesn't need opt-in

...

Just to be even clearer.  This was not a mistake in ES5/5.1 and it is not a
bug.  It is a semantics, which as Brendan points out goes all the way back
to ES1.  It is also a behavior which makes complete sense from a prototypal
inheritance perspective and can be found in the Self language.

The basic idea is that the properties prototype object are shared parts of
all of inheriting child object.  Modifying such a shared part by a child,
introduces a local change that is visible to that child (and its children)
so this requires creation of a "own" property on the child. However,
read-only properties can not modified (by normal means, eg assignment) so
there is no need to create a "own" copy.  Assigning to an inherited
read-only property or a "own" read-only property should have the same affect
(whether it is ignoring the assignment, throwing, etc.).  Allowing
assignment to an inherited read-only property would break the invariant that
that a prototype's readonly property is an immutable value that is  shared
among all children of the prototype.

If there was a mistake in designing ES5, it was allowing
Object.defineOwnProperty to create child properties that over-ride inherited
read-only data properties.  This broke an invariant that previously existed
in the language but this invariant  was already violated by some pre-ES5
clause 15 objects, (eg the writability of the prototype property of some
children of Function.prototype).  However, I think the ES5 decision was
probably the right one given the legacy clause 15 usages and the overall
reflective nature of defineOwnProperty).

Allen

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Herby Vojčík]

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 it had an impact on 
Javascript creation, I had always an impression that in Javascript (having 
become ECMAScript) it was 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: 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://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake>. 
Right now, because of pressure from test262, we are in danger of having all 
browsers conform to this mistake, at which point it may be too late to fix 
it. Today, the diversity of actual browser behaviors means it is still 
possible to fix this mistake, much as the diversity of ways ES3 
implementations were broken made it possible for ES5 to fix many mistakes.



The [[CanPut]] check goes back to ES1, though. Recent-ish deviations in JSC 
and (because V8 was drafting off JSC) V8 don't nullify all that history.


On the other hand, JSC and V8 are doing fine AFAIK. It's hard to make a 
real-world case where this matters, even with Object.create. And I see the 
ocap (not just SES) appeal of the fix.




Just to be even clearer.  This was not a mistake in ES5/5.1 and it is not a 
bug.  It is a semantics, which as Brendan points out goes all the way back 
to ES1.  It is also a behavior which makes complete sense from a prototypal 
inheritance perspective and can be found in the Self language.


The basic idea is that the properties prototype object are shared parts of 
all of inheriting child object.  Modifying such a shared part by a child, 
introduces a local change that is visible to that child (and its children) 
so this requires creation of a "own" property on the child. However, 
read-only properties can not modified (by normal means, eg assignment) so 
there is no need to create a "own" copy.  Assigning to an inherited 
read-only property or a "own" read-only property should have the same affect 
(whether it is ignoring the assignment, throwing, etc.).  Allowing 
assignment to an inherited read-only property would break the invariant that 
that a prototype's readonly property is an immutable value that is  shared 
among all children of the prototype.


If there was a mistake in designing ES5, it was allowing 
Object.defineOwnProperty to create child properties that over-ride inherited 
read-only data properties.  This broke an invariant that previously existed 
in the language but this invariant  was already violated by some pre-ES5 
clause 15 objects, (eg the writability of the prototype property of some 
children of Function.prototype).  However, I think the ES5 decision was 
probably the right one given the legacy clause 15 usages and the overall 
reflective nature of defineOwnProperty).


Allen










___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss 


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Andreas Rossberg]

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 but does not include
>> it (e.g. throws out `with'). Then your "state machine" simply says,
>> declaratively:
>>
>> - If a program is ES5 but not ES6, treat as ES5.
>> - If a program is ES6 but not ES5, treat as ES6.
>> - If a program is both ES5 and ES6, with identical semantics, treat as
>> ES6 (although it doesn't matter).
>> - If a program is both ES5 and ES6, with different semantics, treat as
>> ES5 (for compatibility).
>> - If a program is neither ES5 nor ES6, it's an error (obviously).
>
> If the a program is both ES5 and ES6 with identical semantics, then
> presumably we could equally treat it as ES5 with no behavior change?
> If so, couldn't this be stated in a much simpler fashion:
>
> - If a program is ES5, treat as ES5.
> - If a program is not ES5 but is ES6, treat as ES6.
> - If a program is neither ES5 nor ES6, it's an error (obviously).

Indeed, that is even more to the point.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 
codebases. Mozilla's won't. So that means the spec will be the only 
unconsolidated "implementation".

Yes, new features (especially around parameters) may combine with old 
(arguments). Let's do the case analysis and see how bad this must be. I think 
it's strictly less bad on balance, weighing the cost to implementors, than 
forking.

Forking the spec also raises the risk of more incompatible changes than those 
(few, almost none) that we intended. I'd rather bail on completion reform back 
to ES5 strict runtime semantics if that is what it takes to keep a 
consolidated/minimized spec.

/be

On Jan 9, 2012, at 12:09 PM, Allen Wirfs-Brock wrote:

> 
> 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 
>>> 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 still don't understand what your plan 
>>> for ES6 is. Does the ES6 spec include the state machine and an updated form 
>>> of the ES5-non-strict portions of the ES5 spec, as referenced by that state 
>>> machine?
>> 
>> I defer to Allen, but one approach is to leave ES5-nonstrict as is, and 
>> combine strict and extended modes for the "6" in 5&6 and ES56. As you 
>> proposed!
>> 
>> HTH,
>> 
>> /be
>> 
> 
> I've been thinking about this, but I'm not yet certain about a preferred 
> approach.
> 
> One alternative is to keep the current ES5 specification( both non-strict and 
> strict) as a normative part of ECMA-262 and add a new part which is the 
> complete specification for "ES6".  Essentially Ecma-262-6 part 1 would be the 
> same as Ecma-262-5 (plus any errata level corrections) but excluding most of 
> clause 15 (the builty-in library) and Ecma-262-9 part 2 would be a 
> comprehensive specification for a language that starts with implicit ES5 
> strict mode (modulo completion reform and any other semantic changes) add new 
> ES6 features and excludes ES5 "non-strict" features and semantics.  Because 
> of the shared heap, the new clause 15 would have to apply to both the part 1 
> and part 2 languages.  The specification would have to include something like 
> my state machine which determines whether the part 1 or part 2 language is to 
> be used to process a Program.
> 
> This approach has the advantage that it simplifies the specification of the 
> new ES6 features and minimizes the risk of unintentionally changing the 
> specification of ES-5 non-strict features that must exist somewhere in the 
> specification. I'm finding various places where significant changes in 
> specification technique is required to support new feature semantics and 
> making sure that  the rewritten specification also works for legacy 
> (non-strict ES5).   However, this approach has the disadvantage that 
> implementors who what to share as much logic as possible between "ES5 mode" 
> and "ES6 mode" many have to do their own analysis of the differences and 
> commonalities.
> 
> Allen
> 
> 
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

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 are in danger of having all 
>> browsers conform to this mistake, at which point it may be too late to fix 
>> it. Today, the diversity of actual browser behaviors means it is still 
>> possible to fix this mistake, much as the diversity of ways ES3 
>> implementations were broken made it possible for ES5 to fix many mistakes.
> 
> The [[CanPut]] check goes back to ES1, though. Recent-ish deviations in JSC 
> and (because V8 was drafting off JSC) V8 don't nullify all that history.
> 
> On the other hand, JSC and V8 are doing fine AFAIK. It's hard to make a 
> real-world case where this matters, even with Object.create. And I see the 
> ocap (not just SES) appeal of the fix.
> 

Just to be even clearer.  This was not a mistake in ES5/5.1 and it is not a 
bug.  It is a semantics, which as Brendan points out goes all the way back to 
ES1.  It is also a behavior which makes complete sense from a prototypal 
inheritance perspective and can be found in the Self language. 

The basic idea is that the properties prototype object are shared parts of all 
of inheriting child object.  Modifying such a shared part by a child, 
introduces a local change that is visible to that child (and its children) so 
this requires creation of a "own" property on the child. However, read-only 
properties can not modified (by normal means, eg assignment) so there is no 
need to create a "own" copy.  Assigning to an inherited read-only property or a 
"own" read-only property should have the same affect (whether it is ignoring 
the assignment, throwing, etc.).  Allowing assignment to an inherited read-only 
property would break the invariant that that a prototype's readonly property is 
an immutable value that is  shared among all children of the prototype.

If there was a mistake in designing ES5, it was allowing 
Object.defineOwnProperty to create child properties that over-ride inherited 
read-only data properties.  This broke an invariant that previously existed in 
the language but this invariant  was already violated by some pre-ES5 clause 15 
objects, (eg the writability of the prototype property of some children of 
Function.prototype).  However, I think the ES5 decision was probably the right 
one given the legacy clause 15 usages and the overall reflective nature of 
defineOwnProperty).

Allen





___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Gavin Barraclough]

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 "state machine" simply says,
> declaratively:
> 
> - If a program is ES5 but not ES6, treat as ES5.
> - If a program is ES6 but not ES5, treat as ES6.
> - If a program is both ES5 and ES6, with identical semantics, treat as
> ES6 (although it doesn't matter).
> - If a program is both ES5 and ES6, with different semantics, treat as
> ES5 (for compatibility).
> - If a program is neither ES5 nor ES6, it's an error (obviously).

If the a program is both ES5 and ES6 with identical semantics, then presumably 
we could equally treat it as ES5 with no behavior change?

If so, couldn't this be stated in a much simpler fashion:

- If a program is ES5, treat as ES5.
- If a program is not ES5 but is ES6, treat as ES6.
- If a program is neither ES5 nor ES6, it's an error (obviously).

cheers,
G.


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

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 
>> 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 still don't understand what your plan 
>> for ES6 is. Does the ES6 spec include the state machine and an updated form 
>> of the ES5-non-strict portions of the ES5 spec, as referenced by that state 
>> machine?
> 
> I defer to Allen, but one approach is to leave ES5-nonstrict as is, and 
> combine strict and extended modes for the "6" in 5&6 and ES56. As you 
> proposed!
> 
> HTH,
> 
> /be
> 

I've been thinking about this, but I'm not yet certain about a preferred 
approach.

One alternative is to keep the current ES5 specification( both non-strict and 
strict) as a normative part of ECMA-262 and add a new part which is the 
complete specification for "ES6".  Essentially Ecma-262-6 part 1 would be the 
same as Ecma-262-5 (plus any errata level corrections) but excluding most of 
clause 15 (the builty-in library) and Ecma-262-9 part 2 would be a 
comprehensive specification for a language that starts with implicit ES5 strict 
mode (modulo completion reform and any other semantic changes) add new ES6 
features and excludes ES5 "non-strict" features and semantics.  Because of the 
shared heap, the new clause 15 would have to apply to both the part 1 and part 
2 languages.  The specification would have to include something like my state 
machine which determines whether the part 1 or part 2 language is to be used to 
process a Program.

This approach has the advantage that it simplifies the specification of the new 
ES6 features and minimizes the risk of unintentionally changing the 
specification of ES-5 non-strict features that must exist somewhere in the 
specification. I'm finding various places where significant changes in 
specification technique is required to support new feature semantics and making 
sure that  the rewritten specification also works for legacy (non-strict ES5).  
 However, this approach has the disadvantage that implementors who what to 
share as much logic as possible between "ES5 mode" and "ES6 mode" many have to 
do their own analysis of the differences and commonalities.

Allen



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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-strict semantic changes, e.g. arguments aliasing, without early 
>> errors.
>> 
>> 2. Completion reform.
>> 
>> 3. New early errors.
>> 
>> I think 3 is a good thing and a non-problem. Some of us hope 2 is a matter 
>> of indifference to real-world code, but we don't know for sure. That leaves 
>> 1.
> 
> Yes, but (1) is not a trivial set -- e.g. receiver coercions, eval
> semantics, delete type errors, arguments aliasing, poisoning of
> caller/arguments, etc.

You're right, there's a lot of runtime meaning shift in ES5-strict, indeed -- 
more than just parameter no-aliasing.

Still the bet we are trying to place (not done yet detailing the proposal) is 
that most people won't use explicit version-based opt-in (also, such noise gets 
lost easily over the life of code snippets), *and* that the hard cases you cite 
are rare. None is common.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Andreas Rossberg]

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 errors.
>
> 2. Completion reform.
>
> 3. New early errors.
>
> I think 3 is a good thing and a non-problem. Some of us hope 2 is a matter of 
> indifference to real-world code, but we don't know for sure. That leaves 1.

Yes, but (1) is not a trivial set -- e.g. receiver coercions, eval
semantics, delete type errors, arguments aliasing, poisoning of
caller/arguments, etc.

> No other semantic changes, right? The key idea of the state machine is not 
> its exact spec (still being discussed) but that "one JS" should mean sane 
> operation or early error, based on smooth upgrade to use non-conflicting new 
> features (or conflicts, e.g. 'with' vs. 'module').
>
> Why work harder on implicit opt-in? Yes, savvy users will put a pragma on 
> line 1. Not all JS users are savvy and requiring them to become so asks too 
> much.

But it's especially the non-savvy ones that would be particularly
well-advised to put in that pragma, so that they avoid nasty surprises
beyond their grasp!

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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

I should have written more, since "without early errors" is an assumption, not 
a requirement. Allen's state machine o.p discussed this more. From Allen's o.p.:

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 to the corresponding element of the function's arguments 
object.

This triggers different state transitions.

I'm working on SpiderMonkey now, and we already must analyze for arguments[i] 
and formal parameter assignments to deoptimize nonstrict code. The main 
challenge is good error blame when the compiler detects a conflict requiring an 
early error. You want to blame both the (possibly much earlier) formal or 
arguments[i] assignment, and the later ES6 feature.

I believe that all current optimizing JS engines have to do this kind of 
analysis. So I wonder if it wouldn't be "easy" (not sure how normative we make 
this) to deal with (1) with early errors.

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 semantics for new syntax.
> 
> I was referring to strict vs classic mode. The way I understood the
> discussion so far, certain syntax would implicitly opt into extended
> mode, and thereby also into strict mode -- locally, and from classic.
> That implies semantic changes for existing features.

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

2. Completion reform.

3. New early errors.

I think 3 is a good thing and a non-problem. Some of us hope 2 is a matter of 
indifference to real-world code, but we don't know for sure. That leaves 1.

No other semantic changes, right? The key idea of the state machine is not its 
exact spec (still being discussed) but that "one JS" should mean sane operation 
or early error, based on smooth upgrade to use non-conflicting new features (or 
conflicts, e.g. 'with' vs. 'module').

Why work harder on implicit opt-in? Yes, savvy users will put a pragma on line 
1. Not all JS users are savvy and requiring them to become so asks too much.


> [The discussion seems to have changed direction again with Allen's
> "state machine" idea. That probably makes some of my comments
> obsolete. Sorry for lagging behind.]

No problem.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Claus Reinke]

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 language or library design
choice was discussed in length and detail in the appropriate sub-forum,
then decided on, implemented, and rolled out, at first without a
hitch, as long as it only affected those directly in the know; then,
a couple of months later or so, the main forums would start seeing
trouble reports from users who didn't use the new feature directly,
but who where relying on code (applications/libraries) whose
_dependencies_ where affected by the change.

When Haskell implementations still had monolithic flags to enable
all extensions at once, it would happen like this: some dependency D
would not compile in standard mode, because it needed one of the
extended language features, say F1; so extended mode had to be
enabled for that dependency D, and sometimes for the whole project
P; but, in extended mode, _all_ extended features were enabled,
including the one feature F2 that had recently been changed; enabling
the new version of F2 would then interfere with compilation of either
D or P, hopefully via an early error - compilation failure.

But the dependency D had been written long before F2 had been
redesigned, and P itself had no direct uses of either F1 or F2, only
via the dependency D. So the authors/maintainers of D and P had
no idea of the discussion that led to the change of F2, they just saw
an early error for code that used to work (and would still work, but
for the fact that they had upgraded to newer implementations).

Similar fun ensued when authors started to use some extensions,
but had to enable all extensions to make their code compile: in
addition to the extended features they were working with, their
code was now also affected by all other extended features, often
expert-mode extensions that they had no idea about.

When Haskell implementations started using explicit feature-based
versioning, thing calmed down considerably. Library authors would
select the set of extensions they needed to use, and enable them
only for their code (think of it as a specification of a language "API").
So neither their library code nor the code of library clients were
affected by unrelated features (or changes to unrelated features).

And authors moving into language extensions would also enable
them one by one, slowly building up to the level of complexity and
expertise they needed. Blog posts would mention which extensions
needed to be enabled to make examples run. When code used a
language extension, the compiler would complain that this wasn't
part of the portable standard, and suggest which pragma to use in
order to enable just this one extension.

That doesn't mean that all problems are solved (eg, library versioning
remains an interesting problem), but language extensions cause less
trouble than they used to, and there is much less pressure for extending
the language standard (Haskell 2010 is still very conservative, but a
small flood of extensions are available, selectively).

Claus

(*) For background, the early history of Haskell is documented
   in this HOPL-III paper (no discussion of feature-based versioning,
   but describes the early language revisions, up to the long-time
   standard Haskell98, as well as some of the extensions, and the
   conflict between language design experimentation and stability):

   "A History of Haskell: being lazy with class", 2007
   
http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/index.htm



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Andreas Rossberg]

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 based upon syntax or static semantics rules that 
> only exist in ES6.  For example, a destructuring pattern
> ES5-only:  The construct is based upon syntax that or static semantics rules 
> that that are not in ES6. For example, use of a with statement t.
> ES5&ES6:  The construct has identical semantics in both ES5 and ES6.
> 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 to the corresponding element of the function's 
> arguments object.
>
> We can then use the following state machines to describes the processing of a 
> Program based upon the occurrence for these feature categories.  Initially 
> start in State 5&6:

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 "state machine" simply says,
declaratively:

- If a program is ES5 but not ES6, treat as ES5.
- If a program is ES6 but not ES5, treat as ES6.
- If a program is both ES5 and ES6, with identical semantics, treat as
ES6 (although it doesn't matter).
- If a program is both ES5 and ES6, with different semantics, treat as
ES5 (for compatibility).
- If a program is neither ES5 nor ES6, it's an error (obviously).

I very much like that opt-in would be for whole programs only. I think
that is good, and IMHO progress over some of the earlier discussion.

But still, deciding what semantics a program has can depend on very
minor syntactic details. This has several potential problems:

1. For eternity, we will require future programmers to remember what
exact features were introduced with ES6, in order to be sure that they
trigger the right (i.e. strict) semantics for their program.

2. The syntactic trigger in a given program may be hidden somewhere
deep down the source code, which makes it very difficult to decide for
the reader (and the compiler, which may have to do extra work in the
parser to decide).

3. Apparently minor local modifications may accidentally change the
semantics of the whole program.

The obvious way to avoid all these issues is to always put an explicit
trigger at the top. And I expect that style guides would recommend
that. But that kind of defeats the purpose, doesn't it? I still
haven't heard a convincing argument why it is advantageous to not make
this explicit trigger mandatory.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Andreas Rossberg]

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. The way I understood the
discussion so far, certain syntax would implicitly opt into extended
mode, and thereby also into strict mode -- locally, and from classic.
That implies semantic changes for existing features.

[The discussion seems to have changed direction again with Allen's
"state machine" idea. That probably makes some of my comments
obsolete. Sorry for lagging behind.]

>> on a fine-grained level is far more
>> confusing (and error-prone!) than helpful. In all sorts of ways.
>
> Our experience was that adding new features to the default version where 
> there was no backward incompatibility was not confusing. We've been doing 
> this since 2006. Not to say all the particulars are right, or that we 
> anticipated all the combinations of ES5-strict and Harmony, of course! But I 
> think you protest too much without evidence.

Yes, but these didn't imply semantic changes to existing features,
like with implicit strict mode opt-in.

>> I'm also concerned about the 3 and a half language modes that might
>> result. With Dave's original proposal at least, the only opt-in was on
>> module level.
>
> Dave mentioned generators, IIRC. We were thinking of classes too (talked 
> about it privately).
>
>
>> 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. But see below, I 
> agree the opt in has to be "chunky", and is in the (not perfectly clear, 
> complete, etc.) proposal for "ES6 doesn't need [version] opt-in".

We had been discussing opting in a function if it's using
destructuring on its parameters, for example. I would count that as a
case that is not "chunky" enough, because it can be local to "evil"
classic features and e.g. screw up lexical scoping. Likewise
generators. I really think we should avoid these cases.

[Now the idea seems to be that any ES6 feature would always opt-in the
whole program. A like that much better, but it is not what Dave
originally proposed, and what we had been discussing before, as far as
I can tell.]

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 your 
> concern here.
> 
> Sorry, I missed that. In that case, I still don't understand what your plan 
> for ES6 is. Does the ES6 spec include the state machine and an updated form 
> of the ES5-non-strict portions of the ES5 spec, as referenced by that state 
> machine?

I defer to Allen, but one approach is to leave ES5-nonstrict as is, and combine 
strict and extended modes for the "6" in 5&6 and ES56. As you proposed!

HTH,

/be


> If not, what standards document governs how a future standards compliant 
> browser is supposed to handle code which has non opted into anything, neither 
> implicitly-explicitly nor explicitly?
>  
> 
> 
> -- 
> Cheers,
> --MarkM

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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 still don't understand what your plan
for ES6 is. Does the ES6 spec include the state machine and an updated form
of the ES5-non-strict portions of the ES5 spec, as referenced by that state
machine? If not, what standards document governs how a future standards
compliant browser is supposed to handle code which has non opted into
anything, neither implicitly-explicitly nor explicitly?



-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 -- and it is 
> much more than a terminology difference. Any other cleanups we do in ES6 --- 
> that we believe to be practically backward compatible with ES5-strict 
> practice but not with the normative spec nor with test262 --- would fall into 
> the same category as completion reform. So the status of things like we 
> imagine completion reform to be, whether or not completion reform itself is 
> one of those, is something we need to resolve. 

Yes. This is not easy to resolve by a-prior reasoning, though. We might just do 
nothing incompatible, but we could also probably get away with completion 
reform and your fixing-override-mistake change. Some experimentation in nightly 
and even longer-lived/used builds is required.


> The other change I hope fits into the same bucket is 
> . 
> Right now, because of pressure from test262, we are in danger of having all 
> browsers conform to this mistake, at which point it may be too late to fix 
> it. Today, the diversity of actual browser behaviors means it is still 
> possible to fix this mistake, much as the diversity of ways ES3 
> implementations were broken made it possible for ES5 to fix many mistakes.

The [[CanPut]] check goes back to ES1, though. Recent-ish deviations in JSC and 
(because V8 was drafting off JSC) V8 don't nullify all that history.

On the other hand, JSC and V8 are doing fine AFAIK. It's hard to make a 
real-world case where this matters, even with Object.create. And I see the ocap 
(not just SES) appeal of the fix.


> And there is one further issue I think is worth clearing up in email here.
> 
> What do we expect to be the normative status of the state machine itself and 
> of the ES5 spec, after ES6 becomes official, for a browser that claims to be 
> standards compliant, including ES6 compliant? AFAICT, no one has commented on 
> this specifically, and we may be reading different assumptions into Allen's 
> proposal.
> 
> What I am assuming Allen's proposal means is that the state machine would 
> also be normative, and therefore those parts of the ES5 spec that are 
> reachable from this state machine would remain normative as well. As I 
> understand ECMA rules, it would be at least unusual for the earlier edition 
> of the spec to remain normative even for systems claiming conformance to the 
> later edition of the "same" spec. (same by spec number, i.e., 262).

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.

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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  (=ES5.nonstrict-differs-from-ES6)
> ES5.nonstrict-ES6-intersection
> ES6-only  (=ES6-differs-from-ES5.nonstrict)

As Mark just wrote this depends on how we resolve some fine points (completion 
reform among them).


> This might be about to the question as to whether there should be a mode that 
> combines ES6-differs-from-ES5.strict constructs with ES5.nonstrict. I don’t 
> think there should be.

Oh no, that's right out. We can't have 'let' be reserved conditionally without 
more complexity (we could just reserve it and see what breaks, but then that's 
not ES5-nonstrict is it :-P).

/be___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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.
>>
> [...]
>
> While I agree it's important to get labels right, if that is indeed the
> only remaining issue here, that's wonderful. I'm mellow about labels others
> find attractive, as long as we agree on observables.
>
> I think there is an observable difference between what I'm advocating and
> what Allen is. Not as sure about your position.
>
>
> I think the only open issue is whether
>
>   "use strict";
>
> opts into completion reform and any other semantic change that does not
> have a syntactic trigger.
>
> 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 -- and it is
much more than a terminology difference. Any other cleanups we do in ES6
--- that we believe to be practically backward compatible with ES5-strict
practice but not with the normative spec nor with test262 --- would fall
into the same category as completion reform. So the status of things like
we imagine completion reform to be, whether or not completion reform itself
is one of those, is something we need to resolve.

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 danger of having all
browsers conform to this mistake, at which point it may be too late to fix
it. Today, the diversity of actual browser behaviors means it is still
possible to fix this mistake, much as the diversity of ways ES3
implementations were broken made it possible for ES5 to fix many mistakes.


And there is one further issue I think is worth clearing up in email here.

What do we expect to be the normative status of the state machine itself
and of the ES5 spec, after ES6 becomes official, for a browser that claims
to be standards compliant, including ES6 compliant? AFAICT, no one has
commented on this specifically, and we may be reading different assumptions
into Allen's proposal.

What I am assuming Allen's proposal means is that the state machine would
also be normative, and therefore those parts of the ES5 spec that are
reachable from this state machine would remain normative as well. As I
understand ECMA rules, it would be at least unusual for the earlier edition
of the spec to remain normative even for systems claiming conformance to
the later edition of the "same" spec. (same by spec number, i.e., 262).


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 indeed the only 
> remaining issue here, that's wonderful. I'm mellow about labels others find 
> attractive, as long as we agree on observables.
> 
> I think there is an observable difference between what I'm advocating and 
> what Allen is. Not as sure about your position.

I think the only open issue is whether

  "use strict";

opts into completion reform and any other semantic change that does not have a 
syntactic trigger.

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.

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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 mellow about labels others
find attractive, as long as we agree on observables.

I think there is an observable difference between what I'm advocating and
what Allen is. Not as sure about your position. But it is possible I'm
misunderstanding something and there is no observable difference. At this
point, we've narrowed the issue enough that we should probably postpone
this final step till we can engage verbally with lower latency -- at the
upcoming meeting.


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Axel Rauschmayer]

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!

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  (=ES5.nonstrict-differs-from-ES6)
ES5.nonstrict-ES6-intersection
ES6-only  (=ES6-differs-from-ES5.nonstrict)

This might be about to the question as to whether there should be a mode that 
combines ES6-differs-from-ES5.strict constructs with ES5.nonstrict. I don’t 
think there should be.

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 for correct operation, 
>> and you then start using ES6 features (which imply ES5-strict), which breaks 
>> arguments aliasing.
> 
> Hmmm, I was thinking this proposal implied much more of a breaking change 
> (e.g. removing the global object from scope),

Nope, as dherman's o.p. said: "giving up". But not the free variable analysis 
based on implicitly imported global object properties, for early errors on 
typos, of course.


> but if the change in semantics largely comes down to enabling ES5-strict then 
> maybe this isn't so bad.  If we are talking about implicitly enabling 
> ES5-strict for the whole program, I would think there may be a quite a few 
> more hazards to consider? (code that implicitly introduces variables onto the 
> global object, assumes this conversion to global object value in function 
> calls, uses callee/caller/arguments, etc).

See Allen's state machine. It requires state transitions for the syntax whose 
meaning shifted from ES5 (non-strict, as Mark points out this is only part of 
ES5 so a misnamed label) to ES6.


> Still, I'm warming up to the idea considerably if the implicit opt-in is 
> triggering no major breaking changes.

The state machine won't trigger breaking runtime shifts but it will make early 
errors out of inconsistent combinations of ES5-nonstrict and ES6 features in a 
single program.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 completion reform -- it changes semantics such that ES5-strict 
is not a subset of ES6 but we believe no code will notice (we could be wrong).

We give up on typeof null and removing the global object. The free variable 
analysis based on global properties still gives early error on typo wins. That 
makes the subset relation technically false too but let's also wink at it by 
considering only strict programs that reach runtime under either an ES5 or an 
ES6 implementation.

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 positions :-).


> The reason the state machine matters is implementation (including the fine 
> spec, the normative implementation). Authors can think of writing non-strict 
> ES5 or lower, or ES5 strict -- or ES6 if they use a bit of novelty. Different 
> beans again.
> 
> I'm not sure what informs your label count expectation. In writing JS for the 
> web over the next several years, you might have to worry quite a bit about 
> ES5 strict vs. ES6. You can't just assume ES6 works everywhere that ES5 
> strict works.
> 
> The issue is: What does it mean for a browser to be standards compliant once 
> it is fully conformant with ES6? Yes, of course there will be a long phase of 
> partial ES6 compliance as features are incrementally rolled out. Just as 
> there was with ES5.

Still is.


> But during this period, no one claims full conformance with ES6, so standards 
> compliance mean only compliance with ES5. To be standards compliant once one 
> is ES6 compliant, the state machine + ES6 keeps some portion of the ES5 spec 
> as a live normative spec because it is reachable from the state machine. The 
> only question is: Which portion is reachable? With Allen's plan, all of it. 
> With the one line revision Axel and I have in mind, the ES5-strict spec stops 
> being reachable as normative for ES6 compliant browsers. It is dead code that 
> can be considered garbage.

Your post two above the one to which I'm replying proposes to have only ES5 
non-strict and ES6, with "use strict"; (the string literal directive) enabling 
ES6. I don't a difference except in state-machine labels with what Allen 
proposes.

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.

Function declarations in blocks and (depending on implementation) const 
extensions fall into ES5-nonstrict-differs-from-ES6 as noted. That is, 
"ES5-nonstrict" must be read to include an implementations extensions that 
pre-date ES5, that are enabled without "use strict";, and of course which 
conflict with ES5 strict.

You previously wrote:

> For example, since legacy constrains us from making nested named function 
> declarations a triggering feature, if program #2 [one with "use strict"; and 
> conforming to ES5 strict] has a nested named function and the browser 
> rejected it, that browser would still conform to both the ES5 and ES6 spec. 

ES6 will normatively require block-nested function declarations to be 
supported, with certain semantics. So I don't agree that a conforming ES6 
implementation could reject such functions in blocks.

You continued:

> The easy fix is to make "use strict"; a triggering condition.

I agree that this follows from the state label definitions (whatever their 
names) and the state machine.

Then you wrote:

> For non-strict code, by the state machine, the ES6 spec would still delegate 
> to the ES5 spec. And the ES6 spec would otherwise be the same. But the strict 
> portion of the ES5 spec would simply be dead code, because all of the 
> conditions that would trigger it have already triggered the state machine 
> into using the ES5 spec.

Here again I'm confused. the ES6 spec is not going to delegate to a separate 
and older edition, namely ES5. It will be self-contained. So there must be 
something in the ES6 spec that defines how to process "use strict"; *or* new 
ES6 syntax, and how that makes duplicate formals an early error, etc. etc.

IOW ECMA-262 Ed. 6 must contain some kind of state machinery for specifying 
opt-in.


> In the ES6 era, I hope to be able to say "ES5-strict is dead. Long live ES6!".

Ok, I can adjust labels to agree with this. But it doesn't relieve the ES6 spec 
from talking about opt-in from ES5-nonstrict, so are we really just arguing 
about names or labels? If so, great -- those are important to get right.

If I seemed to disagree on number of modes, it may be because I don't see how a 
conforming ES6 implementation could continue to reject extensions that 
ES5-strict rejects (e.g., functions in blocks). ES6 will require 
functions-in-blocks to work a certain way.

Any implementation that supported an extension under ES5-strict where the 
semantics for the same syntax differ between the extension and ES6 will have to 
suffer (SpiderMonkey let and const fall into this category). But that is 
SpiderMonkey's headache, not ECMA-262's.


> However, ES5-non-strict (or "non-strict", or "ES3") will continue to live for 
> the foreseeable future. It will probably outlive most of us.

Yup.

/be


> 
> 
>  
> 
> /be
> 
> 
> >
> > ES6-only => (

Re: ES6 doesn't need opt-in

[Gavin Barraclough]

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 features (which imply ES5-strict), which breaks 
> arguments aliasing.

Hmmm, I was thinking this proposal implied much more of a breaking change (e.g. 
removing the global object from scope), but if the change in semantics largely 
comes down to enabling ES5-strict then maybe this isn't so bad.  If we are 
talking about implicitly enabling ES5-strict for the whole program, I would 
think there may be a quite a few more hazards to consider? (code that 
implicitly introduces variables onto the global object, assumes this conversion 
to global object value in function calls, uses callee/caller/arguments, etc).

Still, I'm warming up to the idea considerably if the implicit opt-in is 
triggering no major breaking changes.

G.



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Axel Rauschmayer]

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

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 semantics that a given script would be evaluated with?

If there's new syntax somewhere, the consumer of the code may have to read and 
understand it. But let's be real: JQuery users *do not* read and understand 
that library's every line. They use its well-documented APIs.

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 features (which imply ES5-strict), which breaks arguments aliasing.

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Gavin Barraclough]

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 by one level
> with every future version of ES?
> 
> Btw, I'm really uncomfortable with implicit feature tracking -
> it works ok for people who follow all the relevant mailinglist
> discussions and spec versions, but it leaves in the dark all those
> who "just code in JS" and enter a situation where their code base
> might have to be interpreted according to any of a number of
> specs (most JS coders do not even read one version of the spec,
> but rely on blogs and books, which will equally show no explicit
> in-source sign of what spec version their examples refer to and
> whether they are out of date).

I share these concerns.

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 
semantics that a given script would be evaluated with?

G.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Claus Reinke]

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.
If a Program can not be explicitly identified as either ES5 or ES6, it is 
treated as an ES5 program.


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 by one level
with every future version of ES?

ES5 already has the var-"hoisting" oddity where I might have
to scan the whole file before being able to decide whether a
given variable occurrence is bound to a given variable declaration.
I'm not alone in not wanting to see (another) such hazard (*).

Btw, I'm really uncomfortable with implicit feature tracking -
it works ok for people who follow all the relevant mailinglist
discussions and spec versions, but it leaves in the dark all those
who "just code in JS" and enter a situation where their code base
might have to be interpreted according to any of a number of
specs (most JS coders do not even read one version of the spec,
but rely on blogs and books, which will equally show no explicit
in-source sign of what spec version their examples refer to and
whether they are out of date).

Making feature-based versioning explicit (by pragma opt-in)
doesn't solve all problems, but at least everybody knows what
everyone else is talking about, and help can be offered ("if you
want ES6 semantics for let and yield, write 'use let,yield' or just
'use ES6', if you want JS1.8 semantics for these features, use ..;
if you want to concatenate old and new code, protect the old
code with 'use ES5' and the new code with 'use ES6'").

By making feature-based versioning implicit (by feature use), only
experts will be able to say "wait, I remember that kind of issue -
perhaps your engine has switched to another ES version. could
you check whether your source has any yields in it, or perhaps
destructuring, or perhaps a with, or perhaps a vat? yes, please
check even seemingly unrelated parts of the source.".

Also, what happened to the bold "this version will break a few
things, but we'll end up with a much cleaner language spec"?

I'm not saying you are wrong - if you can pull it off, great! But the
new plan reminds me strongly of bad experiences in Haskell-land.

Claus

(*) At least one popular tool (jslint) has decided not to implement
the resulting 2-pass complexity (find var declarations, then parse
for real) but restricts the input language instead, and makes do
with a single pass over the source and naïve scope-tracking.

If I remember correctly, simply lifting jslint's unpopular vars-first
restriction would lead to incorrect internal scope tracking (I don't
know how jshint handles this, btw?).


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Herby Vojčík]

Hi,

I think Allen had another point. What you are counting, are semantic modes 
of the code, that is, runtime.
What Allen counts, are specification modes of the language, that is, 
compilation.

These are different beans, as he said earlier.

Things that Allen defines (afaict) are:

- compilation targets

ES5 ::= "When run, the program will be interpreted according to ES5 spec. In 
particular, parts with "use strict"; will be interpreted with ES5 strict 
mode semantics and parts without it with ES5 non-strict mode semantics. In 
other words, it will be compiled according to ES5 spec."


ES6 ::= "When run, the program will be interpreted according to ES6 spec. In 
particular, parts with "use strict"; will be interpreted with ES6 (strict) 
mode semantics and part without it also with ES6 (strict) mode semantics. 
In other words, it will be compiled according to ES5 spec."


- categories of the code elements with respect to compilation targets (they 
are event in the pre-compilation parsing state machine)


Identical-in-both (ES5&ES6), Valid-but-differs (ES5~ES6), Valid-only-in-ES5 
(ES5-only), Valid-only-in-ES6 (ES6-only)


- states and transitions of the pre-compilation parsing state machine

5&6, ES5, ES6, Compat5 states
transitions for all of them with respect to events above (that is, 
categories)



The output of the state machine is the compilation target (inferred directly 
from the state at which the state machine finishes: ES5, ES5, ES6 and ES5, 
respectively), eventually an early error that prevents compilation because 
of conflicting ES5-only and ES6-only code was detected while parsing.


"use strict"; and its two modes are only important here, when the program is 
being compiled (when in state machine, it should imo trigger 
"Identical-in-both" event).


He also recommends opt-ins to be sure to get ES5 target or ES6 target 
(unless there is conflict in code, of course) as the output of the state 
machine by citing pieces of code with no functionality but triggering 
"Valid-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 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 the state machine may delegate to any of these three 
normative specs we have three modes. If the state machine may only delegate 
to ES5-non-strict or ES6, i.e., if the ES5-strict spec becomes dead code as 
of conformance with state machine + ES6 spec, then we have two modes.


To get this effect, we need only classify ES5's "use strict"; directive as 
ES6-only. If any objection to doing so has been stated, I missed it. Is 
there a reason not to do so? It's a one line change that leaves the rest of 
your proposal unperturbed and solves this problem.





On Fri, 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 go together.


Quoting Brendan:


- ES6 is a superset of ES5.strict.


That's always been promised.



Then I would only expect two labels: ES6 and non-strict

ES6-only => (a subset of) ES6
ES5-only => only possible for non-strict constructs => non-strict
ES5&ES6 => (a subset of) ES6
ES5~EAS6 => not possible  (“The construct has identical syntax and static 
semantics in both ES5 and ES6, but differing semantics.”)


--
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com






--
   Cheers,
   --MarkM





___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss 


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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 belaboring this point. But the labels and the
> quote below don’t go together.
> >
> > Quoting Brendan:
> >
> >>> - ES6 is a superset of ES5.strict.
> >>
> >> That's always been promised.
> >
> >
> > 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.



>
> The reason the state machine matters is implementation (including the fine
> spec, the normative implementation). Authors can think of writing
> non-strict ES5 or lower, or ES5 strict -- or ES6 if they use a bit of
> novelty. Different beans again.
>
> I'm not sure what informs your label count expectation. In writing JS for
> the web over the next several years, you might have to worry quite a bit
> about ES5 strict vs. ES6. You can't just assume ES6 works everywhere that
> ES5 strict works.
>

The issue is: What does it mean for a browser to be standards compliant
once it is fully conformant with ES6? Yes, of course there will be a long
phase of partial ES6 compliance as features are incrementally rolled out.
Just as there was with ES5. But during this period, no one claims full
conformance with ES6, so standards compliance mean only compliance with
ES5. To be standards compliant once one is ES6 compliant, the state machine
+ ES6 keeps some portion of the ES5 spec as a live normative spec because
it is reachable from the state machine. The only question is: Which portion
is reachable? With Allen's plan, all of it. With the one line revision Axel
and I have in mind, the ES5-strict spec stops being reachable as normative
for ES6 compliant browsers. It is dead code that can be considered garbage.

In the ES6 era, I hope to be able to say "ES5-strict is dead. Long live
ES6!".

However, ES5-non-strict (or "non-strict", or "ES3") will continue to live
for the foreseeable future. It will probably outlive most of us.




>
> /be
>
>
> >
> > ES6-only => (a subset of) ES6
> > ES5-only => only possible for non-strict constructs => non-strict
> > ES5&ES6 => (a subset of) ES6
> > ES5~EAS6 => not possible  (“The construct has identical syntax and
> static semantics in both ES5 and ES6, but differing semantics.”)
> >
> > --
> > Dr. Axel Rauschmayer
> > a...@rauschma.de
> >
> > home: rauschma.de
> > twitter: twitter.com/rauschma
> > blog: 2ality.com
> >
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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 names for this are:

ES5-non-strict
Non-strict
ES3

By continuing to call this simply ES5 while precluding the program from
being an ES5-strict program, you confuse the crucial issue I'm trying to
clarify.


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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 the state machine may delegate to any of these three
normative specs we have three modes. If the state machine may only delegate
to ES5-non-strict or ES6, i.e., if the ES5-strict spec becomes dead code as
of conformance with state machine + ES6 spec, then we have two modes.

To get this effect, we need only classify ES5's "use strict"; directive as
ES6-only. If any objection to doing so has been stated, I missed it. Is
there a reason not to do so? It's a one line change that leaves the rest of
your proposal unperturbed and solves this problem.



On Fri, 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 go together.
>
> Quoting Brendan:
>
> >> - ES6 is a superset of ES5.strict.
> >
> > That's always been promised.
>
>
> Then I would only expect two labels: ES6 and non-strict
>
> ES6-only => (a subset of) ES6
> ES5-only => only possible for non-strict constructs => non-strict
> ES5&ES6 => (a subset of) ES6
> ES5~EAS6 => not possible  (“The construct has identical syntax and static
> semantics in both ES5 and ES6, but differing semantics.”)
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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.non-strict and 
> all prior ES versions on one hand and ES6 and ES5.strict on the other hand.

Notice that two of the four states contain possible outcome

terminate with Error: invalid combination of ES5 and ES6 features

These are the states labeled ES5 and ES6.

It should be clear that you need more than two states to judge whether a given 
hunk of code is ES5 non-strict (or lower) -- the default unversioned 

Re: ES6 doesn't need opt-in

[Axel Rauschmayer]

> 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 ES5.strict on the other hand. But 
it makes sense that even if developers (engine users) are presented with 
something simple, implementors have to take care of many more details.

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 normative implementation). Authors can think of writing non-strict 
>> ES5 or lower, or ES5 strict -- or ES6 if they use a bit of novelty. 
>> Different beans again.
> 
> Ah, got it! You want ECMA-262 version 6 to allow an à la carte approach: 
> implementors can choose between non-strict ES5, strict ES5, ES6, etc.

No! ES6 will be a normative all or none spec, ignoring informative annexes and 
Annex B (revised to be normative-optional, meaning if you implement these APIs 
you must follow this annex, but you are not required to implement them).

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').


>> I'm not sure what informs your label count expectation. In writing JS for 
>> the web over the next several years, you might have to worry quite a bit 
>> about ES5 strict vs. ES6. You can't just assume ES6 works everywhere that 
>> ES5 strict works.
> 
> 
> I was thinking about how to specify only (exclusively) an ES6 environment. 
> You pretend to live in a “perfect ES6 world” and then only have two labels. 
> There are two ways out of this world:
> 
> - Non-ES6 environments for implementors: refer to ECMA-262 version 5.1.
> 
> - Non-ES6 environments for developers: simulate ES6 (via static compilation, 
> dynamic compilation, etc.).

That's fair, and some developers will just assume ES6 and require latest l33t 
browsers. There are many possible bean-counting approaches depending on your 
business, hobby, mood, etc.

For the spec we need an algorithm for syntax-as-opt-in. That's what the state 
machine is about.

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Axel Rauschmayer]

>> 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 or lower, or ES5 strict -- or ES6 if they use a bit of novelty. Different 
> beans again.

Ah, got it! You want ECMA-262 version 6 to allow an à la carte approach: 
implementors can choose between non-strict ES5, strict ES5, ES6, etc.

> I'm not sure what informs your label count expectation. In writing JS for the 
> web over the next several years, you might have to worry quite a bit about 
> ES5 strict vs. ES6. You can't just assume ES6 works everywhere that ES5 
> strict works.


I was thinking about how to specify only (exclusively) an ES6 environment. You 
pretend to live in a “perfect ES6 world” and then only have two labels. There 
are two ways out of this world:

- Non-ES6 environments for implementors: refer to ECMA-262 version 5.1.

- Non-ES6 environments for developers: simulate ES6 (via static compilation, 
dynamic compilation, etc.).


-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 strict, then I don't 
> see a lot value in saying:  use strict;

The value is that the string literal is non-breaking in pre-ES5 
implementations, which has been a source of real bugs (concatenation, too-early 
adoption).

Explicit opt in via

  use strict;

seems better to me than anything with a version number in it. More below.


> I would think that:
>   use ES6;  //or use version 6; etc
> would better express the user intent.
> 
> BTW, I would interpret this as meaning "at least ES6" and still do feature 
> driven version detection of future versions using an expanded state machine.

While the ECMA editions will be numbered (unpredictably!), and RFC4329 points 
toward post-hoc standardization of the ;version= MIME type parameter, I do not 
think we should embed version numbers in pragmas.

We could, certainly. That was the plan of record until recently. It matches the 
;version= progression we're likely to want anyway, to hide new code from being 
loaded by old browsers with inevitable syntax errors whose reporitng slows the 
futile loads even further.

But I'd rather leave ;version= to the MIME type parameter, which is just a 
post-hoc reflection of ECMA's edition numbering. This reduces the tendency to 
think of versions, modes, and the like. It's a human factors thing. Versions 
suck, Hixie and Anne and others were right to push back on them, even if they 
didn't solve the forward compatibility problem (no one has) or are in denial 
about HTML5 (with 5) :-P.


> Other ES5 opt-ins at the top level include:
> 
> var arguments;
> 
> function ES5(yes,yes){};
> 
> These probably won't cause any deoptimization.
> 
> However, I agree that it would be rare for someone to actually need to do 
> this.  The intent was more to emphasize that the way you force a particular 
> spec-level interpretation is to code something that is unique to that 
> spec-level.

Sure.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 go together.
> 
> Quoting Brendan:
> 
>>> - ES6 is a superset of ES5.strict.
>> 
>> That's always been promised.
> 
> 
> 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 or lower, or ES5 strict -- or ES6 if they use a bit of novelty. Different 
beans again.

I'm not sure what informs your label count expectation. In writing JS for the 
web over the next several years, you might have to worry quite a bit about ES5 
strict vs. ES6. You can't just assume ES6 works everywhere that ES5 strict 
works.

/be


> 
> ES6-only => (a subset of) ES6
> ES5-only => only possible for non-strict constructs => non-strict
> ES5&ES6 => (a subset of) ES6
> ES5~EAS6 => not possible  (“The construct has identical syntax and static 
> semantics in both ES5 and ES6, but differing semantics.”)
> 
> -- 
> Dr. Axel Rauschmayer
> a...@rauschma.de
> 
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

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 example, accessing a formal 
>> parameter after an assignment to the corresponding element of the function's 
>> arguments object.
> 
> This is something we propose to do with completion reform, and also until 
> this year for typeof null.
> 
> It's clear we can't get away with changing typeof null == "null". Even with 
> full opt-in, it's a runtime migration hazard (one of the five fingers of 
> fate). I withdraw it -- I'm the one who proposed it in lieu of an 
> Object.isObject predicate -- but I do not think we should add Object.isObject 
> either.
> 
> Rather, we need to rethink reflection on types in light of not only null vs. 
> object, but value types/proxies. I'd rather not rush that. In the mean time, 
> and for lo these 16 years (heading toward 17!), developers have coped and can 
> continue to do so with typeof x == "object" && x === null or simpler (!x, x 
> == null, other context-specialized combinations).
> 
> In general, the latest "new syntax is its own opt-in" thinking, with Allen's 
> state machine approach, means our five fingers of fate have to be small 
> enough that we can get away with them. At least Mark and I believe completion 
> reform (making the completion value depend on a statically decidable 
> expression-statement) is the only such finger we can get away with folding 
> right now.
> 
> 
>> If you want to explicitly force ES6 processing put a:
>>  let ES6;
> 
> 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 strict, then I don't see 
a lot value in saying:  use strict;

I would think that:
   use ES6;  //or use version 6; etc
would better express the user intent.

BTW, I would interpret this as meaning "at least ES6" and still do feature 
driven version detection of future versions using an expanded state machine.  

> 
> 
>> at the top of the source file. 
>> 
>> If you want to explicitly force ES5 processing put a:
>>  with (5);
>> at the top of the source file
> 
> That will potentially deoptimize the top level for some engines, but maybe it 
> doesn't matter. I don't expect it to catch on ;-).

Other ES5 opt-ins at the top level include:

var arguments;

function ES5(yes,yes){};

These probably won't cause any deoptimization.

However, I agree that it would be rare for someone to actually need to do this. 
 The intent was more to emphasize that the way you force a particular 
spec-level interpretation is to code something that is unique to that 
spec-level.


Allen


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Axel Rauschmayer]

> 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.strict.
> 
> That's always been promised.


Then I would only expect two labels: ES6 and non-strict

ES6-only => (a subset of) ES6
ES5-only => only possible for non-strict constructs => non-strict
ES5&ES6 => (a subset of) ES6
ES5~EAS6 => not possible  (“The construct has identical syntax and static 
semantics in both ES5 and ES6, but differing semantics.”)

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

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 implementation perspective, I suppose you consider each state in my 
>FSM a "mode" in which case we have 4 processing modes.  Or 

If you are using "mode" to classify the semantics of arguments and assignment 
to undeclared identifiers then there are two modes: "strict" and "non-strict"

If you are using "mode" to classify what can occur in a StatementList there are 
three modes: ES5, ES5-strict, ES-6.

Allen


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 standardization. 
Do these make ongoing new modes?

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.

/be



> 
> 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 
> > 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 function 
> > declarations a triggering feature, if program #2 has a nested named 
> > function and the browser rejected it, that browser would still conform to 
> > both the ES5 and ES6 spec.
> 
> Implementations that currently support extensions to ES5 (and wish to 
> continue to support them) must classify their extensions into one of the four 
> categories I identified and then process them according to the state machine. 
> Because no currently implementation of function declarations within blocks 
> (that I'm aware of) matches the ES6 lexical scoping semantics, it would 
> expect such function declarations to be classified as ES5~ES6.  Then, 
> according to the state machine, a program like:
> 
> function f(g) {
>   //not the following will produce inconsistent results among common browsers
>   if (!g) {
>  function g() {return 1}
>   }
>  else if (typeof g !== 'function') {
> function g() {return 2}
>   }
>   return g;
> }
> 
> will be processed using the (implementation extended) ES5 specification and 
> both f and g would presumably be non-strict functions.  If you wanted the 
> above to be processed as ES6 code you would need to add some ES6-only 
> features such as: let ES6; or use some other forced opt-in such as a version 
> in the MIME type.
> 
> The above is exactly analogies to how any "standard" ES5~ES6 features would 
> be treated.
> 
> Allen
> 
> 
> 
> 
> 
> -- 
> Cheers,
> --MarkM

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

(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 to the corresponding element of the function's 
> arguments object.

This is something we propose to do with completion reform, and also until this 
year for typeof null.

It's clear we can't get away with changing typeof null == "null". Even with 
full opt-in, it's a runtime migration hazard (one of the five fingers of fate). 
I withdraw it -- I'm the one who proposed it in lieu of an Object.isObject 
predicate -- but I do not think we should add Object.isObject either.

Rather, we need to rethink reflection on types in light of not only null vs. 
object, but value types/proxies. I'd rather not rush that. In the mean time, 
and for lo these 16 years (heading toward 17!), developers have coped and can 
continue to do so with typeof x == "object" && x === null or simpler (!x, x == 
null, other context-specialized combinations).

In general, the latest "new syntax is its own opt-in" thinking, with Allen's 
state machine approach, means our five fingers of fate have to be small enough 
that we can get away with them. At least Mark and I believe completion reform 
(making the completion value depend on a statically decidable 
expression-statement) is the only such finger we can get away with folding 
right now.


> If you want to explicitly force ES6 processing put a:
>   let ES6;

Or (no quotes)

  use strict;

I think we want this pragma supported, not only the string-literal 
expression-statement "directive".


> at the top of the source file. 
> 
> If you want to explicitly force ES5 processing put a:
>   with (5);
> at the top of the source file

That will potentially deoptimize the top level for some engines, but maybe it 
doesn't matter. I don't expect it to catch on ;-).

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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
> 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
> function declarations a triggering feature, if program #2 has a nested
> named function and the browser rejected it, that browser would still
> conform to both the ES5 and ES6 spec.
>
> Implementations that currently support extensions to ES5 (and wish to
> continue to support them) must classify their extensions into one of the
> four categories I identified and then process them according to the state
> machine. Because no currently implementation of function declarations
> within blocks (that I'm aware of) matches the ES6 lexical scoping
> semantics, it would expect such function declarations to be classified as
> ES5~ES6.  Then, according to the state machine, a program like:
>
> function f(g) {
>   //not the following will produce inconsistent results among common
> browsers
>   if (!g) {
>  function g() {return 1}
>   }
>  else if (typeof g !== 'function') {
> function g() {return 2}
>   }
>   return g;
> }
>
> will be processed using the (implementation extended) ES5 specification
> and both f and g would presumably be non-strict functions.  If you wanted
> the above to be processed as ES6 code you would need to add some ES6-only
> features such as: let ES6; or use some other forced opt-in such as a
> version in the MIME type.
>
> The above is exactly analogies to how any "standard" ES5~ES6 features
> would be treated.
>
> Allen
>
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

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 example, since legacy constrains us from making nested named function 
> declarations a triggering feature, if program #2 has a nested named function 
> and the browser rejected it, that browser would still conform to both the ES5 
> and ES6 spec. 

Implementations that currently support extensions to ES5 (and wish to continue 
to support them) must classify their extensions into one of the four categories 
I identified and then process them according to the state machine. Because no 
currently implementation of function declarations within blocks (that I'm aware 
of) matches the ES6 lexical scoping semantics, it would expect such function 
declarations to be classified as ES5~ES6.  Then, according to the state 
machine, a program like:

function f(g) {
   //not the following will produce inconsistent results among common browsers
   if (!g) {
  function g() {return 1}
   }
  else if (typeof g !== 'function') {
 function g() {return 2}
   }
   return g;
}

will be processed using the (implementation extended) ES5 specification and 
both f and g would presumably be non-strict functions.  If you wanted the above 
to be processed as ES6 code you would need to add some ES6-only features such 
as: let ES6; or use some other forced opt-in such as a version in the MIME type.

The above is exactly analogies to how any "standard" ES5~ES6 features would be 
treated.
   
Allen


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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 function
declarations a triggering feature, if program #2 has a nested named
function and the browser rejected it, that browser would still conform to
both the ES5 and ES6 spec.

The easy fix is to make "use strict"; a triggering condition. For
non-strict code, by the state machine, the ES6 spec would still delegate to
the ES5 spec. And the ES6 spec would otherwise be the same. But the strict
portion of the ES5 spec would simply be dead code, because all of the
conditions that would trigger it have already triggered the state machine
into using the ES5 spec.

On Fri, Jan 6, 2012 at 12:30 AM, Mark S. Miller  wrote:

> 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 the ES6 spec can avoid describing the semantics of non-strict code.
> Cool.
>
> --
> Cheers,
> --MarkM
>



-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Herby Vojčík]

-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 want to read through a file, encounter an ES6 trigger at the end 
and then have to revise the understanding of the code that I had so far. I 
like the whole-file-or-nothing approach for switching semantics that you 
proposed.


--
Dr. Axel Rauschmayer
a...@rauschma.de

===

But you can! Allen has explicitly said "put 'let ES6;' at the beginning if 
you want to force ES6". As a human, you can argue that it is humanly to 
actually do it. And when the code is such that it is really ES5&ES6 the 
whole time and only at the end the ES6 feature is used, then what? It is so.


I think the Mark Miller's "has the huge benefit that the ES6 spec can avoid 
describing the semantics of non-strict code. Cool." is undepinning what the 
real value behind the Allen's state machine is.


Herby

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Axel Rauschmayer]

>> 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 agreed semantics. If there is an observable difference, how 
>> is this not three modes?
> 
> 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.
> 
> The tricky cases are thing like:
> 
> function f(a) {
> arguments[0]=2;
> return a
> }
> print(f(1));  //2 if ES5, 1 if ES6
> 
> There is nothing in the source file that implies which specification to apply 
> so for backwards computability a browser must default to interpreting such 
> program as a ES5 program. Anything syntactically unique to ES5 (eg, use of a 
> with statment) or ES6 (eg, use rest or spread) would force one interpretation 
> or another

But what you are saying is that ES6 is not a superset of ES5.strict, right?

I thought that there were only 2 semantics:
  1.  ES5.non-strict (which is a superset of all previous versions) [a.k.a. 
"non-strict"]
  2.  ES6 (which is a superset of ES5.strict) [a.k.a. "strict"]

My understanding is that #1 would be the default and when one encounters 
anything ES6-specific (an “ES6 trigger”) or "use strict" then the semantics 
switches to #2.
=> encountering a with statement would be fine, because #1 is the default, 
anyway.
=> encountering a with statement and either an ES6 trigger or a "use strict" 
would be an error.

As a human, I would want an ES6 trigger to appear as early as possible. I 
wouldn’t want to read through a file, encounter an ES6 trigger at the end and 
then have to revise the understanding of the code that I had so far. I like the 
whole-file-or-nothing approach for switching semantics that you proposed.

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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 the ES6 spec can avoid describing the semantics of non-strict code.
Cool.

-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

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 features.
>> 
>> Do these three programs operate in three different modes? If not, do #1 and 
>> #2 operate in the same mode, or do #2 and #3 operate in the same mode?
> 
> It isn't about "modes".  #1 and #2 are ES5 programs and are processed as such 
> (applying/not the appropriately strictness as per ES5) . #3 is an ES6 program 
> is processed as such (including using the strict semantics that are universal 
> to ES6).
> 
> 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 agreed semantics. If there is an observable difference, how is 
> this not three modes?

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.

The tricky cases are thing like:

function f(a) {
arguments[0]=2;
return a
}
print(f(1));  //2 if ES5, 1 if ES6

There is nothing in the source file that implies which specification to apply 
so for backwards computability a browser must default to interpreting such 
program as a ES5 program. Anything syntactically unique to ES5 (eg, use of a 
with statment) or ES6 (eg, use rest or spread) would force one interpretation 
or another

Allen







> 
>  
> -- 
> Cheers,
> --MarkM

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

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 of it to start behaving differently (breaking 
> changes).  I think in practice this will be very confusing.  Take this:
>  
>   var x = typeof null;
>   module {
> var y = typeof null;
> x == y // false!
>   }
>  

Note that my most resent postings were suggesting a different form of "implicit 
explicit opt-in":  use of new syntax causes all of the code in the same source 
file to potentially behave differently

  var x = typeof null;
  module {
var y = typeof null;
x == y // ->true!
  }

In practice, I agree that we don't want to make such a breaking change for 
typeof.  But this approach would allow to make "strict mode semantics" be 
implicit for any source file that uses any new ES6 syntactic features.

Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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 modes? If not, do #1
> and #2 operate in the same mode, or do #2 and #3 operate in the same mode?
>
>
> It isn't about "modes".  #1 and #2 are ES5 programs and are processed as
> such (applying/not the appropriately strictness as per ES5) . #3 is an ES6
> program is processed as such (including using the strict semantics that are
> universal to ES6).
>

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 agreed semantics. If there is an observable difference, how
is this not three modes?


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

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, 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 
>> really exists to be an ES3 compatibility mode, and was constrained to be 
>> backwards compatible from ES3. Likewise, I am happy to call the new ES6 
>> strict simply "ES6".
>> 
> 
> When I talked about "ES5" in my original post I meant full ES5 including both 
> strict and non-strict modes.  Since ES6 is supposed to be a strict super set 
> of ES5 strict mode, anything in the ES5-only category must be an exclusively 
> non-strict mode feature (for example, with).  I suppose you could call that 
> category "ES3" but I decided to label it "ES5-only"  to keep things focused 
> on differences between ES5 and ES5.
> 
>> Concretely, I am confused how your transition diagram is supposed to handle 
>> "use strict";. Reading your state machine literally, since "use strict"; is 
>> accepted by ES5, if it is accepted by ES6 (as I think we all agree it would 
>> be), then it would leave us in state ES5&ES6. Were you two base categories 
>> "ES6 non-strict" (or ES3) and "ES6 strict" (or ES6), then a "use strict"; 
>> would put us in your ES6 strict (or ES6) category, which is what I would 
>> have expected.
> 
> Yes, "use strict" is in the ES5&ES6 category.  A ES5 completely strict mode 
> program would start in State 5&6  and stay in that state for its entire 
> "compilation".  Only encountering use of a new ES6 feature would case a 
> transition to State ES6.  Looking at it another way, Both State ES5 and State 
> 5&6 include support for both strict and non-strict ES5 code.  State ES6 only 
> allows strict code.
> 
> Them either I still don't understand, this proposal is broken, or we're 
> talking about three modes. Take the following three programs:

My point wasn't to try to define modes. I think that is where we are 
miscommunicating. 

There are exactly two language specifications we have to deal with.  The ES5 
spec. and the ES6 spec. A given ES source program may conform to one, or the 
other, or both (or neither).  The exercise I was working through is how do you 
determine whether to process a given source file according to the ES5 spec. or 
the ES6 spec., without explicitly preassociating the source file with one or 
another.  That is what my state machine does.  It starts assuming the source 
file is in the intersection, where it it doesn't matter which specification you 
apply.  As soon as it see a feature that is unique to one or the other  of the 
specification it clamps to that specification for the entire program.  The 
extra states are to deal with the situation where the appropriate specification 
to use for a feature can not be  directly inferable from the syntax of the 
feature. 


> 
> 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 modes? If not, do #1 and 
> #2 operate in the same mode, or do #2 and #3 operate in the same mode?

It isn't about "modes".  #1 and #2 are ES5 programs and are processed as such 
(applying/not the appropriately strictness as per ES5) . #3 is an ES6 program 
is processed as such (including using the strict semantics that are universal 
to ES6).


> 
> Putting #1 and #2 into the same mode breaks ES5 code. So to avoid three 
> modes, my conclusion is that #2 and #3 must be in the same mode. But that 
> does not seem to be what you're saying. What am I misunderstanding?
> 
> 
> -- 
> Cheers,
> --MarkM

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: ES6 doesn't need opt-in

[Luke Hoban]

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 think this is close to what Brendan has been 
advocating as well?).  Let me try to motivate this from a somewhat different 
direction.  Wall of text below - but the punchline is:

Let's avoid versioning by making (almost) no breaking changes.

# Versioning #
There are two goals to versioning - (1) allow breaking changes that code can 
explicitly opt-in to and (2) support reasonable forward compatibility of new 
code running on old runtimes.

The original plan for ES6 was to support (1) and (2) via a versioned script 
tag.  This allowed breaking changes because it was explicit opt in, and 
supported forward compatibility to the extent that there was graceful 
degradation of behaviour on old runtimes (skipping the script block).

Versioned script tags are onerous though, and folks are rightly looking for 
better options.

The better option is to not do versioning at all.  To do that, you need to give 
up on (1) and (2).  That is - no breaking changes (or at least no practically 
significant ones), and no 1st class support for forward compatibility.

# Forward compatibility #
The forward compatibility point in favor of a versioned script tag was never 
particularly strong anyway.  A versioned script tag is ignored on most down-rev 
browsers, but it is still hard to construct programs using new syntax that 
behave pleasantly on those browsers, because the granularity of feature 
detection is at the script-block level, not the application-feature level.  To 
the extent that apps want to use new syntax and still work on older browsers, 
they can almost as easily just accept the early errors from their 

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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 strict, to be backwards compat with
> ES5-strict. I am perfectly happy to call ES6 non-strict "ES3", since
> ES5-non-strict really exists to be an ES3 compatibility mode, and was
> constrained to be backwards compatible from ES3. Likewise, I am happy to
> call the new ES6 strict simply "ES6".
>
> When I talked about "ES5" in my original post I meant full ES5 including
> both strict and non-strict modes.  Since ES6 is supposed to be a strict
> super set of ES5 strict mode, anything in the ES5-only category must be an
> exclusively non-strict mode feature (for example, with).  I suppose you
> could call that category "ES3" but I decided to label it "ES5-only"  to
> keep things focused on differences between ES5 and ES5.
>
> Concretely, I am confused how your transition diagram is supposed to
> handle "use strict";. Reading your state machine literally, since "use
> strict"; is accepted by ES5, if it is accepted by ES6 (as I think we all
> agree it would be), then it would leave us in state ES5&ES6. Were you two
> base categories "ES6 non-strict" (or ES3) and "ES6 strict" (or ES6), then a
> "use strict"; would put us in your ES6 strict (or ES6) category, which is
> what I would have expected.
>
>
> Yes, "use strict" is in the ES5&ES6 category.  A ES5 completely strict
> mode program would start in State 5&6  and stay in that state for its
> entire "compilation".  Only encountering use of a new ES6 feature would
> case a transition to State ES6.  Looking at it another way, Both State ES5
> and State 5&6 include support for both strict and non-strict ES5 code.
>  State ES6 only allows strict code.
>

Them either I still don't understand, this proposal is broken, or we're
talking about three modes. Take the following three programs:

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 modes? If not, do #1 and
#2 operate in the same mode, or do #2 and #3 operate in the same mode?

Putting #1 and #2 into the same mode breaks ES5 code. So to avoid three
modes, my conclusion is that #2 and #3 must be in the same mode. But that
does not seem to be what you're saying. What am I misunderstanding?


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

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 perfectly happy to call ES6 non-strict "ES3", since ES5-non-strict 
> really exists to be an ES3 compatibility mode, and was constrained to be 
> backwards compatible from ES3. Likewise, I am happy to call the new ES6 
> strict simply "ES6".
> 
When I talked about "ES5" in my original post I meant full ES5 including both 
strict and non-strict modes.  Since ES6 is supposed to be a strict super set of 
ES5 strict mode, anything in the ES5-only category must be an exclusively 
non-strict mode feature (for example, with).  I suppose you could call that 
category "ES3" but I decided to label it "ES5-only"  to keep things focused on 
differences between ES5 and ES5.

> Concretely, I am confused how your transition diagram is supposed to handle 
> "use strict";. Reading your state machine literally, since "use strict"; is 
> accepted by ES5, if it is accepted by ES6 (as I think we all agree it would 
> be), then it would leave us in state ES5&ES6. Were you two base categories 
> "ES6 non-strict" (or ES3) and "ES6 strict" (or ES6), then a "use strict"; 
> would put us in your ES6 strict (or ES6) category, which is what I would have 
> expected.

Yes, "use strict" is in the ES5&ES6 category.  A ES5 completely strict mode 
program would start in State 5&6  and stay in that state for its entire 
"compilation".  Only encountering use of a new ES6 feature would case a 
transition to State ES6.  Looking at it another way, Both State ES5 and State 
5&6 include support for both strict and non-strict ES5 code.  State ES6 only 
allows strict code.

Allen
> 
> 
> On Thu, Jan 5, 2012 at 6:37 PM, 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 based upon syntax or static semantics rules that 
> only exist in ES6.  For example, a destructuring pattern
> ES5-only:  The construct is based upon syntax that or static semantics rules 
> that that are not in ES6. For example, use of a with statement t.
> ES5&ES6:  The construct has identical semantics in both ES5 and ES6.
> 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 to the corresponding element of the function's 
> arguments object.
> 
> We can then use the following state machines to describes the processing of a 
> Program based upon the occurrence for these feature categories.  Initially 
> start in State 5&6:
> 
> State 5&6
> if current construct is in ES5&ES6, process using intersection semantics, 
> then goto State 5&6
> if current construct is in ES5~ES6, process using ES5 semantics then, 
> goto State Compat5
> if current construct is in ES5-only, process using ES5 semantics then 
> goto  State ES5
> if current construct is in ES6-only, process using ES6 semantics then 
> goto State ES6
> 
> State ES5
> if current construct is in ES5&ES6, process using intersection semantics, 
> then goto State ES5
> if current construct is in ES5~ES6, process using ES5 semantics, then 
> goto State ES5
> if current construct is in ES5-only, process using ES5 semantics then 
> goto  State ES5
> if current construct is in ES6-only, terminate with Error: invalid 
> combination of ES5 and ES6 features
> 
> State ES6
> if current construct is in ES5&ES6, process using intersection semantics, 
> then goto State ES6
> if current construct is in ES5~ES6, process using ES6 semantics, then 
> goto State ES6
> if current construct is in ES5-only, terminate with Error: invalid 
> combination of ES5 and ES6 features
> if current construct is in ES6-only, process using ES6 semantics then 
> goto  State ES6
> 
> State Compat5  (or have an analogous Compat6 state, and restart to State ES5 
> when necessary)
> if current construct is in ES5&ES6, process using intersection semantics, 
> then goto State Compat5
> if current construct is in ES5~ES6, process using ES5 semantics then, 
> goto State Compat5
> if current construct is in ES5-only, process using ES5 semantics then 
> goto  State ES5
> 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.
> If a Program can not be explicitly identified as either ES5 or ES6, it is 
> treated as an ES5 program

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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 really exists to be an ES3 compatibility mode, and was
constrained to be backwards compatible from ES3. Likewise, I am happy to
call the new ES6 strict simply "ES6".

Concretely, I am confused how your transition diagram is supposed to handle
"use strict";. Reading your state machine literally, since "use strict"; is
accepted by ES5, if it is accepted by ES6 (as I think we all agree it would
be), then it would leave us in state ES5&ES6. Were you two base categories
"ES6 non-strict" (or ES3) and "ES6 strict" (or ES6), then a "use strict";
would put us in your ES6 strict (or ES6) category, which is what I would
have expected.


On Thu, Jan 5, 2012 at 6:37 PM, 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 based upon syntax or static semantics rules
> that only exist in ES6.  For example, a destructuring pattern
> ES5-only:  The construct is based upon syntax that or static semantics
> rules that that are not in ES6. For example, use of a with statement t.
> ES5&ES6:  The construct has identical semantics in both ES5 and ES6.
> 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 to the corresponding element of the
> function's arguments object.
>
> We can then use the following state machines to describes the processing
> of a Program based upon the occurrence for these feature categories.
>  Initially start in State 5&6:
>
> State 5&6
> if current construct is in ES5&ES6, process using intersection
> semantics, then goto State 5&6
> if current construct is in ES5~ES6, process using ES5 semantics then,
> goto State Compat5
> if current construct is in ES5-only, process using ES5 semantics then
> goto  State ES5
> if current construct is in ES6-only, process using ES6 semantics then
> goto State ES6
>
> State ES5
> if current construct is in ES5&ES6, process using intersection
> semantics, then goto State ES5
> if current construct is in ES5~ES6, process using ES5 semantics, then
> goto State ES5
> if current construct is in ES5-only, process using ES5 semantics then
> goto  State ES5
> if current construct is in ES6-only, terminate with Error: invalid
> combination of ES5 and ES6 features
>
> State ES6
> if current construct is in ES5&ES6, process using intersection
> semantics, then goto State ES6
> if current construct is in ES5~ES6, process using ES6 semantics, then
> goto State ES6
> if current construct is in ES5-only, terminate with Error: invalid
> combination of ES5 and ES6 features
> if current construct is in ES6-only, process using ES6 semantics then
> goto  State ES6
>
> State Compat5  (or have an analogous Compat6 state, and restart to State
> ES5 when necessary)
> if current construct is in ES5&ES6, process using intersection
> semantics, then goto State Compat5
> if current construct is in ES5~ES6, process using ES5 semantics then,
> goto State Compat5
> if current construct is in ES5-only, process using ES5 semantics then
> goto  State ES5
> 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.
> If a Program can not be explicitly identified as either ES5 or ES6, it is
> treated as an ES5 program.
>
> If you want to explicitly force ES6 processing put a:
>   let ES6;
> at the top of the source file.
>
> If you want to explicitly force ES5 processing put a:
>   with (5);
> at the top of the source file
>
> Allen
>
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

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 in ES6.  For example, a destructuring pattern
ES5-only:  The construct is based upon syntax that or static semantics rules 
that that are not in ES6. For example, use of a with statement t.
ES5&ES6:  The construct has identical semantics in both ES5 and ES6.
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 to the corresponding element of the function's arguments 
object.

We can then use the following state machines to describes the processing of a 
Program based upon the occurrence for these feature categories.  Initially 
start in State 5&6:

State 5&6
 if current construct is in ES5&ES6, process using intersection semantics, 
then goto State 5&6
 if current construct is in ES5~ES6, process using ES5 semantics then, goto 
State Compat5
 if current construct is in ES5-only, process using ES5 semantics then goto 
 State ES5
 if current construct is in ES6-only, process using ES6 semantics then goto 
State ES6

State ES5
 if current construct is in ES5&ES6, process using intersection semantics, 
then goto State ES5
 if current construct is in ES5~ES6, process using ES5 semantics, then goto 
State ES5
 if current construct is in ES5-only, process using ES5 semantics then goto 
 State ES5
 if current construct is in ES6-only, terminate with Error: invalid 
combination of ES5 and ES6 features

State ES6
 if current construct is in ES5&ES6, process using intersection semantics, 
then goto State ES6
 if current construct is in ES5~ES6, process using ES6 semantics, then goto 
State ES6
 if current construct is in ES5-only, terminate with Error: invalid 
combination of ES5 and ES6 features
 if current construct is in ES6-only, process using ES6 semantics then goto 
 State ES6

State Compat5  (or have an analogous Compat6 state, and restart to State ES5 
when necessary)
 if current construct is in ES5&ES6, process using intersection semantics, 
then goto State Compat5
 if current construct is in ES5~ES6, process using ES5 semantics then, goto 
State Compat5
 if current construct is in ES5-only, process using ES5 semantics then goto 
 State ES5
 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.
If a Program can not be explicitly identified as either ES5 or ES6, it is 
treated as an ES5 program.

If you want to explicitly force ES6 processing put a:
   let ES6;
at the top of the source file. 

If you want to explicitly force ES5 processing put a:
   with (5);
at the top of the source file

Allen


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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


> - ES{3,5}.non-strict is neither a subset nor a superset of ES6, it has to be 
> handled differently.
> 
> If these modes (strict versus non-strict) exist, then I would want a per-file 
> marker for strict code:
> - "use strict";

This doesn't mean Harmony, though. Not now, in ES5 implementations -- it means 
only ES5-strict. And not in dowrev impls, where it means nothing (and semantics 
differ at runtime).


> - use strict;

This is a good idea but it was not proposed by Dave to mean Harmony opt-in. 
Rather, |use module;| was, as a way to avoid bracing and indenting a top level 
hunk of code in an anonymous module {...} declaration.


> - module {
> 
> 
> Compared to languages such as Java, JavaScript additionally faces the 
> challenge that a developer can’t control what language version is implemented 
> by the browser. How will that be handled? Sketching a solution would provide 
> a more complete picture of how to migrate to ES6.

APIs can be object-detected. New syntax requires autoconf-style eval/Function 
tests. All doable, nothing mysterious, some try/catch pain required.

I rather expect a boot-loader script will use more coarse-grained means of 
deciding what to fetch. We had proposed a way to reflect on the maximum 
supported version (__ECMASCRIPT_VERSION__, IIRC) but that was unsatisfying. 
More to do here.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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}) { print(function () {"use strict"; return p;}()); }
1

The strict function expression still has to cope with the nasty object scope 
environment on its outside.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 one (of 
N) functions declared or expressed in the program. We could be narrow and 
impute Harmony opt-in only to the nearest containing function (or failing that, 
program). That might help incremental migration, indeed, and it seems a more 
locally "reasonable" rule.

But it may be that developers would benefit more from 
in-for-a-penny-in-for-a-pound. Hard to say without user testing.


>  In other words, the default is strict mode unless the code exclusively uses 
> ES5 syntactic constructs.

Right, but we need to settle on the unit or scale of "the code".

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 isn't exactly a No. ;)

Trying to avoid scope creep. Also not dismissing RFC4329 ;version=6 parameter 
setting -- that works to hide new code from old browsers (I believe back to IE8 
-- perhaps not the geriatric browsers).


>> Now what do you say?
> 
> Sorry, I still think that a growing set of subtle implicit rules for
> activating subtle semantic changes

Not changes, new semantics for new syntax. The fingers of fate may allow 
completion reform (Mark and I think so). The interactions are not that hard, 
and making a mode-wall doesn't avoid solving all of them -- you still may have 
runtime (heap-based) interactions between old and new modes.

We did JS1.7 this way, BTW. You had to opt in to get 'let' and 'yield', but 
that was for the compiler. We did not hold back other features, and there were 
no runtime (post-compile) version checks:

brendan-eichs-computer-3:src.old brendaneich$ grep VERSION_1_7 *.c
jsapi.c:{JSVERSION_1_7, "1.7"},
jsparse.c:   || (JSVERSION_NUMBER(cx) == JSVERSION_1_7 &&
jsparse.c:   ((JSVERSION_NUMBER(cx) == JSVERSION_1_7 &&
jsparse.c:if (JSVERSION_NUMBER(cx) == JSVERSION_1_7) {
jsparse.c:if (JSVERSION_NUMBER(cx) == JSVERSION_1_7) {

(jsapi.c is just a string <-> enumerator mapping table; jsparse.c shows the 
compiler checks.)


> on a fine-grained level is far more
> confusing (and error-prone!) than helpful. In all sorts of ways.

Our experience was that adding new features to the default version where there 
was no backward incompatibility was not confusing. We've been doing this since 
2006. Not to say all the particulars are right, or that we anticipated all the 
combinations of ES5-strict and Harmony, of course! But I think you protest too 
much without evidence.


> I'm also concerned about the 3 and a half language modes that might
> result. With Dave's original proposal at least, the only opt-in was on
> module level.

Dave mentioned generators, IIRC. We were thinking of classes too (talked about 
it privately).


> 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. But see below, I agree 
the opt in has to be "chunky", and is in the (not perfectly clear, complete, 
etc.) proposal for "ES6 doesn't need [version] opt-in".


> Allen
> gave a couple of good examples we also ran into when trying to
> implement block scoping liberally in V8 -- in the end, we concluded
> that it doesn't make sense to allow opting into extended mode locally.

Yes, this is one place where during the ES4 period, we made 'let' at top level 
of program and function bodies equate to 'var', which is no good (arguments 
aliasing, for one). But lesson learned.

The idea is to opt in at least the enclosing function, if not the enclosing 
Program (non-terminal, so 

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

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 warming to the idea.
> 
> I think having the opt-in unit be the destructuring pattern and everything 
> recursively contained within it would be a bad idea. In this regard, 
> destructuring is a different category of opt-in by new syntax than is module, 
> class, and generator.

This first came up in the context of formal parameters that use destructuring 
(or default value initializers, or rest).  In that case, the idea was that this 
would imply that the function with those parameters is a "strict" function.

Whether  the use of destructuring (or rest/spread) in declarations or 
expressions within the body of the function also implies a "strict" function is 
potentially a separate issue. However, I  think we need to keep things as 
simple and consistent as possible so on that basis perhaps they should also 
imply a strict function.  In neither case, were we thinking of restricting the 
strictness to just the destructuring pattern itself.

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.  In other words, the default is strict mode unless the code 
exclusively uses ES5 syntactic constructs.

Allen



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Axel Rauschmayer]

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 
ES6 code bases.
- ES{3,5}.non-strict is neither a subset nor a superset of ES6, it has to be 
handled differently.

If these modes (strict versus non-strict) exist, then I would want a per-file 
marker for strict code:
- "use strict";
- use strict;
- module {


Compared to languages such as Java, JavaScript additionally faces the challenge 
that a developer can’t control what language version is implemented by the 
browser. How will that be handled? Sketching a solution would provide a more 
complete picture of how to migrate to ES6.

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Andreas Rossberg]

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-mode programs, we
>> now have to define many features for both modes (and mixed uses of
>> both modes). I.e., there are more syntactic and semantic combinations
>> to worry about.
>
> Yes, this is a trade-off. It probably helps developers migrate, provided they 
> choose sane combinations. For example, Allen (private correspondence) 
> wondered if a function using the arguments object is evolved to have 
> destructuring parameters:
>
>  function f({a,b}, c) { arguments[0] = {a:3,b:4}; return [a, b] }
>  f({a:1,b:2}, 3);
>
> I say anyone wanting deep aliasing (f returns [3, 4]) should suffer 
> disappointment. I doubt developers want such deep aliasing, and no 
> implementor does.

Whoa, yeah, please let's not go there.


>> - All this together (new features in old mode,
>
> Nope. ;-)
>
>
>> implicit opt-in,
>
> Yup.
>
>
>> 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 isn't exactly a No. ;)

> Now what do you say?

Sorry, I still think that a growing set of subtle implicit rules for
activating subtle semantic changes on a fine-grained level is far more
confusing (and error-prone!) than helpful. In all sorts of ways.

I'm also concerned about the 3 and a half language modes that might
result. With Dave's original proposal at least, the only opt-in was on
module level. That precluded a number of highly undesirable
combinations, e.g. extended mode nested into a "with" statement. Allen
gave a couple of good examples we also ran into when trying to
implement block scoping liberally in V8 -- in the end, we concluded
that it doesn't make sense to allow opting into extended mode locally.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Andreas Rossberg]

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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Andreas Rossberg]

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 proposed, it's an alternative to explicit
>>> anonymous module{...} bracketing syntax that translates the block or body
>>> enclosing the pragma to an anonymous module.
>>
>> Yes, I understand that. My point was that you can reformulate all
>> that, for (almost) equivalent effect, by saying that "use module" is
>> _not_ a module definition, but basically the same mode pragma as
>> before,
>
> Just to be clear: you mean |use version 6;| here by "mode pragma as before"?

Yes.

>> The only difference I can see with this description is its effect on
>> the semantics of multi-part scripts.
>
> Dave's proposal has
>
>   
>     window.foo = "hi";
>   
>   
>     use module;
>     alert(foo);
>   
>
> desugar to
>
>   
>     window.foo = "hi";
>   
>   
>     module {
>       alert(foo);   // no early error, runs and alerts "hi"
>     }
>   
>
> which is not the same as what we were thinking of with "no global object as
> top scope" enabled by a version pragma:
>
>   
>     window.foo = "hi";
>   
>   
>     use version 6;
>     alert(foo);     // early error here!
>   

Right. That's (part of) what I was alluding to with my above remark. ;)

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Claus Reinke]

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 bit of experience with, and I've tried to raise the issue
of feature-based language versioning here earlier [1,2].

In Haskell's beginning, there was the single language standard, and
every implementation had a single flag for enabling all of its additional
or experimental features (beyond the standard). But implementations
come and go, and even the de-facto standard of most-widely-used
implementation has changed over time. Even when several
implementations agreed on a feature, they might disagree on some
details (eg, a proven safe but restrictive variant versus a possibly
unsafe but pragmatically better version). And the language
committees have been notoriously slow in adopting experimental
features into the language standard.

So the situation became untenable, and the solution was feature-based
language versioning (based on pragmas), in addition to named standards:

By default, code is interpreted according to the most recent language
standard but, for stability, code can explicitly opt into a specific version
of the standard. Up to here, that is similar to Javascript, only that the
version can be specified in code pragmas as well.

On top of this default, language *extensions* can be selected individually,
via pragmas. It is then up to the implementation to recognize whether
or not the selected set of language extensions is supported. As in JS,
language extensions tend to have recognizable syntax, too, so
implementations can also warn intelligently about attempts to use
features that have not been selected (or about conflicts that arise
because of features that have been selected, such as stolen syntax).

Useful language extensions can be adopted by other implementations
(at which point they need to be specified, not just implemented), and
later moved into one of the next language standards. Agreeing on the
next language standard becomes more of gather-successful-features
than redesign-everything-from-scratch, with shorter language update
cycles as well. A feature missing a language update deadline becomes
less of an issue, as it is still available as an extension. Features that do
not work out in practice are easier to remove, as they have their own
pragma (not mixed into a numeric language version).

In the current phase of JS evolution, with an evolving new standard
and partial implementations of new features, it would be especially
helpful to identify which features a piece of code depends on and
which features a given implementation supports. Being able to opt
in to new features individually also puts a bound on upgrade work
(e.g. opt into let, but not yield, or vice-versa), and helps to ensure
that coders are aware of changes (if I opt into let, I expect let to be
special; if I opt into ES.next because I want yield, I might be surprised
by changes to let and scope and typeof and ..).

Just a thought..
Claus

[1] Should ES begin to standardise pragmas?
   https://mail.mozilla.org/pipermail/es-discuss/2011-April/013791.html
[2] feature-based and compartment-based language versioning
   https://mail.mozilla.org/pipermail/es-discuss/2011-July/015755.html


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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 destructuring pattern and everything
recursively contained within it would be a bad idea. In this regard,
destructuring is a different category of opt-in by new syntax than is
module, class, and generator.


On Wed, Jan 4, 2012 at 4:53 PM, Brendan Eich  wrote:

> 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 may well be the shortest path to migration and adoption, esp.
> compared to version= lock-in.
>
> /be
>
>
> >
> > --
> > Cheers,
> > --MarkM
>



-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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

> 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 language versions being such a prominent issue on the web, I wouldn’t 
> mind seeing at first glance what kind of code I am looking at.
> 
> My idea might be completely off, but whatever the final solution, it should 
> be dead-simple to explain.
> 
> On Jan 5, 2012, at 0:56 , Mark S. Miller wrote:
> 
>> (BTW I still think we want a real |use strict;| pragma, to choke old 
>> implementations.)
>> 
>> Yes. Crock suggested this in the old ES5 days and I think it is still a good 
>> idea:
>> 
>> "use strict"; // still runs on old browsers, but non-strictly
>> 
>> use strict;  // causes an early error on old browsers.
>> 
>> Had we adopting it into ES5, it would have this meaning clearly. It may 
>> still be a good idea, but consider the new complexity. Now the second form 
>> also causes an early error on old ES5 browsers, where the script might 
>> otherwise have been able to run strictly.
>> 
> 
> -- 
> Dr. Axel Rauschmayer
> a...@rauschma.de
> 
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
> 
> 
> 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 may well be the shortest path to migration and adoption, esp. 
compared to version= lock-in.

/be


> 
> -- 
> Cheers,
> --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Axel Rauschmayer]

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 language versions being such a prominent issue on the web, I wouldn’t 
mind seeing at first glance what kind of code I am looking at.

My idea might be completely off, but whatever the final solution, it should be 
dead-simple to explain.

On Jan 5, 2012, at 0:56 , Mark S. Miller wrote:

> (BTW I still think we want a real |use strict;| pragma, to choke old 
> implementations.)
> 
> Yes. Crock suggested this in the old ES5 days and I think it is still a good 
> idea:
> 
> "use strict"; // still runs on old browsers, but non-strictly
> 
> use strict;  // causes an early error on old browsers.
> 
> Had we adopting it into ES5, it would have this meaning clearly. It may still 
> be a good idea, but consider the new complexity. Now the second form also 
> causes an early error on old ES5 browsers, where the script might otherwise 
> have been able to run strictly.
> 

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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 value on the heap shared
by legacy non-strict scripts and newfangled Harmony strict scripts. So far
we've been careful that the opt-in switches only per-code properties, not
per-heap properties. How would this work.


>
> We need a normative spec, of course! But we do not need to support new
> features in pre-strict-mode, indeed pre-ES6, combinations. New syntax is
> the opt-in!
>

If all new syntax causes opt-in, that does effectively bar non-strict mode
from being extended with non-strict versions of these primitives. That's a
fine outcome, but I'm surprised to hear it.

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.

-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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 and I agreed
earlier that "class" would also opt-in, so I'm not sure what you're arguing
against.


>
> My argument is not against strict mode (the basis of Harmony!) but rather
> against requiring "use strict"; directives to use new features that can be
> expressed without incompatible meaning shifts (only with guaranteed early
> errors in pre-Harmony implementations).


We're already agreeing that there should be multiple ways to opt-in to
strict mode, with "function*" joining this happy set.


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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
> > already there. But even with that, you still have to rely on explicit
> > opt-in (via "use strict"?) for enabling some features elsewhere.
>
> Which features?
>

Lexical scoping (top level aside of course). Encapsulated functions. Sane
arguments. Poisoning of .caller, .callee, .arguments. Ability to write code
that continues to run on old browsers and to run sanely on old ES5
browsers. Throw errors on failed assignment rather than silently continuing
as if everything is fine. Throw exception on a failed delete. Throw on
assigning to an undefined variable rather than having misspelling silently
create a new global. Preventing an eval from corrupting its caller's
scope. Need I go on? Compared to ES5 strict, ES5 non-strict is insane.

Regarding adoption of strict, another audience we should keep in mind is
people newly learning JavaScript. Would you rather teach them to say "use
strict"; or teach them to program in a language without sane scope rules or
encapsulated functions, and with silent errors?


No -- "use strict"; the string literal expression-statement is meaningless
> pre-ES5, ES5-strict in ES5, and redundant in Harmony code.


I don't see how it can be redundant in harmony code. Say I write a script,
intending it to be harmony, but which doesn't begin with "class", "module",
"function*", or whatever else we decide is a new opt-in. But I want the
code above the first, say "module", to still obey harmony rules rather than
non-strict rules. I would still need to say something else at the top of
the script to ensure this.


>
> (BTW I still think we want a real |use strict;| pragma, to choke old
> implementations.)


Yes. Crock suggested this in the old ES5 days and I think it is still a
good idea:

"use strict"; // still runs on old browsers, but non-strictly

use strict;  // causes an early error on old browsers.

Had we adopting it into ES5, it would have this meaning clearly. It may
still be a good idea, but consider the new complexity. Now the second form
also causes an early error on old ES5 browsers, where the script might
otherwise have been able to run strictly.


>
> Now what do you say?



-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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 "previously-illegal
token sequence" approach. It does feel like an example of
it readability wise. The eye rapidly learns to see "function*" as a
keyword. The extra grammar complexity to recognize it is minimal.



> If yes for generators, then why not for comprehensions, rest/spread,
> destructuring (separate from the 'let' issue), for/of, and other new forms?
>

I hadn't thought about comprehensions. As for rest/spread and
destructuring, sure, if there's no complexity. However, Allen just pointed
out that there would be complexity for allowing non-strict destructuring,
so let's not. If we run across problems with the others, then probably not
for those either. We've got enough important things to do that we shouldn't
waste any time enhancing non-strict mode when doing so is non-trivial.


>
> /be
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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



Good arguments -- both you and Andreas. I withdraw the suggestion that
these be normative optional -- it indeed accomplished nothing useful.
Instead, we simply do not forbid them in non-strict mode, which as you
observe has always been the status quo.

I accept that destructuring is problematic for reasons I've overlooked. No
doubt others are too. For each one, the first solutions we should reach for
are 1) leave them out of strict mode, or 2) (as you suggest) make its
presence an implicit opt-in to strict mode (which amusingly does
effectively forbid it from appearing in non-strict code).

For destructuring, I think it is less suggestive notationally that it
represents a boundary at which rules change, so I would rather simply omit
it from non-strict mode. But either way would avoid these specification
complexities, which I agree we should avoid.


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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 tool should by
> default
> > warn on the presence of any non-strict code. And every IDE should offer
> to
> > make the code strict if it isn't already.
>
> Well, I had hoped that with ES6 we have more elegant ways of opting
> into Harmony than something like the "use strict" kludge. I also
> thought that that was part of Dave's motivation.
>

For style guides targeting ES6 only code, yes. They should simply advocate
opting into strict mode in some way, and the preferred choice is unlikely
to be "use strict";. For ES5, or for any code that must work on pre-ES6
browsers, "use strict"; is of course the only way to opt in to strict mode.
I was thinking in terms of styles guides that anyone might write in the
next three years.

-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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. For any ES6 features that have no dependence on 
>> mode, like destructuring, we mandate that they be present in strict code, 
>> and we make them normative optional (the new Appendix B category) in 
>> non-strict code. Implementors are free to implement them or not in 
>> non-strict mode, but if they implement them, it must mean the same thing as 
>> the mandated meaning in strict code.
> 
> I don't think we every contemplated forbidding implementations from extending 
> non-strict modes with versions of new features ES6 features.
> 
> However, your assumptions that destructuring has has no mode dependencies is 
> wrong and a good example of why it is not so trivial to "include" it in 
> non-strict code. Here are some of the dependencies  I've already run into WRT 
> formal parameter destructuring:
>  using 'arguments'  (or 'eval') in a formal parameter destructuring 
> pattern or as a rest parameter - currently forbidden by strict mode

Destructuring opts into strict mode or rather its successor, ES.next. Harmony 
rolls on this way.


>  effect of multiple use of the same name - currently forbidden in strict 
> mode but currently allowed in non-strict mode

Not allowed by JS1.[78]* in SpiderMonkey or Rhino -- we prefigured ES5-strict 
on this, for sanity. When you use destructuring parameters in Firefox, you 
cannot have duplicate parameter names *anywhere* in the parameter list.

js> function f({a,b},a){}
typein:1: SyntaxError: duplicate argument is mixed with destructuring pattern:
typein:1: function f({a,b},a){}
typein:1: ^
js> function f(b,{a,b}){} 
typein:2: SyntaxError: duplicate argument is mixed with destructuring pattern:
typein:2: function f(b,{a,b}){}
typein:2: .^
js> function f({a,a},c){} 
typein:3: SyntaxError: duplicate argument is mixed with destructuring pattern:
typein:3: function f({a,a},c){}
typein:3: ...^


>  interaction between new formal parameter forms and non-strict mode 
> arguments object

See above. Function is implicitly strict.


>  how is declaration instantiation order for non-strict functions impacted 
> by parameter default value expressions

See above, again.


>  can the temporal dead-zone rules related to parameter default value 
> expression evaluation in strict mode also apply to non-strict functions

Ditto.


> These tend to be subtle issues and the "right" answer is not always obvious.  
> If different implementors decided to add the new formal parameter affordances 
> to non-strict mode, without any guidance, they would likely come up with 
> differing solutions to some of these issues and hence create 
> imcompatabilities.

We need a normative spec, of course! But we do not need to support new features 
in pre-strict-mode, indeed pre-ES6, combinations. New syntax is the opt-in!


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

Sorry, I should have read this far. I guess the proposal was unclear enough 
that people went down a bad path (at least you, probably Mark and Andreas). 
Sorry about that -- the intention (at least my view of it when reviewing Dave's 
draft proposal) was that new syntax opts in, and at a function granularity at 
least!

/be___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 destructuring, we mandate that they be present in strict code, and 
> we make them normative optional (the new Appendix B category) in non-strict 
> code.

Too complicated. Why not just have "one JavaScript" (modulo ES5 strict mode, 
whether its selection was explicit or implicit)?


> Implementors are free to implement them or not in non-strict mode, but if 
> they implement them, it must mean the same thing as the mandated meaning in 
> strict code.

We need interop on the web. If we let implementations vary as to whether, e.g., 
rest parameters require "use strict", then I predict the implementations that 
*do not* require "use strict" will win, and we'll have to spec normative 
non-optional anyway.

I'm very sure developers will not want "use strict"; as a requirement. That 
battle has been lost already with most developers (the war goes on, but let's 
not refight unnecessarily).

Anyway, predictions aside, I do not agree we should require "use strict" if the 
syntax speaks for itself.

My argument is not against strict mode (the basis of Harmony!) but rather 
against requiring "use strict"; directives to use new features that can be 
expressed without incompatible meaning shifts (only with guaranteed early 
errors in pre-Harmony implementations).

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 bodies such a block lambda's or Dave's do { } 
> expressions, if they are adopted??

Oh absolutely block lambda bodies are in Harmony > ES5-strict mode, you betcha!

Ditto generator bodies.

Class bodies, we covered. Module bodies -- in the o.p.

I like do {...} expressions, BTW -- tweeted about them today. They would be a 
wafer-thin (John Cleese pseudo-French accent) addition to ES.next.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 both modes (and mixed uses of
> both modes). I.e., there are more syntactic and semantic combinations
> to worry about.

Yes, this is a trade-off. It probably helps developers migrate, provided they 
choose sane combinations. For example, Allen (private correspondence) wondered 
if a function using the arguments object is evolved to have destructuring 
parameters:

  function f({a,b}, c) { arguments[0] = {a:3,b:4}; return [a, b] }
  f({a:1,b:2}, 3);

I say anyone wanting deep aliasing (f returns [3, 4]) should suffer 
disappointment. I doubt developers want such deep aliasing, and no implementor 
does.

We don't get to clean the slate with JS, so making "mode walls" between 
language versions may help implementors (by which I include spec writers) but 
that's about it. Authors are not helped, and mode walls probably hurt (we hear).

I think we're better off working through the combinations, removing legacy 
(mis-)features as we go. For example, function f above, because it uses 
destructuring parameters, opts into the new language which *is* based on 
ES5-strict -- so there's no arguments aliasing at all!

The general idea would be that any new syntax that doesn't create backward 
compatibility problems on its face opts the containing (or following, in the 
case of new syntax in function head) body into strict mode. By body I probably 
mean function or program body and not just braced block.


> - Providing Harmony features in classic mode decreases the incentive
> for users to upgrade to strict mode. Is that a good thing?

See above -- Harmony > ES5-strict in the proposal and so users do upgrade to 
strict mode. They just don't have to sprinkle "use strict"; string literals 
expression statements around. That's a win.


> - 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
> already there. But even with that, you still have to rely on explicit
> opt-in (via "use strict"?) for enabling some features elsewhere.

Which features?


> As a
> result, we expect programmers to remember two separate, fairly random
> (for anybody not intimate with the history) lists of features that (1)
> require opt-in, and (2) imply opt-in. Style guides will probably
> suggest to put "use strict" on top of every Harmony program to escape
> the mess.

If the new syntax implies strict mode in the containing body, then this goes 
away.


> - All this together (new features in old mode,

Nope. ;-)


> implicit opt-in,

Yup.


> explicit opt-in)

No -- "use strict"; the string literal expression-statement is meaningless 
pre-ES5, ES5-strict in ES5, and redundant in Harmony code.

(BTW I still think we want a real |use strict;| pragma, to choke old 
implementations.)

Now what do you say?

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

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 they are adopted??

Allen




___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 Dave's proposal, use module {...}).
>>> 
>>> Ah, but wrapping into modules is incompatible with having multiple
>>> script parts.
>> 
>> I don't know what you mean. "Incompatible" in the sense that you cannot 
>> transform multiple scripts into multiple anonymous modules?
> 
> Yes.

That's a feature, in the proposal. You want the old behavior? Use 

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 module{...} bracketing syntax that translates the block or body 
>> enclosing the pragma to an anonymous module.
> 
> Yes, I understand that. My point was that you can reformulate all
> that, for (almost) equivalent effect, by saying that "use module" is
> _not_ a module definition, but basically the same mode pragma as
> before,

Just to be clear: you mean |use version 6;| here by "mode pragma as before"?


> except that it now is implicit with every module body.

Assuming you do, then there is a difference -- see below.


> The only difference I can see with this description is its effect on
> the semantics of multi-part scripts.

Dave's proposal has

  
window.foo = "hi";
  
  
use module;
alert(foo);
  

desugar to

  
window.foo = "hi";
  
  
module {
  alert(foo);   // no early error, runs and alerts "hi"
}
  

which is not the same as what we were thinking of with "no global object as top 
scope" enabled by a version pragma:

  
window.foo = "hi";
  
  
use version 6;
alert(foo); // early error here!
  

/be___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

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 strict mode. If it 
> > appears in non-strict code, it would be a SyntaxError.
> 
> That's a choice. I'm asking why it's the best one. Just because class syntax 
> might involve new reserved identifiers doesn't require strict mode. The 
> introductory keyword is class and the new keywords are all in the braced body.
> 
> The idea is that the always-reserved 'class' keyword is opt-in enough -- no 
> need for a "use strict"; string litearl (ignored by old browsers anyway!).
> 
> "opt-in enough", interesting. I'm not sure if this is what you meant, but it 
> suggests a very attractive option I hadn't considered: treat "class", like 
> "module", as yet another way to opt-in to strict mode. All code recursively 
> inside a class would be strict.

Yes, that's what I meant.

Harmony > ES5-strict  ES5 (> means supserset,  means neither super- nor 
subset).

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.


> For class, you're right. I really like the idea of having it be another way 
> to opt-in to strict mode. What other constructs might join "class" and 
> "module" as new strict-mode opt-ins?

As Dave mentioned, generators:

  function* Fibonacci() {
let [a, b] = [0, 1];
for (;;) {
  yield a;
  [a, b] = [b, a+b];
}
  }


> 
> > Want to use "let" scoping outside a module? Again, just say "use strict";.
> 
> The string literal directive is meaningless in old browsers, and the other 
> new syntax than let is guaranteed to fail with a syntax error in old engines, 
> so what's the benefit of requiring the extra "use strinct"; again?
> 
> Huh? In ES5, the following code is legal:
> 
> var let = 88;
> 
> The following code is not:
> 
> function foo() { "use strict"; var let = 88; }

Consider instead these examples:

  var let = 88;
  function foo() { "use strict"; let bar = 99; }

My point was pre-ES5 implementations don't respect "use strict", so the first 
line works while the second line fails with an early error due to unrecognized 
'let'. As you note, ES5 implementations support the first and fail on the 
second with a different early error.

Now, if ES6 implementations extend "use strict" to enable let, then suddenly 
both work.

Therefore if authors face ES5 and ES6 implementations in the field, saying "use 
strict" is not enough to reliably use 'let'. True, ES5 implementations will 
fail with an early error -- just as they would on class or module declarations. 
But they'd fail on most 'let' declarations anyway, so why should "use strict" 
be required?

This is the question: if 'let' can be used reliably only in ES6 implementations 
and it fails fast in pre-ES6 implementations, why insist on, or educate users 
to add, "use strict" -- especially when that is not meaningful to pre-ES5 
browsers, and the only difference between pre-ES5 and ES5 browsers is what kind 
of early error (perhaps just the message detail) is thrown?


> I don't want to twist the grammar to turn "let" into a context sensitive 
> reserved word so that somehow
> 
> "var let = 88;" and use of let-scoping can co-exist in the same mode. 
> This seems like too high a price to pay simply to avoid any of the strict 
> mode opt ins.

Agreed, that is a bridge too far and we've said so before. Gavin B. was asking 
again about it and I replied citing destructuring (let [x] = y; after another 
terminated statement) as one ambiguous case.


> Any code under active maintenance should opt-in to strict somehow anyway.

You think so but developers are not doing it. Some have tried and been burned 
by concatenation without testing in ES5 implementations. Others don't like the 
performance effects (real but not necessarily biting them). "use strict" is not 
catching on, sorry to relate, and this is why I do not think we should yoke 
'let' to it.

If we don't need to predicate 'let' on "use strict" to avoid backward 
incompatibility (other than in details of early error thrown), then we should 
not. The destructuring ambiguity remains, but perhaps there is a solution. 
Still thinking about this...


> Non-strict mode is only for legacy that needs to keep working without any 
> further human attention -- most of the web. This code already doesn't use let 
> scoping, so what's the issue?

There are two issues:

1. Needless "use strict" when new syntax (mostly or completely) is necessary 
and sufficient opt-in by itself. We agree this is the case for class and module 
-- also (I hope) for function*.

2. Lack of "use strict" adoption means coupling to it too much raises risk of 
ES6 non-adoption.


> Again, the criteria I care about is "practica

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

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 destructuring, we mandate that they be present in strict code, and 
> we make them normative optional (the new Appendix B category) in non-strict 
> code. Implementors are free to implement them or not in non-strict mode, but 
> if they implement them, it must mean the same thing as the mandated meaning 
> in strict code.

I don't think we every contemplated forbidding implementations from extending 
non-strict modes with versions of new features ES6 features.

However, your assumptions that destructuring has has no mode dependencies is 
wrong and a good example of why it is not so trivial to "include" it in 
non-strict code. Here are some of the dependencies  I've already run into WRT 
formal parameter destructuring:
  using 'arguments'  (or 'eval') in a formal parameter destructuring 
pattern or as a rest parameter - currently forbidden by strict mode
  effect of multiple use of the same name - currently forbidden in strict 
mode but currently allowed in non-strict mode
  interaction between new formal parameter forms and non-strict mode 
arguments object
  how is declaration instantiation order for non-strict functions impacted 
by parameter default value expressions
  can the temporal dead-zone rules related to parameter default value 
expression evaluation in strict mode also apply to non-strict functions

These tend to be subtle issues and the "right" answer is not always obvious.  
If different implementors decided to add the new formal parameter affordances 
to non-strict mode, without any guidance, they would likely come up with 
differing solutions to some of these issues and hence create imcompatabilities.
 
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 function.  

Allen
   

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Andreas Rossberg]

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 destructuring, we mandate that they be present in strict code,
> and we make them normative optional (the new Appendix B category) in
> non-strict code. Implementors are free to implement them or not in
> non-strict mode, but if they implement them, it must mean the same thing as
> the mandated meaning in strict code.

Hm, I don't understand what would be gained by that. You don't get rid
of the spec complexity. And you risk reducing cross-browser
compatibility, which is hardly a good thing. It doesn't really help
the browser vendors either.

I think for anything but legacy, we should avoid normative optional.

>> - 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
>> already there. But even with that, you still have to rely on explicit
>> opt-in (via "use strict"?) for enabling some features elsewhere. As a
>> result, we expect programmers to remember two separate, fairly random
>> (for anybody not intimate with the history) lists of features that (1)
>> require opt-in, and (2) imply opt-in. 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 tool should by default
> warn on the presence of any non-strict code. And every IDE should offer to
> make the code strict if it isn't already.

Well, I had hoped that with ES6 we have more elegant ways of opting
into Harmony than something like the "use strict" kludge. I also
thought that that was part of Dave's motivation.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Herby Vojčík]

Then, why not to put every feature on ES6 mode only and backporting them one 
by one, giving time for each backport to see if it really works and not 
putting effort to backport another one until the previous one is generally 
accepted as safe?


Herby

-Pôvodná správa- 
From: Allen 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 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 both modes (and mixed uses of
both modes). I.e., there are more syntactic and semantic combinations
to worry about.


Yes, I'm already seeing this as I look at the working draft of the ES6 
specification to see how I would have to modify it to support this new 
approach.  Rather than working in a small number of discrete modes, each of 
which implies a specific set of environmental semantic rules, I have to 
consider pairwise interactions between features that span modes.  Some 
initial issues I've had to look at are include the possibility of the 
presence of a local with scope when dealing with lexical declarations, 
impacts of being able to redeclare 'eval' or 'arguments',  and interactions 
between formal parameter destructuring and non-strict mode arguments 
objects.


If the impact was only on the spec. work this might not be a big deal, but 
these sorts of mode-crossing feature interactions are also visible to 
implementors and ES programmers and add practical and conceptual complexity 
that they will have to deal with.


There certainly are features (for example, is and isnt) which seem to have 
minimal impact in any mode.  But for others, there are complexities that go 
beyond just the syntactic compatibility issues.  Modes (whether via explicit 
or implicit opt-in) seem to help reduce this complexity.


I think Dave has pushed us down a useful path, but I also think we need to 
carefully semantic interactions as well as syntactic compatibility issues 
for each feature that we consider adding to "non-strict" code.  In some 
cases, it may make the language easier to understand and use if features are 
only available in "strict mode".


Allen

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

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 both modes (and mixed uses of
> both modes). I.e., there are more syntactic and semantic combinations
> to worry about.

Yes, I'm already seeing this as I look at the working draft of the ES6 
specification to see how I would have to modify it to support this new 
approach.  Rather than working in a small number of discrete modes, each of 
which implies a specific set of environmental semantic rules, I have to 
consider pairwise interactions between features that span modes.  Some initial 
issues I've had to look at are include the possibility of the presence of a 
local with scope when dealing with lexical declarations, impacts of being able 
to redeclare 'eval' or 'arguments',  and interactions between formal parameter 
destructuring and non-strict mode arguments objects.

If the impact was only on the spec. work this might not be a big deal, but 
these sorts of mode-crossing feature interactions are also visible to 
implementors and ES programmers and add practical and conceptual complexity 
that they will have to deal with. 

There certainly are features (for example, is and isnt) which seem to have 
minimal impact in any mode.  But for others, there are complexities that go 
beyond just the syntactic compatibility issues.  Modes (whether via explicit or 
implicit opt-in) seem to help reduce this complexity.

I think Dave has pushed us down a useful path, but I also think we need to 
carefully semantic interactions as well as syntactic compatibility issues for 
each feature that we consider adding to "non-strict" code.  In some cases, it 
may make the language easier to understand and use if features are only 
available in "strict mode".

Allen



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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 prohibit them either. For any ES6 features that have no dependence on
> mode, like destructuring, we mandate that they be present in strict code,
> and we make them normative optional (the new Appendix B category) in
> non-strict code. Implementors are free to implement them or not in
> non-strict mode, but if they implement them, it must mean the same thing as
> the mandated meaning in strict code.
>

Except for nested named function definitions, which already have bizarre de
facto behaviors in non-strict code that no one can fix. Perhaps there are
more such conflicts in legacy non-standard features? If so, we probably
need to exempt them as well.



-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Axel Rauschmayer]

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 from modes: What will ES6 support for legacy browsers look 
like?

- Wouldn’t you know per piece of code/file whether it is ES5 or ES6? And make 
that decision (all in or all out) per browser? I still don’t completely 
understand why/when it would be a mixed affair. I would write minimal setup 
code inline and then load a module as quickly as possible.

- One possibility: several versions of each file: ES3, ES5, ES6. Are there 
ideas for how we could either statically keep the versions and let each browser 
load the appropriate one or how we could dynamically compile (either 
server-side or client-side, possibly including caching)? This multi-version 
scheme could even be applied to (the JS code embedded in) HTML files.

Axel

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Mark S. Miller]

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 proposal (in both Dave's original form and
> with Mark's refinement) is that it essentially gives up the idea that
> Harmony builds on strict mode. It is not at all obvious to me what
> implications that will have. A few observations:
>
> - 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 both modes (and mixed uses of
> both modes). I.e., there are more syntactic and semantic combinations
> to worry about.
>
> - Providing Harmony features in classic mode decreases the incentive
> for users to upgrade to strict mode. Is that a good thing?
>


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 destructuring, we mandate that they be present in strict code,
and we make them normative optional (the new Appendix B category) in
non-strict code. Implementors are free to implement them or not in
non-strict mode, but if they implement them, it must mean the same thing as
the mandated meaning in strict code.


>
> - 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
> already there. But even with that, you still have to rely on explicit
> opt-in (via "use strict"?) for enabling some features elsewhere. As a
> result, we expect programmers to remember two separate, fairly random
> (for anybody not intimate with the history) lists of features that (1)
> require opt-in, and (2) imply opt-in. 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 tool should by default
warn on the presence of any non-strict code. And every IDE should offer to
make the code strict if it isn't already.



>
> - All this together (new features in old mode, implicit opt-in,
> explicit opt-in) makes it more subtle to see what piece of ES6 code is
> strict and which isn't. This is a disadvantage when reading code and a
> potential pitfall for refactoring (probably much worse than strict
> mode today).
>

The only sensible refactoring of non-strict code is to make it strict. All
other refactorings should start with that one.


>
> - Finally, not having a new mode restricts our ability to clean up the
> language beyond what's already in strict mode (see typeof).
>
> 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.
>
> /Andreas
>



-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss