#12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This is nothing to do with specialisation. It has to do with how the constraint solver solves constraints. But it's not easy to fix you problem. GHC's constraint solver uses the "given" constraint (here `Num Int` via a superclass of `C Int b`) where possible. You may say "If there is an instance declaration, use that instead of the given constraint. But no {{{ f :: Ord [a] => ... f x = ..Need Eq [a]... }}} There is a top-level instance for `Eq [a]`, but if we use it we'll need `Eq a` and we haven't got that. So we must satisfy the `Eq [a]` from the superclass of `Ord [a]`. I suppose we could make a special case when the instance declaration does not generate any new constraints, as is the case for `Num Int`. Would that deal with your "ton of cases"? Can you give more concrete examples? I worry that it might not be long before someone complains that GHC is bypassing the dictionary they have passed in. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12791#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler