Competing packages for XML or DBM is really awful, unless they happen to be interface compatible. And there is a good way of switching imps at assembly time, such that lib code that consumes xml doesn't depend on which xml imp I have. Of course, I realize that a good interface for those is still an open topic. And bad standards really can be worse than no standard. So what it comes down to, is, how big a 'standard' library should a Haskell programmer expect?
On 9/17/07, David Roundy <[EMAIL PROTECTED]> wrote: > On Mon, Sep 17, 2007 at 11:07:10AM +0100, Adrian Hey wrote: > > Ketil Malde wrote: > > >What would the disadvantages be to replacing Data.Map with this > > >implementation? > > > > Personally I don't really like the idea of Data.Map, Data.Map.AVL or > > any other lib becoming entrenched as official or de-facto standards. > > It seems like a recipe for stagnation to me. IMHO such libs just > > shouldn't be bundled with ghc (or any other compiler) for this reason. > > To me, it seems like a recipe for usefulness. It would allow data > structures to be used in multiple libraries. Competing packages is fine > and dandy for something like an XML parser or DBM interface, but I'd like > data structures to be standard, so that other packages can use them in > their interfaces without putting undue burden on their users (and without > the users being forced to figure out how to convert back and forth between > various different Data.Map.*). > -- > David Roundy > Department of Physics > Oregon State University > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe