[GHC] #13490: Ambiguous types with constraints on new variables
GHC
ghc-devs at haskell.org
Tue Mar 28 07:42:44 UTC 2017
#13490: Ambiguous types with constraints on new variables
-------------------------------------+-------------------------------------
Reporter: crockeea | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.0.2
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: GHC rejects | Unknown/Multiple
valid program | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by simonpj):
You are walking on thin ice. Consider
{{{
f :: Eq [a] => [a] -> [a]
f x = [x] == [x]
}}}
From the RHS we need `Eq [a]` which is provided by the type signature.
But GHC could ''also'' solve `Eq [a]` by using `instance Eq a => Eq [a]`
(which is usually the right thing to do). Then it would need `Eq a`,
''which it cannot get from `Eq a`''. To avoid this dead end GHC tries to
solve "wanted" constraints from "givens" first.
But what if it was
{{{
f :: (Eq b, b ~ [a]) => [a] -> [a]
f x = [x] == [x]
}}}
Now it's not quite so obvious. I would have expected this still to work,
just, because equalities are always solved first. But the ice is a bit
thinner.
I would have expected your example to work too, just. And so it does in
HEAD, and hence in 8.2. But it'd be much more robust to put `(Typeable
z)` in the context. Is there some reason you can't do that?
I'll add your example as a regression test and close as 'worksforme'.
Simon
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13490#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list