Who needs Ord for Sets and Maps anyway?

[Jean-Philippe Bernardy]

On 1/19/06, Johannes Waldmann <waldmann at imn.htwk-leipzig.de> wrote:
>
> > 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.

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.