(Message didn't get through the first time. Reposting.)
Hi
What you suggest sounds like a solution that's easy to learn, useful, and
can be implemented with modest effort. It might be the a good solution
for the problem at hand, documenting the haskell libraries.
However, if one would take this way, one should keep the tool
simplicistic. Or you could end up defining just another ad hoc tag syntax
for just another literate programming system.
I strongly disagree with the idea of incorporating any documentation
generation facility into the language, or the compiler. The compiler's job
is to produce good executables, not documentation. As has been noted, the
GHC team can't "solve all programming problems in the world".
What the compiler, or some other tool that comprehends the Haskell syntax,
could do, is provide a way to read the source code, and output it again,
with some of the structure made explicit by inserting (XML-) tags. This
output could then be used by a documentatin generation tool, such as an
Eiffel-like one.
This way, you could separate the language specific task of making sense of
the code, from the documentation generation system. After all, the general
problem of producing program documentation is not Haskell specific at all.
A word on heavy infrastructure. I mean, the infrastructure is exactly as
heavy as it is for the users to install and use it. There were thoughts of
building complete new text editors and programming environments. Making
some existing text formating system easy to install on a range of
platforms, would require much less effort.
Whatever front end markup method will be adopted, using XML as a target
language, and a XSL-based formatting system for typesetting would probably
still be the solution of choice.
bye
