Changelogs and "available since"
Hi All, I was volunteer to solve this problem: http://hackage.haskell.org/trac/summer-of-code/ticket/1565 In a conversation on the libraries@haskell.org I was suggested to scratch my idea here. I would use hoogle for this. Currently it stores the package name and the symbols of the modules about a package. I would extend it to store the version of the package as well. Extend the query methods to use all the available package description at search. And make a VersionRange from the matched Versions. In a second turn I have to solve the problem, how a user can get all the hoogle files about every version of the used packages. (Applied version policy can help to have less files.) #1 Using a central repository, (like hackage) where upload require hoogle input file as well. #2 Implement a tool, top of (or inside) cabal-install, which generates all the needed files. Finally Haddock has to be taught to query hoogle to get availability description for each symbol. Please feel free to suggest other ideas or tell your opinion about mine. Regards, Laszlo
On Mon, Aug 17, 2009 at 6:18 PM, Laszlo Nagy
Hi All,
I was volunteer to solve this problem: http://hackage.haskell.org/trac/summer-of-code/ticket/1565 In a conversation on the libraries@haskell.org I was suggested to scratch my idea here.
I would use hoogle for this. Currently it stores the package name and the symbols of the modules about a package. I would extend it to store the version of the package as well. Extend the query methods to use all the available package description at search. And make a VersionRange from the matched Versions. In a second turn I have to solve the problem, how a user can get all the hoogle files about every version of the used packages. (Applied version policy can help to have less files.) #1 Using a central repository, (like hackage) where upload require hoogle input file as well. #2 Implement a tool, top of (or inside) cabal-install, which generates all the needed files. Finally Haddock has to be taught to query hoogle to get availability description for each symbol.
Please feel free to suggest other ideas or tell your opinion about mine.
How about tackling the problem at a lower level. Given two .hs files (or .hi) files find the symbols that were added between file A and file B. You can the reuse this functionality in a number of different tools. Just my 2 cents, Johan
On 17/08/2009 17:18, Laszlo Nagy wrote:
Hi All,
I was volunteer to solve this problem: http://hackage.haskell.org/trac/summer-of-code/ticket/1565 In a conversation on the libraries@haskell.org I was suggested to scratch my idea here.
I would use hoogle for this. Currently it stores the package name and the symbols of the modules about a package. I would extend it to store the version of the package as well. Extend the query methods to use all the available package description at search. And make a VersionRange from the matched Versions. In a second turn I have to solve the problem, how a user can get all the hoogle files about every version of the used packages. (Applied version policy can help to have less files.) #1 Using a central repository, (like hackage) where upload require hoogle input file as well. #2 Implement a tool, top of (or inside) cabal-install, which generates all the needed files. Finally Haddock has to be taught to query hoogle to get availability description for each symbol.
Please feel free to suggest other ideas or tell your opinion about mine.
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. Cheers, Simon
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
participants (4)
-
Duncan Coutts -
Johan Tibell -
Laszlo Nagy -
Simon Marlow