Disappointment
[
Home
]
[ Index:
by date

by threads
]
[ Message by date: previous  next ] [ Message in thread: previous  next ] [ Thread: previous  next ]
[ Message by date: previous  next ] [ Message in thread: previous  next ] [ Thread: previous  next ]
Date:   (:) 
From:  Axel_Poigné <axel.poigne@i...> 
Subject:  Re: [Camllist] Disappointment 
> Computer scientists like to obfuscate dead simple ideas with > complicated > looking mathematics to deter commonsenseoriented 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