[GHC] #15589: Always promoting metavariables during type inference may be wrong

[GHC]

#15589: Always promoting metavariables during type inference may be wrong
-------------------------------------+-------------------------------------
        Reporter:  goldfire          |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.4.3
      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 goldfire):

 The "tyvars in scope" is a red herring. Or, rather, your approach of
 linking a unification var to its enclosing implication carries the same
 data, so there is no difference between our approaches.

 My comment:3 tersely suggested a way to allow `x`'s instantiation, even
 before everything has settled. It might be equivalent to your
 instantiation constraints -- hard to say. (Are these specified in the
 paper? I don't recall.)

 Consider this version:

 {{{
 f (y::Proxy c) = let x :: forall a b (d :: a) z. z -> SameKind (IfK c b d)
 d
                      x = undefined
                  in (x (y :: Proxy True), blah)
 }}}

 Now, we get the key bit of information -- that `c` is `True` -- in an
 argument passed to `x`, which we cannot look at without instantiating `x`.
 (We need to instantiate `x` before looking at its arguments because
 perhaps `x` is higher-rank and we'll need to "push down" the polymorphic
 type of `x`'s argument. Indeed, I could have made my example higher-rank
 to demonstrate this, but didn't for simplicity.) If the instantiation
 constraints can handle this case, then they're likely equivalent to what I
 was thinking about in comment:3.

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