Skip to content
Snippets Groups Projects
Forked from Glasgow Haskell Compiler / haddock
1071 commits behind the upstream repository.
Nathan Collins's avatar
Nathan Collins authored
* Improve documentation of Haddock markup.

- document that Haddock supports inferring types top-level functions
  with without type signatures, but also explain why using this
  feature is discouraged. Looks like this feature has been around
  since version 2.0.0.0 in 2008!

- rework the "Module description" section:

  - move the general discussion of field formatting to the section
    intro and add examples illustrating the prose for multiline
    fields.

  - mention that newlines are preserved in some multiline fields, but
    not in others (I also noticed that commas in the `Copyright` field
    are not preserved; I'll look into this bug later).

  - add a subsection for the module description fields documentation,
    and put the field keywords in code formatting (double back ticks)
    instead of double quotes, to be consistent with the typesetting of
    keywords in other parts of the documentation.

  - mention that "Named chunks" are not supported in the long-form
    "Module description" documentation.

- fix formatting of keywords in the "Module attributes"
  section. Perhaps these errors were left over from an automatic
  translation to ReST from some other format as part of the transition
  to using Sphinx for Haddock documentation? Also, add a missing
  reference here; it just said "See ?"!

- update footnote about special treatment for re-exporting partially
  imported modules not being implemented. In my tests it's not
  implemented at all -- I tried re-exporting both `import B
  hiding (f)` and `import B (a, b)` style partial imports, and in both
  cases got the same result as with full imports `import B`: I only
  get a module reference.

* Rework the `Controlling the documentation structure` section.

My main goal was to better explain how to use Haddock without an
export list, since that's my most common use case, but I hope I
improved the section overall:

- remove the incomplete `Omitting the export list` section and fold it
  into the other sections. In particular, summarize the differences
  between using and not using an export list -- i.e. control over what
  and in what order is documented -- in the section lead.

- add "realistic" examples that use the structure markup, both with
  and without an export list. I wanted a realistic example here to
  capture how it can be useful to explain the relationship between a
  group of functions in a section, in addition to documenting their
  individual APIs.

- make it clear that you can associate documentation chunks with
  documentation sections when you aren't using an export list, and
  that doing it in the most obvious way -- i.e. with `-- |`, as you
  can in the export list -- doesn't work without an export list. It
  took me a while to figure this out the first time, since the docs
  didn't explain it at all before.

- add a "no export list" example to the section header section.

- add more cross references.

* Add examples of gotchas for markup in `@...@`.

I'm not sure this will help anyone, since I think most people first
learn about `@...@` by reading other people's Haddocks, but I've
documented the mistakes which I've made and then gotten confused by.

* Use consistent Capitalization of Titles.

Some titles were in usual title caps, and others only had the first
word capitalized. I chose making them all use title caps because that
seems to make the cross references look better.
8a9a0941
History

Haddock, a Haskell Documentation Tool Build Status

About haddock

This is Haddock, a tool for automatically generating documentation from annotated Haskell source code. It is primary intended for documenting library interfaces, but it should be useful for any kind of Haskell code.

Haddock lets you write documentation annotations next to the definitions of functions and types in the source code, in a syntax that is easy on the eye when writing the source code (no heavyweight mark-up). The documentation generated by Haddock is fully hyperlinked

  • click on a type name in a type signature to go straight to the definition, and documentation, for that type.

Haddock understands Haskell's module system, so you can structure your code however you like without worrying that internal structure will be exposed in the generated documentation. For example, it is common to implement a library in several modules, but define the external API by having a single module which re-exports parts of these implementation modules. Using Haddock, you can still write documentation annotations next to the actual definitions of the functions and types in the library, but the documentation annotations from the implementation will be propagated to the external API when the documentation is generated. Abstract types and classes are handled correctly. In fact, even without any documentation annotations, Haddock can generate useful documentation from your source code.

Documentation formats

Haddock can generate documentation in multiple formats; currently HTML is implemented, and there is partial support for generating LaTeX and Hoogle.

Source code documentation

Full documentation can be found in the doc/ subdirectory, in DocBook format.

Contributing

Please create issues when you have any problems and pull requests if you have some code.

Hacking

To get started you'll need a latest GHC release installed.

Clone the repository:

  git clone https://github.com/haskell/haddock.git
  cd haddock

and then proceed using your favourite build tool.

Using Cabal sandboxes
cabal sandbox init
cabal sandbox add-source haddock-library
cabal sandbox add-source haddock-api
cabal sandbox add-source haddock-test
# adjust -j to the number of cores you want to use
cabal install -j4 --dependencies-only --enable-tests
cabal configure --enable-tests
cabal build -j4
# run the test suite
export HADDOCK_PATH="dist/build/haddock/haddock"
cabal test
Using Stack
stack init
stack install
# run the test suite
export HADDOCK_PATH="$HOME/.local/bin/haddock"
stack test

If you're a GHC developer and want to update Haddock to work with your changes, you should be working on ghc-head branch instead of master. See instructions at https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules for an example workflow.