On Mon, Sep 17, 2007 at 06:43:40PM +0100, Adrian Hey wrote: > >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.*). > > I would consider it exceedingly poor design to produce a lib that > mentioned (Data.)Map in it's API, precisely because that pretty much > rules out the possibility of using any more efficient future map > implementations without an API change. > > Ideally the way to deal with this is via standardised interfaces (using > type classes with Haskell), not standardised implementations. Even this > level of standardisation is not a trivial clear cut design exercise. > e.g we currently have at least two competing class libs, Edison and the > collections package. Which one should become standard?
Data.Map is a standardized interface, *not* a standardized implementation. I'm not saying it's a *good* standardized interface, but it's the only one we've got. I would like to hope that the implementation could be improved without a change in interface. I agree that a type class interface would be better, and don't know what type class interface would be best. But until one of them is generally accepted, I'm not likely to learn to use either of them. -- David Roundy Department of Physics Oregon State University _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe