-
Notifications
You must be signed in to change notification settings - Fork 18
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
Implicit constructors defeat syntactic equality #106
Comments
|
I'm not really sure what the right solution to this is yet. I think the new pattern expander supporting the old would be helpful, though. I think Coq's behavior is that you have to always specify a position for all arguments, even implicit ones, when pattern matching. That is annoying behavior. Right now, the specific problem is the new pattern matcher we're working on in #103/#105 decides totality by checking that there is a pattern for every constructor, using Right now, it has some kind of hack that I don't fully understand to make this work some of the time. For example, in I think the root cause is probably that we're using |
Yeah using Are you implementing Coquand's algorithm for totality checking? |
Don't remember; @pwang347, did you implement a particular algorithm? My guess would be it's ad-hoc, as the framework supports deep pattern matching and other things. |
No specific algorithm, I believe it was ad-hoc with some inspiration from pattern matrices |
currently, implicit parameters confuse our pattern matcher, since the implicits are actually handled by by a new constructor. This became a problem in #103. We have a workaround, but a better work-around would be attaching meta-data to the constructor, and a system by which both the original constructor and the implicit version are always equal in pattern matching, etc.
The text was updated successfully, but these errors were encountered: