Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

[Henning Thielemann]

On Thu, 24 Sep 2015, Herbert Valerio Riedel wrote:

> Consequently, the `Monad` class is left with a now redundant `return`
> method as a historic artifact, as there's no compelling reason to
> have `pure` and `return` implemented differently.
>
> Traditionally, `return` is often used where `pure` would suffice
> today, forcing a `Monad` constraint even if a weaker `Applicative`
> would have sufficed.

I do not see why this proposal is necessary and urgent. Over the past 
years several redundant methods where added to type classes in order to 
allow for optimized implementations. Without much investigation I remember 
Foldable.sum, Foldable.product, ..., Applicative.*>, Applicative.<*, 
Functor.<$, Bits.zeroBits and discussions about Monad.join. Although I 
think that it is never possible to implement 'return' more efficiently 
than 'pure', we could pretend for now that it is possible. :-) At least, 
leaving 'return' does not hurt much.

My practical concern is that the change will break every current Monad 
instance for no benefit and I would not be able to write code that works 
for current and past GHC versions.


> As a result, language extensions like `ApplicativeDo`[3] have to
> rewrite `return` to weaken its `Monad m =>` constraint to
> `Applicative m =>` in order to benefit existing code at the cost
> of introducing magic behavior at the type level.

Like Henrik Nilsson, I wonder why people cannot replace 'return' by 'pure' 
if they want to make use of ApplicativeDo. I think the people who want a 
new feature should adapt their code. Why should I break my Monad instances 
instead?


> Consequently, it is possible to write forward-compatible instances
> that are valid under this proposal starting with GHC 7.10/`base-4.8`.

Because the completely unrelated bug [1] affects several of my packages, I 
can use forward-compatible instances only starting with GHC-8.0.

Bugs like this one also underline why it is so important to write code 
that works across multiple versions of GHC. Otherwise it's easily possible 
that a program depends on a set of packages that cannot be compiled by any 
GHC version.

If you are very keen to remove 'return' I would ask you to wait some more 
release cycles of GHC.


[1] https://ghc.haskell.org/trac/ghc/ticket/10009