GHC 7.8 release?

[Krzysztof Skrzętnicki]

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 <marlowsd at 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 at haskell.**org <Glasgow-haskell-users at haskell.org>
> http://www.haskell.org/**mailman/listinfo/glasgow-**haskell-users<http://www.haskell.org/mailman/listinfo/glasgow-haskell-users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20130213/5f969a51/attachment-0001.htm>