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