A Haskell Documentation Standard
Simon Marlow
simonmar@microsoft.com
Mon, 29 Jan 2001 05:06:39 -0800
Hi All,
Henrik - thanks for your comprehensive message! I've set up the mailing
list on haskell.org (haskelldoc@haskell.org; go to
http://www.haskell.org/mailman/listinfo/haskelldoc). Let's communicate
on there from now on.
My thoughts on the matter appear to differ slightly from yours and
Jan's, so I'll try to express my own priorities for a documentation
system.
- we're all agreed that what is needed is an automatic
documentation-generation tool that takes annotated Haskell
and delivers documentation. It's important that we don't
tie ourselves to one particular documentation format, so
I believe we need a separately-specified format for the
in-source documentation. This is one target for attack.
- a big win is that even without any annotations, you get
documentation for free (i.e. hyperlinked type signatures
for exported functions, class definitions, etc.). Just having
this working would make we very happy :)
- here's where we differ: instead of defining a new interface
format and writing code to generate/parse the new format, I
propose we define the format to be the same as Haskell source.
Why?
- we already have a pretty printer/parser for Haskell
source.
- we can start generating documentation from existing
source straight away, without waiting for support from
the compiler writers (who are generally a lazy bunch :-)
It is true that by eliminating the compiler from the
documentation path we lose the benefit of automatically derived
types. However, the compiler often infers ugly types anyway
(type synonyms may be expanded), and it's always good practice
to give type signatures to every exported function. I bet there
are very few functions in GHC's libraries that are exported
without a type signature.
Of course, I'm thinking more about "external" than "internal"
documentation. But even for internal documentation, I don't
think it would be a big loss not to get types if they weren't
explicitly mentioned in the source.
And there's an upgrade path: if we define the "interface-file"
format to be exactly the same as the syntax of a Haskell module
(perhaps with code optinoal), then the compiler can always just
read a source file and output the same file with types filled in.
I see the priorities as (a) getting the format for the documentation
annotations specified, and (b) extending HDoc to do the business (and to
add GHC extensions :).
Cheers,
Simon