> On Tue, Nov 13, 2007 at 12:07:45AM +0000, Neil Mitchell wrote: >> Hi >> >> > the point is that haddock.ghc is using the ghc api, which is >> > (a) an internal api, or at least an api to ghc's internals and >> > (b) still under rapid development. >> >> It's an exported, stable, documented and supported API - or at least I >> believe that is the eventual intention. >> >> > one could think of a special list of ghc-api based, but >> > not-ghc-core tools, like haddock.ghc, ghctags, .., with >> > their own buildbots triggered after every day of ghc >> > updates, but since those tools are intended to be used >> > on ghc's sources, that would be complicated. >> >> I have GHC API based tools, which do various things. I don't think any >> of them should be integrated into the GHC build tree, or even hosted >> on darcs.haskell.org. If we don't make a clear separation between GHC >> and the users of the GHC API, then we don't really have an API. >> >> Hopefully, in time, the pain associated with using the GHC API will >> reduce. > > It's not just a ghc-dependant haddock, it's a haddock-dependant GHC. > GHC knows about haddock comments, parses them, and stores them in the > syntax tree like any other language feature. Which is especially > troubling for me. What's next - GHC being able to parse c2hs > placeholders?
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? :-) David _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
