Twan van Laarhoven | 16 May 02:10
Picon

Proposal/Idea: Split up base even further

Hello librarians,

Here is an idea to resolve some of the problems that remain with the base package:

The problem:

Users can not update their version of the 'base' package, since it is tied to 
Ghc. If a useful new function is added using it requires updating the compiler. 
On the one hand this puts people off using these new functions. On the other 
hand it also makes updates to for instance Data.List take way longer to reach 
the users because we have to wait for the next Ghc release.

The proposal:

User code should NEVER import the library that is now called 'base', it should 
provide an internal API only. For example, base can include the modules
      Internal.Data.List
      Internal.Control.Monad
      Internal.IO
      etc.
Which are as minimal and low level as possible, containing just the things that 
Ghc RELIES on like:

   - type classes for which instances can be derived (Eq, Ord, etc.)
   - data types and classes with syntactic sugar (Bool, [], Num, Monad)
   - low level stuff like IO and ST and primitives

In short, everything that is now under Ghc.*, and hopefully less, becomes the 
new base library. In my opinion half of that can still be moved out, like most 
of Ghc.List, Ghc.Enum, Ghc.IO and Ghc.Read.
(Continue reading)

Neil Mitchell | 16 May 15:40
Picon

Re: Proposal/Idea: Split up base even further

Hi Twan,

I think this is already being done to some extent - so things that GHC
ties to closely are being moved out of base. See this wiki page:

http://hackage.haskell.org/trac/ghc/wiki/PackageReorg#Implementation-specificnotes

Thanks

Neil

On Fri, May 16, 2008 at 1:14 AM, Twan van Laarhoven <twanvl <at> gmail.com> wrote:
> Hello librarians,
>
> Here is an idea to resolve some of the problems that remain with the base
> package:
>
>
> The problem:
>
> Users can not update their version of the 'base' package, since it is tied
> to Ghc. If a useful new function is added using it requires updating the
> compiler. On the one hand this puts people off using these new functions. On
> the other hand it also makes updates to for instance Data.List take way
> longer to reach the users because we have to wait for the next Ghc release.
>
>
> The proposal:
>
> User code should NEVER import the library that is now called 'base', it
(Continue reading)


Gmane