select and selectSplit

Johannes Waldmann waldmann at
Fri Feb 15 06:44:21 EST 2008

Hash: SHA1

Chris Kuklewicz wrote:

> As mentioned in another reply, the select treats the source list like an
> unordered (perhaps multi) set.

See - the proposed function is in the "wrong" module;
it uses a concrete data type (List)
which normally represents an abstract Sequence type
but here some abstract data type (Bag) is intended.
(my "favourite Haskell code smell": list obsession :-)

Why then, are there so many of these functions?
My theory is - because "lists are there" (since LISP)
and there is (in Haskell) no agreement on those abstract types,
and in fact implementations (Data.Set) change rather frequently,
so programmers are hesitant to commit to them.

But of course we'd only need an agreement on interfaces,
then you'd not commit to one implementation. Again, Java did this right,
they have interfaces for Set, Map. They even treat List as interface.
Sure, they had fewer design choices as their type system has less freedom,
just some special form of one-parameter type classes.
But then, their syntax encourages the use of interface types -
they are as easy to write as a class type.

I'm not actually advocating to introduce more syntactic sugar
to Haskell (for existential types), I think proper (refactoring)
tool support would help a great deal already.

Best regards, Johannes.
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the Libraries mailing list