headers
Ian Lynagh | 6 Aug 22:35
Gravatar

PROPOSAL: More base package breakup


Hi all,

This is trac #1338:
    http://hackage.haskell.org/trac/ghc/ticket/1338#comment:14
    http://hackage.haskell.org/trac/ghc/attachment/ticket/1338/packagegraph.png

Initial deadline: 21 Aug (2 weeks).

The base package is still a large, unwieldy beast, making it hard to
develop and debug. If possible, I'd like to cut it down a bit more
before the 6.10 release.

I won't inline all the details here, as it's a huge amount of text and
an image, but basically I'm proposing to:

* Create packages:
    timeout, unique, concurrent,
    st,
    system, numeric, generics,
    version, getopt, debug, printf
    ghc-exts
* Merge what I've listed as "control" into "containers"

There's definitely a "foreign" package fighting to get out too, but that
needs more work before we can set it free.

An important point to note is that Simon Marlow has made a base 3
compatibility library that will come with GHC 6.10, and will provide the
same interface as the base library that came with 6.8, so breaking
(Continue reading)

Permalink | Reply |
headers
Sean Leather | 6 Aug 23:38

Re: PROPOSAL: More base package breakup

Hi Ian,

The base package is still a large, unwieldy beast, making it hard to
develop and debug. If possible, I'd like to cut it down a bit more
before the 6.10 release.

I won't inline all the details here, as it's a huge amount of text and
an image, but basically I'm proposing to:

* Create packages:
   timeout, unique, concurrent,
   st,
   system, numeric, generics,
   version, getopt, debug, printf
   ghc-exts

I have a very strong request to name the "generics" package something else. The reason is that this not the only flavor of generic programming. Many others are available and/or will be made available. (We [1] are working on a few.) For example, if you go to the Hackage package list [2] and grep for "generic," you'll find a number of packages, not to mention Uniplate and Strafunski (a.k.a. StrategyLib). If you go to the wiki on research papers in the area of generics [3], you find a lot. Only 2 of those cover the Data.Generics library.

Naming the package "generics" is deceiving, because it conveys that it is the only (or main) generics library. I would recommend calling it "syb," because that is its more popular name based on the research that has been done, esp. considering the continuing use of "Scrap Your ..." in titles. ;)

As a side note, it appears that I am not the first person to say this. [4]

Thanks,
Sean
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Permalink | Reply |
headers
Ian Lynagh | 6 Aug 23:45
Gravatar

Re: PROPOSAL: More base package breakup


Hi Sean,

On Wed, Aug 06, 2008 at 11:38:05PM +0200, Sean Leather wrote:
> 
> Naming the package "generics" is deceiving, because it conveys that it is
> the only (or main) generics library. I would recommend calling it "syb,"

"syb" is fine with me.

Thanks
Ian
Permalink | Reply |
headers
Duncan Coutts | 13 Aug 02:04
Gravatar

Re: PROPOSAL: More base package breakup

On Wed, 2008-08-06 at 21:37 +0100, Ian Lynagh wrote:
> Hi all,
> 
> This is trac #1338:
>     http://hackage.haskell.org/trac/ghc/ticket/1338#comment:14
>     http://hackage.haskell.org/trac/ghc/attachment/ticket/1338/packagegraph.png
> 
> Initial deadline: 21 Aug (2 weeks).

Generally this looks good if a little on the ultra-fine-grained side. If
we can fold back a few of those tiny single-module packages that'd
probably be good.

I think we should not move the Applicative class however. It belongs in
the same package as Functor and Monad (and we should be encouraging
everything to be an instance of Applicative).

Similarly, I think the Monoid class should stay in base. I don't care so
much about the extra Monoid types currently defined in Data.Monoid but
the class should stay.

I don't think it makes any sense to put Monoid and Applicative in the
containers package. They're almost completely unrelated.

One reason is that classes (but not their instances) are common
interfaces and so belong further down in the package dep graph. People
tend to try to reduce package dependencies so making people depend on
containers to give an applicative instance will mean that in many cases
people simply will not.

I'll let other people comment on Data.Foldable and .Traversable since I
don't use them.

Duncan
Permalink | Reply |
headers
Henning Thielemann | 13 Aug 09:15

Re: PROPOSAL: More base package breakup


On Wed, 13 Aug 2008, Duncan Coutts wrote:

> On Wed, 2008-08-06 at 21:37 +0100, Ian Lynagh wrote:
>> Hi all,
>>
>> This is trac #1338:
>>     http://hackage.haskell.org/trac/ghc/ticket/1338#comment:14
>>     http://hackage.haskell.org/trac/ghc/attachment/ticket/1338/packagegraph.png
>>
>> Initial deadline: 21 Aug (2 weeks).
>
> Generally this looks good if a little on the ultra-fine-grained side. If
> we can fold back a few of those tiny single-module packages that'd
> probably be good.
>
> I think we should not move the Applicative class however. It belongs in
> the same package as Functor and Monad (and we should be encouraging
> everything to be an instance of Applicative).

+1

> Similarly, I think the Monoid class should stay in base. I don't care so
> much about the extra Monoid types currently defined in Data.Monoid but
> the class should stay.
>
> I don't think it makes any sense to put Monoid and Applicative in the
> containers package. They're almost completely unrelated.

+1

> One reason is that classes (but not their instances) are common
> interfaces and so belong further down in the package dep graph. People
> tend to try to reduce package dependencies so making people depend on
> containers to give an applicative instance will mean that in many cases
> people simply will not.

+1

> I'll let other people comment on Data.Foldable and .Traversable since I
> don't use them.

For me Foldable and Traversable belong to where Applicative is.

Boring comment, isn't it?
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Permalink | Reply |

Gmane