[ghc-steering-committee] Haddock

Cale Gibbard cgibbard at gmail.com
Fri Jun 19 16:00:41 UTC 2020


In addition to this, it seems like the situation involving the
relationship between commits on haddock and commits on GHC is
currently somewhat unsatisfactory. In order to build an arbitrary
commit on haddock, you need to know which commit of GHC to use to
build it, but instead, the commits of GHC have a pointer to the
haddock repo, rather than the other way around. I remember being
surprised that the git submodule relationship wasn't at least in the
opposite direction.

I think it would make a fair amount of sense just to regard haddock as
being a full-fledged part of GHC and perhaps just unify the
repositories, since it's so intimately connected to GHC's internals
anyway, but I might be unaware of other constraints on its development
process.


On Fri, 19 Jun 2020 at 11:35, Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>
> Good thought. Personally, I'd be happy to have a Haddock maintainer on the committee;
> but I'd like them to be a full member, contributing to the discussion and shepherding proposals -- not merely acting as the Haddock liaison.
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> |  On Behalf Of Richard Eisenberg
> |  Sent: 18 June 2020 22:29
> |  To: ghc-steering-committee <ghc-steering-committee at haskell.org>
> |  Subject: [ghc-steering-committee] Haddock
> |
> |  Hi committee,
> |
> |  With a steady level of activity adding new features to GHC, I fear we may
> |  be forgetting one important downstream client: Haddock. For a nice
> |  example of how our decisions can cause trouble, see
> |  https://github.com/goldfirere/singletons/issues/466#issuecomment-
> |  646117067. Despite appearing on the singletons bug tracker, that comment
> |  is all about Haddock support for https://github.com/ghc-proposals/ghc-
> |  proposals/blob/3dfec03b11e8829d7febbb7290c3183f752466d7/proposals/0054-
> |  kind-signatures.rst, the -XStandaloneKindSignatures extension.
> |
> |  This makes me wonder: should we invite a maintainer of Haddock to be an
> |  ex-officio (and voting) member of the committee? This would have two
> |  salutary effects:
> |  - It would force us to consider an important aspect of the user
> |  experience -- reading documentation -- of newly proposed features.
> |  - It would force us to give Haddock a heads-up about new features they
> |  may want to incorporate.
> |
> |  If we don't think we need an ex-officio committee member, then perhaps we
> |  should instead require future proposals to describe a plausible impact on
> |  Haddock. I say "plausible impact" to suggest that the proposal text would
> |  not be binding on Haddock (which would be awfully dictatorial of us), but
> |  that it gives Haddock a starting place to consider their own design,
> |  while forcing proposers to think about this important-but-easily-
> |  neglected aspect of language evolution.
> |
> |  What do we think?
> |
> |  Richard
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org
> |  https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


More information about the ghc-steering-committee mailing list