Stefan O'Rear wrote:
On Tue, Nov 13, 2007 at 04:34:30AM +0100, David Waern wrote:
You are right, it's not the most modular solution. Nevertheless, we now
have the ability to generate documentation from all kinds of GHC-specific
source code - pretty cool.
Out of curiosity: Do you have a better solution for Haddock, if the
requirement is to be able to understand GHC-specific code? Perhaps one
could avoid having to modify the parser, and instead try to match
Haddock-comments/declarations by their SrcLocs.
Or perhaps your ideal solution would be something not involving GHC? :-)
No, I don't have a better idea. I just have a bad feeling about the
current approach...
Believe me, we're aware that it's not ideal.
Perhaps a better solution would be to represent the documentation by
Dynamics in GHC's abstract syntax, and to pass in the functions that parse
and rename the documentation annotations, perhaps in the DynFlags. That
would let us extract the code that parses and renames Haddock comments from
GHC, at the expense of a slightly clunky interface (Dynamics). David, does
that sound at all plausible, or am I missing some obvious reason why this
couldn't work?
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
