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

[Julian Bean]

On 19 Oct 2015, at 20:52, Henning Thielemann <lemming at henning-thielemann.de> wrote:
> I see the benefit of ApplicativeDo in the short distance of the value producer and the value naming. E.g. compare
> 
> liftA3
>   (\x y z -> complicatedFunc x y z)
>   produceX produceY produceZ
> 
> and
> 
> do x <- produceX
>   y <- produceY
>   z <- produceZ
>   pure $ complicatedFunc x y z


Agreed. Furthermore I quite like the way applicative comprehensions read:

[complicatedFunc x y z | x <- produceX, y <- produceY, z <- produceZ ]

Also, what this example doesn’t show is that sometimes complicatedFunc is actually a complicated *expression* which merely mentions x,y,z each 1 or more times:

[ . . . some long code mentioning x . . .
  . . . and y and x again and now z . . .
  | x <- produceX,
    y <- produceY, 
    z <- produceZ
 ]

As Henning says the tradeoffs here are all to do with drawing the eye correctly between the use of x,y,z and the binding of x y x.

There is also the fact that x y and z may not ‘naturally’ occur in the right order - the ordering of effects in the producers can easily be significant.

Jules