Polymorphism in the Prelude

[Daniel Gorín]

On 18 Jun 2014, at 12:09, Yitzchak Gale <gale at sefer.org> wrote:

> Richard Eisenberg wrote:
>> 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.
> 
> In my opinion, Richard missed the most important reason:
> 
> 3) Gratuitous polymorphism makes code much less readable
>  and much costlier to maintain, usually for almost no gain.

The crucial problem for me would be:

4) Instance-based APIs are currently very difficult to  discover.

Just to name a few examples of useful but hidden functions:

- looking at the Haddock for Data.Maybe, it is very hard to find:
    forM :: Monad m => Maybe a -> (a -> m b) -> m (Maybe b)

- looking at the Haddock for Data.Either, it is *impossible* to discover:
    (+++) :: (a -> a') -> (b -> b') -> Either a b -> Either a’ b’

- looking at the Haddock for Data.Tuple, it is *impossible* to discover:
   (***) :: (a -> a’) -> (b -> b’) -> (a,b) -> (a’,b’)

- looking at the Haddock for Data.Map , it is hard to spot:
   sequenceA_ :: Applicative f => Map a (f b) -> f ()

It helps if one knows in advance what Foldable, Traversable or Arrow are, but it is
easier to  understand a generalization if you were first exposed to concrete cases.
So whenever we replace a concrete function by a typeclass-based generalization,
we hurt the available documentation and make the learning curve even steeper.

This is perhaps “just” a tooling problem that could be solved by haddock in some
way, but until then it is my main concern with these proposals.

Daniel