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

[David Waern]

Simon wrote:

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

Say you are working on GHC in a fancy IDE. Everytime you save a source
file, it is reloaded in the background. It is also re-Haddocked, so that
the documentation for that module and tool-tip information in the editor
is automatically updated. Now, you don't want this background process to
take an entire minute, if you've just changed one file. So, should Haddock
then implement a system that determines which files need to be
re-Haddocked, and thus, type checked?

With the GHC-API that would probably be easy. But it seems a little
backwards, especially if we generalize this to any other tool that use the
GHC API. Should each tool include the GHC --make mechanism? We soon have a
shiny new Cabal make system, where tools that depend on .hi files would
fit in very naturally.

Of course, tools that needs to cache information that they have computed
from the .hi files could do so and install their own files. I'm not saying
Haddock shouldn't keep it's interface files, for instance.

David