Proposal: reduce base from the top

[Stefan O'Rear]

On Tue, Apr 03, 2007 at 02:36:06PM +0100, Ross Paterson wrote:
> On Tue, Apr 03, 2007 at 11:21:34AM +0100, Simon Marlow wrote:
> > This is an attempt to propose a set of changes that we could reasonably 
> > make in the GHC 6.8 timeframe, that would significantly reduce the size of 
> > base and give us more flexibility to independently develop packages.
> > [...]
> > Control.Applicative
> > Data.Foldable, Data.Traversable
> > Data.Map, Data.IntMap, Data.Set, Data.IntSet
> > Data.Sequence, Data.Tree
> > Data.HashTable
> > Data.Graph
> > ---> new package collections? containers?  or split further?
> >      (dep. on array, generics, concurrent)
> 
> Data.HashTable (and thus Data.Array.*) is used in the implementation
> of Data.Typeable.  It also differs from the others in being a mutable
> data structure.  I imagine that without it this package wouldn't need to
> depend on array and concurrent.

I hear that a lot - but as I see it, why does *Typeable* need to be in
base?  As long as we have a portable Unsafe.Coerce (exists now), and a
portable equivalent to GHC.Prim.Any (should be trivial to add to both
Hugs and YHC - names anyone?) Typeable/Dynamic can be a portable
high-level library. 

My cursory grepping of the '*.*hs' files in base reveals only one
non-deriving non-SYB use of Typeable/Dynamic/TypeRep: DynException. 
 
I suppose this highlights a major problem with the class/module
system.  If package A defines FooLike, and package B defines Foo, one
needs to depend on the other in order for instances to exist.
Assuming you don't want O(n^2) instance packages floating around.
Random other eample: QuickCheck (Arbitrary) depends on most data
types. 

Stefan