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
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
