Re: Buy-in for technical proposal 47 which affect GHC devs

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 wrote:

Laurent P. René de Cotret 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-vK4No5qvKIIdIZwhhFFlw6i... _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs