[GHC] #11408: Delicate solve order
GHC
ghc-devs at haskell.org
Mon Jan 11 17:41:30 UTC 2016
#11408: Delicate solve order
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.10.3
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
Should we successfully infer a type for `f`:
{{{
f x = [h x, [x]]
}}}
assuming `h :: forall b. F b -> b`?
Assuming `(x::alpha)` and we instantiate `h` at `beta`, we get the
constraints
{{{
(1) beta ~ [alpha] from the list [h x, [x]]
(2) alpha ~ F beta from the call of h
}}}
Now if we happen to unify the constraint (1) first, `beta := [alpha`],
then we successfully infer
{{{
f :: forall a. (a ~ F [a]) => a -> [[a]]
}}}
But if we unify the constraint (2) first, `alpha := F beta`, we get
{{{
f :: forall b. (b ~ [F b]) => F b -> [[F b]]
}}}
which is ambiguous.
Eeek! This actually shows up in type inference for `indexed-
types/should_compile/IndTypesPerfMerge`, where the function `merge` has (a
slightly more complicated form of) this delicately-balanced situation.
But see `Note [Orientation of equalities with fmvs]` in `TcFlatten` for
why we don't defer solving (2).
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11408>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list