Hello GHC, Friday, July 6, 2007, 10:04:05 PM, you wrote:
#1338: base package breakup Not clear what to do with these: 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)
package named Collections already exists. one possible way of splitting these modules would be separation of Control.Applicative, Data.Foldable, Data.Traversable while changing names of established modules and adding new hierarchy roots aren't good ideas, may be it will better to rename them to Class.* or even Concept.*? Monads, Data/Typeable, i/o Streams and other classes may be moved to the same place. the intention is to split packages to those defining concepts (classes) and whose implementing them, with multiple packages that implements these concepts
Data.Array.* --> new package array (maybe; I'm slightly dubious here) (dep. on concurrent for Data.Array.Diff)
definitely!
Needs the above to happen first: Data.Generics.* --> generics (maybe; Data class is defined for everything and is derivable)
how about using standalone deriving in this package? derive Data for Int, Handle....
Needs Data.Array.Diff to move out of base first: Control.Concurrent.*, System.Timeout --> new package concurrent
how about renaming System.Timeout to Control.Concurrent.Timeout ?
Needs concurrent to be done first: Data.Unique --> new package unique (dep on concurrent)
may be it's better to consider it as one more multi-threading service and move it into concurrent package? separate package for 60 lines-long module doesn't seem like a good approach
Will happen soon: Data.ByteString.* --> bytestring (dep. on base, generics, array)
Other modules we might move: Text.Printf, Data.Monoid, System.CPUTime
afaiu, Data.Monoid should go together with Foldable and so on? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com