should haddock.ghc be a sub-repo of ghc?

[Simon Peyton-Jones]

| 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.

Simon