[GHC] #9404: tcInferRho muddies the waters

[GHC]

#9404: tcInferRho muddies the waters
-------------------------------------+-------------------------------------
              Reporter:  goldfire    |            Owner:  goldfire
                  Type:  bug         |           Status:  patch
              Priority:  normal      |        Milestone:
             Component:  Compiler    |          Version:  7.9
            Resolution:              |         Keywords:
      Operating System:              |     Architecture:  Unknown/Multiple
  Unknown/Multiple                   |       Difficulty:  Unknown
       Type of failure:              |       Blocked By:
  None/Unknown                       |  Related Tickets:
             Test Case:              |
              Blocking:              |
Differential Revisions:  Phab:D469   |
-------------------------------------+-------------------------------------

Comment (by goldfire):

 On Phab:D469, Simon says, about line 328 of !TcExpr:

 > This smells wrong. tcInferRho ends up calling tcInfer, which makes an
 OpenKind ReturnTv. But then we unify it with a liftedTypeKind ReturnTv
 later.
 >
 > Complicated and silly. Better if tcInferRho takes the kind it is
 expecting. Then we have only one ReturnTv, not two; and the whole ReturnTv
 story is located in tcInfer, rather than having a non-return-ish hack in
 the typing rule for $
 >
 > Make sense?

 I've decided: no, this doesn't make sense. The call to `tcInferRho` is to
 infer the type of the left-hand argument to `$`. This type is a function
 type `arg -> res`. If it turns out to be unlifted, the
 `matchExpectedFunTys` will fail. The silliness with the new `ReturnTy` bit
 isn't about the result of `tcInferRho` -- it's about the result of
 `matchExpectedFunTys`. So the straightforward refactoring Simon proposes
 doesn't work.

 Instead, what we should do here is to unify `arg2_ty`'s kind with `*`. But
 !TcUnify doesn't have a function for that -- something like
 `matchExpectedStar`. The closest thing -- `unifyKindX` tells us about sub-
 kinding relationships, instead of actually unifying the kinds.

 So, I propose: do nothing for now. It's working, although a little uglily,
 as is. When we have proper kind equalities and no sub-kinding anymore,
 this will be easy to fix. Please close the ticket if you agree.

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