[GHC] #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1

[GHC]

#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