#13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | ConstraintKinds, KindSignatures Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): A bit more detail.... It's all a result of the ambiguity between tuples and constraints. * `A`, `B`, `C`, and `D` are all mutually recursive * When inferring the kind for them, they get initial kinds {{{ A :: k1 -> k2 B :: k3 -> k4 C :: k5 -> Constraint D :: k5 -> Constraint }}} where the `ki` are kind unification variables * Then we happen visit them in order `C` (and `D`), `B`, `A`. * So when kind-checking `B` we have not yet figured out `A`'s kind * And becuase of the tuple/constraint ambiguity, we prematurely choose that the tuple `(A l, A l)` will be a `BoxedTuple` not a `ConstraintTuple`. Something rather similar comes up with the empty tuple; we have an open ticket for that, #9547 (maybe others). What we really want, of course, is to defer the choice until we have worked out the kinds of `A`, `B`, `C`, and `D`; and there is no difficulty in principle with doing that. But it's tricky at the moment because we use one piece of code (`TcHsType.tc_hs_type`) for both kind checking (working out what the kinds of each type constructor are) and desugaring (producing a `Type` from a `HsType`. In the first of these steps we don't need to aggressively commit to which kind of tuple we want; in the latter step we do. This will become straightforward when we adopt #13737. Meanwhile, there's a decent workaround, so I'll park this one for now. I don't think there is an easy solution in the current setup. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13742#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler