How are the Haddock module fields Portability, Stability and Maintainer used?

16
votes

In lots of Haddock-generated module documentation (e.g. Prelude), a small box in the top-right can be seen, containing portability, stability and maintainer information:

An example package information box

From looking at the source code to such modules and experimentation, I confirmed that this information is generated from lines like the following in the module description:

-- Maintainer  :  [email protected]
-- Stability   :  stable
-- Portability :  portable

There are several strange things about this:

  • The fields only seem to work in this order — any fields put out of order are simply treat as part of the module description itself. This is despite the fact that the order in the source file is the opposite of the order in the generated documentation!

  • I have been unable to find any official documentation of these fields. There is a Cabal package property named stability, the example values of which match the values I've seen in the equivalent Haddock fields, but beyond that, I've found nothing.

So: How are these fields intended to be used, and are they documented anywhere?

In particular, I'd like to know:

  • The full list of commonly-used values for Portability and Stability. This HaskellWiki page has a list, but I'd like to know where this list originated from.

  • The criteria for deciding whether a module is portable or non-portable. In particular, the package I would like the answers to these questions for, acme-strfry, is an FFI binding to strfry, a function only available in glibc. Is the package non-portable, because it only works on glibc systems, or portable, because it does not use any Haskell language extensions? The common usage seems to imply the latter.

  • Why a specific order of fields is required in the source file, and why it's the opposite of the ordering in the generated documentation.

2
haskellhaddock

2 Answers

4
votes

Oh, I thought those fields were from the cabal package description. They don't seem to be documented at all on Haddock's docs. I've found this, which doesn't really answer your question but:

http://trac.haskell.org/haddock/ticket/71

So if it's freeform anyway, why not just write "non-portable (depends on glibc)"? I've seen even "portable (depends on ghc)", which is odd. I also wonder what happens with modules that were non-portable due to non-Haskell98 extension Foo, after Foo was added to Haskell 2010.

Note that the Cabal documenation you link to also says stability is freeform. Of course, even if haddock or cabal were to define what are the acceptable values, it'd still be up to the maintainer to subjectively select one.

About the specific order, you should probably just ask at the haddock mailing list, or check the source and file a bug.

PS: strfry is an invaluable contribution to the Haskell community, but it should be pure and portable, don't you think?

3
votes

Ah yes, one of the more obscure and crufty features of Haddock.

As best as I can tell, it's just an undocumented hack. There's no sane reason why the order of the fields should matter, but it does. The specific choice of formatting (i.e., as a special form inside the module comment rather than as a separate block of some kind) isn't the best either. My guess is that somebody wanted to quickly add this feature one day, so they hacked up something minimal but functioning, and left it at that. (Without bothering to document it.)

Personally, I just don't bother with these fields at all. The information is available from Cabal, so I don't bother duplicating it in Haddock as well. Perhaps some day Cabal will pass this information to Haddock automatically...