[GHC] #14419: Check kinds for ambiguity

[GHC]

#14419: Check kinds for ambiguity
-------------------------------------+-------------------------------------
        Reporter:  goldfire          |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.1
      Resolution:                    |             Keywords:  TypeInType
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 simonpj):

 * I agree that `checkValidTyCon` is a better place.  (It's outside "the
 knot".)

 * We should ''remove'' any `checkValidType` calls on the individual kind
 ascriptions.  No point in calling it on the `a` in `data T (x::a) = ...`.
 I have not looked into just where we'd remove it.

 Your point about the ambiguity check is very interesting.  At the term
 level, the ambiguity check models this:
 {{{
 f :: forall a. F a -> Int
 f = ...

 f2 :: forall a. F a -> Int
 f2 = f
 }}}
 It's very confusing if `f2` does not typecheck; after all, it has the same
 type as `f`.  The ambiguity check tests this.  At the call of `f` we
 instantiate its foralls (say `a :-> alpha`); and then unify with a
 skolemised version of `f2`'s type.  And thus we unify `F alpha ~ F a` and
 fail.

 Analogously, suppose we said (as you suggest)
 {{{
 type family F (x :: a)
 type family T2 (x :: a) :: F x -- Kind: forall a. forall (x :: a) -> F x
 }}}
 I've changed your `T2` to be a data type.  Occurrences of `T2` will look
 like `T2 {a} x`, where the `{a}` is invisible in the source language; it
 is implicitly instantiate.  But not that the `x` argument is fully
 explicit.

 Now
 type T3 :: forall a. forall (x::a) -> F x
 type T3 x = T2 x
 }}}
 (I know we don't have separate kind signatures yet, but we will!)  Notice
 that we must apply `T2` to its explicit args; the `forall (x::a) -> blah`
 behaves like an arrow not like an (implicitly-instantiated) forall from
 the point of view of ambiguity checking.

 Looking at `TcUnify.tc_sub_type_ds`, the culprit looks like the call to
 `topInstantiate`. It already comes in two variants:
 * `topInstantiate`: instantiate all outer foralls
 * `topInstantiateInferred`: instantiate all outer `Inferred` foralls

 But the former instantiates `Required` foralls, and '''I think it should
 never do so.'''

 NB: See `Note [TyVarBndrs, TyVarBinders, TyConBinders, and visibility]` in
 `TyCoRep` for a refresher on `Inferred/Specified/Required`.  (NB:
 `Required` binders never occur in the foralls of a term variable, so this
 change cannot affect the term level.)

 Richard, do you agree? Ryan, would you like to try that (a one-line change
 in `should_inst` in `Inst.top_instantiate`)?

 Richard, I must say that I find it hard to be sure where we should call
 `topInstantiate` and where `topInstantiateInferred`.  Some comments at the
 call sites would be very welcome.

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