On Tue, 2009-08-18 at 08:58 +0100, Simon Marlow wrote:
Using Hoogle sounds like a reasonable approach to get something working quickly; I'm slightly concerned about the added complication of requiring another tool, though. By all means try it out and see how it goes.
Perhaps add 'cabal hoogle' functionality first. Rather than having Haddock query Hoogle, you could preprocess the information from Hoogle first and feed it to Haddock in some format that Haddock can easily digest.
To me, it seems fairly clear that there's some piece of infrastructure missing here, that all of haddock, hoogle, hstags, a PVP-checker and API diff / changelog tool could use. For example, why is it that haddock has a --hoogle flag to generate a file separate from the .haddock file yet containing more or less the same information. This will not scale. The key is to get API (and corresponding docs) out of a Haskell package in a form that is machine readable, reasonably stable and does not require the ghc api package to be able to read. This should enable cabal to be able to generate and install this info once and have it be used by a plethora of tools, rather than cabal calling each service up-font at the time the package is built/installed. The obvious choice, I think, is to make haddock responsible for defining the format and generating the data. Then haddock gets developed along with ghc and serves as the translator from the ever-changing ghc data formats to something more stable that is suitable for these doc and api tools. So haddock would split in two, data extraction and separately html generation. Not that all this helps Laszlo in the short-term. Duncan