#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