Typechecker plugins: request for review and another workflow question

[Eric Seidel]

> On Nov 10, 2014, at 09:46, Adam Gundry <adam at well-typed.com> wrote:
> 
> On 10/11/14 15:58, Austin Seipp wrote:
>> - 2) I am kind of not a fan of having separate 'plugins for
>> core2core' and 'plugins for typechecking' flags, AKA -ftc-plugin and
>> -fplugin. Ideally I would think all plugins could be uniformly
>> specified by simply saying '-fplugin'. This mostly avoids the need for
>> duplication and a naming convention/slew of flags for each case (which
>> we have to catalog and document). There may be an easy way to make
>> this the case; I haven't looked closely yet (it has been some time
>> since I starred at the plugin code, even though Max wrote it and I
>> helped get it merged!)
> 
> FWIW, I originally envisaged reusing the existing plugins machinery, and
> I don't think there are any great problems in doing so (see
> https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker). In fact, I
> had an early implementation of typechecker plugins that did exactly this.
> 
> I have been wondering, however, about another possible approach. We could:
> 
> 1. make the constraint solver changes use a *hook*, instead of the
> plugins directly, and
> 
> 2. make it possible for plugins to install/modify hooks at some
> suitable point in the compilation pipeline.
> 
> I don't know the hooks machinery very well, but if this is feasible it
> seems like it would provide more power (plugins could modify any part of
> GHC for which a hook is available) and avoid having multiple overlapping
> ways of extending GHC. In the future, I can imagine wanting plugins to
> hook into other parts of GHC (e.g. error message postprocessing for
> domain-specific error reporting), and this seems like a good way to
> achieve that.

I think we could merge the TcPlugin type into the existing Plugin type without
much difficulty, but I also agree that combining both plugin types with
Hooks to present a more uniform interface would be nice.

Eric