Improve documenation of Haddock markup (#614)

* 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.

1 files changed, 357 insertions, 93 deletions

diff --git a/doc/markup.rst b/doc/markup.rst
index b0ebc738..d0b9392d 100644
--- a/doc/markup.rst
+++ b/doc/markup.rst
@@ -8,7 +8,7 @@ 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
+Documenting a Top-Level Declaration
 -----------------------------------
 
 The simplest example of a documentation annotation is for documenting
@@ -35,6 +35,8 @@ the following:
 
 -  A type signature for a top-level function,
 
+-  A definition for a top-level function with no type signature,
+
 -  A ``data`` declaration,
 
 -  A ``newtype`` declaration,
@@ -57,9 +59,12 @@ this is possible in Haddock too: ::
     -- ^The 'square' 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.
+Since Haddock uses the GHC API internally, it can infer types for
+top-level functions without type signatures. However, you're
+encouraged to add explicit type signatures for all top-level
+functions, to make your source code more readable for your users, and
+at times to avoid GHC inferring overly general type signatures that
+are less helpful to your users.
 
 Documentation annotations may span several lines; the annotation
 continues until the first non-comment line in the source file. For
@@ -81,13 +86,13 @@ comments: ::
     square :: Int -> Int
     square x = x * x
 
-Documenting parts of a declaration
+Documenting Parts of a Declaration
 ----------------------------------
 
 In addition to documenting the whole declaration, in some cases we can
 also document individual parts of the declaration.
 
-Class methods
+Class Methods
 ~~~~~~~~~~~~~
 
 Class methods are documented in the same way as top level type
@@ -99,7 +104,7 @@ signatures, by using either the ``-- |`` or ``-- ^`` annotations: ::
        -- | This is the documentation for the 'g' method
        g :: Int -> a
 
-Constructors and record fields
+Constructors and Record Fields
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Constructors are documented like so: ::
@@ -150,7 +155,7 @@ would join up documentation of each field and render the result. The
 reason for this seemingly weird behaviour is the fact that ``someField``
 is actually the same (partial) function.
 
-Function arguments
+Function Arguments
 ~~~~~~~~~~~~~~~~~~
 
 Individual arguments to a function may be documented like this: ::
@@ -159,7 +164,9 @@ Individual arguments to a function may be documented like this: ::
        -> Float    -- ^ The 'Float' argument
        -> IO ()    -- ^ The return value
 
-The module description
+.. _module-description:
+
+The Module Description
 ----------------------
 
 A module itself may be documented with multiple fields that can then be
@@ -183,50 +190,100 @@ module documentation example and then talk about the fields. ::
     module W where
     ...
 
-The “Module” field should be clear. It currently doesn't affect the
-output of any of the backends but you might want to include it for human
-information or for any other tools that might be parsing these comments
+All fields are optional but they must be in order if they do appear.
+Multi-line fields are accepted but the consecutive lines have to start
+indented more than their label. If your label is indented one space as
+is often the case with the ``--`` syntax, the consecutive lines have
+to start at two spaces at the very least. For example, above we saw a
+multiline ``Copyright`` field: ::
+
+    {-|
+    ...
+    Copyright   : (c) Some Guy, 2013
+                      Someone Else, 2014
+    ...
+    -}
+
+That could equivalently be written as ::
+
+    -- | ...
+    -- Copyright:
+    --  (c) Some Guy, 2013
+    --  Someone Else, 2014
+    -- ...
+
+or as ::
+
+    -- | ...
+    -- Copyright: (c) Some Guy, 2013
+    --     Someone Else, 2014
+    -- ...
+
+but not as ::
+
+    -- | ...
+    -- Copyright: (c) Some Guy, 2013
+    -- Someone Else, 2014
+    -- ...
+
+since the ``Someone`` needs to be indented more than the
+``Copyright``.
+
+Whether new lines and other formatting in multiline fields is
+preserved depends on the field type. For example, new lines in the
+``Copyright`` field are preserved, but new lines in the
+``Description`` field are not; leading whitespace is not preserved in
+either [#backend]_. Please note that we do not enforce the format for
+any of the fields and the established formats are just a convention.
+
+.. [#backend] Technically, whitespace and newlines in the
+   ``Description`` field are preserved verbatim by the HTML backend,
+   but because most browsers collapse whitespace in HTML, they don't
+   render as such. But other backends may render this whitespace.
+
+Fields of the Module Description
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The ``Module`` field specifies the current module name. Since the module
+name can be inferred automatically from the source file, it doesn't
+affect the output of any of the backends. But you might want to
+include it for any other tools that might be parsing these comments
 without the help of GHC.
 
-The “Description” field accepts some short text which outlines the
+The ``Description`` field accepts some short text which outlines the
 general purpose of the module. If you're generating HTML, it will show
 up next to the module link in the module index.
 
-The “Copyright”, “License”, “Maintainer” and “Stability” fields should
-be obvious. An alternative spelling for the “License” field is accepted
-as “Licence” but the output will always prefer “License”.
+The ``Copyright``, ``License``, ``Maintainer`` and ``Stability`` fields should
+be obvious. An alternative spelling for the ``License`` field is accepted
+as ``Licence`` but the output will always prefer ``License``.
 
-The “Portability” field has seen varied use by different library
+The ``Portability`` field has seen varied use by different library
 authors. Some people put down things like operating system constraints
 there while others put down which GHC extensions are used in the module.
-Note that you might want to consider using the “show-extensions” module
-flag for the latter.
+Note that you might want to consider using the ``show-extensions`` module
+flag for the latter (see :ref:`module-attrs`).
 
-Finally, a module may contain a documentation comment before the module
-header, in which case this comment is interpreted by Haddock as an
-overall description of the module itself, and placed in a section
-entitled “Description” in the documentation for the module. All usual
-Haddock markup is valid in this comment.
+Finally, a module may contain a documentation comment before the
+module header, in which case this comment is interpreted by Haddock as
+an overall description of the module itself, and placed in a section
+entitled ``Description`` in the documentation for the module. All the
+usual Haddock :ref:`markup` is valid in this comment.
 
-All fields are optional but they must be in order if they do appear.
-Multi-line fields are accepted but the consecutive lines have to start
-indented more than their label. If your label is indented one space as
-is often the case with “--” syntax, the consecutive lines have to start
-at two spaces at the very least. Please note that we do not enforce the
-format for any of the fields and the established formats are just a
-convention.
-
-Controlling the documentation structure
+Controlling the Documentation Structure
 ---------------------------------------
 
 Haddock produces interface documentation that lists only the entities
-actually exported by the module. The documentation for a module will
+actually exported by the module. If there is no export list then all
+entities defined by the module are exported.
+
+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
+re-exported from 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
+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
@@ -237,9 +294,154 @@ is often used as a kind of ad-hoc interface documentation, with
 headings, groups of functions, type signatures and declarations in
 comments.
 
+In the next section we give examples illustrating most of the
+structural markup features. After the examples we go into more detail
+explaining the related markup, namely :ref:`section-headings`,
+:ref:`named-chunks`, and :ref:`re-exporting-entire-module`.
+
+.. _structure-examples:
+
+Documentation Structure Examples
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We now give several examples that produce similar results and
+illustrate most of the structural markup features. The first two
+example use an export list, but the third example does not.
+
+The first example, using an export list with :ref:`section-headings`
+and inline section descriptions: ::
+
+    module Image
+      ( -- * Image importers
+        --
+        -- | There is a "smart" importer, 'readImage', that determines
+        -- the image format from the file extension, and several
+        -- "dumb" format-specific importers that decode the file at
+        -- the specified type.
+        readImage
+      , readPngImage
+      , readGifImage
+      , ...
+        -- * Image exporters
+        -- ...
+      ) where
+
+    import Image.Types ( Image )
+
+    -- | Read an image, guessing the format from the file name.
+    readImage :: FilePath -> IO Image
+    readImage = ...
+
+    -- | Read a GIF.
+    readGifImage :: FilePath -> IO Image
+    readGifImage = ...
+
+    -- | Read a PNG.
+    readPngImage :: FilePath -> IO Image
+    readPngImage = ...
+
+    ...
+
+Note that the order of the entities ``readPngImage`` and
+``readGifImage`` in the export list is different from the order of the
+actual declarations farther down; the order in the export list is the
+order used in the generated docs. Also, the imported ``Image`` type
+itself is not re-exported, so it will not be included in the rendered
+docs (see :ref:`hyperlinking-re-exported`).
+
+The second example, using an export list with a section description
+defined elsewhere (the ``$imageImporters``; see :ref:`named-chunks`):
+::
+
+    module Image
+      ( -- * Image importers
+        --
+        -- $imageImporters
+        readImage
+      , readPngImage
+      , readGifImage
+      , ...
+        -- * Image exporters
+        -- ...
+      ) where
+
+    import Image.Types ( Image )
+
+    -- $imageImporters
+    --
+    -- There is a "smart" importer, 'readImage', that determines the
+    -- image format from the file extension, and several "dumb"
+    -- format-specific importers that decode the file at the specified
+    -- type.
+
+    -- | Read an image, guessing the format from the file name.
+    readImage :: FilePath -> IO Image
+    readImage = ...
+
+    -- | Read a GIF.
+    readGifImage :: FilePath -> IO Image
+    readGifImage = ...
+
+    -- | Read a PNG.
+    readPngImage :: FilePath -> IO Image
+    readPngImage = ...
+
+    ...
+
+This produces the same rendered docs as the first example, but the
+source code itself is arguably more readable, since the documentation
+for the group of importer functions is closer to their definitions.
+
+The third example, without an export list: ::
+
+    module Image where
+
+    import Image.Types ( Image )
+
+    -- * Image importers
+    --
+    -- $imageImporters
+    --
+    -- There is a "smart" importer, 'readImage', that determines the
+    -- image format from the file extension, and several "dumb"
+    -- format-specific importers that decode the file at the specified
+    -- type.
+
+    -- | Read an image, guessing the format from the file name.
+    readImage :: FilePath -> IO Image
+    readImage = ...
+
+    -- | Read a GIF.
+    readGifImage :: FilePath -> IO Image
+    readGifImage = ...
+
+    -- | Read a PNG.
+    readPngImage :: FilePath -> IO Image
+    readPngImage = ...
+
+    ...
+
+    -- * Image exporters
+    -- ...
+
+Note that the section headers (e.g. ``-- * Image importers``) now
+appear in the module body itself, and that the section documentation
+is still given using :ref:`named-chunks`. Unlike in the first example
+when using an export list, the named chunk syntax ``$imageImporters``
+*must* be used for the section documentation; attempting to use the
+``-- | ...`` syntax to document the image importers here will wrongly
+associate the documentation chunk with the next definition!
+
+.. _section-headings:
+
+Section Headings
+~~~~~~~~~~~~~~~~
+
 You can insert headings and sub-headings in the documentation by
-including annotations at the appropriate point in the export list. For
-example: ::
+including annotations at the appropriate point in the export list, or
+in the module body directly when not using an export list.
+
+For example: ::
 
     module Foo (
       -- * Classes
@@ -276,7 +478,31 @@ line is also supported. e.g.: ::
       , g
       ) where
 
-Re-exporting an entire module
+When not using an export list, you may insert section headers in the
+module body. Such section headers associate with all entities
+declaried up until the next section header. For example: ::
+
+    module Foo where
+
+    -- * Classes
+    class C a where ...
+
+    -- * Types
+    -- ** A data type
+    data T = ...
+
+    -- ** A record
+    data R = ...
+
+    -- * Some functions
+    f :: ...
+    f = ...
+    g :: ...
+    g = ...
+
+.. _re-exporting-entire-module:
+
+Re-Exporting an Entire Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Haskell allows you to re-export the entire contents of a module (or at
@@ -292,8 +518,10 @@ What will the Haddock-generated documentation for this module look like?
 Well, it depends on how the modules ``B`` and ``C`` are imported. If
 they are imported wholly and without any ``hiding`` qualifiers, then the
 documentation will just contain a cross-reference to the documentation
-for ``B`` and ``C``. However, if the modules are not *completely*
-re-exported, for example: ::
+for ``B`` and ``C``.
+
+However, if the modules are not *completely* re-exported, for example:
+::
 
     module A (
       module B,
@@ -304,48 +532,39 @@ re-exported, for example: ::
     import C (a, b)
 
 then Haddock behaves as if the set of entities re-exported from ``B``
-and ``C`` had been listed explicitly in the export list [2]_.
+and ``C`` had been listed explicitly in the export list [#notImplemented]_.
+
+.. Comment: was this ever implemented? Perhaps this part of the docs
+   should just be removed until it is implemented?
 
-.. [2]
-   NOTE: this is not fully implemented at the time of writing (version
-   0.2). At the moment, Haddock always inserts a cross-reference.
+.. [#notImplemented] This is not implemented at the time of writing
+   (Haddock version 2.17.3 with GHC 8.0.2). At the moment, Haddock
+   always inserts a module cross-reference.
 
 The exception to this rule is when the re-exported module is declared
-with the ``hide`` attribute (:ref:`module-attrs`), in which case the module is
+with the ``hide`` attribute (see :ref:`module-attrs`), in which
+case the module is
 never cross-referenced; the contents are always expanded in place in the
 re-exporting module.
 
-Omitting the export list
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-If there is no export list in the module, how does Haddock generate
-documentation? Well, when the export list is omitted, e.g.: ::
-
-    module Foo where
-
-this is equivalent to an export list which mentions every entity defined
-at the top level in this module, and Haddock treats it in the same way.
-Furthermore, the generated documentation will retain the order in which
-entities are defined in the module. In this special case the module body
-may also include section headings (normally they would be ignored by
-Haddock). ::
+.. _named-chunks:
 
-    module Foo where
-
-    -- * This heading will now appear before foo.
-
-    -- | Documentation for 'foo'.
-    foo :: Integer
-    foo = 5
+(Named) Chunks of Documentation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Named chunks of documentation
------------------------------
+It is often desirable to include a chunk of documentation which is not
+attached to any particular Haskell declaration, for example, when
+giving summary documentation for a group of related definitions (see
+:ref:`structure-examples`). In addition to including such documenation
+chunks at the top of the file, as part of the
+:ref:`module-description`, you can also associate them with
+:ref:`section-headings`.
 
-Occasionally it is desirable to include a chunk of documentation which
-is not attached to any particular Haskell declaration. There are two
-ways to do this:
+There are several ways to associate documentation chunks with section
+headings, depending on whether you are using an export list or not:
 
--  The documentation can be included in the export list directly, e.g.: ::
+-  The documentation can be included in the export list directly, by
+   preceding it with a ``-- |``. For example: ::
 
        module Foo (
           -- * A section heading
@@ -354,11 +573,13 @@ ways to do this:
           ...
         ) where
 
+   In this case the chunk is not "named".
+
 -  If the documentation is large and placing it inline in the export
    list might bloat the export list and obscure the structure, then it
    can be given a name and placed out of line in the body of the module.
    This is achieved with a special form of documentation annotation
-   “``-- $``”: ::
+   ``-- $``, which we call a *named chunk*: ::
 
        module Foo (
           -- * A section heading
@@ -371,11 +592,48 @@ ways to do this:
        -- Here is a large chunk of documentation which may be referred to by
        -- the name $doc.
 
-   The documentation chunk is given a name, which is the sequence of
-   alphanumeric characters directly after the “``-- $``”, and it may be
-   referred to by the same name in the export list.
+   The documentation chunk is given a name of your choice (here
+   ``doc``), which is the sequence of alphanumeric characters directly
+   after the ``-- $``, and it may be referred to by the same name in
+   the export list. Note that named chunks must come *after* any
+   imports in the module body.
+
+-  If you aren't using an export list, then your only choice is to use
+   a named chunk with the ``-- $`` syntax. For example: ::
+
+       module Foo where
+
+       -- * A section heading
+       --
+       -- $doc
+       -- Here is a large chunk of documentation which may be referred to by
+       -- the name $doc.
+
+   Just like with entity declariations when not using an export list,
+   named chunks of documentation are associated with the preceding
+   section header here, or with the implicit top-level documentation
+   section if there is no preceding section header.
+
+   **Warning**: the form used in the first bullet above, where the
+   chunk is not named, *does not work* when you aren't using an
+   export list. For example ::
 
-Hyperlinking and re-exported entities
+       module Foo where
+
+       -- * A section heading
+       --
+       -- | Some documentation not attached to a particular Haskell entity
+
+       -- | The fooifier.
+       foo :: ...
+
+   will result in ``Some documentation not ...`` being attached to
+   *next* entity declaration, here ``foo``, in addition to any other
+   documentation that next entity already has!
+
+.. _hyperlinking-re-exported:
+
+Hyperlinking and Re-Exported Entities
 -------------------------------------
 
 When Haddock renders a type in the generated documentation, it
@@ -455,26 +713,27 @@ The options and module description can be in either order.
 
 The following attributes are currently understood by Haddock:
 
-``hide`` ``hide``
+``hide``
     Omit this module from the generated documentation, but nevertheless
     propagate definitions and documentation from within this module to
     modules that re-export those definitions.
 
-``hide`` ``prune``
+``prune``
     Omit definitions that have no documentation annotations from the
     generated documentation.
 
-``ignore-exports`` ``ignore-exports``
+``ignore-exports``
     Ignore the export list. Generate documentation as if the module had
     no export list - i.e. all the top-level declarations are exported,
     and section headings may be given in the body of the module.
 
-``not-home`` ``not-home``
+``not-home``
     Indicates that the current module should not be considered to be the
     home module for each entity it exports, unless that entity is not
-    exported from any other module. See ? for more details.
+    exported from any other module. See :ref:`hyperlinking-re-exported`
+    for more details.
 
-``show-extensions`` ``show-extensions``
+``show-extensions``
     Indicates that we should render the extensions used in this module
     in the resulting documentation. This will only render if the output
     format supports it. If Language is set, it will be shown as well and
@@ -482,6 +741,8 @@ The following attributes are currently understood by Haddock:
     be rendered, including those implied by their more powerful
     versions.
 
+.. _markup:
+
 Markup
 ------
 
@@ -497,7 +758,7 @@ Paragraphs
 One or more blank lines separates two paragraphs in a documentation
 comment.
 
-Special characters
+Special Characters
 ~~~~~~~~~~~~~~~~~~
 
 The following characters have special meanings in documentation
@@ -514,7 +775,7 @@ Furthermore, the character sequence ``>>>`` has a special meaning at the
 beginning of a line. To escape it, just prefix the characters in the
 sequence with a backslash.
 
-Character references
+Character References
 ~~~~~~~~~~~~~~~~~~~~
 
 Although Haskell source files may contain any character from the Unicode
@@ -546,7 +807,9 @@ call these “bird tracks”). For example: ::
 There is an important difference between the two forms of code block: in
 the bird-track form, the text to the right of the ‘\ ``>``\ ’ is
 interpreted literally, whereas the ``@...@`` form interprets markup as
-normal inside the code block.
+normal inside the code block. In particular, ``/`` is markup for italics,
+and so e.g. ``@x / y / z@`` renders as ``x`` followed by italic
+``y`` with no slashes, followed by ``z``.
 
 Examples
 ~~~~~~~~
@@ -621,7 +884,7 @@ markup is accepted [3]_: ```T'``.
    because strictly speaking the ````` character should not be used as a
    left quote, it is a grave accent.
 
-Emphasis, Bold and Monospaced text
+Emphasis, Bold and Monospaced Text
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Emphasis may be added by surrounding text with ``/.../``. Other markup
@@ -637,9 +900,10 @@ underscore if you need it bold:
 Monospaced (or typewriter) text is indicated by surrounding it with
 ``@...@``. Other markup is valid inside a monospaced span: for example
 ``@'f' a b@`` will hyperlink the identifier ``f`` inside the code
-fragment.
+fragment, but ``@__FILE__@`` will render ``FILE`` in bold with no 
+underscores, which may not be what you had in mind.
 
-Linking to modules
+Linking to Modules
 ~~~~~~~~~~~~~~~~~~
 
 Linking to a module is done by surrounding the module name with double
@@ -652,7 +916,7 @@ is valid before turning it into a link but unlike with identifiers,
 whether the module is in scope isn't checked and will always be turned
 into a link.
 
-Itemized and Enumerated lists
+Itemized and Enumerated Lists
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 A bulleted item is represented by preceding a paragraph with either
@@ -732,7 +996,7 @@ which was unexpected. ::
         * bar
     -}
 
-Definition lists
+Definition Lists
 ~~~~~~~~~~~~~~~~
 
 Definition lists are written as follows: ::
@@ -833,7 +1097,7 @@ and will be removed in the future.
 Headings
 ~~~~~~~~
 
-Headings inside of comment documentation are possible be preceding them
+Headings inside of comment documentation are possible by preceding them
 with a number of ``=``\ s. From 1 to 6 are accepted. Extra ``=``\ s will
 be treated as belonging to the text of the heading. Note that it's up to
 the output format to decide how to render the different levels. ::