Annex A of 5th Edition

[Jason Orendorff]

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
>