Typechecker plugins: request for review and another workflow question
iavor.diatchki at gmail.com
Tue Nov 11 18:31:02 UTC 2014
thanks Adam! I merged your changes into `wip/tc-plugin` and updated the
type-nats plugin to work with the new plugin interface.
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 <eric at seidel.io> wrote:
> > 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
> > 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs