Typechecker plugins: request for review and another workflow question

[Eric Seidel]

> On Nov 11, 2014, at 04:19, Adam Gundry <adam at well-typed.com> wrote:
> 
> I've just pushed wip/tc-plugins-amg, in which I remove the hs-boot file
> and unify the core2core and typechecker plugins under a single -fplugin
> flag. This did involve making a separate module for plugins, which I
> think is probably a good thing.

Thanks! I just checked out your branch, but had to add `Plugins` to the
list of exposed modules in ghc.cabal in order to actually use a plugin
though. Otherwise I get a horrible

  Symbol not found: _ghc_Plugins_Plugin_con_info

error from the linker when I try to compile a module with -fplugin=MyPlugin.

> I looked at using a hook instead, with a plugin to modify hooks, but I'm
> not sure exactly where such a plugin should be invoked. Ideally we want
> the typechecker modifications to work on a per-module basis, but most of
> the hooks seem to have a wider scope than that.

Well, I think we want the option to decide between per-module and global
invocation of plugins, e.g. if I pass -fplugin on the command-line then
I would expect ghc to use the plugin for *any* module it ends up compiling.

The list of plugins to enable is in the DynFlags, which suggests to me that
GHC must compile each module with a specific set of DynFlags, based on the
LANGUAGE and OPTIONS_GHC pragmas. The Hooks are also in the DynFlags, so
perhaps all we need to do is make -fplugin add a Hook, and let GHC's
existing machinery take care of the rest?

Eric