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:
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.