> 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

Reply via email to