Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detailed kinds for numeric literals #487

Open
c42f opened this issue Aug 9, 2024 · 0 comments
Open

Detailed kinds for numeric literals #487

c42f opened this issue Aug 9, 2024 · 0 comments

Comments

@c42f
Copy link
Member

c42f commented Aug 9, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant