On 18 Jun 2014, at 12:09, Yitzchak Gale
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