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
