I'm afraid this kind of 5-minute talk makes sense only if you already know a lot about monads or are a computer scientist; not if you're a programmer who wants to learn a new language. For instance, this statement starts making sense only if you've seen a lot of examples of monads (maybe even read Moggi and Wadler) and want to understand the big picture. "... when Haskell programmers want to perform a side effect, they explicitly construct a description of the side effecting computation as a value." And even then, what does it mean to "construct a description of the side effecting computation as a value" for the Maybe monad? An IO action or a State Monad action indeed are values that describe computations, but what computation does (Just 1) describe?  It's the simple monads that are tricky to explain (I've seen a discussion to that effect in this forum and I wholeheartedly agree).  --Bartosz On Sunday, September 16, 2012 7:49:51 AM UTC-7, Tillmann Rendel wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi,

<br>

<br>Kristopher Micinski wrote:

<br>&gt; Everyone in the Haskell cafe probably has a secret dream to give the

<br>&gt; best "five minute monad talk."

<br>

<br>(1) Most programming languages support side effects. There are different 

<br>kinds of side effects such as accessing mutable variables, reading 

<br>files, running in parallel, raising exceptions, nondeterministically 

<br>returning more than one answer, and many more. Most languages have some 

<br>of these effects built into their semantics, and do not support the 

others at all.

<br>

<br>(2) Haskell is pure, so it doesn't support any side effects. Instead, 

<br>when Haskell programmers want to perform a side effect, they explicitly 

<br>construct a description of the side effecting computation as a value. 

<br>For every group of related side effects, there is a Haskell type that 

describes computations that can have that group of side effects.

<br>

<br>(3) Some of these types are built in, such as IO for accessing the world 

<br>outside the processor and ST for accessing local mutable variables. 

<br>Other such types are defined in Haskell libraries, such as for 

<br>computations that can fail and for computations that can return multiple 

<br>answers. Application programmers often define their own types for the 

side effects they need to describe, tailoring the language to their needs.

<br>

<br>(4) All computation types have a common interface for operations that 

<br>are independent of the exact side effects performed. Some functions work 

<br>with arbitrary computations, just using this interface. For example, we 

<br>can compose a computation with itself in order to run it twice. Such 

generic operations are highly reusable.

<br>

<br>(5) The common interface for constructing computations is called 

<br>"Monad". It is inspired by the mathematical theory that some computer 

<br>scientists use when they describe what exactly the semantics of a 

<br>programming language with side effects is. So most other languages 

<br>support some monad natively without the programmer ever noticing, 

<br>whereas Haskell programmers can choose (and even implement) exactly the 

<br>monads they want. This makes Haskell a very good language for side 

effecting computation.

<br>

<br>&nbsp; &nbsp;Tillmann

<br>

<br>______________________________<wbr>_________________

<br>Haskell-Cafe mailing list

<br><a href="javascript:" target="_blank" gdf-obfuscated-mailto="dAMhBNdrc5wJ">Haskel...@haskell.org</a>

<br><a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/<wbr>mailman/listinfo/haskell-cafe</a>

<br></blockquote>