-
-
Notifications
You must be signed in to change notification settings - Fork 113
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
Number System #298
Number System #298
Conversation
Woohoo! Happy to see this here. Haven't gotten to really dig into the code yet, but re: the coerce functions, I believe we wanted them to exist in the respective libraries:
and then the same for int64.gr, float{32, 64}.gr, etc. |
@ospencer I'm pretty sure we want them in runtime so we can add our sugar without adding additional deps. |
@phated sorry, my code example was kinda bad. They shouldn't be implemented in the separate libraries, just imported from the runtime there. When we want to add syntax, we can import the same functions from the runtime into pervasives. Here's really what the code should look like:
And then once we're ready, we can do this in Pervasives (the syntax is just a fake example):
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well done! Code looks really good. I left some notes for some places we can do some cleanup, as well as some places we should create some issues. Sorry about the number of comments, but when it's time to merge it's a lot easier for me to scroll through and see that the comments are resolved rather than reading through the whole thing again. 😛
@belph could you also update the data_representations
document with the layout of the new numbers?
|
||
The downside of this tag for numbers is the loss of one bit of information. There are 2^31 possible values for signed numbers in Grain rather than 2^32. | ||
The downside of this tag for numbers is the loss of one bit of information. If larger numbers are needed, then users must use one of the other (heap-allocated) number types. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sorta implies that the user has to do something rather than the numbers being automatically promoted. Am I mistaken?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent work! Feels really sweet to see this come to fruition.
…o-handle which type to use
c398c7c
to
9bbf53e
Compare
This PR adds the first version of our long-awaited number system! 🤓 📈
Number Types
Grain has the following number types:
1/3
)Syntax
The syntax works as you would probably expect:
A nice side effect of this PR is that literal integers in Grain now can run the full range of possible Int64 values!
Note that there is no syntax for rationals; instead, they are constructed by dividing two integer-like numbers.
By default, all number literals are of type
Number
. That way, they can all be freely combined using integer operations:It even supports equality checks across number types!
Do be aware that this means that runtime errors are possible! (sorry, @ospencer)
What if you want to work with a specific subtype of number? We have syntax for that:
For example, this will not type-check:
Unfortunately, neither will this!
For the moment, all of the builtin operations need to be performed on
Number
s. As such, we have a variety of utilities to convert back and forth between the specific subtypes andNumber
:Known Issues
i32
numbers. This should probably be upgraded toi64
in order to avoid weird edge cases in the futureCloses #250 and closes #255 .