Proposal: Slim base-5 API package

[Edward Kmett]

It pretty much is the evolution of the SplitBase API effort.

One of the main reasons why Joachim joined the core libraries committee was
to work on refining split base into an implementable specification.

-Edward

On Mon, Jul 15, 2013 at 12:22 PM, Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> On Mon, 15 Jul 2013, Joachim Breitner wrote:
>
>  The problem
>> ===========
>>
>> currently, base is a big beast that mixes a lot of different aspects,
>> from really basic stuff like Data.List to quite specific system
>> libraries like System.Console.GetOpt to gory GHC details such as
>> GHC.Conc.Signal. There are various issues with this:
>>
>>      * No implementation of a module included in base is able to use
>>        stuff from other libraries, like containers. There are even
>>        copies of container code in base.
>>      * Changes to the API of obscure modules like GHC.Conc.Signal
>>        require version bumps in base, which cause lots of depending
>>        packages to upload new version just to change their dependency.
>>      * The large expose surface of base makes refactoring like the
>>        actual split of the base implementation harder.
>>      * Compilers like haste or fay have a hard time providing a proper
>>        base, as many of the modules do not make sense in that setting.
>>
>
>
> How is your proposal related to your SplitBase effort:
>    http://ghc.haskell.org/trac/**ghc/wiki/SplitBase<http://ghc.haskell.org/trac/ghc/wiki/SplitBase>
> ?
>
> ______________________________**_________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130715/d4e3a250/attachment.htm>