ES3.1 Draft: 11 June 2008 version available
Attaching comments.
In general this looks pretty clean. (Some obvious missing parts excepted.) Of the things that do not look clean I want to single out three worries specifically: That your strict mode is overreaching, that too much (any!) emphasis is placed on catering to a non-existent "secure subset" language, and that strict compatibility has not been maintained with JS1.6/1.7/1.8 in the methods incorporated from those specifications. See the comments for details. Also, there are numerous occasions where the proposed language is incompatible with Proposed ES4, so we have work to do to reconcile them.
and thanks for any work on making ES3 better while we wait for ES4!
One thing I miss form the targeted additions part of the spec is: function.bindEvent aka function.bindEventListener
The difference from function.bind is that binded arguments are appended after instead of before the arguments when called.
Example code for function.bind and function.bindEvent (where arguments is a true array):
function.bind = function() { // Binds arguments to a function, so when you call the returned wrapper function, // arguments are intact and arguments passed to the wrapper function is appended. // first argument is 'this' and the rest is arguments var args = arguments, __fn = this, __object = args.shift(); return function(){ return __fn.apply(__object, args.concat(arguments))}; };
function.bindEvent = function() { // Same as bind, but prepends the arguments to the wrapper function var args = arguments, __fn = this, __object = args.shift(); return function(){ return __fn.apply(__object, arguments.concat(args))}; };
I'm trying to understand the nature of the ES3.1 - ES4 subset relationship that this committee has agreed to.
p69 12.10. Disallowing the with statement in strict mode breaks the ES3.1 - ES4 subset relationship (we've found no compelling reason to ban it).
How does having ES4 support more than ES3.1 supports break the subset relationship?
- Sam Ruby
On Jun 12, 2008, at 9:45 AM, Sam Ruby wrote:
I'm trying to understand the nature of the ES3.1 - ES4 subset relationship that this committee has agreed to.
p69 12.10. Disallowing the with statement in strict mode breaks the ES3.1 - ES4 subset relationship (we've found no compelling reason to ban it).
How does having ES4 support more than ES3.1 supports break the subset relationship?
Having ES3.1 strict mode forbid features that ES4 strict mode does not
(but which are in both languages) feels like breaking the subset
relationship to me. The reason is that program that is purely ES3 but
has the strict mode pragma added could then be legal in one language
but not the other, which seems problematic.
To the extent that strict mode limits ES3-with-pragma programs, I
think it should impose the same limits in ES3.1 and ES4.
, Maciej
Fair question. I don't recall that it has been spelled out carefully, actually. I'll take a stab at it in the morning. (Also, the ES3 ->
ES3.1 and ES3 -> ES4 relationships are important.) Any useful
definition will have to deal with bugfixes and security fixes (like global type names being read-only under some circumstances in ES4).
On Thu, Jun 12, 2008 at 9:45 AM, Sam Ruby <rubys at apache.org> wrote:
p69 12.10. Disallowing the with statement in strict mode breaks the ES3.1 - ES4 subset relationship (we've found no compelling reason to ban it).
Regarding whether there's a compelling reason to ban "with", what about the issue that "with" is an insanely confusing construct?
On the spreadsheet, how much red was accumulated on "strict with"? IIRC, it was a lot. Does anyone think "with" is a valuable construct? Why? Anyone care to post a defense of "with"?
On Jun 13, 2008, at 10:11 AM, Mark S. Miller wrote:
On Thu, Jun 12, 2008 at 9:45 AM, Sam Ruby <rubys at apache.org> wrote:
p69 12.10. Disallowing the with statement in strict mode breaks the ES3.1 - ES4 subset relationship (we've found no compelling reason to ban it).
Regarding whether there's a compelling reason to ban "with", what about the issue that "with" is an insanely confusing construct?
The horse has left the barn.
On the spreadsheet, how much red was accumulated on "strict with"?
"Reformed with" was an attempt to restore lexical scope by exact type
annotation. That's what people voted down, not the ES1-3 "with"
statement.
IIRC, it was a lot. Does anyone think "with" is a valuable construct? Why? Anyone care to post a defense of "with"?
There's no point tilting at windmills. "with" is absolutely required
for web compatibility, and it won't go away for a long, long time --
if ever. It's insanely popular. It's not only common in extant or
"legacy" JS, new uses crop up all the time.
You might hope to cause "with" to go away by forbidding it in a new,
optional ES3.1 mode, but the chances of that seem at least as small
as the chances that "with" popularity will simply make people avoid
such a strict mode.
On Fri, Jun 13, 2008 at 10:21 AM, Brendan Eich <brendan at mozilla.org> wrote:
"Reformed with" was an attempt to restore lexical scope by exact type annotation. That's what people voted down, not the ES1-3 "with" statement.
I'm confused. Aren't we talking about "reformed with"? What other "with" do people imagine is compatible with strict mode? I must have missed something.
-----Original Message----- From: es4-discuss-bounces at mozilla.org [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Mark S. Miller Sent: 13. juni 2008 19:30 To: brendan at mozilla.org Cc: es3.x-discuss at mozilla.org; es4-discuss at mozilla.org Subject: Re: ES3.1 Draft: 11 June 2008 version available
On Fri, Jun 13, 2008 at 10:21 AM, Brendan Eich <brendan at mozilla.org> wrote:
"Reformed with" was an attempt to restore lexical scope by exact type annotation. That's what people voted down, not the ES1-3 "with" statement.
I'm confused. Aren't we talking about "reformed with"?
Dead for a long time, now.
What other "with" do people imagine is compatible with strict mode? I must have missed something.
The one in ES3. What makes it not compatible with strict mode?
Regarding whether there's a compelling reason to ban "with", what about the issue that "with" is an insanely confusing construct?
Compared to many other notations that language standards committees consider 'non-controversial' (such as using '*' to mean multiply and 'curly braces' for essential grouping) this would seem to be a very mild insanity.
Mike
Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
On Fri, Jun 13, 2008 at 11:20 AM, Lars Hansen <lhansen at adobe.com> wrote:
What other "with" do people imagine is compatible with strict mode? I must have missed something.
The one in ES3. What makes it not compatible with strict mode?
Doesn't it make static scope analysis impossible?
On Fri, Jun 13, 2008 at 11:32 AM, Mike Cowlishaw <MFC at uk.ibm.com> wrote:
Compared to many other notations that language standards committees consider 'non-controversial' (such as using '*' to mean multiply and 'curly braces' for essential grouping) this would seem to be a very mild insanity.
If it were merely equivalent to some expansion of this construct to the rest of the language, that'd be true. It isn't.
On Fri, Jun 13, 2008 at 2:44 PM, Mark Miller <erights at gmail.com> wrote:
On Fri, Jun 13, 2008 at 11:20 AM, Lars Hansen <lhansen at adobe.com> wrote:
What other "with" do people imagine is compatible with strict mode? I must have missed something.
The one in ES3. What makes it not compatible with strict mode?
Doesn't it make static scope analysis impossible?
Deleting a variable also makes static scope analysis impossible. (Deleting a property is fine.)
Once try/catch is fixed, I can't think of anything else that prevents static scope analysis of ES3.1 strict or ES4 strict. Does anyone know of any other cases?
On Jun 14, 2008, at 12:21 PM, Mark S. Miller wrote:
On Fri, Jun 13, 2008 at 2:44 PM, Mark Miller <erights at gmail.com>
wrote:On Fri, Jun 13, 2008 at 11:20 AM, Lars Hansen <lhansen at adobe.com>
wrote:What other "with" do people imagine is compatible with strict mode? I must have missed something.
The one in ES3. What makes it not compatible with strict mode?
Doesn't it make static scope analysis impossible?
Deleting a variable also makes static scope analysis impossible. (Deleting a property is fine.)
Deleting a variable is only possible for variables introduced by eval,
and I gather eval will not be able to inject bindings into local scope
in strict mode.
Once try/catch is fixed, I can't think of anything else that prevents static scope analysis of ES3.1 strict or ES4 strict. Does anyone know of any other cases?
Named function expressions have the same kind of problem as try/catch
(assuming the problem is a random non-activation object being on the
scope chain).
, Maciej
On Sat, Jun 14, 2008 at 10:49 PM, Maciej Stachowiak <mjs at apple.com> wrote:
On Jun 14, 2008, at 12:21 PM, Mark S. Miller wrote:
On Fri, Jun 13, 2008 at 2:44 PM, Mark Miller <erights at gmail.com> wrote:
On Fri, Jun 13, 2008 at 11:20 AM, Lars Hansen <lhansen at adobe.com>
Named function expressions have the same kind of problem as try/catch (assuming the problem is a random non-activation object being on the scope chain).
On the front of the scope chain, in fact:-
The production FunctionExpression : function Identifier ( FormalParameterListopt ){ FunctionBody } is evaluated as follows:
- Create a new object as if by the expression new Object().
- Add Result(1) to the front of the scope chain.
- This is stated in 10.1.4 Scope Chain and Identifier Resolution: "During execution within an execution context, the scope chain of the execution context is affected only by with statements (see 12.10) and catch clauses (see 12.14)."
The spec doesn't mention that FunctionExpression with Identifier can affect scope chain. Example:-
(function f() { var propertyIsEnumerable = 0; (function f() { alert(propertyIsEnumerable); //=> native code })(); })();
Garrett
On Jun 14, 2008, at 11:43 PM, Garrett Smith wrote:
The spec doesn't mention that FunctionExpression with Identifier can affect scope chain. Example:-
(function f() { var propertyIsEnumerable = 0; (function f() { alert(propertyIsEnumerable); //=> native code })(); })();
Both catch variables and named function expression bindings based on
Object properties are bugs in ES3, fixed in ES4 proposals and specs
for a while now, and fixed in some JS implementations (both cases are
fixed in Opera, IIRC; catch variables are let-based in Firefox 2 and 3).
On Sat, Jun 14, 2008 at 11:43 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
The spec doesn't mention that FunctionExpression with Identifier can affect scope chain. Example:-
(function f() { var propertyIsEnumerable = 0; (function f() { alert(propertyIsEnumerable); //=> native code })(); })();
Hi Garrett, thanks for alerting us to this bizarre behavior. I had no idea. I did reproduce this behavior and minor variants. However, oether variants didn't work, indicating that I don't yet understand what's happening here. For example, on Firefox 2.0.0.14 in squarefree:
var g = function f() { return x; }
g()
ReferenceError on line 1: x is not defined
g.x = 3;
3
g()
ReferenceError on line 1: x is not defined
As I thought I understood this example, I would have expected the last call to g() to return 3. Can someone explain why it doesn't?
On Jun 16, 2008, at 8:39 AM, Mark S. Miller wrote:
On Sat, Jun 14, 2008 at 11:43 PM, Garrett Smith
<dhtmlkitchen at gmail.com> wrote:The spec doesn't mention that FunctionExpression with Identifier can affect scope chain. Example:-
(function f() { var propertyIsEnumerable = 0; (function f() { alert(propertyIsEnumerable); //=> native code })(); })();
Hi Garrett, thanks for alerting us to this bizarre behavior. I had no idea.
Lars included it in "Compatibility Between ES3 and Proposed ES41",
section 1.6, although the example there shows only the catch variable
case. IIRC, Pratap pointed the problem out well over a year ago, but
I can't find the reference at the moment.
I did reproduce this behavior and minor variants. However, oether variants didn't work, indicating that I don't yet understand what's happening here. For example, on Firefox 2.0.0.14 in squarefree:
var g = function f() { return x; } g() ReferenceError on line 1: x is not defined g.x = 3; 3 g() ReferenceError on line 1: x is not definedAs I thought I understood this example, I would have expected the last call to g() to return 3. Can someone explain why it doesn't?
Ad-hoc properties on the function object do not show up as variables
referenced lexically, the bug is different. ES3 says (13, third
production's semantics):
The production FunctionExpression : function Identifier
( FormalParameterListopt ) { FunctionBody } is evaluated as follows:
- Create a new object as if by the expression new Object().
- Add Result(1) to the front of the scope chain.
- Create a new Function object as specified in section 13.2 with
parameters specified by FormalParameterListopt and body specified by
FunctionBody. Pass in the scope chain of the running execution
context as the Scope. - Create a property in the object Result(1). The property's name is
Identifier, value is Result(3), and attributes are { DontDelete,
ReadOnly }. - Remove Result(1) from the front of the scope chain.
- Return Result(3).
Therefore one bad case for a named function expression goes like this:
js> var g = function f(){return x}
js> Object.prototype.x = 'wrong'
wrong js> var x = 'right'
js> g()
wrong
Garrett showed an example using a standard property of
Object.prototype, propertyIsEnumerable.
Worse, the ES3 spec says "as if by the expression new Object()". So
by the book, one could do this (doesn't work in Firefox, Opera,
perhaps others who wisely ignore the spec):
js> var fake = {x:'fake'}
js> Object = function(){return fake}
js> var g = function f(){return x}
js> g()
fake
but you would need to be careful to restore Object to
fake.constructor or equivalent before going too far.
talks about the inconsistencies in ES3 between "original value
of ..." and "as if by the expression".
On Jun 16, 2008, at 10:49 AM, Brendan Eich wrote:
Lars included it in "Compatibility Between ES3 and Proposed ES41",
Meant to write "Compatibility Between ES3 and Proposed ES4[1]" there.
No ES4.1 or ES41 in sight!
/be
I have uploaded to the wiki (linkes3.1:es3.1_proposal_working_draft, see under "Draft Specification") the current draft of the specification for ES3.1. This is in the form of in-place edits and markups to the ES3 specification (specifically, on the 11 June draft). Revision history is at the end of the document.
I have not yet incorporated the review comments you sent on the 11 June draft. For the moment I am focusing on incorporating normative content, but will certainly address all of your review comments in upcoming drafts.
pratap
Is there a changelog between successive ES3.1 drafts?
--lars
From: es3.x-discuss-bounces at mozilla.org [mailto:es3.x-discuss-bounces at mozilla.org] On Behalf Of Pratap Lakshman (VJ#SDK) Sent: 26. juni 2008 22:23 To: es3.x-discuss at mozilla.org Cc: es4-discuss at mozilla.org Subject: ES3.1 Draft: 24 June 2008 version available
I have uploaded to the wiki (link <es3.1:es3.1_proposal_working_dra ft> , see under "Draft Specification") the current draft of the
specification for ES3.1. This is in the form of in-place edits and markups to the ES3 specification (specifically, on the 11 June draft). Revision history is at the end of the document.
I have not yet incorporated the review comments you sent on the 11 June draft. For the moment I am focusing on incorporating normative content, but will certainly address all of your review comments in upcoming drafts.
pratap
So far, we've been trying to primarily track changes relative to the original ES3 spec. and that is how we intend to release next week's version. However, we can probably create you a version that shows the delta's relative to the June 11 version if that would be helpful. I think after next week's release will probably be the right point to start trying to maintain a change log.
I wouldn't recommend putting much energy into the June 24 version as that is just a working draft that is not very clean or complete.
From: es4-discuss-bounces at mozilla.org [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Lars Hansen Sent: Thursday, June 26, 2008 9:18 PM To: Pratap Lakshman (VJ#SDK); es3.x-discuss at mozilla.org Cc: es4-discuss at mozilla.org Subject: RE: ES3.1 Draft: 24 June 2008 version available
Is there a changelog between successive ES3.1 drafts?
--lars
From: es3.x-discuss-bounces at mozilla.org [mailto:es3.x-discuss-bounces at mozilla.org] On Behalf Of Pratap Lakshman (VJ#SDK) Sent: 26. juni 2008 22:23 To: es3.x-discuss at mozilla.org Cc: es4-discuss at mozilla.org Subject: ES3.1 Draft: 24 June 2008 version available
I have uploaded to the wiki (linkes3.1:es3.1_proposal_working_draft, see under "Draft Specification") the current draft of the specification for ES3.1. This is in the form of in-place edits and markups to the ES3 specification (specifically, on the 11 June draft). Revision history is at the end of the document.
I have not yet incorporated the review comments you sent on the 11 June draft. For the moment I am focusing on incorporating normative content, but will certainly address all of your review comments in upcoming drafts.
pratap
Lars, The revision history that I am maintaining at the end of the document is the closest to a change log at the moment; it calls out the changes made between the 11 June draft and this one.
Just as a heads-up you should expect to see more changes between now and the next draft that we hope to upload in the 1st week of July; here are a few of the changes we will try to get into that version: (1) syntactic section for getter/setters (2) changes to strict mode (based on the email threads on the "use subset" directive) (3) changes related to renaming the [[Dynamic]] attribute (4) decimal (5) changes related to introducing const into the grammar (6) spec language fixes related to string indexing (7) Unicode clarifications Hopefully that should be a technically complete draft that people can start reviewing in preparation for the July TC39 meeting. Once we get that draft ready, I'll start maintaining an even more detailed change log.
In the meantime, if you want details beyond what is called out in the revision history, please let me know.
pratap
From: es4-discuss-bounces at mozilla.org [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Lars Hansen Sent: Friday, June 27, 2008 9:48 AM To: Pratap Lakshman (VJ#SDK); es3.x-discuss at mozilla.org Cc: es4-discuss at mozilla.org Subject: RE: ES3.1 Draft: 24 June 2008 version available
Is there a changelog between successive ES3.1 drafts?
--lars
From: es3.x-discuss-bounces at mozilla.org [mailto:es3.x-discuss-bounces at mozilla.org] On Behalf Of Pratap Lakshman (VJ#SDK) Sent: 26. juni 2008 22:23 To: es3.x-discuss at mozilla.org Cc: es4-discuss at mozilla.org Subject: ES3.1 Draft: 24 June 2008 version available
I have uploaded to the wiki (linkes3.1:es3.1_proposal_working_draft, see under "Draft Specification") the current draft of the specification for ES3.1. This is in the form of in-place edits and markups to the ES3 specification (specifically, on the 11 June draft). Revision history is at the end of the document.
I have not yet incorporated the review comments you sent on the 11 June draft. For the moment I am focusing on incorporating normative content, but will certainly address all of your review comments in upcoming drafts.
pratap
Lars had some very useful feedback on the June 11 ES3.1 draft that we have tried to incorporate into the July 4 draft. I promised several people that I would provide a detailed listing of the resolutions to Lars' issues. It is attached. In the document, a double strike out means that we have directly taken Lars' suggestion or otherwise resolved the issue in line with his comments. Single strike through means I think we have resolved (or at least noted) the issue, although perhaps differently than Lars had suggested. Items with no strike outs are still unresolved. In all cases, italic text are my comments. And "I" means Allen Wirfs-Brock and may or may not reflect the opinion of anybody else who is actively contributing to the ES3.1 specification draft.
From: es3.x-discuss-bounces at mozilla.org [mailto:es3.x-discuss-bounces at mozilla.org] On Behalf Of Lars Hansen Sent: Thursday, June 12, 2008 5:11 AM To: Pratap Lakshman (VJ#SDK); es3.x-discuss at mozilla.org Cc: es4-discuss at mozilla.org Subject: RE: ES3.1 Draft: 11 June 2008 version available
Attaching comments.
In general this looks pretty clean. (Some obvious missing parts excepted.) Of the things that do not look clean I want to single out three worries specifically: That your strict mode is overreaching, that too much (any!) emphasis is placed on catering to a non-existent "secure subset" language, and that strict compatibility has not been maintained with JS1.6/1.7/1.8 in the methods incorporated from those specifications. See the comments for details. Also, there are numerous occasions where the proposed language is incompatible with Proposed ES4, so we have work to do to reconcile them.
I have uploaded to the wiki (linkes3.1:es3.1_proposal_working_draft, see under "Draft Specification") the current draft of the specification for ES3.1. This is in the form of in-place edits and markups to the ES3 specification. Revision history is at the end of the document.
pratap