#11457: Run type-checker plugins before GHC's solver -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: plugin 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 gridaphobe): Replying to [comment:2 adamgundry]:
It should be easy to run the plugins first and permit them to reject dictionary constraints that have arisen directly from the source, but it's not clear that is very useful because many constraints arise during solving.
Shouldn't plugins get access to the extra constraints as part of the inner loop in `solveSimpleWanteds`? Oh I see, `solveSimples` has its own loop that greedily solves the constraints that it can, bummer.. We could change `solveSimples` to not grab constraints from the work-list directly, but to just solve the constraints it's given. Then any new work- list items would have to go through the whole pipeline, including plugins. I don't know what the performance implications would be though. But even then, it would still be hard to ensure that our plugin gets to reject the dictionary constraint, what if another plugin runs first and solves it? Hrm..
(Moreover, this would not work for equality constraints, because those are handled eagerly by the unifier.)
Right, but to be fair, I can't think of a reason I, as a user, would want to reject an equality constraint that can be proven. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11457#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler