Annex A of 5th Edition

[Joseph Spencer]

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
> <js.developer.undefined at gmail.com> 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
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >