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

[Mario Blažević]

On 15-10-02 04:50 PM, Bardur Arantsson wrote:
> On 10/02/2015 12:09 PM, Henrik Nilsson wrote:
>> Hi all,
>>
> [--snip--]
>> 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.

	Naming of applicative sub-expressions is perfectly doable without 
reaching for any syntactic sugar. An applicative do like

	do a <- f long expression
            b <- g long expression
            return (h a b)

would be equivalent to

         let a = f long expression
             b = g long expression
          in f <$> a <*> b

	The benefits of applicative do, if I understand the motivation 
correctly, are not so much to help in writing new code intended to be 
applicative. Instead it lets the programmer write in monadic style and 
at the same time enables the compiler to convert the code to applicative 
style if possible. This has the potential to automatically improve 
performance of legacy Haskell codebase, as well as any new 
beginner-friendly code that relies on syntactic sugar.

	As for the issue of textbooks, I assume they describe Haskell 98. Until 
Haskell compilers start defaulting to Haskell 2020 there shouldn't be 
any issue.