[GHC] #11457: Run type-checker plugins before GHC's solver

GHC ghc-devs at haskell.org
Wed Jan 20 17:32:33 UTC 2016


#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


More information about the ghc-tickets mailing list