[GHC] #12791: Superclass methods could be more aggressively specialised.
GHC
ghc-devs at haskell.org
Tue Nov 1 16:15:08 UTC 2016
#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
More information about the ghc-tickets
mailing list