Herbert Valerio Riedel
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