A Haskell Documentation Standard
Jan Skibinski
jans@numeric-quest.com
Tue, 30 Jan 2001 13:03:47 -0500 (EST)
On Tue, 30 Jan 2001, Simon Marlow wrote:
> - 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 :)
Right, but without the comments.
The question of compiler support aside ...
> 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.
Am I missing something here? I thought that the Haskell Report
does not the comments semantics.
They are the free floating entities, and can be put anywhere
as it pleases a module developer. And we can have many possible
types of comments describing: module, datatype, class, function,
etc.
Add to it some important decorations, delimiting some
categories of functions, and we are in a complete mess.
Granted the variety of styles used, how on earth even the
cleverest parser can figure it out? Typical parsers (I am not
talking here about HDoc) do not care because they skip the
comments anyway but it is not the case for the documentation
extractors.
And the scheme: [(E1, C1), (E2, C2) ...] where (Ei,Ci)
are pairs of top level entities and their associated
comments, may work sometimes under the assumption that
Ci always precedes Ei, but this is only the assumption
which I can easily break anytime I wish: I can insert
a category decoration somewhere in between or even reverse
the order from Ci Ei to Ei Ci - what I often do because it
pleases me so.
This is the sad affair, because we could treat the problem
the same way we treat the function signatures. The association
between the function signatures (FSi) and their bodies (FBi)
are not in any way positionally described. Sure, I have not
seen a code whether someone writes:
FS1 FS2 FS3 FB3 FB2 FB1, or FB1 FS1,
but this is still OK - at least in Hugs, which I just checked
to see if I am correct.
There are few solutions possible:
1. Describe precise positional standard for placement
of comments (see Eiffel (*) example)
2. Invent markups to identify comment types and their
associations (see Java. But I am not talking here
about the variable markups, etc. for a moment.)
3. Deliver development tools that force one particular
layout and use its own internal markup system, but
which is never visible to humans, unless they insist.
(See Smalltalk browsers enforcing the style. Eiffel
has it too, but admits old fashion editing, as long
as the result conforms to the standard.)
4. Bite a bullet and admit that comments are as important
as the code; extend Haskell Report to add those specialized
comments to be part of the language
...... etc.
All of those have their problems however.
Jan
P.S.
Because our first few messages are not stored in the
haskelldoc archive I am again showing the pointer to Eiffel
online book. Chapters 1 and 5 talk about documentation
issues.
http://www-staff.socs.uts.edu.au/~rist/eiffel/
There are plenty of Eiffel sites. The oldest is the
ISE site of Bertrand Meyer, the language inventor:
http://www.eiffel.com