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

[aditya siram]

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> 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 listHaskell-Cafe at haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100806/943e71e9/attachment.html