
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