[Haskell-cafe] Suggestions For An Intro To Monads Talk.

[Gregory Crosswhite]

 It might be a little late at this point, but here's my take on monads:

In most imperative languages sequencing of statements is a feature that
is hard-coded into the language to act in a certain way, e.g. to have a
particular implicit state (the global state plus possibly the fields
available from a class, if the code is in a method).  In Haskell,
sequencing of statements is a first-class feature of the language that
we can define to work however we want.  For example, the Maybe monad
allows us to define the sequencing operation to abort whenever we access
a Maybe value that is Nothing.  In most languages they have to introduce
a special keyword "return" to get this kind of early-exit functionality,
but in Haskell we don't need such a keyword because Monads allow us to
extend the sequencing operation to *add* this kind of functionality.

Similarly, in most languages you cannot completely change the implicit
state available to code;  the most that you can do is to use
"Object-Oriented programming", which is an additional feature to the
language, to add additional implicit state that is available to code
(when it is inside a method) that stacks on top of the global state.  By
contrast, in Haskell defining an implicit state for code is trivial, and
furthermore we can do additional things like forcing this state to be
read-only, all without having to add new features to the language itself.

Not only is sequencing is a first-class operation that we can define at
will, but it is also possible to compose the functionality of multiple
sequencing operations so that, for example, we can get access to both a
read-only state, a global mutable state, *and* have the ability to
perform an early exit from our code, all (again) within the language. 
This technique is known as stacking "Monad transformers", and there are
multiple libraries for doing it.

Finally, here is something that is trivial to do in Haskell:  create a
sequencing operation based on continuations that allows code to perform
operations asynchronously while writing code in a synchronous style. 
That is, you can define a monad that lets you write code that looks like

    do
        result <- request x
        case result of
            A -> request y
            B -> request z

which has the feature that rather than blocking a thread while we wait
for a request, we instead actually implicitly creates a callback that
runs the rest of the code as soon as the result as ready.  In most other
languages you'd have to invent a special language features such as
continuations in order to allow for a coding style like this, but in
Haskell we don't need them because *overriding the sequence operation
itself* is a first-class feature of the language that allows us to do this.

So again, the moral of this story is that just like having access to
continuations as a first-class object allows one to do powerful things,
so too does having access to the sequencing operation as a first-class
object let us do stuff that makes our job as programmers easier.

Cheers,
Greg

On 08/06/10 08:17, aditya siram wrote:
> Thanks all for you suggestions!
> Upon further reflection I realized that my audience is more pragmatic
> than theoretical. Instead of emphasizing how monads are constructed
> and the monad laws I think I want to dive right into the most common
> and useful monads. From my vantage point they are (in no particular
> order) : Reader, Writer, State, IO, ST, STM, Parsec (have I missed
> any?) and of course the transformer versions. I am debating whether or
> not to add [] to the bunch.
>
> To explain monads (now that I have Timothy's awesome blog post to
> reference) I'll be drawing the parallel between monads and interfaces
> in Java. And thanks to Tillman for showing me where the analogy breaks
> down. Are there any such parallels in other languages like Perl and
> Python?
>
> I'm still a little iffy on why the monad concept isn't used in other
> languages. From where I sit it seems as though monads really let you
> play with the order of evaluation - just because one statement is
> executed after another doesn't mean they are executed in that order. I
> think other languages don't make this easy.
>
> -deech
>
> On Wed, Aug 4, 2010 at 6:21 PM, Daniel van den Eijkel <dvde at gmx.net
> <mailto:dvde at gmx.net>> wrote:
>
>     For me, the following two things did the magic, so I'll suggest them:
>
>     1.
>     Writing a recursive function that takes a binary tree and returns
>     the same tree, but with its leaves enumerated. Each function call
>     takes the tree and the counter and returns the resulting tree and
>     the new counter value. The pattern that emerges is similar to the
>     state monad. The pattern shows that the order of the recursive
>     calls is not ambiguous, unlike in a function that just counts the
>     leaves, for example. Changing the order of the recursive calls
>     changes the result.
>     (code below)
>
>     2.
>     Putting the above pattern into a datatype and rewriting the
>     apply-funtion for this datatype (>>=) allows only to apply
>     funtions in a non-ambiguous way. Not giving a deconstructor for
>     the IO monad forces the programmer to decide in which order calls
>     to IO functions have to be done.
>
>     I hope this is clear enough; I was able to use the IO monad at the
>     moment I realized that Haskell uses this kind of "trick" to ensure
>     that the order of execution of function arguments is always
>     well-defined and never ambiguous. Of course, there is much more
>     about monads, but this was my entry point.
>
>     Best regards
>     Daniel
>
>
>     code (tree enumeration):
>
>     data Tree a = Leaf a | Node (Tree a) (Tree a) deriving Show
>
>     enumTree n (Node a b) =
>      let (n', a')  = enumTree n a in
>      let (n'', b') = enumTree n' b in
>      (n'', Node a' b')
>
>     enumTree n (Leaf x) = (n+1, Leaf n)
>
>
>
>
>
>     aditya siram schrieb:
>>     Hi all,
>>     I am doing an "Intro To Monads" talk in September [1]. The
>>     audience consists of experienced non-Haskell developers but they
>>     will be familiar with basic functional concepts (closures,
>>     first-class functions etc.).
>>
>>     I am looking for suggestions on how to introduce the concept and
>>     its implications. I'd also like to include a section on why
>>     monads exist and why we don't really see them outside of Haskell.
>>
>>     Has anyone here done a talk like this? And if so what parts of
>>     your presentation were successful and what would you stay away from.
>>
>>     Thanks for the feedback.
>>     -deech
>>
>>     [1] It's in St.Louis, Missouri at the St.Louis Perl Mongers
>>     meeting <http://St.Louis%20Perl%20Mongers%20meeting> so come on
>>     by if you're around!
>>     ------------------------------------------------------------------------
>>     _______________________________________________ Haskell-Cafe
>>     mailing list Haskell-Cafe at haskell.org
>>     <mailto:Haskell-Cafe at haskell.org>
>>     http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100806/ff568d5f/attachment.html