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