Unfortunately, in some cases, function application is just worse. For instance, when the result is a complex arithmetic expression:

    do x <- expr1; y <- expr2; z <- expr3; return $ x*y + y*z + z*x

In cases like this, you have pretty much no choice but to name intermediate variables, because the alternative is incomprehensible. But applicative notation:

    (\x y z -> x*y + y*z + z*x) <$> expr1 <*> expr2 <*> expr3

moves the variable bindings away from the expressions they're bound to, and we require extra parentheses to delimit things, and possibly more.

Desugaring the above do into applicative is comparable to use of plain let in scheme (monad do is let*, mdo was letrec). And sometimes, let is nice, even if it has an equivalent lambda form.

And as Jake mentioned, syntax isn't the only reason for Applicative. Otherwise it'd just be some alternate names for functions involving Monad.



On Wed, Oct 2, 2013 at 5:12 AM, <p.k.f.holzenspies@utwente.nl> wrote:

I thought the whole point of Applicative (at least, reading Connor’s paper) was to restore some function-application-style to the whole effects-thing, i.e. it was the very point *not* to resort to binds or do-notation.

 

That being said, I’m all for something that will promote the use of the name “pure” over “return”.

 

+1 for the Opt-In

 

Ph.

 

 

 

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Iavor Diatchki

 

do x1 <- e1

 

   -- The following part is `Applicative`

   (x2,x3) <- do x2 <- e2 x1

                 x3 <- e3

                 pure (x2,x3)

 

   f x1 x2 x3


_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users