#1897: Ambiguous types and rejected type signatures
----------------------------------------+-----------------------------------
Reporter: guest | Owner: chak
Type: bug | Status: reopened
Priority: normal | Milestone: 6.10 branch
Component: Compiler (Type checker) | Version: 6.9
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: Linux
Architecture: x86 |
----------------------------------------+-----------------------------------
Changes (by simonpj):
* cc: [email protected] (added)
Comment:
Here is yet another example, this time from Andres Loeh:
{{{
{-# LANGUAGE TypeFamilies, EmptyDataDecls, RankNTypes #-}
module Foo where
data X (a :: *)
type family Y (a :: *)
-- This works (datatype).
i1 :: (forall a. X a) -> X Bool
i1 x = x
-- This works too (type family and extra arg).
i2 :: (forall a. a -> Y a) -> Y Bool
i2 x = x True
-- This doesn't work (type family).
i3 :: (forall a. Y a) -> Y Bool
i3 x = x
}}}
The definition `i3` is currently rejected, because we can't determine that
`Y alpha ~ Y Bool`, where `alpha` is an otherwise unconstrained
unification variable, that comes from instantiating the occurrence of `x`.
Choosing `alpha := Bool` will solve this, and in this case any solution
will do; it's a bit like resolving an ambiguous type variable.
It's tricky in general, though. Suppose we had two constraints `(X alpha
~ X Bool)` and `(Y alpha ~ Y Char)`. Now we can't solve it so easily!
Worse, suppose we had an instance declaration
{{{
type instance Y Bool = Char
}}}
Should we still resolve `alpha := Bool`? Would the answer change if there
was a ''second'' instance?
{{{
type instance Y Int = Char
}}}
Arguably, searching for all possible solutions is not terribly good.
It's not at all obvious what the Right Thing is.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1897#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
