Buy-in for technical proposal 47 which affect GHC devs

Carter Schonwald carter.schonwald at gmail.com
Tue Mar 21 21:55:45 UTC 2023


Would this include making those modules not hidden in ghc base? There’s
been a few times where that status made it quite hard to build
documentation for those modules!

On Tue, Mar 21, 2023 at 1:16 PM Ben Gamari <ben at well-typed.com> wrote:

> Laurent P. René de Cotret <laurent.decotret at outlook.com> writes:
>
> > Dear GHC developers,
> >
> > In recent weeks, John Ericson has fine-tuned a Haskell Foundation
> > Technical Proposal to split `base` into two libraries: `ghc-base` and
> > `base`, the latter simply re-exporting everything for `ghc-base` (for
> > now). You can read about the rationale and specifics more in details
> > in the proposal itself:
> > https://github.com/haskellfoundation/tech-proposals/pull/47
> >
> > Note that this proposal has recently been streamlined into a form
> > which is more focused than its initial state, and might be worth a
> > re-read.
> >
> > The Haskell Foundation Technical Working Group has reached a consensus
> > that this work will benefit the Haskell community. Moreover, the
> > Haskell Foundation has agreed to spend some of its resources to
> > implement this proposal, which would start by ensuring the completion
> > of MR7898 (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7898).
> >
> > This work will affect GHC developers. Therefore, the Technical Working
> > Group would like to get buy-in from the GHC developers before formally
> > accepting this proposal.
> >
> Hi Laurent,
>
> In general I am quite supportive of this proposal. I have discussed the
> idea with John on several occassions and agree that separating the
> implementation of `base` from its user-facing interfaces with a package
> boundary would simplify life for both users and GHC's maintainers (c.f.
> [1]).
>
> I also threw together my own implementation of the idea in a few hours
> some weeks back (having forgotten about John's effort); this can be
> found in the wip/ghc-base branch [2]. From that experience I have no
> doubts that this idea is feasible. The only issues that I am slightly
> unsure of are:
>
>  * whether/how to prevent `ghc-base` references from seeping into error
>    messages.
>
>  * which interfaces should be re-exposed from `base`. In [2] we propose
>    that a fair number of interfaces be marked as GHC-internal.
>    Those which are marked [3] as "hidden" should likely be
>    exposed only via `ghc-base`. However, for compatibility reasons we
>    may decide to continue exporting some subset of "internal" modules
>    (with frozen export lists) from `base`.
>
> Regardless, I am very happy to see this split move forward and am
> grateful to John for his work in this direction.
>
> Cheers,
>
> - Ben
>
>
>
> [1] https://github.com/haskell/core-libraries-committee/issues/146
> [2] https://gitlab.haskell.org/ghc/ghc/-/tree/wip/ghc-base
> [3]
> https://docs.google.com/spreadsheets/d/1WmyYLbJIMk9Q-vK4No5qvKIIdIZwhhFFlw6iVWd1xNQ/edit#gid=1315971213
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230321/941d5c98/attachment.html>


More information about the ghc-devs mailing list