[GHC] #16344: GHC infers over-polymorphic kinds

[GHC]

#16344: GHC infers over-polymorphic kinds
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.6.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by goldfire):

 Simon has proposed a fix:

 In TcHsType, we find this, under `kcLHsQTyVars_NonCusk`:

 {{{#!hs
     mk_tc_binder :: LHsTyVarBndr GhcRn -> TyVar -> TyConBinder
     -- See Note [Dependent LHsQTyVars]
     mk_tc_binder hs_tv tv
        | hsLTyVarName hs_tv `elemNameSet` dep_names
        = mkNamedTyConBinder Required tv
        | otherwise
        = mkAnonTyConBinder tv
 }}}

 Simon suggests that changing it to this fixes the bug:

 {{{#!hs
     mk_tc_binder :: LHsTyVarBndr GhcRn -> TyVar -> TyConBinder
     mk_tc_binder hs_tv tv
        = mkAnonTyConBinder tv
 }}}

 Note: just deleting code!

 Indeed, this change fixes the example in the ticket because it effectively
 forgets that the first argument to `T` and the kind of the second are
 related. The program above is rejected right in the `kc` pass, because GHC
 tries to unify `ka` (a `TyVarTv`) with `Type` when looking at `Int` (never
 mind the `Maybe` it will see soon). Some examples are rejected in the `tc`
 pass though, like this:

 {{{#!hs
 data T2 ka (a::ka) = MkT2 (T2 Type a)
 }}}

 All fine during `kc`, but then once we produce `T2 :: forall ka -> ka ->
 Type`, failure in `tc`. While I'm never comfortable with non-CUSK types
 being rejected in the `tc` pass, I suppose it's OK.

 More problematically, this is never rejected at all:

 {{{#!hs
 data T3 ka (a::ka) = forall b. MkT3 (T3 Type b)
 }}}

 This is accepted outright. The `kc` pass assigns kind `ka` to `b` (fine)
 and then the `tc` pass instantiates `ka` to be `Type` and assigns kind
 `Type` to `b`. Also fine (it's type-correct), but `T3` is polymorphically
 recursive, and should be rejected.

 So, I claim that Simon's fix makes these examples (erroneously accepted
 polymorphic recursion) harder to find, but doesn't get rid of them all.
 Instead, a more involved fix would be to, for example, require that all of
 these types are immediately followed by `ka` at recursive occurrences --
 anything other than a first argument of `ka` is rejected. I'm not sure how
 to achieve this elegantly (haven't thought about it), but that should
 stamp out the problem.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16344#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler