typeKind confuses Type and Constraint

The typeKind function takes a type and reports its kind. It gets this wrong, sometimes: if you ask for typeKind of the quantified constraint Eq a => C a (where C is a class), you get Type. This is wrong, though I don't have a concrete case where GHC misfires.

We could fix typeKind to get this right, but doing so would require making the FunTy case recursive (right now, it always returns Type). This is wasteful, because most clients of typeKind do not care about the distinction between Type and Constraint.

Instead, I propose making a new tcTypeKind which behaves correctly in this case.

We could also muse about making tcTypeKind monadic so that it can look through unification variables. This might also simplify the story around Note [The tcType invariant].

Regardless of the "make monadic" idea, I claim that, when this is done, we should have isPredTy be functionally equivalent to (== Constraint) . tcTypeKind.

Trac metadata

Trac field	Value
Version	8.6.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture