-
Notifications
You must be signed in to change notification settings - Fork 24
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
Improve error message for impossible JoinKinds constraint #424
base: master
Are you sure you want to change the base?
Conversation
b128e9e
to
8cf13be
Compare
Thanks. EDIT: Never mind, for some reason I thought that this extension was introduced in GHC 8.6. Also, doctests fail, presumably due to a missing import. |
-- @is_concrete@ will be unified with @False@. | ||
-- | ||
class IsOpticKind (m :: OpticKind) (is_concrete :: Bool) | m -> is_concrete | ||
instance is_concrete ~ 'True => IsOpticKind An_AffineFold is_concrete |
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.
What will happen if a kind is forgotten, we get a "wrong" custom type error?
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.
Yes, I was a bit dissatisfied with the need to list all the optic kinds explicitly, but I couldn't immediately see how to avoid it. Having thought a bit more I've got a version that doesn't need this.
8cf13be
to
f7704fb
Compare
This is less vulnerable to us forgetting to extend the definition if we add a new optic kind.
cffcdf0
to
28feead
Compare
I was playing around with this branch and noticed this:
We should be able to do better here, by checking if more parameters are concrete. On the other hand, we're a bit stuck if the context doesn't force a particular optic kind (cf. #308):
|
What's the status of this PR? |
I've been away on holiday so apologies for the radio silence. I'm still planning to polish this a bit, but it may be a little while before I can get back to it. |
@adamgundry I posted an alternative solution in #439, please have a look if you have a moment. It's not as fancy, but should be more predictable :) |
Fixes #423.
WARNING: typeclass Prolog ahead.