Polymorphism in the Prelude

[Edward Kmett]

Having attempted to program with NoImplicitPrelude "in anger", I personally think this fix is worse than the disease and I'm personally -1.

In some sense, the current path we're taking forward is actually substantially similar except the non-generalized versions are just the haskell2010 and haskell98 packages, which work well for the kind of trivial classroom exercises needed for the first semester worth of coursework, but desire to work with the rest of the library ecosystem provides gentle pressure to encourage people to learn the rest.

The difference is the vast majority of users aren't constantly plagued by the demand they use extensions to get what should really be baseline tools.

In the long term, yes we might want to embrace Category and other abstractions. The main issue I have is that it is very hard to motivate through Prelude in that there is only one Prelude type anyone can point to that is an instance.

-Edward

> On Jun 16, 2014, at 9:46 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> 
> 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
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140616/c9467335/attachment.html>