Open RafaelBocquet opened 9 years ago
I get this:
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20150225 for x86_64-apple-darwin):
ASSERT failed!
file compiler/types/Coercion.hs line 1024
Sub (TFCo:R:@@TYPENatBag[0] <jv_a4tA>_N) representational
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 append
by reducing it to
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.
ghc: panic! (the 'impossible' happened)
(GHC version 7.11.20150702 for x86_64-unknown-linux):
ASSERT failed!
file compiler/types/Coercion.hs line 1024
Sym cobox_a4TI representational
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 ?
Not this week -- sorry. Doing a frantic run to put together a POPL paper. Next week should be OK, though.
I have a vague idea of what's going on.
From your original post:
When matching types
AH t t6 t2 t7 t4 t7 :: T t (H t6 t2 t6)
(AH t t6 t2 t7 t4 t7 |> {- coercion -} :: T t (H jv jz jv)
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 ?