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

[Manuel Gómez]

On Fri, Oct 2, 2015 at 8:31 PM, Henrik Nilsson
<Henrik.Nilsson at nottingham.ac.uk> wrote:
> Further, it is also worth noting that by almost any
> measure C++ is an extremely successful language despite
> its warts.

Ah, success at the cost of warts.  I see our priorities as a community
have changed.

> Anyway, a discussion about the pros and cons of
> applicative do entitrely tangential to the point being
> made. The point is that applicative do is not yet part
> of any Haskell standard, and at this point it is not
> clear what any future syntactic support for applicative
> code will look like exactly. Therefore is premature to
> use this as an argument for this particular proposal,
> making any such an argument a weak one. Removal of
> "return" as a method of Monad can clearly wait until
> such time that syntactic support for applicative code
> makes it into the language, if it then is found that
> that support, whatever it looks like, would be
> unworkable without this change.
>
> …
>
> Bottom line: Breaking changes should only be adopted
> for very compelling reasons. The reasons put forward
> for far for "monad of no return" fails to meet that
> standard. Therefore it should not be adopted, at least
> not at this time.

`return` should have never been a part of the `Monad` type class.  It
does not belong there any more than `fail` does.  We could discuss (in
a separate thread) whether `pure` should be named `return`.  We could
likewise discuss whether it should be in some separate class like the
often-suggested `Point` with whatever name.  We could likewise discuss
where that class should lie in the hierarchy.

In a post-AMP Haskell, however, retaining `return` in `Monad` does not
serve any purpose: any `Monad` instance requires an `Applicative`
instance, wherein `pure` must be defined, and it is a law required by
all instances that they behave identically.  The only expressive
purpose of `return` being in the `Monad` type class is providing an
opportunity to break the laws the community expects for all instances
of `Monad`.

This community rightly values statically eliminating opportunities for
errors, and the removal of `return` as a method of `Monad` serves this
purpose.  This is reason alone to implement this proposal, even in the
absence of `ApplicativeDo`.