Re: Who needs Ord for Sets and Maps anyway?

Quoting Sebastian Sylvan :

...

A good "standard" class hierarchy for collections and several implementations is very much needed, IMO.

Yes, yes, and yes. I think the Java collections framework http://java.sun.com/docs/books/tutorial/collections/index.html is quite brilliant (regarding both the implementations and the interface design) and I wonder what keeps us from copying it as literally as possible. This is not a rhetorical question. They solve the problem of what comparison method to use for the elements by providing constructors that have a Comparator<E> object as argument. What's wrong with that? (Does it solve the problems that were discussed here recently?) I fear (or I hope) that the average well-trained Java programmer is way ahead of the average Haskell programmer when using data structures *and* hiding them behind interfaces. I've seen too many Haskell sources (including my own) that use concrete collection/map types (Data.List, Data.Map) all over the place where in fact interfaces (see Collection<E>, List<E> etc.) would be the right thing. In Haskell, we would need existential types to express that a function returns "an object of *some* type that implements the (hypothetical) Set interface". I guess the notational extra work for that is the main reason (at least for me) for wrongly preferring concrete datatypes over abstract types in Haskell. PS (I know this is heresy but - can we please in Haskell-0X rename "class" to "interface" so that the non-Haskell world knows what we're talking about. You know if the mountain's not gonna walk to the prophet, then ...) (note that I'm currently not proposing to rename "data" to "class". But looking at GADT data definitions still makes me wonder...) -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------