Perhaps looking at what base-compat has to offer ("*A compatibility layer for base*") is relevant to this discussion. See:
https://github.com/sol/base-compat#readme http://hackage.haskell.org/package/base-compat I didn't use it but it looks as promising approach to base API stability. All best, Krzysztof Skrzętnicki On Wed, Feb 13, 2013 at 10:00 AM, Simon Marlow <marlo...@gmail.com> wrote: > On 13/02/13 07:06, wren ng thornton wrote: > >> On 2/12/13 3:37 AM, Simon Marlow wrote: >> >>> One reason for the major version bumps is that base is a big >>> conglomeration of modules, ranging from those that hardly ever change >>> (Prelude) to those that change frequently (GHC.*). For example, the new >>> IO manager that is about to get merged in will force a major bump of >>> base, because it changes GHC.Event. The unicode support in the IO >>> library was similar: although it only added to the external APIs that >>> most people use, it also changed stuff inside GHC.* that we expose for a >>> few clients. >>> >>> The solution to this would be to split up base further, but of course >>> doing that is itself a major upheaval. However, having done that, it >>> might be more feasible to have non-API-breaking releases. >>> >> >> While it will lead to much wailing and gnashing of teeth in the short >> term, if it's feasible to break GHC.* off into its own package, then I >> think we should. The vast majority of base seems quite stable or else is >> rolling along at a reasonable pace. And yet, every time a new GHC comes >> out, there's a new wave of fiddling the knobs on cabal files because >> nothing really changed. On the other hand, GHC.* moves rather quickly. >> Nevertheless, GHC.* is nice to have around, so we don't want to just >> hide that churning. The impedance mismatch here suggests that they >> really should be separate packages. I wonder whether GHC.* should be >> moved in with ghc-prim, or whether they should remain separate... >> >> But again, this depends on how feasible it would be to actually split >> the packages apart. Is it feasible? >> > > So I think we'd need to add another package, call it ghc-base perhaps. The > reason is that ghc-prim sits below the integer package (integer-simple or > integer-gmp). > > It's feasible to split base, but to a first approximation what you end up > with is base renamed to ghc-base, and then the new base contains just stub > modules that re-export stuff from ghc-base. In fact, maybe you want to do > it exactly like this for simplicity - all the code goes in ghc-base. There > would be some impact on compilation time, as we'd have twice as many > interfaces to read. > > I believe Ian has done some experiments with splitting base further, so he > might have more to add here. > > Cheers, > Simon > > > > ______________________________**_________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.**org <Glasgow-haskell-users@haskell.org> > http://www.haskell.org/**mailman/listinfo/glasgow-**haskell-users<http://www.haskell.org/mailman/listinfo/glasgow-haskell-users> >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users