Lambda the Ultimate

This isn't actually a dumb question, as it reveals an important subtlety of monads. The short answer is that changing the association doesn't actually change the order of operations (it's "m, k, h" on both sides). It would be far stranger if bind were required in some sense to be commutative! But probably the short answer doesn't help that much...

In order to really understand this, it's important to remember that the monad operations (such as bind) are a distinct layer of operations from the "actual" operations (m, k, and h) being manipulated. All the associativity requirement says is that I should be able to build my composite operation in any order, and as long as it's made of the same basic operations in the same order, it'll be the same operation. At the risk of giving a wrong intuition, you can (sort of) think of it like building a list. If m, k, and h are lists and ++ is concatenation, you'd certainly expect that (m ++ k) ++ h == m ++ (k ++ h). This is the kind of associativity we're dealing with here.

The reason it's important has little to do with the actual underlying operations (IO actions, lists, etc.). It has more to do with the expected semantics of nesting monad operations, Haskell's "do" notation, etc. I think you might find this post helpful (and hopefully more clear than what I've written).

You have three things to do: m, k, and h.
So you either do
m and k ... h
or
m ... k and h

You're making a cake: mix batter, bake, eat.
You can think of this in two way
First I'm mixing batter and baking, and later I'll eat the cake.
Or
First I'm mixing the batter, and later I'll bake and eat.
But they both do the same thing. You can extend this by thinking that each stage produces a value (mixed batter, baked cake, full tummy). The operations are still associative.

No mystery.

It's only sort-of associativity, precisely because of the lambda abstraction. It's saying something like:

doing m then doing k then doing h

is the same as

preparing the groundwork to do k then h, then doing m then finishing the job

I guess in the side-effecting monads as shell scripts analogy you're saying: You can write the bits of the script in any order as long as they appear in the correct order on the page (a bit like list associativity), as long as when you come to execute some of it you're not trying to execute up to line n before you've written out lines 1 to (n-1).

Consider monoids first, which are slightly easier. Commutativity is about order. In a commutative monoid, say, we have AB=BA, so order doesn't matter. But in general, monoids aren't commutative and order does matter.

Associativity for monoids states that A(BC)=(AB)C. Note that the order of the elements doesn't change. In effect, associativity states that the way we choose to group the elements into a sequence of binary products shouldn't matter, but it says nothing about the order.

The same happens with a monad. There are such things as commutative monads where order doesn't matter (eg. the Reader monad), but much of the time order does matter. But all monads are associative. The associativity law for monads is about how we group the subexpressions, not about the order. This is more apparent if you look at the monad laws using Haskell do-notation.

I go back to first principles to try to understand the mechanism. I have this observation. Could someone tell me if I'm correct or not? Here it is:

Monad works the way it is only because call-by-need, call-by-name or call-by-value reduction strategy is used, such that the expression in an abstraction won't be evaluated. If we use normal order reduction, monad won't work as expected.

(blank post)