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? Stefan
signature.asc
Description: Digital signature
_______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
