974293 - var s=0.toString() causes error on every browser kind.

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Jim Michaels]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140212131424

Steps to reproduce:

var s=0.toString();


Actual results:

"SyntaxError: identifier starts immediately after numeric literal"

this is a cross-browser spec bug.
var s=0.toString();
gives the error in any js due to bug in the ecmascript 262 5.1 spec starting at I think
CallExpression on p.219 and the first entry in same causes conflict with last entry.
prioritizing MemberExpression over CallExpression . IdentifierName in CallExpression:
it's what currently allows 
var n=1.1;
and
var s=n.toString();
to work.
0.toString() is a CallExpression . IdentifierName because CallExpression 
however, because MemberExpression comes first in CallExpression:, 
DecimalLiteral first entry which matches 0. would not kick in.
DecimalLiteral comes from MemberExpression's MemberExpression . IdentifierName 
which leads to PrimaryExpression in DecimalLiteral,
which leads to Literal, 
which leads to NumericLiteral
which leads to DecimalLiteral and its first entry on p.214

the s=n.toString() is an an AssignmentExpression
which leads to ConditionalExpression
which leads to LogicalORExpression
which leads to LogicalANDExpression
which leads to BitwiseORExpression
which leads to BitwiseXORExpression
which leads to BitwiseANDExpression
which leads to EqualityExpression
which leads to RelationalExpression
which leads to ShiftExpression
which leads to AdditiveExpression
which leads to MultiplicativeExpression
which leads to UnaryExpression
which leads to PostfixExpression
which leads to LeftHandSideExpression
which leads to CallExpression

toString is not a reserved word in ecmascript 262 5.1.



Expected results:

should assign the string "0"

Comment 1

[Masatoshi Kimura [:emk]]

(0).toString() works.

Comment 2

[Till Schneidereit [:till]]

This isn't a bug at all. If you want to call methods on numeric literals without fractional parts, you have to use ..:
0..toString() works.

Comment 3

[Jim Michaels]

(In reply to Till Schneidereit [:till] from comment #2)
> This isn't a bug at all. If you want to call methods on numeric literals
> without fractional parts, you have to use ..:
> 0..toString() works.

I don't think the authors of the BNF grammar really intended for this to be a feature of the language.
I would think that other languages that can do something like 0.somefunction() (C#?) would not have a problem with what I reported.

reasons to change:
- newbies and learning examples tend to make up examples like this for simplicity's sake, and for learning and language. 
- it's reasonable assumption
- proving a workaround only shows that the language is flawed and the BNF needs to be redesigned.

reasons not to change:
- cost of manpower and time involved for changing existing codebase
- it's a minor problem very few people are likely to use (except for newbies and teachers and offchance surprises like I had)
- effort to redesign
- redesign could introduce new flaws
- debugging time for new js engine

just looking at the situation. maybe nothing should be done. I am not a mozilla dev. I am only a reporter at this point, with eng. skillset.

I can only think that the reasons to "not" were the real reason this was canned.
think: a BNF grammar can have bugs in it just like any program can. the question to ask is, "is it worth fixing?". my guess would be no. if you are an idealist, then go for it.
right now js is "good enough".

Comment 4

[Till Schneidereit [:till]]

(In reply to Jim Michaels from comment #3)
> reasons not to change:
> - cost of manpower and time involved for changing existing codebase
> - it's a minor problem very few people are likely to use (except for newbies
> and teachers and offchance surprises like I had)
> - effort to redesign
> - redesign could introduce new flaws
> - debugging time for new js engine

There's one overriding reason not to change this *in our JS engine*: spec changes get proposed and either adopted or rejected by the EcmaScript standard comittee, TC39.

You should propose this change on the es-discuss mailing list[1], where it can be discussed by people from all mainstream JS engines and a lot of people from the JS community.

[1]: https://mail.mozilla.org/listinfo/es-discuss

Comment 5

[Masatoshi Kimura [:emk]]

Please discuss on the ES-discuss list, then.