7.8.3 Numeric Literals

2010-03-09

This might be your first encounter with some complex productions. They tell you that the following form of literals will be deemed valid by the parser:

0
12345
1.
1.23
1.23E4
1.23e4
1.23e45
1.23e+4
1.23e-4

and

.23
.00
.23e4
.00e4
.00e0
.23E4
.23e45
.23e+4
.23e-4

and

0
12345
1e4
1E4
1e45
1e+4
1e-4

Disallowed are any other combinations... some illegal examples:

e14
12e
.e
.e14
015
0x14e+23
4+e24

There is no octal notation in the standard, but see Appendix B for an extented version that does interpret the octal notation. Strict mode is not allowed to parse a NumericLiteral as octal literals!

Note that the following string is bad

2.toString()

opposed to this, which is correct

2..toString()

This is because the parser should take the longest sequence of characters. When parsing the number in the first example, it will create a token including the dot, because it can be part of the number literal. Only then it encounters an Identifier, which matches no known productions and the whole string is rejected.

In the second example, obviously, the first dot is parsed as part of the NumericLiteral, but the second is not. It will become a Punctuator token and evaluate to a property call, eventually.

The specification then goes on to explicitly define for each case how the numeric value should be derived from a string literal. This can be seen as a grammar on its own and is specified in Appendix A.2.