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