Ambiguous type variable: it's a red herring!
module Ret where
data Whoops = Whoops Int Int
foo :: Maybe Int
foo = return (case Whoops 1 2 of
Whoops a -> a
_ -> 0)
Note that there is a pattern match error in the case statement, which the compiler correctly reports. However, it first reports the following red herring:
ret.hs:6:7: error:
• Ambiguous type variable ‘m0’ arising from a use of ‘return’
prevents the constraint ‘(Monad m0)’ from being solved.
Probable fix: use a type annotation to specify what ‘m0’ should be.
These potential instances exist:
instance Monad IO -- Defined in ‘GHC.Base’
instance Monad Maybe -- Defined in ‘GHC.Base’
instance Monad ((->) r) -- Defined in ‘GHC.Base’
...plus two others
(use -fprint-potential-instances to see them all)
• In the expression:
return
(case Whoops 1 2 of {
Whoops a -> a
_ -> 0 })
In an equation for ‘foo’:
foo
= return
(case Whoops 1 2 of {
Whoops a -> a
_ -> 0 })
One would think that the context foo :: Maybe Int is sufficient for the compiler to realize that return (blah) implies that m0 = Maybe, regardless of the errors involved in the expression (blah).
ghc 7.10.3 does not report this red herring. One can get a similar red-herring type error in ghc 7.10.3 by replacing return (...) with return $ ... in the example above.
The red herring also does *not* appear, in ghc 7.10.3 or in ghc 8.0.1, if you name the broken case expression with a let binding.
module Ret where
data Whoops = Whoops Int Int
foo :: Maybe Int
foo = return boo where
boo = case Whoops 1 2 of
Whoops a -> a
_ -> 0
There seems to be something fishy going on here.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |