-
Notifications
You must be signed in to change notification settings - Fork 16
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
Pure pattern-matching #152
Conversation
Added effect to type shape proofs in Core. This effect describes the effect of pattern-matching. In this commit, it is always NTerm effect, but we are going to recognize positively-recursive types, and attach pure effect to shape proofs of such ADTs.
This commit introduces `strictly_positive` flag to ADT definitions in Core. ADTs marked as strictly positively recursive have the witness with pure effect attached, so they can be deconstructed without introducing NTerm effect.
This implementation has some slight problem with generated accessors for recursive records. For instance, when we write the following code
the
Notice, that the method is in recursive block, and therefore is impure, even if the pattern-matching on |
All the changes look good to me, however I did look at the problem mention above and there seems to exist simple (partial) fix. It will make record accessors non recursive when record is marked
If we ever decide to make non-termination detection more precise, for example like the one that's present in coq, my change will become redundant as whole problem will be solved. Until then it will help with the not obscure code. |
changes mentioned:
|
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.
I haven't spotted anything suspicious, so I'm in favor of merging. However, as (I think) @ilikeheaps pointed out, we should make sure existing tests still make sense after the change. I remember you identified ok0079_impureMethod.fram
as outdated, which tests the fix for an old bug reported in #14. We should force impurity in that test by some other means.
@Foxinio These changes looks reasonable, but I think we should merge them in a separate pull-request. This PR propose basic solution to the problem of pure pattern-matching that has some limitations, but has no edge cases. Your fix improves the solution, but is not perfect, and in a long run will be probably replaced by something better. Having separate commits for them would make history cleaner, and it would be easier to revert your changes in order to provide the final solution. |
This pull-request aims to resolve #149. This will be done in the following steps
TypeInference.Module.adt_info
)TypeInference
TypeInference.Pattern
)TData
type in Core