Mind if I join you in praising this? On Sep 17, 2012, at 12:06 AM, Kristopher Micinski <krismicin...@gmail.com> wrote:
> Agreed. Great. I still contend that it would be cool to get this to > be a real thing at something like the Haskell workshop, I think > hearing the different perspectives would be an interesting insight > into the many different ways to explain monads. But I suppose the way > to start would be to put up a webpage for collecting them.. > > kris > > On Sun, Sep 16, 2012 at 3:55 PM, Conal Elliott <co...@conal.net> wrote: >> Hi Tillmann. Wow. Lovely and spot on! And I almost never hear monad >> explanations without wincing. Thanks for sharing. -- Conal >> >> On Sun, Sep 16, 2012 at 7:48 AM, Tillmann Rendel >> <ren...@informatik.uni-marburg.de> wrote: >>> >>> Hi, >>> >>> >>> Kristopher Micinski wrote: >>>> >>>> Everyone in the Haskell cafe probably has a secret dream to give the >>>> best "five minute monad talk." >>> >>> >>> (1) Most programming languages support side effects. There are different >>> kinds of side effects such as accessing mutable variables, reading files, >>> running in parallel, raising exceptions, nondeterministically returning more >>> than one answer, and many more. Most languages have some of these effects >>> built into their semantics, and do not support the others at all. >>> >>> (2) Haskell is pure, so it doesn't support any side effects. Instead, when >>> Haskell programmers want to perform a side effect, they explicitly construct >>> a description of the side effecting computation as a value. For every group >>> of related side effects, there is a Haskell type that describes computations >>> that can have that group of side effects. >>> >>> (3) Some of these types are built in, such as IO for accessing the world >>> outside the processor and ST for accessing local mutable variables. Other >>> such types are defined in Haskell libraries, such as for computations that >>> can fail and for computations that can return multiple answers. Application >>> programmers often define their own types for the side effects they need to >>> describe, tailoring the language to their needs. >>> >>> (4) All computation types have a common interface for operations that are >>> independent of the exact side effects performed. Some functions work with >>> arbitrary computations, just using this interface. For example, we can >>> compose a computation with itself in order to run it twice. Such generic >>> operations are highly reusable. >>> >>> (5) The common interface for constructing computations is called "Monad". >>> It is inspired by the mathematical theory that some computer scientists use >>> when they describe what exactly the semantics of a programming language with >>> side effects is. So most other languages support some monad natively without >>> the programmer ever noticing, whereas Haskell programmers can choose (and >>> even implement) exactly the monads they want. This makes Haskell a very good >>> language for side effecting computation. >>> >>> Tillmann >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
