Add flipped fmap

[wren ng thornton]

Bas van Dijk wrote:
> On Thu, Apr 8, 2010 at 11:21 PM, wren ng thornton
> <wren at community.haskell.org> 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