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

[Bardur Arantsson]

On 10/02/2015 11:55 PM, Mario Blažević wrote:
> 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.
> 

... if you already know how to do that. That's the point.

Regards,