Haddock 2 and GHC builds (Re: build fails while running haddock in fgl)

[Claus Reinke]

> The problem is that Haddock has to be built with the final GHC
> version, otherwise it can't use the final version's interface files.
> So I was just referring to the method of building GHC without docs,
> then using it to build Haddock and then installing the docs. I was not
> referring to any new method of solving this.
> 
> Well, there are actually other ways of doing it (now that we are on
> this topic again). You could for  example install the boot libs with
> Haddock's GHC (temporarily and in-place during the build of the new
> GHC) and then Haddock could be used to generate the docs without
> having to build it with the new GHC.

I realize now that I still do not understand why, if  a Haddock 0.8
(built with a long-forgotten GHC x) can be used for a GHC HEAD 
build, Haddock 2 cannot be used as a drop-in replacement.

Why does Haddock have to read any interface files other
than those it writes itself? And why would installing the bootlibs
with a different GHC be a requirement for being able to process
the bootlib docs with a Haddock that uses that different GHC?

The motivations for making Haddock a GHC API client were - 
correct me if I'm wrong:

- no separate parser needed, and Haddock will not fail to
    parse anything that GHC can parse
- GHC can do the scoping (and typing?) for Haddock

Neither of these require that Haddock's outputs are in any
way dependent on the GHC it uses, and if GHC HEAD can 
be built with GHC 6.8, then a Haddock using GHC 6.8 should
be able to process the sources.

So, does this mean that Haddock is just not yet as well
decoupled from its host GHC as it should be, or am I missing
something else? Apart from the issues you list above, I recall 
at least two examples that made me wonder about the tight
coupling of GHC and Haddock:

- GHC knows about Haddock comments; I still think that
    shouldn't be, and last time we discussed this, we all went
    away fairly optimistic that it should be possible for GHC
    just to extract comments (has there been any progress on
    this, btw?), and for Haddock to process those comments 
    further, including scoping their names.

- Haddock knows too much about GHC's language, eg,
    it apparently needs to be extended to handle type families.
    Shouldn't there be an API separating Haddock from
    the language details? Aren't all Haddock comments in
    some way attached to names, and aren't comments, 
    locations, names, and kinds of names, all that Haddock 
    needs to know about? 

    For instance, if type family names are -for purposes of 
    Haddock comments- just another type class like kind
    of name, shouldn't they just work, with GHC reporting
    "here's a type class/instance kind of name" and Haddock
    seeing a Haddock comment referring to said name?

    (one might like to use a different presentation style for
    classes and families, but that is a slightly different matter)

Claus