extending_ghc.rst: fix broken link (Trac #10950)
[ghc.git] / docs / users_guide / extending_ghc.rst
1 .. _extending-ghc:
2
3 Extending and using GHC as a Library
4 ====================================
5
6 GHC exposes its internal APIs to users through the built-in ghc package.
7 It allows you to write programs that leverage GHC's entire compilation
8 driver, in order to analyze or compile Haskell code programmatically.
9 Furthermore, GHC gives users the ability to load compiler plugins during
10 compilation - modules which are allowed to view and change GHC's
11 internal intermediate representation, Core. Plugins are suitable for
12 things like experimental optimizations or analysis, and offer a lower
13 barrier of entry to compiler development for many common cases.
14
15 Furthermore, GHC offers a lightweight annotation mechanism that you can
16 use to annotate your source code with metadata, which you can later
17 inspect with either the compiler API or a compiler plugin.
18
19 .. _annotation-pragmas:
20
21 Source annotations
22 ------------------
23
24 Annotations are small pragmas that allow you to attach data to
25 identifiers in source code, which are persisted when compiled. These
26 pieces of data can then inspected and utilized when using GHC as a
27 library or writing a compiler plugin.
28
29 .. _ann-pragma:
30
31 Annotating values
32 ~~~~~~~~~~~~~~~~~
33
34 .. index::
35    single: ANN pragma
36    single: pragma; ANN
37    single: source annotations
38
39 Any expression that has both ``Typeable`` and ``Data`` instances may be
40 attached to a top-level value binding using an ``ANN`` pragma. In
41 particular, this means you can use ``ANN`` to annotate data constructors
42 (e.g. ``Just``) as well as normal values (e.g. ``take``). By way of
43 example, to annotate the function ``foo`` with the annotation
44 ``Just "Hello"`` you would do this:
45
46 ::
47
48     {-# ANN foo (Just "Hello") #-}
49     foo = ...
50
51 A number of restrictions apply to use of annotations:
52
53 -  The binder being annotated must be at the top level (i.e. no nested
54    binders)
55
56 -  The binder being annotated must be declared in the current module
57
58 -  The expression you are annotating with must have a type with
59    ``Typeable`` and ``Data`` instances
60
61 -  The :ref:`Template Haskell staging restrictions <th-usage>` apply to the
62    expression being annotated with, so for example you cannot run a
63    function from the module being compiled.
64
65    To be precise, the annotation ``{-# ANN x e #-}`` is well staged if
66    and only if ``$(e)`` would be (disregarding the usual type
67    restrictions of the splice syntax, and the usual restriction on
68    splicing inside a splice - ``$([|1|])`` is fine as an annotation,
69    albeit redundant).
70
71 If you feel strongly that any of these restrictions are too onerous,
72 :ghc-wiki:`please give the GHC team a shout <MailingListsAndIRC>`.
73
74 However, apart from these restrictions, many things are allowed,
75 including expressions which are not fully evaluated! Annotation
76 expressions will be evaluated by the compiler just like Template Haskell
77 splices are. So, this annotation is fine:
78
79 ::
80
81     {-# ANN f SillyAnnotation { foo = (id 10) + $([| 20 |]), bar = 'f } #-}
82     f = ...
83
84 .. _typeann-pragma:
85
86 Annotating types
87 ~~~~~~~~~~~~~~~~
88
89 .. index::
90    single: ANN pragma; on types
91
92 You can annotate types with the ``ANN`` pragma by using the ``type``
93 keyword. For example:
94
95 ::
96
97     {-# ANN type Foo (Just "A `Maybe String' annotation") #-}
98     data Foo = ...
99
100 .. _modann-pragma:
101
102 Annotating modules
103 ~~~~~~~~~~~~~~~~~~
104
105 .. index::
106    single: ANN pragma; on modules
107
108 You can annotate modules with the ``ANN`` pragma by using the ``module``
109 keyword. For example:
110
111 ::
112
113     {-# ANN module (Just "A `Maybe String' annotation") #-}
114
115 .. _ghc-as-a-library:
116
117 Using GHC as a Library
118 ----------------------
119
120 The ``ghc`` package exposes most of GHC's frontend to users, and thus
121 allows you to write programs that leverage it. This library is actually
122 the same library used by GHC's internal, frontend compilation driver,
123 and thus allows you to write tools that programmatically compile source
124 code and inspect it. Such functionality is useful in order to write
125 things like IDE or refactoring tools. As a simple example, here's a
126 program which compiles a module, much like ghc itself does by default
127 when invoked:
128
129 ::
130
131     import GHC
132     import GHC.Paths ( libdir )
133     import DynFlags ( defaultLogAction )
134      
135     main = 
136         defaultErrorHandler defaultLogAction $ do
137           runGhc (Just libdir) $ do
138             dflags <- getSessionDynFlags
139             setSessionDynFlags dflags
140             target <- guessTarget "test_main.hs" Nothing
141             setTargets [target]
142             load LoadAllTargets
143
144 The argument to ``runGhc`` is a bit tricky. GHC needs this to find its
145 libraries, so the argument must refer to the directory that is printed
146 by ``ghc --print-libdir`` for the same version of GHC that the program
147 is being compiled with. Above we therefore use the ``ghc-paths`` package
148 which provides this for us.
149
150 Compiling it results in:
151
152 ::
153
154     $ cat test_main.hs
155     main = putStrLn "hi"
156     $ ghc -package ghc simple_ghc_api.hs
157     [1 of 1] Compiling Main             ( simple_ghc_api.hs, simple_ghc_api.o )
158     Linking simple_ghc_api ...
159     $ ./simple_ghc_api
160     $ ./test_main 
161     hi
162     $
163
164 For more information on using the API, as well as more samples and
165 references, please see `this Haskell.org wiki
166 page <http://haskell.org/haskellwiki/GHC/As_a_library>`__.
167
168 .. _compiler-plugins:
169
170 Compiler Plugins
171 ----------------
172
173 GHC has the ability to load compiler plugins at compile time. The
174 feature is similar to the one provided by
175 `GCC <http://gcc.gnu.org/wiki/plugins>`__, and allows users to write
176 plugins that can adjust the behaviour of the constraint solver, inspect
177 and modify the compilation pipeline, as well as transform and inspect
178 GHC's intermediate language, Core. Plugins are suitable for experimental
179 analysis or optimization, and require no changes to GHC's source code to
180 use.
181
182 Plugins cannot optimize/inspect C--, nor can they implement things like
183 parser/front-end modifications like GCC, apart from limited changes to
184 the constraint solver. If you feel strongly that any of these
185 restrictions are too onerous,
186 :ghc-wiki:`please give the GHC team a shout <MailingListsAndIRC>`.
187
188 .. _using-compiler-plugins:
189
190 Using compiler plugins
191 ~~~~~~~~~~~~~~~~~~~~~~
192
193 Plugins can be specified on the command line with the option
194 ``-fplugin=module`` where ⟨module⟩ is a module in a registered package
195 that exports a plugin. Arguments can be given to plugins with the
196 command line option ``-fplugin-opt=module:args``, where ⟨args⟩ are
197 arguments interpreted by the plugin provided by ⟨module⟩.
198
199 As an example, in order to load the plugin exported by ``Foo.Plugin`` in
200 the package ``foo-ghc-plugin``, and give it the parameter "baz", we
201 would invoke GHC like this:
202
203 ::
204
205     $ ghc -fplugin Foo.Plugin -fplugin-opt Foo.Plugin:baz Test.hs
206     [1 of 1] Compiling Main             ( Test.hs, Test.o )
207     Loading package ghc-prim ... linking ... done.
208     Loading package integer-gmp ... linking ... done.
209     Loading package base ... linking ... done.
210     Loading package ffi-1.0 ... linking ... done.
211     Loading package foo-ghc-plugin-0.1 ... linking ... done.
212     ...
213     Linking Test ...
214     $
215
216 Since plugins are exported by registered packages, it's safe to put
217 dependencies on them in cabal for example, and specify plugin arguments
218 to GHC through the ``ghc-options`` field.
219
220 .. _writing-compiler-plugins:
221
222 Writing compiler plugins
223 ~~~~~~~~~~~~~~~~~~~~~~~~
224
225 Plugins are modules that export at least a single identifier,
226 ``plugin``, of type ``GhcPlugins.Plugin``. All plugins should
227 ``import GhcPlugins`` as it defines the interface to the compilation
228 pipeline.
229
230 A ``Plugin`` effectively holds a function which installs a compilation
231 pass into the compiler pipeline. By default there is the empty plugin
232 which does nothing, ``GhcPlugins.defaultPlugin``, which you should
233 override with record syntax to specify your installation function. Since
234 the exact fields of the ``Plugin`` type are open to change, this is the
235 best way to ensure your plugins will continue to work in the future with
236 minimal interface impact.
237
238 ``Plugin`` exports a field, ``installCoreToDos`` which is a function of
239 type ``[CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]``. A
240 ``CommandLineOption`` is effectively just ``String``, and a ``CoreToDo``
241 is basically a function of type ``Core -> Core``. A ``CoreToDo`` gives
242 your pass a name and runs it over every compiled module when you invoke
243 GHC.
244
245 As a quick example, here is a simple plugin that just does nothing and
246 just returns the original compilation pipeline, unmodified, and says
247 'Hello':
248
249 ::
250
251     module DoNothing.Plugin (plugin) where
252     import GhcPlugins
253
254     plugin :: Plugin
255     plugin = defaultPlugin {
256       installCoreToDos = install
257       }
258
259     install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]
260     install _ todo = do
261       reinitializeGlobals
262       putMsgS "Hello!"
263       return todo
264
265 Provided you compiled this plugin and registered it in a package (with
266 cabal for instance,) you can then use it by just specifying
267 ``-fplugin=DoNothing.Plugin`` on the command line, and during the
268 compilation you should see GHC say 'Hello'.
269
270 Note carefully the ``reinitializeGlobals`` call at the beginning of the
271 installation function. Due to bugs in the windows linker dealing with
272 ``libghc``, this call is necessary to properly ensure compiler plugins
273 have the same global state as GHC at the time of invocation. Without
274 ``reinitializeGlobals``, compiler plugins can crash at runtime because
275 they may require state that hasn't otherwise been initialized.
276
277 In the future, when the linking bugs are fixed, ``reinitializeGlobals``
278 will be deprecated with a warning, and changed to do nothing.
279
280 .. _core-plugins-in-more-detail:
281
282 Core plugins in more detail
283 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
284
285 ``CoreToDo`` is effectively a data type that describes all the kinds of
286 optimization passes GHC does on Core. There are passes for
287 simplification, CSE, vectorisation, etc. There is a specific case for
288 plugins, ``CoreDoPluginPass :: String -> PluginPass -> CoreToDo`` which
289 should be what you always use when inserting your own pass into the
290 pipeline. The first parameter is the name of the plugin, and the second
291 is the pass you wish to insert.
292
293 ``CoreM`` is a monad that all of the Core optimizations live and operate
294 inside of.
295
296 A plugin's installation function (``install`` in the above example)
297 takes a list of ``CoreToDo``\ s and returns a list of ``CoreToDo``.
298 Before GHC begins compiling modules, it enumerates all the needed
299 plugins you tell it to load, and runs all of their installation
300 functions, initially on a list of passes that GHC specifies itself.
301 After doing this for every plugin, the final list of passes is given to
302 the optimizer, and are run by simply going over the list in order.
303
304 You should be careful with your installation function, because the list
305 of passes you give back isn't questioned or double checked by GHC at the
306 time of this writing. An installation function like the following:
307
308 ::
309
310     install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]
311     install _ _ = return []
312
313 is certainly valid, but also certainly not what anyone really wants.
314
315 .. _manipulating-bindings:
316
317 Manipulating bindings
318 ^^^^^^^^^^^^^^^^^^^^^
319
320 In the last section we saw that besides a name, a ``CoreDoPluginPass``
321 takes a pass of type ``PluginPass``. A ``PluginPass`` is a synonym for
322 ``(ModGuts -> CoreM ModGuts)``. ``ModGuts`` is a type that represents
323 the one module being compiled by GHC at any given time.
324
325 A ``ModGuts`` holds all of the module's top level bindings which we can
326 examine. These bindings are of type ``CoreBind`` and effectively
327 represent the binding of a name to body of code. Top-level module
328 bindings are part of a ``ModGuts`` in the field ``mg_binds``.
329 Implementing a pass that manipulates the top level bindings merely needs
330 to iterate over this field, and return a new ``ModGuts`` with an updated
331 ``mg_binds`` field. Because this is such a common case, there is a
332 function provided named ``bindsOnlyPass`` which lifts a function of type
333 ``([CoreBind] -> CoreM [CoreBind])`` to type
334 ``(ModGuts -> CoreM ModGuts)``.
335
336 Continuing with our example from the last section, we can write a simple
337 plugin that just prints out the name of all the non-recursive bindings
338 in a module it compiles:
339
340 ::
341
342     module SayNames.Plugin (plugin) where
343     import GhcPlugins
344
345     plugin :: Plugin
346     plugin = defaultPlugin {
347       installCoreToDos = install
348       }
349
350     install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]
351     install _ todo = do
352       reinitializeGlobals
353       return (CoreDoPluginPass "Say name" pass : todo)
354
355     pass :: ModGuts -> CoreM ModGuts
356     pass guts = do dflags <- getDynFlags
357                    bindsOnlyPass (mapM (printBind dflags)) guts
358       where printBind :: DynFlags -> CoreBind -> CoreM CoreBind
359             printBind dflags bndr@(NonRec b _) = do
360               putMsgS $ "Non-recursive binding named " ++ showSDoc dflags (ppr b)
361               return bndr 
362             printBind _ bndr = return bndr
363
364 .. _getting-annotations:
365
366 Using Annotations
367 ^^^^^^^^^^^^^^^^^
368
369 Previously we discussed annotation pragmas (:ref:`annotation-pragmas`),
370 which we mentioned could be used to give compiler plugins extra guidance
371 or information. Annotations for a module can be retrieved by a plugin,
372 but you must go through the modules ``ModGuts`` in order to get it.
373 Because annotations can be arbitrary instances of ``Data`` and
374 ``Typeable``, you need to give a type annotation specifying the proper
375 type of data to retrieve from the interface file, and you need to make
376 sure the annotation type used by your users is the same one your plugin
377 uses. For this reason, we advise distributing annotations as part of the
378 package which also provides compiler plugins if possible.
379
380 To get the annotations of a single binder, you can use
381 ``getAnnotations`` and specify the proper type. Here's an example that
382 will print out the name of any top-level non-recursive binding with the
383 ``SomeAnn`` annotation:
384
385 ::
386
387     {-# LANGUAGE DeriveDataTypeable #-}
388     module SayAnnNames.Plugin (plugin, SomeAnn(..)) where
389     import GhcPlugins
390     import Control.Monad (unless)
391     import Data.Data
392
393     data SomeAnn = SomeAnn deriving (Data, Typeable)
394
395     plugin :: Plugin
396     plugin = defaultPlugin {
397       installCoreToDos = install
398       }
399
400     install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]
401     install _ todo = do
402       reinitializeGlobals
403       return (CoreDoPluginPass "Say name" pass : todo)
404
405     pass :: ModGuts -> CoreM ModGuts
406     pass g = do
407               dflags <- getDynFlags
408               mapM_ (printAnn dflags g) (mg_binds g) >> return g
409       where printAnn :: DynFlags -> ModGuts -> CoreBind -> CoreM CoreBind
410             printAnn dflags guts bndr@(NonRec b _) = do
411               anns <- annotationsOn guts b :: CoreM [SomeAnn]
412               unless (null anns) $ putMsgS $ "Annotated binding found: " ++  showSDoc dflags (ppr b)
413               return bndr
414             printAnn _ _ bndr = return bndr
415
416     annotationsOn :: Data a => ModGuts -> CoreBndr -> CoreM [a]
417     annotationsOn guts bndr = do
418       anns <- getAnnotations deserializeWithData guts
419       return $ lookupWithDefaultUFM anns [] (varUnique bndr)
420
421 Please see the GHC API documentation for more about how to use internal
422 APIs, etc.
423
424 .. _typechecker-plugins:
425
426 Typechecker plugins
427 ~~~~~~~~~~~~~~~~~~~
428
429 In addition to Core plugins, GHC has experimental support for
430 typechecker plugins, which allow the behaviour of the constraint solver
431 to be modified. For example, they make it possible to interface the
432 compiler to an SMT solver, in order to support a richer theory of
433 type-level arithmetic expressions than the theory built into GHC (see
434 :ref:`typelit-tyfuns`).
435
436 The ``Plugin`` type has a field ``tcPlugin`` of type
437 ``[CommandLineOption] -> Maybe TcPlugin``, where the ``TcPlugin`` type
438 is defined thus:
439
440 ::
441
442     data TcPlugin = forall s . TcPlugin
443       { tcPluginInit  :: TcPluginM s
444       , tcPluginSolve :: s -> TcPluginSolver
445       , tcPluginStop  :: s -> TcPluginM ()
446       }
447
448     type TcPluginSolver = [Ct] -> [Ct] -> [Ct] -> TcPluginM TcPluginResult
449
450     data TcPluginResult = TcPluginContradiction [Ct] | TcPluginOk [(EvTerm,Ct)] [Ct]
451
452 (The details of this representation are subject to change as we gain
453 more experience writing typechecker plugins. It should not be assumed to
454 be stable between GHC releases.)
455
456 The basic idea is as follows:
457
458 -  When type checking a module, GHC calls ``tcPluginInit`` once before
459    constraint solving starts. This allows the plugin to look things up
460    in the context, initialise mutable state or open a connection to an
461    external process (e.g. an external SMT solver). The plugin can return
462    a result of any type it likes, and the result will be passed to the
463    other two fields.
464
465 -  During constraint solving, GHC repeatedly calls ``tcPluginSolve``.
466    This function is provided with the current set of constraints, and
467    should return a ``TcPluginResult`` that indicates whether a
468    contradiction was found or progress was made. If the plugin solver
469    makes progress, GHC will re-start the constraint solving pipeline,
470    looping until a fixed point is reached.
471
472 -  Finally, GHC calls ``tcPluginStop`` after constraint solving is
473    finished, allowing the plugin to dispose of any resources it has
474    allocated (e.g. terminating the SMT solver process).
475
476 Plugin code runs in the ``TcPluginM`` monad, which provides a restricted
477 interface to GHC API functionality that is relevant for typechecker
478 plugins, including ``IO`` and reading the environment. If you need
479 functionality that is not exposed in the ``TcPluginM`` module, you can
480 use ``unsafeTcPluginTcM :: TcM a -> TcPluginM a``, but are encouraged to
481 contact the GHC team to suggest additions to the interface. Note that
482 ``TcPluginM`` can perform arbitrary IO via
483 ``tcPluginIO :: IO a -> TcPluginM a``, although some care must be taken
484 with side effects (particularly in ``tcPluginSolve``). In general, it is
485 up to the plugin author to make sure that any IO they do is safe.
486
487 .. _constraint-solving-with-plugins:
488
489 Constraint solving with plugins
490 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
491
492 The key component of a typechecker plugin is a function of type
493 ``TcPluginSolver``, like this:
494
495 ::
496
497     solve :: [Ct] -> [Ct] -> [Ct] -> TcPluginM TcPluginResult
498     solve givens deriveds wanteds = ...
499
500 This function will be invoked at two points in the constraint solving
501 process: after simplification of given constraints, and after
502 unflattening of wanted constraints. The two phases can be distinguished
503 because the deriveds and wanteds will be empty in the first case. In
504 each case, the plugin should either
505
506 -  return ``TcPluginContradiction`` with a list of impossible
507    constraints (which must be a subset of those passed in), so they can
508    be turned into errors; or
509
510 -  return ``TcPluginOk`` with lists of solved and new constraints (the
511    former must be a subset of those passed in and must be supplied with
512    corresponding evidence terms).
513
514 If the plugin cannot make any progress, it should return
515 ``TcPluginOk [] []``. Otherwise, if there were any new constraints, the
516 main constraint solver will be re-invoked to simplify them, then the
517 plugin will be invoked again. The plugin is responsible for making sure
518 that this process eventually terminates.
519
520 Plugins are provided with all available constraints (including
521 equalities and typeclass constraints), but it is easy for them to
522 discard those that are not relevant to their domain, because they need
523 return only those constraints for which they have made progress (either
524 by solving or contradicting them).
525
526 Constraints that have been solved by the plugin must be provided with
527 evidence in the form of an ``EvTerm`` of the type of the constraint.
528 This evidence is ignored for given and derived constraints, which GHC
529 "solves" simply by discarding them; typically this is used when they are
530 uninformative (e.g. reflexive equations). For wanted constraints, the
531 evidence will form part of the Core term that is generated after
532 typechecking, and can be checked by ``-dcore-lint``. It is possible for
533 the plugin to create equality axioms for use in evidence terms, but GHC
534 does not check their consistency, and inconsistent axiom sets may lead
535 to segfaults or other runtime misbehaviour.