-
Notifications
You must be signed in to change notification settings - Fork 138
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
Find least common super-type #1025
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1025 +/- ##
==========================================
+ Coverage 77.46% 77.53% +0.07%
==========================================
Files 273 274 +1
Lines 34764 35085 +321
==========================================
+ Hits 26929 27204 +275
- Misses 6760 6801 +41
- Partials 1075 1080 +5
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
cf611de
to
032de07
Compare
032de07
to
7713243
Compare
9a8b04f
to
b0d42b2
Compare
b0d42b2
to
5ca55cb
Compare
1033722
to
b6c5c9b
Compare
cab37bd
to
351fdf6
Compare
351fdf6
to
56f6e53
Compare
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 is really awesome, the bitmask approach is a really cool idea. I wonder though whether it produces some less precise results, since it doesn't take into account the variance of derived types when computing supertypes; it seems based on the test cases that the least common supertype of [String]
and [Bool]
is AnyStruct
, for example, when it could be [AnyStruct]
.
I couldn't say whether adding this additional precision is valuable or not, but given that arrays, dictionaries and other structures in cadence are all covariant, it seems like we could take advantage of this to produce some more specific results: when the kind of the "container" derived type is the same in a list of types, we should produce a type for their least common supertype that has the same kind for its derived "container".
063795b
to
7055e5a
Compare
Thank you @dsainati1 for the review! Regarding the containers, as I mentioned in the comment, we would need to do some extra bit of work to get it working (e.g.: Need a Cadence type to represent all keyable types, etc.), so currently we infer |
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.
Looks good to me; thanks for opening the issue to follow up on the recursive strategy!
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.
Great work! This is going to be very useful 👏
Cadence Benchstat comparisonThis branch with compared with the base branch onflow:master commit 4348c5d Results
|
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.
Great work! 👏 👍
@SupunS Sorry it took so long to get this in! |
Work towards #61
Description
This PR introduces a utility method to find the "least common supertype", given a list of types.
Approach:
Each type is represented using a bitmask (Type tag).
e.g:
Each 'leaf-type' (types that are not a super type of anyone) has a unique bit, and each super-type has a unique bit-pattern within the bitmask.
'Join of types' and the 'type inclusions' can be found through bitwise operations.
master
branchFiles changed
in the Github PR explorer