[GHC] #15697: Typed holes inferring a more polymorphic type

[GHC]

#15697: Typed holes inferring a more polymorphic type
-------------------------------------+-------------------------------------
        Reporter:  sreenidhi         |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.6.1
      Resolution:                    |             Keywords:  TypedHoles
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 RyanGlScott):

 I suppose the correct behavior here depends on whether or not you want
 valid hole fit suggestions to suggest the most general type of local
 definitions or not. Consider the following modified example:

 {{{#!hs
 testFailure :: Char
 testFailure =
   let x :: _
       x = id
   in x 'a'
 }}}

 You might think that the reported type of the hole would be `Char ->
 Char`, but it's actually `forall a. a -> a`. Indeed, `forall a. a -> a` is
 the most general type that you can give `x`, so from a certain
 perspective, it's the most "correct" answer. But perhaps it's not the one
 you'd desire.

 One idea would be to allow tweaking the generalization behavior for local
 definitions //à la// `MonoLocalBinds`. For instance, in the following
 example:

 {{{#!hs
 testFailure2 :: Bool -> (Bool, Char)
 testFailure2 x =
   let f y = (x, y)
   in f 'a'
 }}}

 If `MonoLocalBinds` isn't enabled, then the inferred type of `f` will be
 `forall b. b -> (Bool, b)`. But if `MonoLocalBinds` //is// enabled, then
 the inferred type of `f` will be `Char -> (Bool, Char)`.

 I imagine we could allow valid hole fits to tweak generalization in a
 similar fashion (whether generalizing should be the default here or not is
 unclear to me).

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