]>
> 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