Add compilation stage plugins

There are several different tools that could be written using one of GHC's intermediate ASTs, like the post type-checking HsSyn Id. These can today be written as separate programs, using the GHC API. An example of such a program would be a CTAGS-on-steroids tool that would let you, as part of compilation, output a file containing all the names in the program, together with their source locations and types. This file could then be used to implement a type and qualified names aware grep.

However, compiling every file twice, once normally and once using this hypothetical tool, just to get that additional output file, is wasteful. It would be better if we could specify a plugin that would run at one of a few well defined places in the pipeline e.g. after renaming or type checking. Those plugins could be passed the data structures (e.g. HsSyn Id) created by GHC and then perform some arbitrary action (e.g. write to a file or modify the AST.)

Trac metadata

Trac field	Value
Version	7.4.1
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tfeature request Trac import labels

changed milestone to %7.8.1

To clarify, you're asking for something like http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/compiler-plugins.html but that allows you to hook in at an earlier stage, before the conversion to core, right?

changed milestone to %7.10.1

Moving to 7.10.1.

Is this feature request covered by Plugins/TypeChecker, D489?

I find this a desirable feature, so I took a quick look.

It seems that tcPlugin is currently focused on a pluggable constraint solver only:

data Plugin = Plugin {
    installCoreToDos :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]
    -- ^ Modify the Core pipeline that will be used for compilation.
    -- This is called as the Core pipeline is built for every module
    -- being compiled, and plugins get the opportunity to modify the
    -- pipeline in a nondeterministic order.
  , tcPlugin :: [CommandLineOption] -> Maybe TcPlugin
    -- ^ An optional typechecker plugin, which may modify the
    -- behaviour of the constraint solver.
  }

data TcPlugin = forall s. TcPlugin
  { tcPluginInit  :: TcPluginM s
    -- ^ Initialize plugin, when entering type-checker.

  , tcPluginSolve :: s -> TcPluginSolver
    -- ^ Solve some constraints.
    -- TODO: WRITE MORE DETAILS ON HOW THIS WORKS.

  , tcPluginStop  :: s -> TcPluginM ()
   -- ^ Clean up after the plugin, when exiting the type-checker.
  }

type TcPluginSolver = [Ct]    -- given
                   -> [Ct]    -- derived
                   -> [Ct]    -- wanted
                   -> TcPluginM TcPluginResult

At this point it seems that there are two main venues:

1. extend TcPlugin to add a hook for processing the final type-checked module (and widening the scope of tcPluginInit and tcPluginSolve), or
2. Add another plugin for AST hooks (ParsedModule, RenamedModule, and TypecheckedModule).

Now, as a user of this feature (or such feature), I would like to be able to do the following.

Assuming I have, for example, two modules:

module A where

import B

main = sayHello "Joe"

module B where

sayHello :: String -> IO ()
sayHello = putStrLn

I would like to create a plugin, here named DependenciesPlugin, that is invoked with:

ghc -fplugin=DependenciesPlugin --make A.hs

This plugin would be called once to initialize itself, which in this case means creating a A.dot file:

graph ModuleADependencies {

And once to terminate itself so that the A.dot file can be closed:

}

In between the initialization and termination, the plugin would be called for each module to process the TypecheckedModule and generate a subgraph and the function dependencies:

  subgraph ModuleA {
     ModuleA.main [label="main"]
  }
  ModuleA.main -> ModuleB.sayHello

  subgraph ModuleB {
     ModuleB.sayHello [label="sayHello"]
  }

And command line options could be provided to tailor the DOT file generation (just module dependencies, only function dependencies, both, only dependencies from a specific functions, etc). Another option is to also take into account the packages these modules come from.

removed milestone

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

I've felt for a while that there should be better integration between plugins and hooks, so that a plugin could hook into more stages of the compilation pipeline, and that hooks could register typechecker plugins. But I don't have a clear design yet, nor any spare cycles to work on this at the moment.

changed milestone to %8.0.1

Milestone renamed

added Pnormal label