Can the Haddock library expose more (then just reading interface files)?

I've ported part of the Leksah metadata collection to use Haddock. But, now it comes, I have not created another backend, but would like to use Haddock as a library and call "createInterface" directly. So I need to change the exposed-modules section of haddock.cabal file to include: "Haddock.Types Haddock.Interface Haddock.Options" Would that be an acceptable patch for the general release, or do you feel it to be too unhygienic or something? The decision came because: 1. Leksah needs to write a binary format, so that the backend would have introduced new dependencies. (binary, binary-shared) 2. Leksah collects information from a variety of sources dynamically and needs a more flexible approach: - .hi files(installed packages without sources), - haddock (packages with sources that compiles) - parsing sources (projects you work on, which may for now not typecheck or compile). This can be better and more efficiently be implemented with a library approach. Jürgen -- View this message in context: http://old.nabble.com/Can-the-Haddock-library-expose-more-%28then-just-readi... Sent from the Haskell - Libraries mailing list archive at Nabble.com.

2009/12/19 jutaro
I've ported part of the Leksah metadata collection to use Haddock. But, now it comes, I have not created another backend, but would like to use Haddock as a library and call "createInterface" directly. So I need to change the exposed-modules section of haddock.cabal file to include: "Haddock.Types Haddock.Interface Haddock.Options" Would that be an acceptable patch for the general release, or do you feel it to be too unhygienic or something?
There has been some discussion about introducing a full-information format that haddock can produce that tools can read. It's not something anyone is working on at the moment, though. So while waiting for something like that, we could try to work something out. Exporting more of Haddock to the outside is a possibility. It would be interesting to know which parts of the Interface structure that you're after. David

Hi David, Leksah calls createInterfaces and uses the returned Interface, which means to analyse the HsDecl structure. Leksah wants to know the type, source position and comment for every exported item. If you can't expose the modules we need, you will find a haddock-leksah package on hackage soon, with the original haddock, and only the cabal file with the added exposed modules. That would be ugly. Jürgen Am Dienstag, den 22.12.2009, 19:13 +0100 schrieb David Waern:
2009/12/19 jutaro
: I've ported part of the Leksah metadata collection to use Haddock. But, now it comes, I have not created another backend, but would like to use Haddock as a library and call "createInterface" directly. So I need to change the exposed-modules section of haddock.cabal file to include: "Haddock.Types Haddock.Interface Haddock.Options" Would that be an acceptable patch for the general release, or do you feel it to be too unhygienic or something?
There has been some discussion about introducing a full-information format that haddock can produce that tools can read. It's not something anyone is working on at the moment, though. So while waiting for something like that, we could try to work something out. Exporting more of Haddock to the outside is a possibility. It would be interesting to know which parts of the Interface structure that you're after.
David

2010/2/2 Jürgen Nicklisch-Franken
Hi David, Leksah calls createInterfaces and uses the returned Interface, which means to analyse the HsDecl structure. Leksah wants to know the type, source position and comment for every exported item. If you can't expose the modules we need, you will find a haddock-leksah package on hackage soon, with the original haddock, and only the cabal file with the added exposed modules. That would be ugly.
I don't see any problems with exposing createInterface and Interface other than it would bring in a lot of additional data types. I'll see if I can expose createInterface in the next major release. I'll probably also rename the current API from Distribution.Haddock to Documentation.Haddock. Don't expect the API to be very stable, however, since it will directly expose internal data structures and functions. David David

Hi David, that would be great. Please drop me a note when you have done the changes, so that I can test if it works. Maybe I still need a haddock-leksah project, to bridge the time, but we can throw it away soon. Regarding the stability of the interface, I've just seen that DocDecl has changed completely with ghc 6.12, (Do you know why?) Jürgen Am Mittwoch, den 03.02.2010, 21:28 +0100 schrieb David Waern:
2010/2/2 Jürgen Nicklisch-Franken
: Hi David, Leksah calls createInterfaces and uses the returned Interface, which means to analyse the HsDecl structure. Leksah wants to know the type, source position and comment for every exported item. If you can't expose the modules we need, you will find a haddock-leksah package on hackage soon, with the original haddock, and only the cabal file with the added exposed modules. That would be ugly.
I don't see any problems with exposing createInterface and Interface other than it would bring in a lot of additional data types. I'll see if I can expose createInterface in the next major release. I'll probably also rename the current API from Distribution.Haddock to Documentation.Haddock. Don't expect the API to be very stable, however, since it will directly expose internal data structures and functions.
David
David

2010/2/5 Jürgen Nicklisch-Franken
Regarding the stability of the interface, I've just seen that DocDecl has changed completely with ghc 6.12, (Do you know why?) Jürgen
Isaac Dupree moved the parser and lexer for the Haddock markup syntax out of GHC during his Summer of Code project. That's why DocDecl now just contains strings. I suggest we move this discussion to the Haddock list since it's getting off-topic for libraries@. David
participants (3)
-
David Waern
-
jutaro
-
Jürgen Nicklisch-Franken