Why is Haskell missing "obvious" Typeclasses

Solution 1:

As other answers have pointed out, Haskell tends to use different vocabulary. However, I don't think they've explained the reason for the difference very well.

In a language like Java, functions are not "first class citizens"; it's true that anonymous functions are available in the latest versions, but this style of interface (Collection, Indexable, Interable, etc.) were designed before that.

This makes it tedious to pass our code around, so we prefer other people's data to be passed to our code. For example:

• Data implementing Java's Iterable lets us write for (Foo x : anIterable) { ... }
• Data implementing PHP's ArrayAccess lets us write anArrayAccess[anIndex]

This style can also be seen in OO languages which implement generators, since that's another way for us to write for yieldedElement in aGenerator: ....

Haskell takes a different approach with its typeclasses: we prefer our code to be passed to other people's data. Some (simplified) examples:

• Functors accept our code and apply it to any elements they 'contain'
• Monads accept our code and apply it in some kind of 'sequence'
• Foldables accept our code and use it to 'reduce' their contents

Java only needs Iterable since we have to call our code in our for loop, so we can make sure it's called correctly. Haskell requires more specific typeclasses since someone else's code will be calling ours, so we need to specify how it should be called; is it a map, a fold, an unfold, etc.?

Thankfully, the type system helps us choose the right method ;)

Solution 2:

The lens package provides some of this.

• Testing for emptiness, creating empty containers These are both provided by the AsEmpty typeclass from Control.Lens.Empty.

• Accessing elements by key/index. The At and Ixed typeclasses from Control.Lens.At.

• Checking for membership in set-like containers. The Contains typeclass from Control.Lens.At.

• Appending and deleting elements to sequence-like containers. The Cons and Snoc typeclasses from Control.Lens.Cons.

Also, the pure method of the Applicative typeclass can often be used to create "singleton" containers. For things that are not functors/applicatives in Haskell, like Set, perhaps point from Data.Pointed could be used.

Solution 3:

Haskell has some type classes for working with collections in the base package: Functor, Foldable and Traversable can be useful for working with collections, and the Monoid, Applicative and/or Alternative typeclasses can be useful for constructing collections.

Together, these classes cover most of the operations mentioned in the question, but maybe less efficient than a more container-specific function (though many of these are class methods, whose default definitions can be overriden if necessary).

null for testing "emptyness"

Foldable supports null since base 4.8 (any (const True) is an alternative for earlier versions).

length/size for element count:

Foldable supports length since base 4.8 (getSum . foldMap (const 1) is an alternative for earlier versions).

elem/member for set inclusion

Foldable supports elem, notElem and member.

empty and/or singleton for default construction

For empty, there is mempty from Monoid and empty from Alternative. For singleton, there is pure from Applicative.

union for set union

There is mappend from Monoid and <|> from Alternative. They don't necessarily implement set union, but they implement some form of union that works well together with empty and usually also with singleton and find.

(\)/diff for set difference

This one is not supported, unfortunately.

(!)/(!!) for unsafe indexing (partial function)

You could use fromJust together with a function for safe indexing.

(!?)/lookup for safe indexing (total function)

There is find from Foldable.

Solution 4:

Partly, the reason is that monads and arrows are new, innovative features of Haskell, while collections are relatively more mundane. Haskell has a long history as a research language; interesting research questions (designing monad instances & defining generic operations for monads) get more development effort than "industrial-strength" polishing (defining container APIs).

Partly, the reason is that those types come from three different packages (base, containers, and vector), with three separate histories and designers. That makes it harder for their designers to coordinate on providing instances of any single type class.

Partly, the reason is that defining a single type class to cover all five of the containers you mentioned is really hard. List, Sequence, and Vector are relatively similar, but Map and Set have completely different constraints. For List, Sequence, and Vector, you want a simple constructor class, but for Set that won't work, since Set requires an Ord instance on the element type. Even worse, Map can support most of your methods, but its singleton function needs two parameters where the rest need only one.