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@well-typed.com> wrote:
Laurent P. René de Cotret <laurent.decotret@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs