>> 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.
To clarify the above a bit: The point of storing the comments in the .hi files is to avoid having to use the GHC API to load and typecheck the modules separately. So we could do a normal compilation of the modules one by one, as in Cabal's build step, followed by a Haddock step that simply gathers the information from the .hi files. Now, I just realized something: this wouldn't work with Simon's idea of passing in a function that parses and renames Haddock comments to GHC. Since to do that, we need to use the GHC API directly. David _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
