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 <e...@seidel.io> wrote: > > > On Nov 11, 2014, at 04:19, Adam Gundry <a...@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 >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
