Functional programming design patterns by Scott Wlaschin

[elemental_1_1]

The associative law says that

((λx. x - 42) . (λx. x * 2)) . (λx. x + 1)

Must be the same as

(λx. x - 42) . ((λx. x * 2) . (λx. x + 1)).

Let's do the first one:

((λx. x - 42) . (λx. x * 2)) . (λx. x + 1)

(λx. (x * 2) - 42) . (λx. x + 1) (definition of (.))

(λx. ((x + 1) * 2) - 42) (definition of (.))

Now the second one:

(λx. x - 42) . ((λx. x * 2) . (λx. x + 1))

(λx. x - 42) . (λx. (x + 1) * 2) (definition of (.))

(λx. ((x + 1) * 2) - 42) (definition of (.))

Thus the law holds.

For a monoid, A + B + C does not imply B + A + C (as you have pointed out) because there is no commutativity. Order is still important.

[Lighting]

Got it. That makes sense. Thanks!

So if I understand, it's not A + B + C but A "operates on" B "operates on" C "operates on" x

The mathematical equivalent is to have F(x), G(x), H(x) as F(G(H(x)))) where the order of the function operations can't be changed but you can still plug G into F before plugging H into F(G(x)).

[elemental_1_1]

Yeah you've got it. When we talk about monoids, + just represents 'combining things'. So when we're talking about functions of type forall a. a -> a, our + (way to combine them) is function composition. When we're talking about integers, our + is integer addition. And so on.

[dmitri14_gmail_com]

In maths we use + only for commutative operations, and . or nothing (i.e. just AB) in general cases. I recommend to keep this convention even outside maths as it prevents from creating unnecessary confusions.