> 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 >
Good idea. Sounds like it would work to me. We should also move the Haddock comments to the .hi files, which Duncan likes to point out. For those that didn't know: Haddock currently needs to itself invoke GHC's type checking on a module to get the comments. Getting them from the .hi files would be much more compositional. David _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
