> On Nov 30, 2020, at 3:50 PM, Christiaan Baaij <christiaan.ba...@gmail.com> > wrote: > > It seems like a function like `rewritePlugin` is something we could/should > just build on top of the existing plugin mechanism, and have something along > the line of: > > > -- | Create a 'TcPluginSolver' from the provided rewrite function > > rewritePluginSolver :: > > (s -> TyCon -> [TcType] -> TcPluginM (Maybe TcType)) -> > > (s -> TcPluginSolver) <> > > where `rewritePlugin` just traverses constraints with the given rewrite and > creates the evidence, emits new wanteds, etc. > (We could develop such a function outside of the `ghc` package, and only once > we have a satisfactory solution, perhaps consider it for inclusion in the > `ghc` package.) > This way, we won't have to make the common case of simplifying type families > slow, and still provide a straightforward API.
Ooh. I like that idea. Much more orthogonal than mine. It would mean, though, that a plugin that needs to reduce lots of type families is slower than it needs to be. (That is, my idea is slower in the common case of doing most type family reduction within GHC, but faster in the case where more type family reduction is done by plugin.) In any case, it would make a nice stepping stone for the future. If you (for any value of you) get all the infrastructure settled, I'll happily contribute the implementation of that particular function. It would be nice if the infrastructure allows me to test, as I'll surely get it wrong a few times before getting it right. Richard
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
