#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