[GHC] #16365: Inconsistency in quantified constraint solving

[GHC]

#16365: Inconsistency in quantified constraint solving
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.6.3
      Resolution:                    |             Keywords:
                                     |  QuantifiedConstraints
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):

 In `works3` we get
 {{{
   [G] forall z. CF a z      -- From the type signature
   [W] forall z. CF a z      -- from the call of works1
 }}}
 We can solve this no problem.

 And we also get
 {{{
   [G] CF a b       -- From the pattern match on Dict  Dict <- works1 p
   [W] C (F a b)    -- From the call of Dict on the RHS of works3
 }}}
 Now `C (F a b)` is a superclass of `CF a b`, so we get
 {{{
   [G] C (F a b)    -- Via superclass expansion
   [W] C (F a b)    -- From the call of Dict on the RHS of works3
 }}}
 We can solve this without difficulty.

 ---------------
 However, in `fails` we get this:
 {{{
   [G] forall z. CF a z   -- From the type signature on fails
   [W] C (F a b)
 }}}
 From superclass expansion we get
 {{{
   [G] forall z. C (F a z)   -- From superclass expansion
   [W] C (F a b)
 }}}
 And now we are stuck.  What `z` would make `C (F a z)` match `C (F a b)`?
 Well, yes, `b` would, but maybe also lots of other things.  GHC simply
 doesn't support matching involving type families.

 So, as it stands, this looks reasonable.  And I don't see an easy way to
 improve matters.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16365#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler