Change History (19)

This is by design. As I discovered en route to the solution to #9200, the old kind inference for closed type families was bogus. For the type family above, what should the return kind be? k, k2, and * are all viable options. Thus, this type family has no principal kind and should be rejected.

Another was of looking at this is that G does not have a CUSK. Therefore, its right-hand side must use kind variables uniformly -- which it doesn't, because the first two equations must specialize k to *.

In this particular case, given the third equation G a = a, I'm pretty sure the only possible return kind is k, no? But there was that whole long discussion about CUSKs that I didn't really follow, so I take it that in general a closed type family may have no principal kind.

I would venture to say though that the error message GHC produces is IMHO not that helpful. In this case the fix is clearly to add a CUSK type family G (a :: k) :: k where; could GHC work out when it is appropriate to suggest adding a CUSK?

I believe we should create a test case so that any accidental change of semantics does not go unnoticed (like it seems to have between 7.8.3 and 7.10.1?). Richard, I'm re-opening and assigning to you but if you don't have the time please re-assign it to me - I'll take care of that in due time.

This G doesn't really use its kind-polymorphism, but the definition kind checks.

However, I think you're right about the suggestion for a CUSK, here and in other cases. And I think it's possible for GHC to have at least some heuristics for when a CUSK is the answer. Specifically, it could include a note about CUSKs in error messages that arise from kind mismatches in non-CUSK right-hand sides.

And, yes, this would make for a decent test case. Thanks for the suggestion.

I'm very unsure I can get to this by Friday (the next RC release), though!

I've added a (not-yet-pushed) test case, but it's hard to see how to improve error messages. The problem is that the place that generates the kind errors is far from where we know whether or not we have a CUSK. I attempted to use addErrCtxt to include a note about CUSKs before kind-checking, but this note got appended to lots of errors that are clearly unrelated to CUSKs -- this is the wrong approach. I think the right approach is to somehow record in TcM that we're kind-checking a declaration which could potentially have a CUSK but in fact does not and then look there before reporting certain errors. But this is terribly heavy.

Foo.hs:6:5: error:
* Expecting one more argument to `Maybe'
Expected kind `k', but `Maybe' has kind `* -> *'
* In the first argument of `F', namely `Maybe'
In the type family declaration for `F'

It is bizarre that one works and the other does not, and I was all ready to open a ticket when Richard said: This is correct behavior. The former has a CUSK, as all open type families have CUSKs with un-annotated kinds defaulting to Type. The latter does not have a CUSK, because the result kind is unknown. You therefore cannot specialize the k variable in the definition of the latter.

I can't help feeling that our CUSK story is a bit wonky, so I'm recording it here.