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

Richard Eisenberg eir at
Mon Sep 28 01:56:27 UTC 2015

On Sep 27, 2015, at 6:22 PM, David Luposchainsky <dluposchainsky at> wrote:

> On 28.09.2015 00:16, David Feuer wrote:
>> For the benefit of people trying out code from papers, tutorials, etc., would it
>> be possible to craft a permanent custom error message for explicit return
>> definitions? I don't remember AMP having such for the new constraint; if it
>> doesn't, maybe it should.
> Sure, that's something we can probably do. I've done some (futile) digging in
> GHC, but the plan is to implement this as a "if a Monad definition contains a
> binding referring to 'return' emit a warning", which is or can be made orthogonal
> of there actually being a "return" in the actual class.

I like this idea -- I, for one, often forget to consider the effect legacy written material has. But if we're doing this for Monad, why not just come up with a pragma so that the magic doesn't have to be baked in? As in, witness the new definition for Monad:

> class Applicative m => Monad m where
>   ...
>   {-# REMOVED return "The `return` method has been removed from Monad. Use `pure` in Applicative instead" #-}

(Please fix my warning text.)

We people with direct access to GHC might not be the only ones who want to refactor a method out from a class.


> _______________________________________________
> Libraries mailing list
> Libraries at

More information about the Libraries mailing list