users_guide: Convert mkUserGuidePart generation to a Sphinx extension
[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 .. code-block:: none
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
194 :ghc-flag:`-fplugin=⟨module⟩` option where ⟨module⟩ is a
195 module in a registered package that exports a plugin. Arguments can be given to
196 plugins with the :ghc-flag:`-fplugin-opt=⟨module⟩:⟨args⟩` option.
197
198 .. ghc-flag:: -fplugin=⟨module⟩
199     :shortdesc: Load a plugin exported by a given module
200     :type: dynamic
201     :category: plugins
202
203     Load the plugin in the given module. The module must be a member of a
204     package registered in GHC's package database.
205
206 .. ghc-flag:: -fplugin-opt=⟨module⟩:⟨args⟩
207     :shortdesc: Give arguments to a plugin module; module must be specified with
208         :ghc-flag:`-fplugin=⟨module⟩`
209     :type: dynamic
210     :category: plugins
211
212     Give arguments to a plugin module; module must be specified with
213     :ghc-flag:`-fplugin=⟨module⟩`.
214
215
216 As an example, in order to load the plugin exported by ``Foo.Plugin`` in
217 the package ``foo-ghc-plugin``, and give it the parameter "baz", we
218 would invoke GHC like this:
219
220 .. code-block:: none
221
222     $ ghc -fplugin Foo.Plugin -fplugin-opt Foo.Plugin:baz Test.hs
223     [1 of 1] Compiling Main             ( Test.hs, Test.o )
224     Loading package ghc-prim ... linking ... done.
225     Loading package integer-gmp ... linking ... done.
226     Loading package base ... linking ... done.
227     Loading package ffi-1.0 ... linking ... done.
228     Loading package foo-ghc-plugin-0.1 ... linking ... done.
229     ...
230     Linking Test ...
231     $
232
233 Plugin modules live in a separate namespace from
234 the user import namespace.  By default, these two namespaces are
235 the same; however, there are a few command line options which
236 control specifically plugin packages:
237
238 .. ghc-flag:: -plugin-package ⟨pkg⟩
239     :shortdesc: Expose ⟨pkg⟩ for plugins
240     :type: dynamic
241     :category: plugins
242
243     This option causes the installed package ⟨pkg⟩ to be exposed for plugins,
244     such as :ghc-flag:`-fplugin=⟨module⟩`. The package ⟨pkg⟩ can be specified
245     in full with its version number (e.g.  ``network-1.0``) or the version
246     number can be omitted if there is only one version of the package
247     installed. If there are multiple versions of ⟨pkg⟩ installed and
248     :ghc-flag:`-hide-all-plugin-packages` was not specified, then all other
249     versions will become hidden.  :ghc-flag:`-plugin-package ⟨pkg⟩` supports
250     thinning and renaming described in :ref:`package-thinning-and-renaming`.
251
252     Unlike :ghc-flag:`-package ⟨pkg⟩`, this option does NOT cause package ⟨pkg⟩
253     to be linked into the resulting executable or shared object.
254
255 .. ghc-flag:: -plugin-package-id ⟨pkg-id⟩
256     :shortdesc: Expose ⟨pkg-id⟩ for plugins
257     :type: dynamic
258     :category: plugins
259
260     Exposes a package in the plugin namespace like :ghc-flag:`-plugin-package
261     ⟨pkg⟩`, but the package is named by its installed package ID rather than by
262     name.  This is a more robust way to name packages, and can be used to
263     select packages that would otherwise be shadowed. Cabal passes
264     :ghc-flag:`-plugin-package-id ⟨pkg-id⟩` flags to GHC.
265     :ghc-flag:`-plugin-package-id ⟨pkg-id⟩` supports thinning and renaming
266     described in :ref:`package-thinning-and-renaming`.
267
268 .. ghc-flag:: -hide-all-plugin-packages
269     :shortdesc: Hide all packages for plugins by default
270     :type: dynamic
271     :category: plugins
272
273     By default, all exposed packages in the normal, source import namespace are
274     also available for plugins.  This causes those packages to be hidden by
275     default.  If you use this flag, then any packages with plugins you require
276     need to be explicitly exposed using :ghc-flag:`-plugin-package ⟨pkg⟩`
277     options.
278
279 At the moment, the only way to specify a dependency on a plugin
280 in Cabal is to put it in ``build-depends`` (which uses the conventional
281 :ghc-flag:`-package-id ⟨unit-id⟩` flag); however, in the future there
282 will be a separate field for specifying plugin dependencies specifically.
283
284 .. _writing-compiler-plugins:
285
286 Writing compiler plugins
287 ~~~~~~~~~~~~~~~~~~~~~~~~
288
289 Plugins are modules that export at least a single identifier,
290 ``plugin``, of type ``GhcPlugins.Plugin``. All plugins should
291 ``import GhcPlugins`` as it defines the interface to the compilation
292 pipeline.
293
294 A ``Plugin`` effectively holds a function which installs a compilation
295 pass into the compiler pipeline. By default there is the empty plugin
296 which does nothing, ``GhcPlugins.defaultPlugin``, which you should
297 override with record syntax to specify your installation function. Since
298 the exact fields of the ``Plugin`` type are open to change, this is the
299 best way to ensure your plugins will continue to work in the future with
300 minimal interface impact.
301
302 ``Plugin`` exports a field, ``installCoreToDos`` which is a function of
303 type ``[CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]``. A
304 ``CommandLineOption`` is effectively just ``String``, and a ``CoreToDo``
305 is basically a function of type ``Core -> Core``. A ``CoreToDo`` gives
306 your pass a name and runs it over every compiled module when you invoke
307 GHC.
308
309 As a quick example, here is a simple plugin that just does nothing and
310 just returns the original compilation pipeline, unmodified, and says
311 'Hello':
312
313 ::
314
315     module DoNothing.Plugin (plugin) where
316     import GhcPlugins
317
318     plugin :: Plugin
319     plugin = defaultPlugin {
320       installCoreToDos = install
321       }
322
323     install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]
324     install _ todo = do
325       putMsgS "Hello!"
326       return todo
327
328 Provided you compiled this plugin and registered it in a package (with
329 cabal for instance,) you can then use it by just specifying
330 ``-fplugin=DoNothing.Plugin`` on the command line, and during the
331 compilation you should see GHC say 'Hello'.
332
333 .. _core-plugins-in-more-detail:
334
335 Core plugins in more detail
336 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
337
338 ``CoreToDo`` is effectively a data type that describes all the kinds of
339 optimization passes GHC does on Core. There are passes for
340 simplification, CSE, vectorisation, etc. There is a specific case for
341 plugins, ``CoreDoPluginPass :: String -> PluginPass -> CoreToDo`` which
342 should be what you always use when inserting your own pass into the
343 pipeline. The first parameter is the name of the plugin, and the second
344 is the pass you wish to insert.
345
346 ``CoreM`` is a monad that all of the Core optimizations live and operate
347 inside of.
348
349 A plugin's installation function (``install`` in the above example)
350 takes a list of ``CoreToDo``\ s and returns a list of ``CoreToDo``.
351 Before GHC begins compiling modules, it enumerates all the needed
352 plugins you tell it to load, and runs all of their installation
353 functions, initially on a list of passes that GHC specifies itself.
354 After doing this for every plugin, the final list of passes is given to
355 the optimizer, and are run by simply going over the list in order.
356
357 You should be careful with your installation function, because the list
358 of passes you give back isn't questioned or double checked by GHC at the
359 time of this writing. An installation function like the following:
360
361 ::
362
363     install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]
364     install _ _ = return []
365
366 is certainly valid, but also certainly not what anyone really wants.
367
368 .. _manipulating-bindings:
369
370 Manipulating bindings
371 ^^^^^^^^^^^^^^^^^^^^^
372
373 In the last section we saw that besides a name, a ``CoreDoPluginPass``
374 takes a pass of type ``PluginPass``. A ``PluginPass`` is a synonym for
375 ``(ModGuts -> CoreM ModGuts)``. ``ModGuts`` is a type that represents
376 the one module being compiled by GHC at any given time.
377
378 A ``ModGuts`` holds all of the module's top level bindings which we can
379 examine. These bindings are of type ``CoreBind`` and effectively
380 represent the binding of a name to body of code. Top-level module
381 bindings are part of a ``ModGuts`` in the field ``mg_binds``.
382 Implementing a pass that manipulates the top level bindings merely needs
383 to iterate over this field, and return a new ``ModGuts`` with an updated
384 ``mg_binds`` field. Because this is such a common case, there is a
385 function provided named ``bindsOnlyPass`` which lifts a function of type
386 ``([CoreBind] -> CoreM [CoreBind])`` to type
387 ``(ModGuts -> CoreM ModGuts)``.
388
389 Continuing with our example from the last section, we can write a simple
390 plugin that just prints out the name of all the non-recursive bindings
391 in a module it compiles:
392
393 ::
394
395     module SayNames.Plugin (plugin) where
396     import GhcPlugins
397
398     plugin :: Plugin
399     plugin = defaultPlugin {
400       installCoreToDos = install
401       }
402
403     install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]
404     install _ todo = do
405       return (CoreDoPluginPass "Say name" pass : todo)
406
407     pass :: ModGuts -> CoreM ModGuts
408     pass guts = do dflags <- getDynFlags
409                    bindsOnlyPass (mapM (printBind dflags)) guts
410       where printBind :: DynFlags -> CoreBind -> CoreM CoreBind
411             printBind dflags bndr@(NonRec b _) = do
412               putMsgS $ "Non-recursive binding named " ++ showSDoc dflags (ppr b)
413               return bndr 
414             printBind _ bndr = return bndr
415
416 .. _getting-annotations:
417
418 Using Annotations
419 ^^^^^^^^^^^^^^^^^
420
421 Previously we discussed annotation pragmas (:ref:`annotation-pragmas`),
422 which we mentioned could be used to give compiler plugins extra guidance
423 or information. Annotations for a module can be retrieved by a plugin,
424 but you must go through the modules ``ModGuts`` in order to get it.
425 Because annotations can be arbitrary instances of ``Data`` and
426 ``Typeable``, you need to give a type annotation specifying the proper
427 type of data to retrieve from the interface file, and you need to make
428 sure the annotation type used by your users is the same one your plugin
429 uses. For this reason, we advise distributing annotations as part of the
430 package which also provides compiler plugins if possible.
431
432 To get the annotations of a single binder, you can use
433 ``getAnnotations`` and specify the proper type. Here's an example that
434 will print out the name of any top-level non-recursive binding with the
435 ``SomeAnn`` annotation:
436
437 ::
438
439     {-# LANGUAGE DeriveDataTypeable #-}
440     module SayAnnNames.Plugin (plugin, SomeAnn(..)) where
441     import GhcPlugins
442     import Control.Monad (unless)
443     import Data.Data
444
445     data SomeAnn = SomeAnn deriving Data
446
447     plugin :: Plugin
448     plugin = defaultPlugin {
449       installCoreToDos = install
450       }
451
452     install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]
453     install _ todo = do
454       return (CoreDoPluginPass "Say name" pass : todo)
455
456     pass :: ModGuts -> CoreM ModGuts
457     pass g = do
458               dflags <- getDynFlags
459               mapM_ (printAnn dflags g) (mg_binds g) >> return g
460       where printAnn :: DynFlags -> ModGuts -> CoreBind -> CoreM CoreBind
461             printAnn dflags guts bndr@(NonRec b _) = do
462               anns <- annotationsOn guts b :: CoreM [SomeAnn]
463               unless (null anns) $ putMsgS $ "Annotated binding found: " ++  showSDoc dflags (ppr b)
464               return bndr
465             printAnn _ _ bndr = return bndr
466
467     annotationsOn :: Data a => ModGuts -> CoreBndr -> CoreM [a]
468     annotationsOn guts bndr = do
469       anns <- getAnnotations deserializeWithData guts
470       return $ lookupWithDefaultUFM anns [] (varUnique bndr)
471
472 Please see the GHC API documentation for more about how to use internal
473 APIs, etc.
474
475 .. _typechecker-plugins:
476
477 Typechecker plugins
478 ~~~~~~~~~~~~~~~~~~~
479
480 In addition to Core plugins, GHC has experimental support for
481 typechecker plugins, which allow the behaviour of the constraint solver
482 to be modified. For example, they make it possible to interface the
483 compiler to an SMT solver, in order to support a richer theory of
484 type-level arithmetic expressions than the theory built into GHC (see
485 :ref:`typelit-tyfuns`).
486
487 The ``Plugin`` type has a field ``tcPlugin`` of type
488 ``[CommandLineOption] -> Maybe TcPlugin``, where the ``TcPlugin`` type
489 is defined thus:
490
491 ::
492
493     data TcPlugin = forall s . TcPlugin
494       { tcPluginInit  :: TcPluginM s
495       , tcPluginSolve :: s -> TcPluginSolver
496       , tcPluginStop  :: s -> TcPluginM ()
497       }
498
499     type TcPluginSolver = [Ct] -> [Ct] -> [Ct] -> TcPluginM TcPluginResult
500
501     data TcPluginResult = TcPluginContradiction [Ct] | TcPluginOk [(EvTerm,Ct)] [Ct]
502
503 (The details of this representation are subject to change as we gain
504 more experience writing typechecker plugins. It should not be assumed to
505 be stable between GHC releases.)
506
507 The basic idea is as follows:
508
509 -  When type checking a module, GHC calls ``tcPluginInit`` once before
510    constraint solving starts. This allows the plugin to look things up
511    in the context, initialise mutable state or open a connection to an
512    external process (e.g. an external SMT solver). The plugin can return
513    a result of any type it likes, and the result will be passed to the
514    other two fields.
515
516 -  During constraint solving, GHC repeatedly calls ``tcPluginSolve``.
517    This function is provided with the current set of constraints, and
518    should return a ``TcPluginResult`` that indicates whether a
519    contradiction was found or progress was made. If the plugin solver
520    makes progress, GHC will re-start the constraint solving pipeline,
521    looping until a fixed point is reached.
522
523 -  Finally, GHC calls ``tcPluginStop`` after constraint solving is
524    finished, allowing the plugin to dispose of any resources it has
525    allocated (e.g. terminating the SMT solver process).
526
527 Plugin code runs in the ``TcPluginM`` monad, which provides a restricted
528 interface to GHC API functionality that is relevant for typechecker
529 plugins, including ``IO`` and reading the environment. If you need
530 functionality that is not exposed in the ``TcPluginM`` module, you can
531 use ``unsafeTcPluginTcM :: TcM a -> TcPluginM a``, but are encouraged to
532 contact the GHC team to suggest additions to the interface. Note that
533 ``TcPluginM`` can perform arbitrary IO via
534 ``tcPluginIO :: IO a -> TcPluginM a``, although some care must be taken
535 with side effects (particularly in ``tcPluginSolve``). In general, it is
536 up to the plugin author to make sure that any IO they do is safe.
537
538 .. _constraint-solving-with-plugins:
539
540 Constraint solving with plugins
541 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
542
543 The key component of a typechecker plugin is a function of type
544 ``TcPluginSolver``, like this:
545
546 ::
547
548     solve :: [Ct] -> [Ct] -> [Ct] -> TcPluginM TcPluginResult
549     solve givens deriveds wanteds = ...
550
551 This function will be invoked at two points in the constraint solving
552 process: after simplification of given constraints, and after
553 unflattening of wanted constraints. The two phases can be distinguished
554 because the deriveds and wanteds will be empty in the first case. In
555 each case, the plugin should either
556
557 -  return ``TcPluginContradiction`` with a list of impossible
558    constraints (which must be a subset of those passed in), so they can
559    be turned into errors; or
560
561 -  return ``TcPluginOk`` with lists of solved and new constraints (the
562    former must be a subset of those passed in and must be supplied with
563    corresponding evidence terms).
564
565 If the plugin cannot make any progress, it should return
566 ``TcPluginOk [] []``. Otherwise, if there were any new constraints, the
567 main constraint solver will be re-invoked to simplify them, then the
568 plugin will be invoked again. The plugin is responsible for making sure
569 that this process eventually terminates.
570
571 Plugins are provided with all available constraints (including
572 equalities and typeclass constraints), but it is easy for them to
573 discard those that are not relevant to their domain, because they need
574 return only those constraints for which they have made progress (either
575 by solving or contradicting them).
576
577 Constraints that have been solved by the plugin must be provided with
578 evidence in the form of an ``EvTerm`` of the type of the constraint.
579 This evidence is ignored for given and derived constraints, which GHC
580 "solves" simply by discarding them; typically this is used when they are
581 uninformative (e.g. reflexive equations). For wanted constraints, the
582 evidence will form part of the Core term that is generated after
583 typechecking, and can be checked by ``-dcore-lint``. It is possible for
584 the plugin to create equality axioms for use in evidence terms, but GHC
585 does not check their consistency, and inconsistent axiom sets may lead
586 to segfaults or other runtime misbehaviour.
587
588 .. _frontend_plugins:
589
590 Frontend plugins
591 ~~~~~~~~~~~~~~~~
592
593 A frontend plugin allows you to add new major modes to GHC.  You may prefer
594 this over a traditional program which calls the GHC API, as GHC manages a lot
595 of parsing flags and administrative nonsense which can be difficult to
596 manage manually.  To load a frontend plugin exported by ``Foo.FrontendPlugin``,
597 we just invoke GHC with the :ghc-flag:`--frontend ⟨module⟩` flag as follows:
598
599 .. code-block:: none
600
601     $ ghc --frontend Foo.FrontendPlugin ...other options...
602
603 Frontend plugins, like compiler plugins, are exported by registered plugins.
604 However, unlike compiler modules, frontend plugins are modules that export
605 at least a single identifier ``frontendPlugin`` of type
606 ``GhcPlugins.FrontendPlugin``.
607
608 ``FrontendPlugin`` exports a field ``frontend``, which is a function
609 ``[String] -> [(String, Maybe Phase)] -> Ghc ()``.  The first argument
610 is a list of extra flags passed to the frontend with ``-ffrontend-opt``;
611 the second argument is the list of arguments, usually source files
612 and module names to be compiled (the ``Phase`` indicates if an ``-x``
613 flag was set), and a frontend simply executes some operation in the
614 ``Ghc`` monad (which, among other things, has a ``Session``).
615
616 As a quick example, here is a frontend plugin that prints the arguments that
617 were passed to it, and then exits.
618
619 ::
620
621     module DoNothing.FrontendPlugin (frontendPlugin) where
622     import GhcPlugins
623
624     frontendPlugin :: FrontendPlugin
625     frontendPlugin = defaultFrontendPlugin {
626       frontend = doNothing
627       }
628
629     doNothing :: [String] -> [(String, Maybe Phase)] -> Ghc ()
630     doNothing flags args = do
631         liftIO $ print flags
632         liftIO $ print args
633
634 Provided you have compiled this plugin and registered it in a package,
635 you can just use it by specifying ``--frontend DoNothing.FrontendPlugin``
636 on the command line to GHC.