Lets sum up the discussion so far for adding (<$$>) ∷ Functor f ⇒ f α → (α → β) → f β (<$$>) = flip (<$>) to Data.Functor: +1 Bas van Dijk: + Adds symmetry to the existing API. + Useful for not breaking the sequential nature of do-expressions. + Likes that the name <$$> is consistent with <**>. - Doesn't like the name that much because its "undirectional". +1 Nicolas Puillard + Likes the consistent name. +1 Felipe Lessa + Has needed <$$> many times. + "<$$> will be as concise and useful as <$>, maybe even more, because `flip fmap` isn't valid." + Adds symmetry to the existing API. +1 Edward Kmett + Complexity budget is hardly breaked because the function is added to a single module. + "Explaining away its absence is harder than justifying its inclusion." -1 Johan Tibell: - Makes the library more complex. - Fears a trend of adding flipped variants for every operator. - More operators make user code harder to understand. - "(<**>) and (=<<) shouldn't have been added in the first place.... should we really add flipped versions of everything because these exists?" -1 Jesper Louis Andersen: - "Personally, I wouldn't add it". + "But it cannot hurt since only 0.1% of packages are affected". -1 Isaac Dupree: - Disagrees with the consistency argument. 0 Brent Yorhey: 0 (<**>) is NOT defined as flip (<*>)...(<**>) performs effects in the opposite order from flip (<*>). 0 I'm personally fairly neutral on the proposal ? Brian Brunswick ? Heinrich Apfelmus So +4 and -3 so far. I must say that Brent Yorheys comment about (<**>) not being flip (<*>) has made the 'symmetry' argument less convincing and has moved me a bit closer to the - camp. However, I'm still for adding it because it can make code nicer. It would help if some more people can give their +1s or -1s so we will have some bigger numbers. Thanks, Bas