[GHC] #13733: Simplify constraints on RULES LHS
GHC
ghc-devs at haskell.org
Mon May 22 16:27:14 UTC 2017
#13733: Simplify constraints on RULES LHS
-------------------------------------+-------------------------------------
Reporter: nomeata | Owner: (none)
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.3
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):
The problem is that the built-in rule that rewrites
{{{
GHC.Classes.$fEq[] @ Integer GHC.Integer.Type.$fEqInteger
---->
GHC.Classes.$fEq[]_$c== @ Integer GHC.Integer.Type.$fEqInteger
}}}
is firing before your user-defined rule has a chance to fire. The basic
problem is that two overlapping rules are competing, and it's a fluke
which "wins". Monkeying around with solving constraints on rule LHSs
might be a sticking plaster, but it won't tackle the underlying issue.
Possible solution: make the built-in rule fire in phase 2,1,0, but not in
the initial "gentle" phase.
Of course, ''not'' firing the built-in class-op rule means that other
things won't happen as early as they otherwise might, so I don't know what
the knock-on effects might be. But I think this is the path to follow if
you want to pursue this.
Something similar happens for the inlining for data constructor wrappers.
I'm sure there is a ticket about this stuff already. Maybe more than one.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13733#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list