should haddock.ghc be a sub-repo of ghc?
davve at dtek.chalmers.se
Mon Nov 12 22:34:30 EST 2007
> On Tue, Nov 13, 2007 at 12:07:45AM +0000, Neil Mitchell wrote:
>> > 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
> 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
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? :-)
More information about the Cvs-ghc