Re: Add flipped fmap

Bas van Dijk wrote:

On Thu, Apr 8, 2010 at 11:21 PM, wren ng thornton wrote:

...

There is good motivation for having both of (>>=) and (=<<): * the (=<<) variant provides an applicative style by giving a name for Kleisli application. * and the (>>=) variant provides an imperative style for those who like that sort of thing.

Applying the same reasoning to <$> and <$$>:

* <$> serves to support the applicative style by giving a name for functorial application. (as you mentioned) * <$$> provides an imperative style for those who like that sort of thing. As in:

do m1 m2 m3 <$$> bigPieceOfCodeThat whenUsingFlipFmap willVisuallyBreak theImperativeNature ofADoExpression

That is more of a conflation of applicative and imperative styles. The style of imperative languages generally prefers: do m1 m2 x <- m3 bigUglyBlah x Frequently further breaking up the big expression and using more temporaries. The reason (>>=) supports imperative style is *not* because we can say, do m1 m2 m3 >>= f The reason (>>=) supports imperative style is *exactly* because we can say m1 >>= \_ -> m2 >>= \_ -> m3 >>= \x -> bigUglyBlah x This old habit of aligning the binds is what lead prople to thinking of monads as capturing "semicolon overloading", from whence the do-notation originates. There has been no similar argument that (<$$>) captures any intuitive notion from the imperative style. Similarly, forM_ captures the intuitive imperative notion of for-loops *not* because it happens to take arguments in reverse order, but because the order of arguments is expressly similar to the for-loop notation used in imperative languages. Imperative style is not about the order of things, it is about a mindset with which we think about the structure of programs. The same goes for applicative style, points-free style, and object-oriented style. -- Live well, ~wren