-
Notifications
You must be signed in to change notification settings - Fork 1
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
Kind unification error (or unhelpful error message ?) #38
Comments
I get this:
What commit are you working from? |
Sorry, I had disabled this assertion as it allowed me to compile/run some programs, and I thought I had checked it was not caused by this before submitting the issue. I can move the error from type instance (@@@) (AD kb ka jz jy jx jw jv) ju = 'Cons (ToSing kb) (ToSing jw) (ToSing (C @@@ jv @@@ jz)) (W @@@ kb
@@@ jv @@@ jz @@@ ju @@@ jx) to the code in type instance (@@@) (AD kb ka jz jy jx jw jv) ju = 'Cons (ToSing kb) (ToSing jw) (ToSing (H jv jz jv)) (AH kb jv jz ju jx ju) and moving AD after H and AH.
The error is the same as in #32. As it can be avoided by reducing type families, it may be related to them. Can you look into this ? #39 is independent, I updated its code so as not to trigger this assertion. |
Not this week -- sorry. Doing a frantic run to put together a POPL paper. |
I have a vague idea of what's going on. From your original post:
Shouldn't the coercion contain the needed proof ? No. The reason is that the coercion there is representational, and GHC is looking for a nominal proof. If your code depends on using that coercion to type-check, GHC is doing the right thing here. One of my tasks over the next month is to smooth out roles in kind coercions, by having all kind coercions be at nominal role. This is much simpler than the current story. But it prevents promotion of Core code that wraps/unwraps newtypes. This is OK, because promotion of Core code is not yet implemented -- we only promote Haskell code, which remains fine. Getting rid of roles in kinds does make implementing Pi harder, but Simon PJ's (always sage) advice is to do the simple thing today and let tomorrow worry about the complex thing. So I'll simplify (it's not actually much code to change) and then worry about this issue later. One effect of this will be that this ticket should get resolved. |
It seems in this case that ghc is able to check
t : k1
andt : k2
, but fails to unify k1 with k2 (t=AH t t6 t2 t7 t4 t7
,k1=T t (H t6 t2 t6)
andk2=T t (H jv jz jv)
).The example is quite long, but I don't know how to make it shorter...
The error is ~5 lines from the end (Actual type = type of
SCons _ _ _ _
)With normalised types, we get a "Can't unify t with t" error message :
Using the flag -fprint-explicit-kinds, we get :
Shouldn't the coercion contain the needed proof ?
The text was updated successfully, but these errors were encountered: