should haddock.ghc be a sub-repo of ghc?
davve at dtek.chalmers.se
Mon Nov 12 20:14:19 EST 2007
>> the point is that haddock.ghc is using the ghc api, which is
>> (a) an internal api, or at least an api to ghc's internals and
>> (b) still under rapid development.
> It's an exported, stable, documented and supported API - or at least I
> believe that is the eventual intention.
The point here I think, is that we should develop against the *released*
version of the GHC API, and then update our code whenever there's a new
version. Currently, that only seems to happen once per year. So coping
with that is acceptable, IMHO.
I admit that there's a trade-off here. If changes were followed
immediately into other projects, that might lead to better, more
thought-through and immediate integration of features. But I think we
should do integration later, to avoid bottlenecks in the development of
I would certainly *like* it if those who implement new GHC syntax would
propagate those changes into Haddock though. That way, they would also get
to decide how new syntax should be rendered in the documentation.
More information about the Cvs-ghc