David Waern wrote:
| In the meantime we could consider the less invasive change: put
FastString
| in place of HsDoc in HsSyn. No need to pass functions into GHC to do
the
| renaming: Haddock can do it itself since it only needs the top-level
| GlobalRdrEnv which GHC provides. I don't think Haddock needs HsSyn with
| parsed/renamed documentation embeded, since it can keep the
documentation
| in a Name->Doc mapping after it has extracted and processed it. Sound
| reasonable?
That sounds reasonable to me.
S
Me too. But what happens if we in the future get the comments from the .hi
files and don't bother with typechecking? Can we then reconstruct the
GlobalRdrEnv easily? I guess the exported names from each .hi file should
suffice, but I don't know the details of renaming.
I'm thinking that putting the Haddock documentation in the .hi file would
be a regression with respect to modularity, so it's not something we should
pursue. Re-typechecking all the code doesn't take very long (about a
minute for the whole of GHC, IIRC). We should store the Haddock comments
in Haddock's own interface file for the purpose of re-exports across
package boundaries.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
