Pre-Pre-HFTP: Decoupling base and GHC

Ericson2314 · February 12, 2022, 3:33pm

We don’t want to do that because we want (the new) base to be portable across GHC versions (and other hypothetical implementations) at all times. The empty library is trivially portable, and we move over definitions only if they are also.

…and right now (2022 Feb) that would require going as close to fully-parameterised (no type classes) as possible

I am interested in these things, but I don’t think overly opinionated instances in GHC are a problem. (Outputable is opinionated but structured errors mean that pretty-printing is increasingly moved to the outskirts!)

If you want to talk to about orphan instances more, would you mind forking that to a new thread? It is orthogonal to the low hanging initial steps for both making GHC a real library and decoupling base.

atravers · February 12, 2022, 8:43pm

Acknowledged. I’ve just searched for orphan here to see if there was an existing Discourse thread - this appeared in the results:

…which mentioned this:

which in turn refers to this:

github.com

nomeata/packages-base/blob/base-split/README.md

Base splitting experiment
=========================

On this branch, based on the ghc-7.6 branch, it is tested how far base can be
split into smaller components that separate concerns. Main goals are:
 
 * Reduce the number of API breaks for packages, by allowing them to specify their
   dependencies more exact.
 * Having a base pure package that does not include IO or Foreign stuff, with an API
   that can also be provided by strange targets (JS, etc.)
 * Separating out floating point stuff might be interesting as well.

Setup 
-----

This branch still contains the base package. But it also contains
base-something packages as subdirectories, with symbolic links into the main
directory, to verify that the individual components build.

How to test

This file has been truncated. show original

May you be more successful.

Ericson2314 · February 14, 2022, 4:30am

Thanks! That is very useful. I am generally a fan of rebasing things no matter how ancient, so I should take a crack at rebasing @nomeata’s changes even though they are a decade old.

From it’s readme

Some changes are just work-arounds due to GHC having the package name base hardcoded

Yes we should definitely get that more flexible so we don’t need to rebuild the compiler are stuff merely moves around. Settings file, maybe?

Ericson2314 · March 26, 2022, 4:37pm

Proposal: Relax instances for Functor combinators; put superclasses on <class>1 to make less-breaking · Issue #10 · haskell/core-libraries-committee · GitHub I wrote up a new benefit that even the most trivial “beachhead” of making ghc-base contain everything and base reexport it all would realize.

atravers · September 8, 2022, 7:41am

atravers · September 12, 2022, 6:25pm

haskell98: Compatibility with Haskell 98
haskell2010: Compatibility with Haskell 2010
~~https://hackage.haskell.org/package/haskell2020~~

…therefore:

https://hackage.haskell.org/package/haskell-glasgow2021
https://hackage.haskell.org/package/haskell-glasgow2024
https://hackage.haskell.org/package/haskell2028
…

with each being a “standardised snapshot” of:

https://hackage.haskell.org/package/haskell

in which all the latest products of active research debuts. The haskell package can also serve as the point of separation (or abstraction) between base and GHC, allowing the two to evolve at their own pace.

Everyone else can then choose the level of stability and compatibility most suitable for their Haskell project.

Ericson2314 · December 11, 2022, 11:54pm

Standard library reform by Ericson2314 · Pull Request #47 · haskellfoundation/tech-proposals · GitHub I have opened a draft tech proposal on this.