Re: Who needs Ord for Sets and Maps anyway?

On 1/19/06, Johannes Waldmann wrote:

...

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.

A lot of things differ between haskell and java. The type system, the undelying paradigms are different. We can use the java collections as a source of inspiration, but merely copying is impractical.

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?)

What if we do the union of two Sets constructed with different comparators ?

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.

Haskell has a long tradition of using concrete lists. Breaking from that tradition involves quite a lot of problems. If you wish, I suggest to look at Robert Will's "Dessy", which implements something close to that.

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.

If I understand correctly, those are unrelated issues. We can parameterize over the collection type using the usual Haskell mechanisms (no need for subtyping).

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...)

Haskell is just different; if one can't get beyond lexical issues, there's IMHO no hope to make the paradigm shift needed to write good haskell. Cheers, JP.