Computer scientists like to obfuscate dead simple ideas with complicated
looking mathematics to deter commonsense-oriented people from making
embarassing observations, such as that computer science was
unable to see something that actually is pretty much obvious -
for ages... ;-)

Maybe computer scientists obfuscate. The mathematical concept of monads however is dead simple (at least if interpreted in a world of sets):

Let X be a set of values and let TX denote a set of "simple terms" over these values. A "simple term" may be thought of as either "an operator applied to a tuple of values" or "a value", e.g. "values" are 1,2,3,... and "simple terms" are 3, +(3,5), ...

Additionally to the "operator" T on sets there are two functions:

- \eta: X -> TX that turns a value into a "simple term", e.g. \eta(3) = 3

- \mu: TX -> X that computes the value of a "simple term", hence defines the semantics, e.g. \mu(+(3,5)) = 8.

(T, \eta, and \mu) form a monad if

- a term that is a value is evaluated to the respective value (which is an axiom missing in Haskell if I understood a previous message correctly)

- if we build "complex terms", i.e. iterate the operator T, it does not matter in which order one evaluates.

I agree that it gets slightly more involved if one specifies the second axiom formally.

Don't know whether this helps to understand monads in programming since so far I did not care very much about them. However that's were Eugenio Moggi took the idea from when introducing monads to semantics.

Axel