The part of the MRP proposal that I actively care about because it fixes a situation that actually causes harm is moving (>>) to the top level.

Why?

Right now (*>) and (>>) have different default definitions. This means that code runs often with different asymptotics depending on which one you pick. Folks often define one but not the other.

This means that the performance of mapM_ and traverse_ needlessly differ. It means that we can't simply weaken the type constraint on mapM_ and sequence_ to Applicative, it as a knock-on consequence it means we can't migrate mapM and sequence out of Traversable to top level definitions and thereby simply provide folks with more efficient parallelizable mapping when they reach for the 'obvious tool'.

return itself lurking in the class doesn't matter to me all that much as it doesn't break anybody's asymptotics and it already has a sensible definition in terms of pure as a default, so effectively you can write code as if MRP was already in effect today. It is a wart, but one that could be burned off on however long a time table we want if we choose to proceed.

-Edward

On Wed, Oct 7, 2015 at 5:13 PM, Mark Lentczner <mark.lentczner@gmail.com> wrote:

On Wed, Oct 7, 2015 at 9:38 AM, Erik Hesselink <hesselink@gmail.com> wrote:
While I don't think it detracts from your argument, it seems you
misread the original proposal. At no point will it remove `return`
completely. It would be moved out of the `Monad` class and be made
into a top-level definition instead, so you would still be able to use
it.

Then why bother?
If you don't intend to regard code that uses "return" as old, out-dated, in need of updating, etc....
If you don't intend to correct people on #haskell to use pure instead of return...
If you don't tsk tsk all mentions of it in books.... 
If you don't intend to actually deprecate it.
Why bother?

But seriously, why do you think that "you would still be able to use it"? That is true for only the simplest of code - and untrue for anyone who has a library that defines a Monad - or anyone who has a library that they want to keep "up to date". Do you really want to have a library where all your "how to use this" code has return in the examples? Shouldn't now be pure? Do I now need -XCPP just for Haddock? and my wiki page? And what gets shown in Hackage? This is just a nightmare for a huge number of libraries, and especially many commonly used ones.

Why bother!


_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries