It would appear to the casual observer that Haddock works fairly excellently cross-packages. For example, I haddocked the Haddock code, and all the links to the types from the GHC API point to the haddock-docs in my GHC 6.10.3 installation. (Yes, you need the versions of the dependent packages chosen, installed and haddocked, and this doesn’t always work out optimally online. But that’s not the problem that I’m confronting.)

Yes, links work. But that’s about it, right now. Compare (broken) http://www.haskell.org/ghc/dist/stable/docs/libraries/haskell98/List.html to (good) http://www.haskell.org/ghc/dist/stable/docs/libraries/base/Data-List.html . The broken one’s source (haskell98:List) imports the good one (base:Data.List). haskell98:List’s documentation luckily lists the *names* of the exported things, because they’re listed in that file’s export list. But not their types or their docs. Not the module doc header (though that shouldn’t be copied anyway), and there’s no link to base:Data.List (which is acceptable. Although maybe someone should write a haddock-header to haskell98:List that says it’s the Haskell 98 version (specified at http://www.haskell.org/onlinereport/list.html ) of the slightly expanded base-package Data.List[link].

Anyway, the way we get any links to modules in other packages is because we read their generated .haddock files. They’re binary and haddock doesn’t have any obvious way to make them human-readable, but they correspond to Haddock.InterfaceFile.InterfaceFile. Which is, roughly, a list of Haddock.Types.InstalledInterface, which seems to be the interesting bit.

data InstalledInterface = InstalledInterface {

instMod :: Module,

instInfo :: HaddockModInfo Name,

instDocMap :: Map Name (HsDoc DocName),

instExports :: [Name],

instVisibleExports :: [Name],

instOptions :: [DocOption],

instSubMap :: Map Name [Name]

}

A Module (not to be confused with GhcModule, which is defined by Haddock) is a low-information type defined in GHC that contains the package name and version and the module name.

HaddockModInfo is just the module’s header description, plus the portability:, stability:, maintainer: fields (HaddockModInfo is defined in GHC, oddly enough: must be parse result. defined in ghc:HsSyn to be precise.)

DocOptions are hide, prune, ignore-exports, not-home. (defined in haddock code.)

The rest contain a lot of “Name”s, which is a GHC thing that refers unambiguously to the place an identifier originates. Sufficient for making a link, but not sufficient by itself for copying the named identifier’s docs or type. So passing over them for now… there is one interesting thing left.

A DocName contains a Name and also (if any) the module we’d like to link to in which that name is documented. instDocMap :: Map Name (HsDoc DocName). This gives more info on any number of Name identifiers. (HsDoc provides formatting, DocName provides its references .) There is no type information here at all, as far as I can tell, which will clearly need to be remedied somehow (in Interface, roughly a superset of InstalledInterface, types appears in ifaceDeclMap, though I’m not sure if that’s where they’re retrieved from for HTML-doc-printing). But there’s another big question I need to find out: *which* names are documented in any given module’s instDocMap? The type provides no clue, nor does its current (lack of a) doc string, nor ifaceRnDocMap. I could look everywhere in the code that it’s generated, or I could ask David Waern… who will need to tell me if I said anything confused here anyway 🙂

Share this: Twitter

Facebook

Like this: Like Loading... Related