[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):

 I think there's a third case: there might be a variable born as a skolem
 that nevertheless mentions unification variables in its kind. This could
 happen, for example, with a `forall`-bound variable in a partial type
 signature.

 I don't see your short-term solution. It sounds like you're saying "forbid
 lexical meta-tyvars in type signatures" but that's a huge hammer. And it
 wouldn't even work, because meta-tyvars might be zonked before we can
 forbid them. Perhaps I'm missing something.

 Your medium-term solution might work -- I don't have enough of it in my
 head to analyze. I took a quick look at the paper (Fig. 7, in particular)
 and have a question: is the new system fully backward-compatible with
 "Practical type inference"? Here is an example I'm worried about:

 {{{#!hs
 polypoly :: ((forall a. a -> a) -> (Int, Char)) -> ()
 polypoly _ = ()

 stuff = polypoly (\f -> (f 5, f 'x'))
 }}}

 This is accepted today, right in line with "Practical type inference". But
 it looks like it wouldn't be accepted by Fig. 7, because that assigns a
 monotype to any un-annotated lambda. The `f` above must be assigned a
 polytype. I have not read the paper (since last summer), but a quick
 glance at the figure provoked this question.

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