>> 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
