With parsers, for example, it amounts to you have a context-free vs. a context-sensitive language. The functions hidden behind a monadic bind are effectively opaque to any sort of analysis, whereas the static structure of an applicative can be analyzed as much as you want. Ed Kmett does this in his trifecta parsing library (I think there's a couple of other libraries that also do this), but you have to use the applicative interface explicitly where possible to take advantage of the additional optimizations.

This would also have benefits for other sorts of EDSLs, for the same reason. An applicative computation might for example be sparked and processed in parallel, whereas it's a lot harder (impossible) to do that if your structure isn't determined beforehand.


On Sun, Sep 4, 2011 at 12:24 AM, Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com> wrote:
On 4 September 2011 12:34, Daniel Peebles <pumpkingod@gmail.com> wrote:
> Hi all,
> For example, if I write in a do block:
> x <- action1
> y <- action2
> z <- action3
> return (f x y z)
> that doesn't require any of the context-sensitivty that Monads give you, and
> could be processed a lot more efficiently by a clever Applicative instance
> (a parser, for instance).

What advantage is there in using Applicative rather than Monad for
this?  Does it _really_ lead to an efficiency increase?

--
Ivan Lazar Miljenovic
Ivan.Miljenovic@gmail.com
IvanMiljenovic.wordpress.com