#5248: Infer type context in a type signature
----------------------------------------+-----------------------------------
Reporter: gidyn | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler (Type checker) | Version: 7.0.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: GHC rejects valid
program
----------------------------------------+-----------------------------------
Comment(by simonpj):
Replying to [comment:2 gidyn]:
I'm not sure what my first sentence means either!
> To put the issue differently: A type variable in a data/type constructor
is restricted to a given type class.
That is no more true of a data constructor than it is of any ordinary
function. Consider
{{{
bar :: Foo f => f a -> Bar f a
bar = ...lots of code...
}}}
Now function `bar` has the same signature as your data constructor `Bar`,
and gives rise to exactly the same type constraints.
Nor would a function or instance decl necessarily have the same context of
the `bar` or `Bar` functions. To take a slightly simpler example,
consider
{{{
class C a where
op :: a -> a
data Bar a = C a => Bar a a
-- So Bar :: C a => a -> a -> Bar a
instance (...) => C (Bar a) where
op (Bar a b) = Bar b a
}}}
Here the `(...)` is empty (''not'' `C a`) because the constraint arising
from the use of `Bar` is satisfied by the pattern match.
}}}
Now suppose the instance declaration whose context you want to infer is
this:
{{{
instance (...) => Foo (Bar f) where
In short, it's not specifically to do with data constructors, and it's not
specifically to do with instance declarations. It would certainly be a
useful feature to be allowed to ask GHC to infer the context; but it
should certainly be explicit when you are doing so.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5248#comment:3>
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
