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

[Bardur Arantsson]

On 10/02/2015 12:09 PM, Henrik Nilsson wrote:
> Hi all,
> 
[--snip--]
> Another reason put forward is support for the
> applicative do syntax. But that is, in standard terms,
> only a future possibility at this point. Further, the
> syntax is arguably rather dubious anyway as it, in
> particular to someone with an imperative background,
> suggests a sequential reading which is exactly what
> applicative is not and why it is useful. So from that
> perspective, using the applicative operators directly,
> without any syntactic sugar, actually amounts to a much
> more transparent and honest syntax, even if a bit more
> verbose in some cases.

"Verbose" is the understatement of the year. There's a lot of code where
ApplicativeDo makes the difference between "readable" and "unreadable".
Like it or not, but programmers are used to *naming things* (even
locally) and using those local names to refer to things.
"Random" combinations of <$> and/or <*> and/or... (whatever) with no
concrete meaningful names don't really work if you're working with
concrete CRUD-like data. (Fine, if you're working with very abstract
things then you might not even have meaningful names and so they lose
their value. This is *not* the universal experience.)

I should also say: I certainly *understand* the textbook argument, but
if we're going that way, then we're going to end up like C++... before
C++11/C++14. The C++ community/committee have realised their mistake
(stagnatiation) and resolved to instead produce more/better/newer
textbooks. For the better, IMO. We can certainly argue over individual
changes, but this is not a good *general* argument against change. Have
you surveyed the actual number of books out there which show how to
implement Monad instances and how many of them would be affected?

Regards,