Re: [Caml-list] Disappointment

["Axel Poigné" <axel.poigne@iais.fraunhofer.de>]

[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]

> 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



[-- Attachment #2: Type: text/html, Size: 5166 bytes --]