showRead = show . read }}} (with `-XAllowAmbiguousTypes`) we are told that term is ill-typed because of a failed constraint due to an ambiguous type variable. But, there is a
#8477: Allow inferring ambiguous types -------------------------------------+------------------------------------ Reporter: aavogt | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 8390 -------------------------------------+------------------------------------ Changes (by simonpj): * cc: goldfire, diatchki (added) Comment: Richard Eisenberg (goldfire) writes: I'm here at MSR Redmond talking with Nik and Daan about type inference, among other things. We're wondering about ambiguity checks. When we type check {{{ perfectly good type for this: `(Show a, Read a) => String -> String`. This type is, of course, ambiguous, but I thought we wanted to ''allow'' ambiguous types. Our only theory is that GHC has to check the RHS ''twice'' -- once to infer a type and then once to check that it has the inferred type. It is during this second pass that we discover that the inferred type is no good. What has intrigued us is that {{{
showRead :: forall a. (Show a, Read a) => String -> String showRead = show . (read :: String -> a) }}} works just fine (with `-XAllowAmbiguousTypes` and `-XScopedTypeVariables`). So, the analysis is ''not'' just looking at the types; it has to be examining the RHS also.
-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8477#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler