You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently large sets of integers are grouped under a single Kind. For example, all signed integers are K"Integer" because the tokenizer rules cannot distinguish between different integers without numeric conversion.
However this seems semantically awkward when the actual value of a K"Integer" can be any of the types Int32, Int64, Int128 or BigInt.
We already need to perform numeric conversion to parse and validate floating point numbers - perhaps we should also do so for other numeric literals, and set their kinds appropriately?
However there's an awkward product here between the converted numeric type and the textural representation. For example a hex integer will be converted to any of the types UInt8, UInt16, UInt32, UInt64, UInt128, BigInt. The same is true of binary and octal text representations. So we have all possible combinations from the product of
Textural representations HexInt, BinInt, OctInt
Value representations UInt8, UInt16, UInt32, UInt64, UInt128, BigInt
At the level of the green tree, the textual representation is probably what's most important. Later during compilation the exact Julia type becomes more important.
The text was updated successfully, but these errors were encountered:
Currently large sets of integers are grouped under a single Kind. For example, all signed integers are
K"Integer"
because the tokenizer rules cannot distinguish between different integers without numeric conversion.However this seems semantically awkward when the actual value of a
K"Integer"
can be any of the typesInt32
,Int64
,Int128
orBigInt
.We already need to perform numeric conversion to parse and validate floating point numbers - perhaps we should also do so for other numeric literals, and set their kinds appropriately?
However there's an awkward product here between the converted numeric type and the textural representation. For example a hex integer will be converted to any of the types UInt8, UInt16, UInt32, UInt64, UInt128, BigInt. The same is true of binary and octal text representations. So we have all possible combinations from the product of
At the level of the green tree, the textual representation is probably what's most important. Later during compilation the exact Julia type becomes more important.
The text was updated successfully, but these errors were encountered: