Add flipped fmap

[wren ng thornton]

Bas van Dijk wrote:
> Hello,
> 
> I would like to propose adding a flipped variant of <$> to Data.Functor:
> 
> (<$$>) ∷ Functor f ⇒ f α → (α → β) → f β
> (<$$>) = flip (<$>)
> 
> Please see the ticket for motivation and patch:
> 
> http://hackage.haskell.org/trac/ghc/ticket/3962


I'm also not in favor.

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.

There is good reason for having (<$>) as an alternative to fmap:
* It also serves to support the applicative style by giving a name for 
functorial application.

There is good reason to have (<*>):
* It supports the use of (<$>) for multi-argument functions.


But I don't see much benefit to having (<**>) let alone (<$$>), when 
they are easily defined by using flip. The other clutter of Applicative 
((<*), (*>),...) can be motivated by performance concerns for certain 
applicative combinator parsers, but I'm not a big fan of them either.

(<$$>) offers no performance benefit, does not offer a definition for a 
perspicuous type[1], and does not seem to offer significant improvement 
in code legibility which could not be obtained from a local definition.

-- 
Live well,
~wren


[1] For example,

* (=<<) is perspicuous because it names Kleisli application. Given a 
prefix name like 'star' it would also be perspicuous for point-free 
style where it serves as the superscript star operator used in category 
theory. Having both (=<<) and 'star' could even be justified for similar 
reasons to having both 'fmap' and (<$>): supporting both applicative and 
pointless styles.

* forM_ is perspicuous because it captures an intuitive notion of 
imperative style, even though mapM_ captures an applicative version of a 
similar notion.

* (flip lookup) would be perspicuous for the same reasons as (=<<): it 
supports the idea of transforming an assoc-list into the function that 
list represents. Similar variations on this theme apply to indexing 
functions for Data.Map where the (Map a b -> (a->b)) ordering supports 
the idea of transforming the map into its associated function.

* (curry . (flip (uncurry foldr))), (curry . (flip (uncurry either))), 
and (curry . (flip (uncurry maybe))) would be perspicuous for capturing 
the transformation of concrete types into their Church encodings.