4 ms·
To nitpick, -14 isn't a literal in all languages. :) (In Haskell, it's just sugar for negate 14, while in Standard ML it's spelt ~14. And I assume there are ot
by anders0 14y ago
To nitpick, -14 isn't a literal in all languages. :)
(In Haskell, it's just sugar for negate 14, while in Standard ML it's spelt ~14. And I assume there are other exceptions too.)
- pdw 14y agoEven in C it's not a literal. The consequence is that in a 32-bit implementation, you can't write INT_MIN as -2147483648 (-2^31), because 2147483648 would overflow a signed int. Instead a workaround such as -2147483647-1 must be used.
- anders0 14y agoHuh. I always assumed it was in C. Shows what I know… :p
- shaurz 14y agoMaking the minus part of the literal can lead to parsing ambiguity. For example, "x-3" would parse as 2 tokens "x" and "-3" (instead of 3 tokens "x", "-" and "3") which would be a syntax error in C. The only workaround I can think of is making any expression followed by a negative number parse as a subtraction.
- reycharles 14y ago> Making the minus part of the literal can lead to parsing ambiguity. Not really. It's done in java. Usually, minus ("-") is parsed as a token and then unary minus on integer literals are transformed to a negative integer literal. So, -2147483648 is read as MINUS INT_LITERAL and thus transformed into "-2147483648" as an INT_LITERAL, but -(2147483648) should be read as MINUS L_PAREN INT_LITERAL R_PAREN and should thus not be transformed.