Table of Contents
Haddock is invoked from the command line, like so:
file is a filename
containing a Haskell source module. Only plain Haskell source
files are accepted (but see Section 2.1, “Using literate or pre-processed source” for instructions
on how to pre-process source files for feeding to Haddock).
All the modules specified on the command line will be processed together. When one module refers to an entity in another module being processed, the documentation will link directly to that entity.
Entities that cannot be found, for example because they are in a module that isn't being processed as part of the current batch, simply won't be hyperlinked in the generated documentation. Haddock will emit warnings listing all the indentifiers it couldn't resolve.
The modules should not be mutually recursive, as Haddock don't like swimming in circles.
The following options are available:
Generate files into
instead of the current directory.
Read the interface file in
file, which must have been
produced by running Haddock with the
--dump-interface option. The interface
describes a set of modules whose HTML documentation is
path (which may be a
relative pathname). The
optional, and defaults to “.”.
This option allows Haddock to produce separate sets of
documentation with hyperlinks between them. The
path is used to direct hyperlinks
to point to the right files; so make sure you don't move the
HTML files later or these links will break. Using a
path means that a
documentation subtree can still be moved around without
--read-interface options may
--read-interface, but use
ghc-pkg to locate the interface file and
HTML documentation for
to reference when generating the documentation.
--use-package options may
Produce an interface
in the file
file. An interface
file contains information Haddock needs to produce more
documentation that refers to the modules currently being
processed - see the
for more details. The interface file is in a binary format;
don't try to read it.
Use auxiliary files in
Reserved for future use (output documentation in DocBook XML format).
Generate documentation in HTML format. Several files
will be generated into the current directory (or the
specified directory if the
-o option is
given), including the following:
The top level page of the documentation: lists the modules available, using indentation to represent the hierarchy if the modules are hierarchical.
The stylesheet used by the generated HTML. Feel
free to modify this to change the colors or
layout, or even specify your own stylesheet using the
An HTML page for each
The index, split into two (functions/constructors and types/classes, as per Haskell namespaces) and further split alphabetically.
(In HTML mode only) Produce extra contents and index files for given HTML Help system. Currently supported Help systems are Microsoft HTML Help 1.3 and 2.0 and GNOME DevHelp.
Using the Microsoft HTML Help system provides two advantages over plain HTML: the help viewer gives you a nice hierarchical folding contents pane on the left, and the documentation files are compressed and therefore much smaller (roughly a factor of 10). The disadvantage is that the help can't be viewed over the web.
In order to create a compiled Microsoft help file, you also need the Microsoft HTML Help compiler, which is available free from http://www.microsoft.com/ (search for “HTML Help compiler”).
Distributed with Microsoft Windows
a CHM viewer for UNIX (Linux, *BSD, Solaris), written by Razvan Cojocaru
a comercial 100% native Cocoa .chm file viewer for the Mac OS X platform
a CHM file viewer. It is designed to integrate nicely with Gnome.
The GNOME DevHelp also provides help viewer which looks like MSHelp viewer but the documentation files aren't compressed. The documentation can be viewed with any HTML browser but DevHelp gives you a nice hierarchical folding contents and keyword index panes on the left. The DevHelp expects to see *.devhelp file in the folder where the documentation is placed. The file contains all required information to build the contents and index panes.
Include links to the source files in the generated
URL is the
base URL where the source files can be found.
Specify a stylesheet to use instead of the default one that comes with Haddock. It should specify certain classes: see the default stylesheet for details.
Specify a file containing documentation which is placed on the main contents page under the heading “Description”. The file is parsed as a normal Haddock doc comment (but the comment markers are not required).
title as the page
heading for each page in the documentation.This will
normally be the name of the library being documented.
The title should be a plain string (no markup please!).
Don't automatically import
in every module. Used when producing documentation for the
Produce extra debugging output.
Display help and exit.
Increase verbosity. Currently this will cause Haddock
to emit some extra warnings, in particular about modules
which were imported but it had no information about (this is
often quite normal; for example when there is no information
Output version information and exit.
When generating HTML, do not generate an index.
Instead, redirect the Index link on each page to
URL. This option is intended for
use in conjuction with
generating a separate index covering multiple
Generate an HTML index containing entries pulled from
all the specified interfaces (interfaces are specified using
This is used to generate a single index for multiple sets of
Set the package name for these modules to
P. In a combined index generated
--gen-index, the package name for each
module is shown in the right-hand column.
Causes Haddock to behaves as if every module has the
ignore-exports attribute (Section 3.7, “Module Attributes”). This might be useful for
generating implementation documentation rather than interface
documetnation, for example.
Causes Haddock to behaves as if module
module has the
atribute. (Section 3.7, “Module Attributes”).
Haddock only accepts plain, non-literate, Haskell source.
This means that if you program in Literate Haskell, or you need
to use the C pre-processor in your Haskell source, then you need
to pre-process the files before feeding them to Haddock. This
is easily accomplished using GHC; for example, suppose we have a
Literate Haskell source file
which we also need to run the C pre-processor:
$ ghc -cpp -E -optP-P -D__HADDOCK__ Foo.lhs -o Foo.hs $ haddock -h Foo.hs ...
-E option to GHC says "stop after
-cpp option turns on the C
-optP-P option tells the C
pre-processor not to leave any extra dropping behind (see the
description of the
-P option in the gcc manual
for details), and the
defines the symbol
pre-processing (this is sometimes handy if you need to any
pre-processing conditionals in your source which depend on
whether the source is going to be fed to Haddock).
 Haddock interface files are not the same as Haskell interface files, I just couldn't think of a better name.