should haddock.ghc be a sub-repo of ghc?
simonpj at microsoft.com
Wed Nov 14 03:06:35 EST 2007
| So in this hypothetical system, haddock uses the GHC API to get at the
| comments in the AST, it somehow figures out which comments are in
| locations that are legal for haddock markup, parses them. It extracts
| the names from the markup and using the GHC API again (stuff from the
| renamer) tries to resolve them to original definitions.
That'd be quite tricky, because different names are in scope in different places. E.g. 'a' means two different things in (f a (\a.a)). I'd forgotten about Names in Haddock comments -- they make a good reason not to treat Haddock comments as opaque strings.
| I'm not sure it makes sense to be resolving names during the early
| renaming phase anyway since haddock markup often refers to names which
| are not imported directly. It might make better sense to keep RdrNames
| and resolve them much later with access to all the exported names in a
| package, not merely the subset imported in the current module.
Hmm. But 'a' might mean zillions of things if several packages expose a module that exports 'a'. The point about the imports is precisely that they establish a name space. Its seems quite reasonable that Haddock comments see the same name space as the rest of the module.
More information about the Cvs-ghc