What are the next steps for reinstallable base?

[mpickering]

It seems to be a shared goal of the community to move in the direction of a more "normal" base package.

What progress has been made towards this?

• ghc-internal is split up from the base library: Now there are two separate packages, one for internals and one for the "user" functions provided as a convenience.
• The base library is not wired-in to GHC anymore, it has a normal unit-id, and is not privileged by the compiler.
• cabal has been taught that it is allowed to reinstall the base library.

Therefore we turn to the question about how else we can make "base" more normal. It seems to me that the next obvious step is to move the base package into it's own repo, so it can be developed and released separately from the compiler.

• base can be released independently of ghc.
• base can be versioned independently of ghc releases.
• base can be built and tested against different ghc versions.
• Contributors can build and work on base using normal tooling (cabal) and development workflows.
• Clearer boundaries between ghc-internal and base.

I want to ask the CLC and other community members if they think this is a good direction to go in, and any obstacles or other considerations that should be taken into account whilst moving forward with this project.

Some specific questions which could be useful to drive the discussion:

1. Whether the CLC considers separate repository development a desirable long-term direction.
2. What obstacles or constraints the CLC foresees with this proposed approach.
3. Whether the CLC would be willing to manage base releases independently of the GHC schedule, if the technical work makes this possible. This would be the final step in making "base" a normal library like the other packages managed by the CLC.

My aim here is to start the conversation and see whether this direction is one the community broadly supports. If so, we can collaboratively develop a clear plan for making it happen. The CLC’s guidance would be especially helpful in understanding the constraints and opportunities involved.

[hasufell]

Thanks for bringing this up Matt!

ghc-internal is split up from the base library: Now there are two separate packages, one for internals and one for the "user" functions provided as a convenience.

I think the boundaries between both packages have to be improved substantially.

Most of the base implementation practically lives in ghc-internal and is just re-exported. I don't see how we can separate base from the GHC project reasonably while this is the case.

I remember people arguing it's just an implementation detail, but:

• it's a problem if we want to separate those projects properly (e.g. move base to github and make contribution easier... pardon my language, but having to deal with GitLab and hadrian is one of the worst experiences I can imagine a new base contributor has to go through)
• I still can't really imagine how we can evolve base independently from GHC when most of the implementation lives in ghc-internal

So to me this seems like the top priority: figuring out what is actually "GHC internal" and start moving implementation back into base.

---

1. Whether the CLC considers separate repository development a desirable long-term direction.

Very strong yes from me.

2. What obstacles or constraints the CLC foresees with this proposed approach.

This will require more coordination between those projects. I think that's good, but it could be a rough initial period.

It might also mean that we should discuss whether GHC HQ remains "maintainers" or if we should move it to a separate group/institution. But that's something that is ultimately up to the current maintainers to decide/agree on.

On the technical side, I'm guessing there will have to be some CPP to support multiple GHC versions (or more precisely: ghc-internal and ghc-prim). So we will also have to come up with a support policy to keep maintainability in a good state.

3. Whether the CLC would be willing to manage base releases independently of the GHC schedule

This just boils down to the question of who will maintain base (as opposed to govern). So we should articulate it as such.

My proposal would be that we create a new "base maintainers" group that is initially instantiated by the sum of GHC developers + current CLC members, but will be separate from CLC from then on. API decisions will still be made by CLC. But we will have access to a wider group of people for reviews and releases. Maybe that will also help with increasing engagement.

[simonpj]

Most of the base implementation practically lives in ghc-internal and is just re-exported. I don't see how we can separate base from the GHC project reasonably while this is the case.

From the user point of view, it really is just an implementation detail. But I see your point:

• If ghc-internals changes, there may be a consequence for base, just to maintain the same API. I don't see this as a very high-bandwidth connection, because I think internally-driven ghc-internals changes are unlikely to have direct consequences.
• If the base maintainers want to change something about the implementation (e..g improve the sortOn algorithm) and that code lives in ghc-internals, they can't change it directly -- instead they must make a PR against ghc-internals. To me that seems not so bad: the GHC team would need to review it only for any accidental consequences on GHC, knowing that the base maintainers were taking responsibility for the primary consequences, namely its effect on base.

Both seem quite manageable to me, even with things as they are. But I'm not at the sharp end. Maybe you can say a bit more about why moving code across is a "top priority"?

Even so, I definitely agree that the more code we can move out of ghc-internals and into base the better. But I think that housekeeping exercise is much more likely to happen if we have an active base team driving it, rather than the status quo. As things stand, the incentives for the busy GHC team to do this tidying up are rather weak.

My proposal would be that we create a new "base maintainers" group that is initially instantiated by the sum of GHC developers + current CLC members,

I think it needs a clear leader or co-leaders. If it's just a group of 15 people, nothing will happen.

[AndreasPK]

I think the boundaries between both packages have to be improved substantially.

I can see how moving things out of ghc-internal would be a top priority for making base a wholly independent project. And that would have it's own merit and presumably also some downsides. But making base wholly independent is not (yet?) the goal here. We want to walk before we run!

I still can't really imagine how we can evolve base independently from GHC when most of the implementation lives in ghc-internal

I find it hard to talk about this in the abstract. But for a concrete example.

Let's say a user depends on isBitSubType :: (Bits a, Bits b) => a -> b -> Bool which currenty is a re-export. If a future version of base wants to "evolve" this function it could just change the implementation from a re-export to a implementation given in base.

As simon said the worst case would be changes to a function where we want the implementation to be in ghc-internal for whatever reason. Then base would be forced to keep it as re-export and the functions semantics would change based on the GHC version used. But are there really functions like that where we expect much "evolution"?

Maybe there are big problems there that you identified that we don't know about there. Ben spent much time looking for things like that in the past and trying to get them deprecated in base to avoid exactly this. There might still be work to do there. Presumably this work would happen to unlock reinstallable-base. But the solution there is rather to drop those things from base, rather than to move them into base.

If you know about code that must be moved into base to allow it to become re-installable it would be good to know concretely where you see the issues.

[hasufell]

Both seem quite manageable to me, even with things as they are. But I'm not at the sharp end. Maybe you can say a bit more about why moving code across is a "top priority"?

I don't think anyone would want to maintain a library where the implementation doesn't actually live in said library. I certainly wouldn't.

These are the main issues:

• Accidential/non-approved changes to ghc-internals might change base API (this happened multiple times already, despite the CLC process and the testsuite in GHC CI). As a consequence, both CLC and base maintainers would have to continue to monitor the GHC repository to catch, understand and possibly intervene in such changes.
• Changing base requires contributing to GHC, which has been a soul crushing experience for me for the past couple of months (and gave me a new form of respect for GHC developers). I can go into detail, but I'd rather spend my time on improving the experience for base contributors. It also makes the entire point of moving to a different platform/repository/CI void, since I can't really experiment with source code changes in my new repository!

There's also some minor side-effects:

• Re-exports also make it hard to follow PVP correctly, requiring API tests and potentially rigorous upper bounds bumping (upper bounds on ghc-internals), which is yet another overhead
• Downloading the base package and looking at its source code code doesn't really work

Even so, I definitely agree that the more code we can move out of ghc-internals and into base the better. But I think that housekeeping exercise is much more likely to happen if we have an active base team driving it, rather than the status quo. As things stand, the incentives for the busy GHC team to do this tidying up are rather weak.

When the base split proposal happened, I remember that I objected to moving the implementation to ghc-internals, but it was repeatedly expressed that this is just an implementation detail. This was GHC developers decision. And I find it a bit confusing that volunteers now have to pay the price of reverting that decision.

I think the more likely outcome will be this: base maintainers will just move the entire implementation back to base and remove all re-exports. What GHC developers do with the duplicated code is up to them. I don't see why base maintainers would have to deal with that.

[AndreasPK]

When the base split proposal happened, I remember that I objected to moving the implementation to ghc-internals, but it was repeatedly expressed that this is just an implementation detail. This was GHC developers decision. And I find it a bit confusing that volunteers now have to pay the price of reverting that decision.

This wouldn't work for technical reasons. A primop returning a Bool would then have a different return type than the Bool type defined in base for example. Maybe the implementations of functions could be moved like that, but without moving the types you still end up with that dependency. It's to do with wired-in things. See also https://gitlab.haskell.org/ghc/ghc/-/issues/26253

There are things one can do to reverse the dependency. But then base is still coupled to GHC in this way since GHC still needs to know about the definition of the type somehow.

I think there were also issues with instances as well where we wanted to avoid orphan instances? But I was not directly involved in the work so maybe I got some details wrong.

For modules where the same module could have been trivially moved into base itself I believe that was actually already done during the split. Would it have been better if work to untangle these things had happened at the time of the split? But there simply were no resources available to figure out all those issues at the time.

[TeofilC]

1. Whether the CLC considers separate repository development a desirable long-term direction.

Yep I think this is a good idea

2. What obstacles or constraints the CLC foresees with this proposed approach.

There are GHC internals still exposed from base, we need to stop exposing these things for this strategy to be most effective. And there are things living in ghc-internal, which are only accidentally there and which should be moved to base. I think having the separate repository will encourage these things to be improved.

3. Whether the CLC would be willing to manage base releases independently of the GHC schedule, if the technical work makes this possible. This would be the final step in making "base" a normal library like the other packages managed by the CLC.

This sounds good to me, but I'm not sure exactly how much extra work this would entail.

[TeofilC]

This was GHC developers decision

I don't think this is accurate. This was a HF tech proposal https://github.com/haskellfoundation/tech-proposals/blob/main/proposals/accepted/051-ghc-base-libraries.rst. GHC developers didn't unilaterally make this decision.

[hasufell]

This was GHC developers decision

I don't think this is accurate. This was a HF tech proposal https://github.com/haskellfoundation/tech-proposals/blob/main/proposals/accepted/051-ghc-base-libraries.rst. GHC developers didn't unilaterally make this decision.

The proposal doesn't mention at all how much of the implementation may be moved into ghc-internal. It just mentions the dependency issue.

That was ultimately up to GHC developers and their decision as maintainers.

[chreekat]

My impression, from a few months ago, was that the next step for a reinstallable base was to start deprecating and removing elements from base that should really only be exposed through ghc-internal or ghc-experimental.

As long as base is getting whiplashed by internal changes in GHC, it won't have an interface that is stable enough to be compatible with two different versions of GHC.

Note: This "product" concern is orthogonal to the governance questions, which I agree are also at the top of the list.

[Bodigrim]

Yes, if anyone wants to make progress on reinstallable base then https://github.com/haskell/core-libraries-committee/issues/299 was meant to be the next step. Currently maintaining base separately from ghc-internal (not even saying across several releases of ghc-internal) would be absolutely untenable.

[mpickering]

Thanks everyone for the thoughtful input so far. It has been good to get the opinion of everyone and there are certainly some challenges I didn't think about. It's also good to get a sense that people seem overall positive about the direction but cautious that we still need to tread carefully. It's definitely a task that we can make progress on together.

From the conversation so far (here and elsewhere), it seems we can roughly agree on four main areas that need a shared plan. We can do some further work at Well-Typed to flesh out this plan a bit more but also if anyone is keen to collaborate then let's do it!

---

1. Entanglement Between base and ghc-internal

This seems to be the main point raised by CLC members on the discussion thread.

A substantial portion of base’s real implementation currently resides in the ghc-internal package.
base re-exports much of this code. The consequences:

• Base maintainers cannot meaningfully maintain or evolve the implementation.
• Changes within GHC can alter base semantics unexpectedly (for example, a new instance can leak)

Why This Matters

Independent development is only useful when base has autonomy over most of its implementation.
Without untangling:

• base cannot be versioned independently
• changes remain tightly coupled to GHC internals
• Contributors will have to indirectly modify ghc-internal to change base.

Open Questions

• What portion of code needs to migrate from ghc-internal to base?
• Which parts must remain due to wired-in constraints (e.g. primops, core types)?
• What should the long-term maintenance boundary look like? This is already fleshed out
• How much is necessary to move before making the repository split? At some tipping point, making the split will force the issue of moving more if it becomes difficult to work on.

2. Increased Coordination and Maintainership Burden

As Julian and Simon noted, decoupling base from GHC introduces new governance and operational overhead:

• A new base maintainer group will be required, with clear leadership.
• Coordination between GHC releases and base releases becomes a cross-project responsibility.
• CI must test multiple GHC versions against multiple base versions.
• Responsibility for breakage becomes more ambiguous.

Why This Matters

Without clear roles and decision-making structures, independent development risks fragmentation and ecosystem instability.

Open Questions

• Who maintains the independent base repository?
• How do GHC HQ, CLC, and base maintainers coordinate?

3. How we replace the current “base bounds == GHC bounds” signalling

This was mainly brought up on discourse and within our company chat.

The ecosystem currently relies on base version bounds as a proxy for specifying compatible GHC versions:

build-depends: base >= X && < Y

This convention works because GHC and base have historically maintained a tight 1:1 mapping.

Why this matters

If base becomes independently versioned:

• base bounds will no longer provide information about compiler compatibility.
• Packages may silently build against unsupported GHC versions.

Open Questions

• How should compiler compatibility be expressed once the base ↔ GHC relationship is broken?
• How do we maintain safety for users on older versions of Cabal that cannot understand new constraint formats?
• Does allowing reinstalling base help, if library authors will now "upper bound" compiler version instead? Are we solving the right problem?
• There is also the issue of portability, how would a package express a bound on a non-GHC Haskell compiler (such as MicroHS).

4. Lack of Compiler Constraint Mechanisms in Cabal

Cabal currently offers no dedicated, revision-friendly, widely supported mechanism for expressing GHC version requirements.
Existing alternatives have serious limitations:

• if impl(ghc):

  • Not revision-safe
  • Not backwards compatible with older Cabal versions
  • impl(ghc >=9.12) and !impl(ghc <9.12)` are not the same.
    • impl(ghc >=9.12) means "implementation is GHC and it's version is >=9.12
    • !impl(ghc < 9.12) is "implementation is not GHC at all or not GHC which is <9.12

• buildable: False:

  • Does not behave correctly for conditional compiler constraints
  • Also not revision-friendly

• other-extensions:

  • A declarative way to specify which features a compiler needs to support.
  • Only expresses lower bounds
  • Extension semantics can change between GHC versions

• Dependency on ghc-internal:

  • Violates the principle that normal libraries must not depend on GHC internals
  • Breaks -Wunused-packages

Why This Matters

Without a robust compiler-constraint mechanism, library authors will not be able to express that their package requires a specific GHC version.

In the past, it has been argued that declarative features such as other-extensions should be used to place requirements on a compiler. In practice, the compiler semantics do change, and packages need to express this in a direct manner. It is common for Hackage trustees to modify base bounds to stop packages building with bad GHC versions.

Open Questions

• What new Cabal features are needed (e.g. ghc-version, compiler-version, or a declarative constraint system)?
• How can such features be introduced without breaking old Cabal versions?
• What is the required migration timeline for the ecosystem?

[simonpj]

Good summary. Some quick thoughts:

Which parts must remain due to wired-in constraints (e.g. primops, core types)?

Another reason is this: if anything that truly belongs in ghc-internal depends on X, then X must be in ghc-internal. For example, if anything in ghc-internal does I/O, then the transitive closure of those I/O functions must be in ghc-internal. I suspect that these direct and indirect depedencies are the reasons for pinning lots of code into ghc-internal.

If we find such dependencies, we could respond in two ways:

• It's fine; keep the code in ghc-inernal.
• Move the ghc-internal code that depends on (say) I/O out, and put it in another library which depends on base.
• Duplicate the I/O system in ghc-internal and in base. (We obviously don't really want this for large complex blobs of code, but might be entirely reasonable for small chunks.)

I'm not taking a position here, just mentioning that I think transitive dependencies are a tiresome reason that moving code into base might require some careful design.

[simonpj]

Dependency on ghc-internal:

An alternative: define a vestigial package ghc-version, which has no content, but only a version number that tracks GHC's own version. Then you say build-depends: ghc-version > 9.6 which reads quite nicely.

[TeofilC]

My impression is that a relatively small proportion of base gets the majority of CLC proposals, eg, Data.List and Prelude. If we could move these and other high traffic bits to live fully into base, then I think that would give us the majority of the gains. The same goes for the GHC internals exposed from base, if we can avoid exposing the bits that change the most often, then we will get most of the gains.

We should also deal with the long tail, but we shouldn't block splitting out base into a separate repository on getting this all done.

[hasufell]

Who maintains the independent base repository?

I already have some ideas, but let's clear up on the approach first. Are GHC developers ok if CLC takes on the responsibility of creating a base maintainer group and finding members? These would also aid with the transition.

[TeofilC]

Part of the issue, I imagine, we want to solve by splitting out this repository is that one group of people does the maintenance work while another has the decision making power. This sort of thing will always lead to friction.

I think the maintainers of base should be exactly the people who can make decisions about it, namely the CLC.

Of course anyone would be free to help with maintenance tasks without being maintainers.

I don't think it would be fair to make someone a maintainer of base if they couldn't be involved in the decision making process around any non-trivial change to it.

[Ericson2314]

Thank you @mpickering for bringing up this issue!

I agree with @TeofilC that the governance issues are overblown. The division of labor is simple: CLC does base, GHC devs and CLC do ghc-internal. And the more re rationalize the division of labor between ghc-internal and base, the more ghc-internal will be something that the CLC need not worry about.

~~As much as it would be nice to try to move some things back to base first, I think @mpickering's original instincts were best, and it is time to rip off the band-aid: let's split out base soon to motivate doing the rest of the work. (Otherwise it is too easy to just be complacent with a halfway done project.)~~

~~It's OK to wait for the cabal parts, as those should be easy, but let's not wait for moving everything we want back out of ghc-internal, because that is going to be a longer process. Let's do that after base is out-of-tree. Let's let the pain of working with submodules compel us to get it done! :)~~

edit Actually now I am more worried about the difficulty moving things across repos.

---

I've always maintained that to solve the entanglement problem will take more libraries. For example, the definition of Monad should be GHC-agnostic, but the definition of IO is GHC-specific. Having two libraries means that only GHC-agnostic -> GHC-specific dependencies are supported, but here we have a clear case of a GHC-specific -> GHC-agnostic dependency.

I think once we have the new repo created, the process will go like this:

1.Redo how wiring-in works, as hinted in in https://gitlab.haskell.org/ghc/ghc/-/issues/26253. The current mechanism is fine for when GHC effectively defines the thing, but it is bad for when GHC merely consumes the thing. (E.g. Monad is defined in regular Haskell, but GHC needs to know about that definition because it is going to use it in special ways.) @TeofilC is right that we need something like Agda/Rust's "lang items" to make this work.

2. Using the above new mechanism, start moving stuff en-mass back to the repo with base, but due to the aforementioned issue of cross-crossing dependencies, actually there will be more libraries in that repo now. We can look at @nomeata's old split base experiments for inspiration on what the library boundaries will look like.

If we want to make the repo split the last step, this is still an option, but we must move quickly on step 1 above, which is redoing the wiring-in mechanisms. That is the part I am worried about dragging on, but I would love to be proven wrong :).

[hasufell]

I think the maintainers of base should be exactly the people who can make decisions about it, namely the CLC.

I'm a bit reluctant about that. Keeping high engagement on CLC proposals alone is a difficult task.

Proposals are often hard to follow and require a bit of research from time to time. The chair(s) have to go through all the issues every other week and ping CLC members, because it's hard to keep an overview.

And that's fine. I want to give people with high expertise, but very limited time still the opportunity to engage in the decision making process.

So I think it's ok to have a base maintenance team where some members are in the CLC and some are not. After all, being a maintainer involves boring tasks, such as dealing with CI, releases and so on.

[TeofilC]

I think it's ok to have a base maintenance team where some members are in the CLC and some are not.

I agree that something like this would be good, but I want to be careful that these people get a say in decision making to some extent. Otherwise they would just be regular contributors rather than maintainers.

In practice, I imagine this could work by delegating authority to a base CI maintainer and/or a release manager and not requiring CLC proposals which soly touch CI or release things (like changelogs, versions)

The main thing is that if we are asking someone to be in charge of a piece of base then they should have autonomy to make changes to it.

[hasufell]

I agree that something like this would be good, but I want to be careful that these people get a say in decision making to some extent.

This is a bit delicate. There's a reason we have terms and rotation in the CLC. But maintainers in general should not be subject to churn. Just as is the case for any other core library.

CLC maintaining a core library already failed previously: https://github.com/haskell/mtl/issues/158

I can very well see base maintainers and CLC members collaborating closely. And base maintainers can apply for CLC as well (we might give them a special opportunity to do so).

CLC is a committee, let's keep it that way.

[TeofilC]

My core point is that maintainers have rights (like being able to merge PRs, decide on project direction) and responsibilities (keeping CI working, making releases, etc). I think it's confusing to call someone a maintainer if we don't grant them any of the rights associated with being a maintainer.

I think we can call it something else or we can change how CLC works and allow certain things to be decided by a base CI /release manager without CLC involvement.

Whatever we do it would be good to clarify what would require a CLC proposal with a split base repo. If we follow the status quo, any change would require a proposal.

[hasufell]

I think it's confusing to call someone a maintainer if we don't grant them any of the rights associated with being a maintainer.

I don't think anyone here is hung up on the terminology.

Whatever we do it would be good to clarify what would require a CLC proposal with a split base repo. If we follow the status quo, any change would require a proposal.

Generally, only changes to external API require CLC proposals.

Changes to CI and documentation wouldn't. Work on moving implementation back from ghc-internals to base also wouldn't require proposals, as long as they don't change the API. There will also be backporting work, assisting reviews, etc.

[tomjaguarpaw]

I think the maintainers of base should be exactly the people who can make decisions about it, namely the CLC.

I want to give people with high expertise, but very limited time still the opportunity to engage in the decision making process.

I don't follow this unless the implication is that the amount of work is going to increase after base split. Have I interpreted that correctly? And if so, why is the amount of work going to increase?

[angerman]

We seem to mostly circle around where code should live. I think the more much more interesting question is: what is are the interfaces/contracts we expect? What is the minimal interface base needs from ghc-internal? if ghc-internals mutates with breaking changes, is base "thick" enough to absorb those changes without braking it's interface?

I think @Ericson2314 is on the right track here that tackling wired in stuff is a priority item.

On this point from @mpickering's post:

library authors will not be able to express that their package requires a specific GHC version.

I'm not sure I fully understand why library authors should feel the need to express they depend on a specific GHC version, don't we want to get away from precisely that? Don't we want to make the foundation so stable that just using a different compiler isn't that much of a thing?

if a library needs a specific feature, I'd much rather see us expose availability of features rather than using version numbers as opaque proxies. Someone backports that features into an older version, and the library stops magically working? Didn't we learn that feature detection is the right approach over user-agent parsing from the web wars?

[hasufell]

I think the maintainers of base should be exactly the people who can make decisions about it, namely the CLC.

I want to give people with high expertise, but very limited time still the opportunity to engage in the decision making process.

I don't follow this unless the implication is that the amount of work is going to increase after base split. Have I interpreted that correctly? And if so, why is the amount of work going to increase?

CLC doesn't maintain any libraries right now.

Maintaining base would at least add the following responsibilities:

• handling CI
• writing tests
• cutting releases
• managing documentation (all of it)
• coordination with GHC

All this has been done by GHC, who are the current maintainers. This is work.

[Bodigrim]

I think the maintainers of base should be exactly the people who can make decisions about it, namely the CLC.

We have GHC core team quite separate from GHC Steering Committee. It would be a disaster if you'd expect every memeber of GHC SC to be a GHC developer. These are very different roles, and I don't see why you'd want them to be the same for base.

---

I've lost enough hours of my life on "reinstallable base" discussions. My experience is that all enthusiasm and calls to "move fast and break things" quickly evaporate as soon as there is real work to be done on regular basis, and things are left not here not there.

Also, ponder at your leisure why pretty much all alternative preludes have died out (or are on life support at best). Why do you think that base won't follow the same fate if it's maintained separately from GHC?

While pursuing your ideals, please don't break something that works reasonably well already.

[hasufell]

Why do you think that base won't follow the same fate if it's maintained separately from GHC?

Only good can come from that.

Right now, a contributor has to:

• ping people on IRC or via email to get their account on GitLab approved
• clone a repo with a bazillion submodules (if it isn't down again)
• figure out how the custom build system hadrian works
• build not only base, but the entirety of GHC
• try to insert comments in GitLab where every key press may take 2 seconds to register
• deal with the incredibly slow and unreliable GHC CI, fragile tests, marge bot crashing, etc. etc.

All of this can be improved if base is maintained autonomously.

[mpickering]

Thanks for all the discussion on the proposal I outlined. My sense is that there’s broad interest in moving the reinstallable-base project forward, and that we’re now at the point where we need to pin down some specifics.

One idea for making progress would be to set up a GitHub repository where we can coordinate more precisely on individual topics via issues. I’m finding myself wanting to respond to everyone, but the number of parallel threads is making that tricky.

Are people happy to move specific discussions to that format? I am volunteering to help coordinate this effort.

[jeltsch]

We seem to mostly circle around where code should live. I think the much more interesting question is: what are the interfaces/contracts we expect? What is the minimal interface base needs from ghc-internal? If ghc-internal mutates with breaking changes, is base “thick” enough to absorb those changes without breaking its interface?

Let me sketch my opinion regarding these matters.

I would categorize the code in the base–ghc-internal conglomerate as follows:

• Portable code, which is code that doesn’t use GHC-specific features
• Non-portable code with a portable interface, which is code that does use GHC-specific features but only internally
• Entirely non-portable code, which is code that uses GHC-specific features and exposes them through its interface

Based on this categorization, I would suggest the following distribution of code:

• Portable code that is not needed by non-portable code is in base
• Non-portable code with a portable interface as well as portable code that is needed by non-portable code is in ghc-internal and has its interface re-exposed through base
• Entirely non-portable code is in ghc-internal and has its interface not re-exposed through base but perhaps exposed by ghc-internal

Once we would have achieved this distribution, it should be rather easy to develop base mostly independently from GHC release cycles, as long as we keep the portable interfaces that ghc-internal exports reasonably stable. Also, there wouldn’t be a need to let base absorb changes that come from changes in low-level GHC functionality, as ghc-internal would absorb those. CPP-based conditional compilation in base shouldn’t really be necessary, as GHC-version-specific things would be in ghc-internal, which wouldn’t have to use conditional compilation either, since there can be a new ghc-internal version for every new GHC version.

I’d be interested to hear what others think about such an approach.

[Ericson2314]

Non-portable code with a portable interface as well as portable code that is needed by non-portable code is in ghc-internal and has its interface re-exposed through base

We do this already, but IMO a problem is the latter category — portable code that is needed by non-portable code — is very large, both in absolute terms, and as a portion of the total amount of portable code. This is why I think it is crucial that we explore ways to move it out after all.