#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