Malcolm Wallace wrote:
Simon Peyton-Jones <[EMAIL PROTECTED]> writes:
| 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.
Hmm, but in a haddock comment, the only names that should get hyperlinks
are top-level exported/imported entities. The RdrName stuff can only be
used to resolve qualified names (again all top-level entities) I think.
None of the other scopes matter to Haddock.
That's true. Haddock only really needs the top-level namespace of the
module to resolve names, so it is possible to rename the Haddock comments
later, after typechecking. GHC retains the top level scope of each module
as a GlobalRdrEnv so that it can be used in GHCi.
If later we wanted to extend Haddock comments to include scoping, perhaps
if we were to extend Haddock to be a source-code markup tool, then this
wouldn't work of course.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
