Community
Participate
Working Groups
Xbase needs a double literal.
*** Bug 364955 has been marked as a duplicate of this bug. ***
I did some initial experiments to investigte possible syntactical ambiguities. Main problems occur because of the optional ';' to separate expressions in a block and the already very heavily loaded '.' operator. It is relatively easy if we make the non-fractional and fractional part of the mantissa mandatory, i.e. allow 0.1 1.0 but refuse .1 1. to avoid ambiguities like 0.1 // 0.1 or 0; .1 or 0.; 1 ? Furthermore leaving the sign of the exponent optional introduces a collision with the ID terminal rule, as e.g. 'e07' is a valid identifier. Thus we'd break existing code in a non-obvious way. Summarizing, that would mean the following literals would be valid 0.1 0.1e+10 1.0e-10 -1.0e-10 but not .1 // mantissa missing integer part 1. // mantissa missing fractional part .1e-7 // mantissa missing integer part 1.e-7 1.0e1 While this may help many users, I suppose it does not really meet the expectations, so I am leaving this open for discussion.
Could we change the IntLiteral to NumberLiteral with an EAttribute 'literal' of type String? The type provider could be used to determine the actual primitive type. We could even exploit the expected type (iff any) to 'simulate' BigInteger and BigDecimal literals such as var BigInteger i = 12345678901234567890123456789012345678901234567890 What do you think? NumberLiteral: value = NUMBER; terminal NUMBER: // see http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.2 ; NumberLiteral could provide support for hex numbers, octals (?) and even the new and fancy binary literals, too. We'd have to disallow floating point literals like '123.' since 123.toString() would be become something like double 123 this.toString() in the semantic model. Opinions?
Sounds good. I'll try to implement it that way. Let's see what further obstacles will appear.
I'd propose not to support hexadecimal floating point literals (see Sebastian's link). They are kind of hard to grasp, e.g. why is it a binary exponent in decimal format. I've never encountered them in real life. The worst thing is they introduce ambiguities, as e.g. 0x1.f could be interpreted as "(float)1" or "0x(1.f)" (=1 + 15/16) My initial comment on the ambiguities of FP literals still holds: We won't get full support for all number literals as in Java. We must e.g. choose whether def e0(int) is a valid method name because 1.e0 could be an extension method call or a FP literal.
we could write the rule such that whenever you have a '.' there must be a number afterwards. That is the following in INVALID 23.e-9 and must be expressed like e.g. : 2.3e-8 Same applies for the chars we use for float, double, etc... A bit limiting but should work.
First shot committed. You can now write as in Java 1 int 0x1 int 1L long 0x1l long 1f float 1d double 1.0 double 1E-20f float 1e20d double 1.0E-20f float 1.0e20d double As discussed before, if you use a dot you have to specify both, the integer and the fractional part, to avoid collisions with feature calls. I also skipped hexadecimal floats. In addition we have big number literals: 1b BigInteger 1.0e-20b BigDecimal The grammar looks a bit strange as I had to allow lookahead after '.' to enable '..' and feature calls. So I had to use a datatype rule. OTOH, I did not want to introduce any more keywords, so the exponential 'e' and the type qualifier chars had to go into terminal rules. Additional validation makes sure the numbers are well formated. I couldn't figure out how to make the implicit BigInteger/BigDecimal conversion work, as this would make the type of the literal depend on the expected type. This would need major changes in the current infrastructure. I will write octal tests tomorrow.
Changed the type qualifiers to BI for BigInteger and BD for BigDecimal. For hexadecimal literals, you have to insert a # before the type qualifier, e.g. 0xbeef#L 0xbeef#BI Added Octal support for all integer types. Also added Java-7-like '_' to separate digits for better readability in all number literals. Updated tests and tutorials, too. Time to resolve this bug.
I reintroduced the INT rule for backwards compatibility. Note that it now also consumes digits separated with underscores.
Never thought numbers were so controversial: As result of an internal discussion we decided to remove builtin support for octal numbers. If you need it, you can simply bind your own NumberLiterals implementation. Hope this is the last "push to MASTER" ;-)
Closing all bugs that were set to RESOLVED before Neon.0
