You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Associativity is about 3 variables being composed twice where order of binary operation is not important e.g. a*(b*c) = (a*b)*c
Here we see only two variables in the discussion:
Page 98:
“Associativity: flatMapping over two functions f and g is the same as flatMapping over f and then flatMapping over g:
Had we used FP syntax Monad[_].flatMap(f) instead (with no m), we would see more explicitly and naturally three identifiers f, g, and h (not sure of final correct wording) operating twice on operator flatMap. Algebraic laws in the math world have no concern for the OO syntax, which is a programming construct, hence I think it's more natural to introduce 3 identifiers f, g, and h here instead of m, f, and g.
Perhaps it would make sense to state this law using the two distinct notations?
The text was updated successfully, but these errors were encountered:
Associativity is about 3 variables being composed twice where order of binary operation is not important e.g.
a*(b*c) = (a*b)*c
Here we see only two variables in the discussion:
Page 98:
“Associativity: flatMapping over two functions f and g is the same as flatMapping over f and then flatMapping over g:
Had we used FP syntax
Monad[_].flatMap(f)
instead (with nom
), we would see more explicitly and naturally three identifiersf
,g
, andh
(not sure of final correct wording) operating twice on operatorflatMap
. Algebraic laws in the math world have no concern for the OO syntax, which is a programming construct, hence I think it's more natural to introduce 3 identifiersf
,g
, andh
here instead ofm
,f
, andg
.Perhaps it would make sense to state this law using the two distinct notations?
The text was updated successfully, but these errors were encountered: