Polymorphism in the Prelude

16 Jun 2014

      Hi libraries,

Let me try to sum up the general sentiment I've seen:

Having lots of polymorphism in the Prelude is great, but for two problems:
  1) It's very confusing to novices.
  2) In the case of using Control.Category definitions: kind-polymorphism is not portable

I wish to ignore (2) for now, as it's a smaller concern given that it affects only a portion of the proposed changes.

As a way to mitigate (1), I have been thinking of proposing something almost exactly along the lines of http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/23719 (thanks for posting that link -- saved me from writing up the same thing!). But, after reading that thread, I tend to agree that tweaking the module system seems the wrong way to deal with helping novices.

In designing my own libraries, my general guideline is to make the easy thing easy and make the hard thing only slightly less easy. Spurred on by Erik Hesselink's comment (http://www.haskell.org/pipermail/libraries/2014-June/023174.html), what if we just have two versions of `base` modules, the "normal" one that exports more monomorphic definitions (which novices are more likely to use) and a "Poly" one that exports more polymorphic definitions. For example:

{{{
{-# LANGUAGE NoImplicitPrelude #-}

import Prelude.Poly
import Data.List.Poly
import Data.Foldable
import Control.Monad.Poly
}}}

and then it just works.

Pros:
- Not disruptive to current status quo.
- No change in error messages for novices.
- Can actually be implemented without *any* changes to `base` -- I could upload this solution to Hackage today.

Cons:
- Maintaining two copies of export lists.
- Needs NoImplicitPrelude pragma.
- Overhead of remembering which modules have a "Poly" version and which don't.
- Somewhat ugly.

Even as I write this, I'm not sure that this is at all a good idea. But, to me, it's really intriguing that the solution is achievable today, with no difficulty. I would wager that if these Poly modules were out in the wild today, we might all grumble at them, but I don't know if there would be a movement to change the Prelude.

Richard

Polymorphism in the Prelude

Richard Eisenberg