-
Notifications
You must be signed in to change notification settings - Fork 36
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
Work on inference, unification and subject-reduction #328
Conversation
There is a bug I need to fix. I am working on it. |
… that are non-linear or appears in the RHS as it may change after SR
…g RHS typing constraints
I have a question: do we assume somewhere in the code that a meta of arity n has a type of the form \forall x1:A1,..,\forall xn:An,B? |
I'm not sure, but most probably. |
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.
There are still changes in there that I think are a mistake, but I guess I can live with them.
So can I merge @fblanqui? (I want to do it myself because I want to fix the commit message.) |
I have a question: do you keep the LHS unchanged after scoping? |
For now yes, but it will have to change once I implement the optimisation. |
Ok. The optimisation does not change the matching behavior. It is important to not change this indeed. Only the RHS metavariables should be instantiated by something. |
Thanks to merge @rlepigre . And thanks for your improvements on this PR! |
Yeah, the only thing that the optimisation will do is just not record the term matching a pattern variable in the case where it is not useful in the RHS (and does not appear non-linearly). This means that we will have wildcards again (i.e., terms of the form |
fix type inference, unification, handling of implicit arguments in rules, subject-reduction
fix issues #303 #330 #334