Break Base Faster

[Ericson, John]

I'm excited for the various proposals to clean up base's warts, but the
time-frames over which to distribute the breaking changes are just so
long---approaching a decade IIUC for Monad-Fail for example. First off, If
anybody has some links to where/why the long transitions were proposed, I'd
love to read them as I am not sure of the exact motivation. If, in fact, we
could just break everything all at once without pissing people off, then
the rest of my email can be discarded :).

As I see it, the underlying issue here is that we are assuming each GHC
version will only work with one version of base. Well, as it stands, none
of the proposed *breaking* changes interact much with the language itself,
so the relationship between base and GHC is less constrained than it seems.

I went on #ghc and learned that multiple bases was tried in the past for
Haskell98 compatability and exceptions in 6.10, and the experience was
unpleasant. But I hope that Cabal support for multiple versions of a
package in a single build plan (
http://www.well-typed.com/blog/2015/07/cabal-setup-deps/), Stackage package
sets, and split base can improve the experience this time around.

Cabal improvements perhaps open the door to linking packages that use
different base versions together, with blanket instances from e.g.
(new.Monad, new.MonadFail) => old.Monad to ease the pain. With
package-qualified-imports, I hope we can have legacy base import from base,
but otherwise we can make them both rely on other packages (especially with
split-base), from which base will just re-export definitions.

In the event that linking both bases is impossible, or the blanket
instances are insufficient for making the same library work with other
libraries requiring either base. Stackage will allow for curating separate
package sets for each base version. I imagine the prospect of splitting the
Haskell ecosystem with multiple bases sounds daunting to some, but package
sets like Stackage provides provide enough cohesion *within* the ecosystem
centered around each base that I'd wager we'd still be in better shape than
how things were circa 6.10.

Finally, split base I hope will generally make experimentation easier by
allowing packages to specify more exactly what they need, and lower the
barrier of entry for new bases. As mentioned above, it allow for legacy
base to more more naturally contain blanket instances of normal base's
classes by avoiding package-qualified imports. For the first release with
split base, I'd follow Rust's example where base is a "facade" and the
packages that back it are initially unstable like ghc-prim.

According to
https://ghc.haskell.org/trac/ghc/wiki/SplitBase#Non-Obviousinterdependencies,
the completion of MonadFail is in fact a big prerequisite to an acyclic
split base. If my previous statements are correct on the benefits of split
base, this puts us in an pleasant situation where MonadFail can speed up
split base, and split base can speed up Monad fail.

As a final thought, I think that multiple bases is far superior than taking
the "-compat" route a la transformers-compat: IMO the need to change
upstream code to use "-compat" severely negates the benefits.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160601/a8849f5c/attachment.html>