Disappointment
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
 Date: -- (:) From: Axel_Poigné Subject: Re: [Caml-list] Disappointment
> 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