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

[Manuel Gómez]

On Fri, Sep 25, 2015 at 7:56 PM, David Feuer <david.feuer at gmail.com> wrote:
> I think they're both wretched. return makes beginners think it's a control
> structure; pure just seems meaningless (I guess that's a slight improvement,
> arguably). I'd have gone for something like inject myself, but there's no
> way that's happening.

Just my $0.02:

I wouldn't say `pure` is meaningless.  It takes a value and turns it
into a computation in the relevant computational context that performs
no effects apart from yielding the given value.  Computations whose
only effect is yielding a single value are typically said to be pure
computations in the Haskell community.  It's a really nice name.

`return`, on the other hand, is tremendously misleading for imperative
programmers who won't understand why in the world anything after it
isn't dead code.  It'd be a reasonable name for a continuation monad
action that actually did something akin to what it does in the
contexts whence the name was borrowed, but even that would be
inaccurate since not even in the context of a continuation monad is
there a notion of "the current procedure".  In any case, `return`
evokes the imperative intuition in learners that should be trying
desperately to avoid the imperative intuition in order to understand
Haskell's use of the word "function", especially since the Haskell
community does also use the word "return" to talk about the value
produced by a function when applied to an argument.

I see no pedagogical value in `return`, and I've had better results
teaching Haskell when I avoid mentioning it at all.  Not a single
Haskell monad can be described clearly and accurately using the
traditional vocabulary of imperative programming; not even IO.