This could easily turn into a frustrating project, especially if it’s done in one go.
But yes, reinstallable base means two things:
we can in theory have more appetite for breaking changes, because users can opt-out
if users can opt-out, that also means we have to maintain previous major version branches (that was the entire point of PVP)
In my opinion however, that doesn’t mean that we should experiment in base. So the way I can imagine this could work is that someone creates a fork of base, accumulates ideas and breaks them down into separate proposals, easy to digest.
It’s also possible that CLC will, after all this time, have to develop a vision. At least to guide potential contributors on the general direction.
I’m a little late to the party but what is the motivation for making base an ordinary package?
At first sight it seems to bring added complexity (both for maintainers and users) for little gain but I’m probably missing something. Has the motivation been discussed somewhere?
The motivation is to make GHC upgrades easier. At the moment, the most common reason that a package P won’t compile with a new GHC version V is not because GHC’s behaviour has changed, but because the new GHC comes with a new base B, and P (rightly or wrongly) won’t build with B.
base just being reinstallable just means that cabal can choose to use whatever version of base it wants, not just the one that came with GHC. So GHC V could still build P, by using the older base version.
It’s not quite that simple in the end, but that’s the idea.
Another motivation is to make those projects properly separate. This will allow us to:
be stricter about interfaces between base and GHC
improve the development experience for base contributors (e.g. we could make it so you potentially don’t have to deal with gitlab, hadrian or building all of GHC anymore)
For completeness’ sake, have the drawbacks been discussed (if there are any)? I don’t mean the implementation problems but the long-term maintenance costs or risks for GHC maintainers, base maintainers and users. I imagine keeping base compatible with multiple GHC versions will require some maintenance.
In case this has already been discussed, sorry. I can’t find a discussion on the motivation and the costs/drawbacks anywhere so I thought it would be good to make these points explicit.
GHC maintainers should ideally be out of the loop; the interface between ghc-base and base should be fairly stable. Most of what you raise should be on the CLC’s plate. That said, I haven’t heard anything from them about how they plan to manage multiple versions of base being under active support.
I can say that multiple versions of base didn’t work very well back when GHC supported two different versions (I think it was in the 6.x era, since I don’t see it on a quick check of version history), but that was something of a hack to start with IIRC. Including in how ghc supported it, since there was nothing like ghc-base back then. There also wasn’t a CLC to help manage the mess.
I didn’t say they should themselves be maintaining it. They should, however, be arranging for it to be maintained (potentially by multiple groups if base major versions differ enough) and coordinating ghc-base API changes, among other things.
Since GHC are technically still maintainers, they’d have to ask the CLC to do so. But they can also choose to find maintainers by themselves. Such an arrangement still has not concluded.
I’ve made a coordination repo now, so that we can try to make some concrete decisions about everything that has been discussed so far.
Is there anyone wanting to take a lead on any of the 3/4 points that I included in the summary above? On the repo I have called the main action area the following:
Doesn’t ghc already have too much to deal with as it is? Now’s the time to offload base to someone who has time.
That is true – but there is more to it than that. This is a chance for more members of the Haskell community to have an opportunity to contribute to our shared “commons”. That gives us a voice, agency, and a stronger sense of shared purpose.
Haskell isn’t a product, something that is done to us; it’s a shared endeavour that we do together.
I think the GHC team would strongly welcome a small group of maintainers to take the lead on the base code. Please do consider joining in.
I don’t really know. GHC has paid/sponsored developers. CLC does not.
But yes, it would probably be nice for such things to be handled by volunteers/other parties, so that compiler engineers can do what they do best: developing the compiler.
I’ve asked this before on the github thread, but GHC developers have not made it clear whether they want to carry out the transition (building a new base maintainer team) on their own or whether they want CLC to execute it.
Please make this clear, otherwise this is going to be confusing.