From 36e3f9136005532bb781a2a148b34ee52f21b561 Mon Sep 17 00:00:00 2001 From: simonmar Date: Thu, 25 Apr 2002 16:48:36 +0000 Subject: [haddock @ 2002-04-25 16:48:36 by simonmar] More keyboard bashing --- doc/haddock.sgml | 350 +++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 340 insertions(+), 10 deletions(-) (limited to 'doc/haddock.sgml') diff --git a/doc/haddock.sgml b/doc/haddock.sgml index a305a2be..d00fbf7b 100644 --- a/doc/haddock.sgml +++ b/doc/haddock.sgml @@ -52,9 +52,10 @@ Documentation annotations in the source code should be easy on the eye when editing the source code itself, so as not to obsure the code and to make reading and writing - documentation annotations easy. Haddock therefore uses - lightweight markup in its annotations, taking several ideas - from IDoc. In fact, Haddock can understand IDoc-annotated source code. @@ -72,10 +73,11 @@ modules. Haddock therefore understands the Haskell module system - and can generate documentation which hides the internal module - structure of the interface. A documentation annotation can - still be placed next to the implementation, and it will be - propagated to the external module in the generated + and can generate documentation which hides not only + non-exported entities from the interface, but also the + internal module structure of the interface. A documentation + annotation can still be placed next to the implementation, and + it will be propagated to the external module in the generated documentation. @@ -161,12 +163,340 @@ Invoking Haddock - + Haddock is invoked from the command line, like so: + + + haddock + option + file + + + Where each file is a filename + containing a Haskell source module. 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: + + + + + + + + + Output documentation in SGML DocBook format. NOTE: at + time of writing this is only partially implemented and + doens't work. + + + + + + + + + + Generate documentation in HTML format. Several files + will be generated into the current directory (or the + specified directory if the option is + given), including the following: + + + index.html + + The top level page of the documentation: lists + the modules available, using indentation to represent + the hierarchy if the modules are hierarchical. + + + + haddock.css + + 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 + option. + + + + module.html + + An HTML page for each + module. + + + + doc-index.html + doc-index-XX.html + + The index, split into two + (functions/constructors and types/classes, as per + Haskell namespaces) and further split + alphabetically. + + + + + + + + dir + =dir + + + + Generate files into dir + instead of the current directory. + + + + + URL + =URL + + + + Include links to the source files in the generated + documentation, where URL is the + base URL where the source files can be found. + + + + + title + =title + + + + Use 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!). + + + + + + + + + + Reserved for future expansion. + + + + + =filename + + + 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. + + + + Documentation and Markup - - + Haddock understands special documentation annotations in the + Haskell source file and propagates these into the generated + documentation. The annotations are purely optional: if there are + no annotations, Haddock will just generate documentation that + contains the type signatures, data type declarations, and class + declarations exported by each of the modules being + processed. + +
+ Documenting a top-level declaration + + The simplest example of a documentation annotation is for + documenting any top-level declaration (function type signature, + type declaration, or class declaration). For example, if the + source file contains the following type signature: + + +square :: Int -> Int +square x = x * x + + + Then we can document it like this: + + +-- |The 'sqaure' function squares an integer. +square :: Int -> Int +square x = x * x + + + The -- | syntax begins a + documentation annotation, which applies to the + following declaration in the source file. + Note that the annotation is just a comment in Haskell — it + will be ignored by the Haskell compiler. + + The declaration following a documentation annotation + should be one of the following: + + + A type signature for a top-level function, + + + A data declaration, + + + A newtype declaration, + + + A type declaration, or + + + A class declaration. + + + + If the annotation is followed by a different kind of + declaration, it will probably be ignored by Haddock. + + Some people like to write their documentation + after the declaration; this is possible in + Haddock too: + + +square :: Int -> Int +-- ^The 'sqaure' function squares an integer. +square x = x * x + + + Note that Haddock doesn't contain a Haskell type system + — if you don't write the type signature for a function, + then Haddock can't tell what its type is and it won't be + included in the documentation. + +
+ Controlling the documentation structure + + Haddock produces interface documentation that lists only + the entities actually exported by the module. The + documentation for a module will include + all entities exported by that module, + even if they were re-exported by another module. The only + exception is when Haddock can't see the declaration for the + re-exported entity, perhaps because it isn't part of the batch + of modules currently being processed. + + However, to Haddock the export list has even more + significance than just specifying the entities to be included + in the documentation. It also specifies the + order that entities will be listed in the + generated documentation. This leaves the programmer free to + implement functions in any order he/she pleases, and indeed in + any module he/she pleases, but still + specify the order that the functions should be documented in + the export list. Indeed, many programmers already do this: + the export list is often used as a kind of ad-hoc interface + documentation, with headings, groups of functions, type + signatures and declarations in comments. + + You can insert headings and sub-headings in the + documentation by including annotations at the appropriate + point in the export list. For example: + + +module Foo ( + -- * Classes + C(..), + -- * Types + -- ** A data type + T, + -- ** A record + R, + -- * Some functions + f, g + ) where + + + Headings are introduced with the syntax + + -- *, + -- ** + + and so on, where the number of *s indicates + the level of the heading (section, sub-section, + sub-sub-section, etc.). + + If you use section headings, then Haddock will generate + a table of contents at the top of the module documentation for + you. + +
+ Re-exporting an entire module + + Haskell allows you to re-export the entire contents of + a module (or at least, everything currently in scope that + was imported from a given module) by listing it in the + export list: + + +module Foo ( + module Bar, + module Baz + ) where + + + What will the Haddock-generated documentation for this + module look like? Well, Haddock simply behaves as if the + export list for modules Bar and + Baz had been expanded in-place in the + export list for Foo, including all of + their structure (section headings etc.). +
+ +
+ More about re-exported entities + + How hyperlinks are re-targetted when an entity is + re-exported. + +
+
+ +
+ +
+ The module description + +
+ +
+ Named chunks of documentation + +
+ +
+ Markup + + links to identifiers + links to modules + itemized lists + enumerated lists + emphasis + code blocks + URLs +
+ -- cgit v1.2.3