<div dir="ltr"><div>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 
:).<br><br>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 <i>breaking</i> changes interact much with the language itself, so the relationship between base and GHC is less constrained than it seems.<br><br></div><div>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 
(<a href="http://www.well-typed.com/blog/2015/07/cabal-setup-deps/" target="_blank">http://www.well-typed.com/blog/2015/07/cabal-setup-deps/</a>), Stackage 
package sets, and split base can improve the experience this time 
around.<br><br>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.<br><br>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 <i>within</i> the ecosystem centered around each base that I'd wager we'd still be in better shape than how things were circa 6.10.<br><br>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.<br></div><div><br></div><div>According to <a href="https://ghc.haskell.org/trac/ghc/wiki/SplitBase#Non-Obviousinterdependencies" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/SplitBase#Non-Obviousinterdependencies</a>, 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.<br></div><div><br>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.<br></div><div><br></div>John<br></div>