Who needs Ord for Sets and Maps anyway?

[Johannes Waldmann]

> Quoting Sebastian Sylvan <sebastian.sylvan at gmail.com>:
> 
>> 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/ -------