John – with notes for Edward K (core libraries) 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
You should really address this to the Core Libraries Committee, not ghc-devs A huge motivation for slow change in base is to avoid breaking libraries. In fact the core libraries committee settled on a “Three release policy”. It’s described here<https://prime.haskell.org/wiki/Libraries/3-Release-Policy> but that page says “not finalised” and it is not linked from the Core Libraries Committee<https://wiki.haskell.org/Core_Libraries_Committee> page. I’m all for splitting base up. Lots of base is NOT connected with the compiler, and moving that out would be good. As it happens, Monad *is* connected; e.g. via do-notation. And MonadFail is connected with how pattern matching in do-notation works. So I rather doubt you could change Monad around without also changing GHC in sync. That’s why base and GHC are the same repo. But yes – please shrink it! Simon From: ghc-devs [mailto:[email protected]] On Behalf Of Ericson, John Sent: 02 June 2016 01:38 To: ghc-devs <[email protected]> Subject: Break Base Faster 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/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.well-typed.com%2fblog%2f2015%2f07%2fcabal-setup-deps%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ca0b0d618e48a406f9d0a08d38a7e32bd%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=TM1019nXTN60qI%2fvvfFTXCdY%2b4ubq%2bD5EjVZm63LsfU%3d>), 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
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
