Moving Haddock *development* out of GHC tree

Mateusz Kowalczyk fuuzetsu at
Thu Aug 14 16:48:39 UTC 2014

On 08/14/2014 01:43 AM, Carter Schonwald wrote:
> one thing I wonder about is how should we approach noting
>  "theres a new language constructor, we should figure out a good way to
> present it in haddock" in this work flow?
> because the initial haddocks presentation might just be a strawman till
> someone thinks about it carefully right?
> On Wed, Aug 13, 2014 at 6:30 PM, Herbert Valerio Riedel <hvriedel at>
> wrote:
>> On 2014-08-14 at 00:09:40 +0200, Mateusz Kowalczyk wrote:
>> [...]
>>> I don't know what the GHC branch name will be yet. ‘ghc-head’ makes most
>>> sense but IIRC Herbert had some objections as it had been used in the
>>> past for something else, but maybe he can pitch in.
>> I had no objections at all to that name, 'ghc-head' is fine with me :-)
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at

If there's more than one reasonable way then there's going to be
strawman along the way somewhere anyway but we can at least delegate
that until later. As I mention in the OP, there's at least no need for
me to worry about it until it's finished on the GHC side although I'll
no doubt be aware of it sooner than that.

The PatternSynonyms stuff is an example where the implementor also
stepped up to putting in support into Haddock for rendering. At the same
time, the implementation has changed multiple times along the way
creating hassle for both parties so perhaps in the future it's better to
simply make sure Haddock still compiles and works but perhaps delegate
everything else to closer to the release.

In the end, it does not matter if Haddock can't display a bleeding edge
feature until it's going out as a release.

Mateusz K.

More information about the ghc-devs mailing list