Why don't the Haskell standard libraries make more use of polymorphism?

29
votes

I'm in the process of learning Haskell, and type classes seem like a powerful way to make type-safe polymorphic functions. But a lot of the Haskell Prelude functions don't use them. More specifically:

  • Most of the list functions don't work with other data structures (for instance, foldr and length are only implemented for lists and can't be used on arrays).

  • Modules like Data.ByteString are unusable unless you use import qualified since they include functions that have the same names as Prelude functions.

It seems like both of these problems would go away if the standard library used generic functions with type classes (please let me know if I'm totally off base with this).

I have two questions:

  1. Are there technical or design reasons that the Prelude is like this, or is it just for historical reasons?

  2. Looking around, it looks like there are a couple of libraries (like Data.Foldable and, if I'm not mistaken, Scrap Your Boilerplate) that replace the standard Prelude functions with generic alternatives. Are there any plans to incorporate these ideas into future versions of Haskell?

4
haskellpolymorphismgeneric-programming
No idea but there are plenty of things that you could do before this like making the Monad class depend on Appliciative. And using 'pure' or 'unit' instead of 'return'. Getting rid of 'map' and only ever use 'fmap' would be an option too but I just do not think that it will happen. Too many things would break if they did. – Robert Massaioli
I think it would be time for more polymorphism, for some corrections in type classes (like the Monad / Applicative fix mentioned by Robert) and for making some compiler extensions standard. You can get only so far with evolution. It would be important for the language to make a clear cut and fix most of gaps and errors of the past. I think the transition doesn't have to be a shock therapy but can be made reasonable smooth (see e.g. Python 2 to 3) – Landei

4 Answers

19
votes

There is a very good pragmatic reason that "standard" Haskell (Prelude + base + maybe some more) doesn't use more polymorphism:

Designing general-use type classes is hard. Good designs for classes that abstract over container types like lists, arrays and "bytestrings" (personally I don't really consider Bytestring a container) aren't floating round waiting to be included in Haskell 2012. There are some designs e.g Listlike and the Edison classes, and a number of people have chipped away at the problem but excepting Foldable and Traversable no-one has produced any compelling designs.

11
votes

The Haskell base library used to be more polymorphic - list comprehensions used to work for any monad, map and ++ weren't limited to List, and perhaps other things.

But folks at the time thought that it led to confusing error messages for beginners and that folks who aren't beginners can use the specifically polymorphic versions.

8
votes

  1. While there are many things in base, and specifically Prelude, that are historic I think any generalization would see plenty of technical push-back. The main issue is speed - if you're function has a type class constraint then you're going to be passing around a dictionary for the type class functions and maybe eating more space for specialization.

  2. Some of the libraries, such as SYB, use extensions that aren't part of Haskell. The first task would be to formalize and build support for these features. Look at the Haskell' documents to see where Haskell is going and how you might be able to influence that path.

6
votes

Real World Haskell has some insights about this in the Monad Transformers chapter:

In an ideal world, would we make a break from the past, and switch over Prelude to use Traversable and Foldable types? Probably not. Learning Haskell is already a stimulating enough adventure for newcomers. The Foldable and Traversable abstractions are easy to pick up when we already understand functors and monads, but they would put early learners on too pure a diet of abstraction. For teaching the language, it's good that map operates on lists, not on functors.