Maciej Marcin Piechotka wrote:
The "a <$> b <$> c <$> d" was done to show the relation between $/. and <$>/<.>.
Yes, but (.) _is_ (<$>) for (a->). Therefore, trying to make (.) and ($) opposing conceptions and then extending it to (<.>) and (<$>) doesn't necessarily make sense. Personally, I think being explicit about the use of fmap here makes code a lot clearer overall. One prime example has already been raised where it makes it clear that (fmap f . fmap g . h) should be written (fmap(f . g) . h) instead. This isn't a case like (<=<) or (<<<) where we are actually generalizing composition in Hask to composition in another category. I'm not a big fan of making a composition operator that crosses between categories; it just doesn't feel like a clean abstraction. The notation of (<$>) for fmap is a clean abstraction in the context of Applicative because it vs (<*>) captures the semantic differences between the spaces in (f x y). Outside of the applicative setting, use of (<$>) instead of fmap tends to obfuscate code rather than improve legibility, IMO. -- Live well, ~wren