another problem with your grammar is that that NumericLiterals need to be Referable. For example the following is valid ES code:
0.0.toLocaleString() But these are just details that could be fixed. There are many grammars that describe any language and creating one is a design activity that involves many trade-offs. The shape of the grammar also has many impacts upon the organization and content of a language specification. Your grammar seems like a perfectly fine approach to describing ECMAScript expressions. However, we currently have a different grammar that originated over 15 years ago. In general, we try to incrementally extend that grammar rather than do major refactorings. We prefer to only do major refactoring when it is necessary in order to express the specification of major new or under specified features. This approach lets us focus on the work of specifying new features rather than just shuffling the existing spec. and reduces the risk of introducing unintended specification bugs. Another concern is that the entire grammar really needs to be revalidated after major changes. The last time the grammar was validated was for ES3 (1999) and we don't currently have the tools or people in place to validate it again (any volunteers out there??). Bottom line: You seem to have a reasonable approach to the expression grammar. There are pros and cons that could be debated about your formulation relative to the current formulation. But, what your formulation accomplishes can (and has) already been dealt with using techniques that don't require grammar changes. Since we have lots of other work to do to finish ES6, refactoring the grammar along your lines just doesn't seem like a good use of resources at this time. Allen On Sep 8, 2012, at 8:19 AM, Joseph Spencer wrote: > Ahh, I see that now. You can disregard what I noted about those > Constants. > > null however is defined in A.1, which still leaves much of my proposed > BNF on the table so please browse the rest of it. > > I modified most Productions above the UnaryExpression in A.3. > > It was necessary as well to change the rules for LeftHandSideExpression > for what is currently written allows this: 5=5. > > Did my attachments come through ok? > > Thanks, > > -Joe > > > On Sat, 2012-09-08 at 07:54 -0500, Jason Orendorff wrote: >> On Sat, Sep 8, 2012 at 4:06 AM, Joseph Spencer >> <[email protected]> wrote: >>> Note: NaN and undefined aren't included in A.1 Lexical Grammar; >>> however, Infinity is. Is this by design? My proposal adds them >>> to A.1. >> >> NaN, undefined, and Infinity aren't keywords in JS. They're just >> global constants (see 15.1.1.1 through 15.1.1.3.) >> >> You can make variables with those names... which makes for some >> funny-looking code, but it's allowed and for compatibility we mustn't >> change it: >> >> function f(undefined) { >> var NaN = "not a number", Infinity = 9999; >> if (undefined) >> return Infinity; >> throw NaN; >> } >> >> Infinity appears in A.2, not A.1; Number("Infinity") uses that >> grammar. But in ordinary JS code Infinity is just an identifier. >> >> Allen, for completeness, it'd be nice to point out the treatment of >> "Infinity" in the Note in section 9.3.1. I filed a bug: >> https://bugs.ecmascript.org/show_bug.cgi?id=649 >> >> -j >> >>> >>> In spite of being NumericLiterals, Infinity and NaN are currently >>> referrable e.g. Infinity.a NaN.a. This is reflected in my >>> proposal, but should probably be removed as referable if >>> compatability isn't a concern here. >>> >>> Let me know if there is anything that you find objectionable. I submit >>> this with all humility, so feel free to critique / reject it in any way >>> you see fit. >>> >>> >>> -Joe >>> >>> On Fri, 2012-09-07 at 10:37 -0700, Brendan Eich wrote: >>>> Joseph Spencer wrote: >>>>> Would it not be beneficial to bring Annex A into greater conformity with >>>>> the rest of the spec at this point? >>>> >>>> Maybe, but there's non-zero risk and the work has non-trivial >>>> opportunity cost. If you can come up with a minimal set of changes and >>>> propose them here, I'll take a look and see if TC39 has the budget to >>>> consider them. >>>> >>>> /be >>>>> >>>>> Such changes seem relatively safe (to a noobie that is ;), as any code >>>>> produced moving forward by devs would still parse just fine under older >>>>> implementations that allowed for the unwanted syntax. It seems that >>>>> doing so would also bring the ecosystem of implementations into greater >>>>> alignment moving forward. >>>>> >>>>> -Joe >>>>> >>>>> On Thu, 2012-09-06 at 16:41 -0700, Brendan Eich wrote: >>>>>> Joseph Spencer wrote: >>>>>>> My apologies on that one. I meant to type the following: >>>>>>> >>>>>>> PostfixExpression: >>>>>>> LeftHandSideExpression [no LineTerminator here] ++ >>>>>>> LeftHandSideExpression [no LineTerminator here] -- >>>>>>> >>>>>>> PrefixExpression: >>>>>>> ++ [no LineTerminator here] LeftHandSideExpression >>>>>>> -- [no LineTerminator here] LeftHandSideExpression >>>>>>> >>>>>>> It appears to me that as currently written the following is considered >>>>>>> valid sytax: >>>>>>> >>>>>>> ++++someVar; >>>>>> Yes, that is goofy. It dates back to ES1 -- if memory serves (and it may >>>>>> not at this late date), my original Netscape 2 "Mocha" JS engine did not >>>>>> parse this. >>>>>> >>>>>> However, I think it may fall out of a desire by Microsoft back in the >>>>>> ES1 days to support the goofy ability of "host objects" to return >>>>>> References (ECMA-262 spec term). >>>>>> >>>>>> >>>>>>> I hadn't thought about es3 compatability though, so I could see the >>>>>>> reasoning in keeping it as is. >>>>>> Yeah, engine implementors have no good incentive to tweak here, and some >>>>>> legitimate fear of a breaking change that would only lose market share. >>>>>> >>>>>> /be >>>>> >>>>> >>>>> >>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
