2008/7/7 Claus Reinke <[EMAIL PROTECTED]>: >> 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?
Haddock reads two types of interface files: * GHC .hi files These are needed by the GHC API for all packages that the package under processing depends on. Otherwise it can't rename and typecheck the code. We want the code renamed, and in the future it would be nice to have it typechecked so that one doesn't have to write type signatures for functions in order for them to be part of the documentation. * Haddocks's .haddock files These store Haddock specific information for packages. In particular, they store a renaming environment used to point names to the correct place in the documentation for a package. So when processing a package we want one of these files for each package dependency, so that links to these packages goes to the right places. (Documentation links don't always point to the same places as links in the regular renaming environment, even though they often do). So this is why Haddock needs to read interface files, and not just write them. > 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 Yes. > 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. The GHC HEAD compiler itself can be processed with a Haddock version using GHC 6.8, the problem is the boot libraries. The boot libraries depend on each other, and they can change from version 6.8 to HEAD, and if a boot library depends on a change made in another boot library, you can no longer process them with a Haddock version using 6.8 because that change is not in the boot libraries that came with 6.8. So, to do this in a stable manner, you would need to install the new boot libraries for Haddock's GHC. > 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. No progress yet. But we still agree that there is too tight coupling and that it should be reduced, and it is probably possible to do that. > - 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) The presentation style is why Haddock needs to know so much about GHC's language. There are many differences between the pretty printing requirements of GHC and the HTML output we want from Haddock, so the HTML backend can not simply re-use the GHC pretty printer. So Haddock goes through tons of GHC language elements in order to render them in its own way. I don't know whether some kind of generalized pretty printer would be a good idea or not. Then there is a lot of other code in Haddock that needs to know details of GHC's language, but it could probably be reduced by using generics. David _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
