[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