Re: Typechecker plugins: request for review and another workflow question

Hi, thanks Adam! I merged your changes into `wip/tc-plugin` and updated the type-nats plugin to work with the new plugin interface. -Iavor PS: It looks like `Plugins` was already in ghc.cabal.in and things worked form me. Maybe the problem was a stale ghc.cabal? On Tue, Nov 11, 2014 at 9:49 AM, Eric Seidel wrote:

...

On Nov 11, 2014, at 04:19, Adam Gundry 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