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.<br><br>"... when Haskell programmers want to perform a side effect, they explicitly construct a description of the side effecting computation as a value."<br><br>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). <br><br>--Bartosz<br><br>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 
<br>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 
<br>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 
<br>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 
<br>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 
<br>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>