-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Fix the polymorphic recursion problem of #9603 #9617
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
Conversation
lpw25
left a comment
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 a neat solution and I believe that it is correct.
|
For those following along with this saga -- including my future self -- the reason for using unification in #1132 was described in my comment in #6673. It was to catch cases like: type 'a t = Leaf of 'a | Node of ('a * 'a) t;;
let rec depth : 'a. 'a t -> _ =
function Leaf x -> x | Node x -> depth x;;where a universal variable leaks out through a unification variable. This is precisely what However, #9603 demonstrates that I think the long term solution is to use similar level-based logic to replace |
|
Thanks for the explanation, very clear. |
|
Check-typo is complaining about two white spaces, and I think it would be good for readability to at least add the PR number to the change entry of #1132 (in the 4.11 section). |
|
Thanks! I will be merging and cherry-picking to 4.11 once the CI is green. |
|
Cherry picked on 4.11 at commit 3a8ab06 |
#1132 , by relying on unification of polytypes, introduced a limitation to polymorphic recursion.
#9603 is an open problem about unification of polytypes.
This PR fixes the polymorphic recursion case, by removing the reliance on unification.