Robert Will wrote:
I've already preferred DData over Edison http://www.haskell.org/ghc/docs/edison/ also because DData is Haskell 98 compliant (without glasgow extensions), thus "portable" (in terms of the haddock documentation of the library). Viewing maps as collections of pairs indeed suggests to change some names (like member and filter) and some types, i.e. using a pair as input instead of curried arguments. (i.e. "member" could become "isDefined" when maps are viewed as finite functions.) I would not mind, if a collection class/interface is provided on top of the given DData modules/types (that one may or may not use) using glasgow extensions. And I would also not mind if there are other bag, set and map implementations (i.e. based on common tree implementation), so that a simple change of the import gives you a different performance behaviour (i.e. modules {Bag, Set, Map}{ByOrderedSeq,ByBalancedTree}.hs) However the (non-portable) instances for a big collection class should be in separate modules. Christian