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

[Ben Gamari]

Herbert Valerio Riedel <hvr at gnu.org> writes:

> Hello *,
>
> Concluding AMP and MFP, We (David and I) proudly present you the final
> installment of the Monad trilogy:
>
> Monad of no `return` Proposal
> =============================
>
> TLDR: To complete the AMP, turn `Monad(return)` method into a
>       top-level binding aliasing `Applicative(pure)`.
>
+1

With a sufficiently long timeframe for adoption (with removal no earlier
than 8.4) it seems like the immediate cost of this change shouldn't be
so onerous; if we managed AMP then we should be able to pull this off as
well. It seems to be the right thing to do and I sincerely believe we
can keep the cost to users low; let's do it.

I find this especially true in light of the recent advances made in the
area of tooling. We are now in a much better position to be offering
tools for automated refactoring than we were even when we considered
AMP. Perhaps one of the HaRe contributors can comment on the feasibility
of automatically rewriting `return` definitions to `pure` definitions?
It feels like this should be quite workable in most cases.

It also helps that we have the luxury of being able to pick this change up
at a relaxed pace. For a long time, we as a community have lamented the
lack of tools (both language features and otherwise) for restructuring
typeclass hierarchies (e.g. see #4879, #2119, #10071). Since we now have
the experience of AMP under our collective belts, it seems like we are
in a much better position to put forward some concrete proposals for
easing this sort of interface refactoring and deprecation.

The `DEPRECATED`/`REMOVED` pragmas on class methods would be a great
step towards this end. With a bit of work we could greatly reduce the
impact of changes like these; an improvement that could bring benefits
well beyond the core libraries. Those interested in contributing in this
area should see the Wiki [1].

With respect to invalidating teaching materials, I think this ship has
already sailed with AMP and `MonadFail`, as Herbert has pointed out.
Nevertheless we can help their users evolve along with the language with
deprecation mechanisms, tools, and approachable error messages.

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/Design/DeprecationMechanisms
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151004/03bfbbd6/attachment.sig>