fmap
is also <$>
because it is function application ($
) in the functor category.
(+5) $ (*10) $ 10 -- 105
(+5) <$> (*10) <$> [1,2,3] -- [15,25,35]
Then I thought, well in that case <*>
is function application in the applicative functor category, and this should work:
[(+5), (+10)] <*> [(*10), (*100)] <*> [1,2,3] -- ERROR
-- however:
[(+5), (+10)] <*> ([(*10), (*100)] <*> [1,2,3]) -- [15,25,35,...]
So, <$>
only works out because fmap
for functions happens to be postcomposition, so (+5) <$> (*10)
becomes (+5) . (*10)
which is then applied to [1,2,3]
.
However left associativity for all the application operators (<<=
included) seems to me like a poor design choice, especially after they recognized the similarity to $
which is already right-associative. Is there another reason for this?
Really, the reason is probably just that it allows <$>
and <*>
to share one precedence level. We definitely want <*>
to be left-associative so stuff like
Prelude> foldr <$> [(+),(*)] <*> [0,1] <*> [[1,2,3], [4,5,6]]
[6,15,7,16,0,0,6,120]
works, and this also makes <$>
behave the correct way even though it doesn't have higher precedence. Actually chaining multiple <$>
operators is indeed not very useful with left-associativity.
However, it would also not be very useful with right-associativity. As chepner commented, it's actually a bit funny that $
is right-associative. Sure, that allows writing compositions like
Prelude> sum $ map (+3) $ take 19 $ cycle [4..7]
160
but then, this could just as well be written as the arguably more elegant
Prelude> sum . map (+3) . take 19 . cycle $ [4..7]
160
(more elegant I say, because here the computation-chain is parsed as a single functional pipeline, rather than imperative-style “do this, then that, then...”). Thanks to the functor laws, this can be done just the same way with <$>
and .
as with $
and .
.
The only reason why you might prefer the multiple-$
style is that it allows infix expressions in the pipeline, perhaps the most common example being lens updates (which are typically written with the flipped &
, but the principle is the same):
Prelude Control.Lens> [4..7] & ix 1+~9 & ix 2*~8
[4,14,48,7]
This works because $
and &
have very low precedence, pretty much lower than any infix operator. That's not the case for <$>
so you can't do
Prelude Control.Lens> ix 1+~9 <$> [[4..8], [5..9]]
<interactive>:23:1: error:
Precedence parsing error
cannot mix ‘+~’ [infixr 4] and ‘<$>’ [infixl 4] in the same infix expression
In such a case, you need to use some parentheses anyway, and then you might as well do it with the also low-precedence composition operators from Control.Category
:
Prelude Control.Lens Control.Category> (ix 1+~9 >>> ix 2*~8) <$> [[4..8], [5..9]]
[[4,14,48,7,8],[5,15,56,8,9]]
or with parens around each updater:
Prelude Control.Lens> (ix 1+~9) . (ix 2*~8) <$> [[4..8], [5..9]]
[[4,14,48,7,8],[5,15,56,8,9]]
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With