# C9 Lectures: Greg Meredith - Monadic Design Patterns for the Web 4 of 4

- Posted: Jul 26, 2011 at 11:51AM
- 37,500 views
- 5 comments

Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Loading user information from MSDN

Something went wrong getting user information from MSDN

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

- Posted: Jul 26, 2011 at 11:51AM
- 37,500 views
- 5 comments

- To download, right click the file type you would like and pick “Save target as…” or “Save link as…”

- It's an easy way to save the videos you like locally.
- You can save the videos in order to watch them offline.
- If all you want is to hear the audio, you can download the MP3!

- If you want to view the video on your PC, Xbox or Media Center, download the High Quality MP4 file (this is the highest quality version we have available).
- If you'd like a lower bitrate version, to reduce the download time or cost, then choose the Medium Quality MP4 file.
- If you have a Windows Phone, iPhone, iPad, or Android device, choose the low or medium MP4 file.
- If you just want to hear the audio of the video, choose the MP3 file.

Right click “Save as…”

Greg Meredith, a mathematician and computer scientist, has graciously agreed to do a C9 lecture series covering monadic design principles applied to web development. You've met Greg before in a Whiteboard jam session with Brian Beckman.

The fundamental concept here is the monad, and Greg has a novel and conceptually simplified explanation of what a monad is and why it matters. This is a very important and required first step in the series since the whole of it is about the application of monadic composition to real world web development.

In **part 4, **Greg primarily focuses on the idea that *a monad is really an API—*a view into the organization of data and control structures, not those structures themselves. In OO terms, it's an *interface*. To make this point concrete, Greg explores one of the simplest possible data structures supporting at least two different, though consistent, interpretations of the same API. The structure used, Conway's partisan games, turns out to be tailor-made for this investigation. Not only does this data structure have the requisite container-like shape, it provides opportunities to see just what's necessary in a container to implement the monadic interface.

Running throughout the presentation is a more general comparison of reuse between an OO approach and a more functional one. When the monadic API is "mixed into" the implementing structure, we get less reuse than when the implementing structure is passed as a type parameter. Finally, doing the work puts us in a unique position to see not just how to generalize Conway's construction *monadically*, but also the underlying pattern that allows the generalization to suggest itself.**Source code for the Conway game****Slides for this presenation**

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.

## Follow the discussion

Oops, something didn't work.

## What does this mean?

Subscriptions allow us send you email notifications when new content is added. You need to be signed in to Channel 9 to use this feature.## What does this mean?

Subscriptions allow us send you email notifications when new content is added.sign up for email notifications?

Hey this was great. What would this look like in F#? Thanks.

@AceHack:

F# has a DSL for monads called Computation Expressions so monads 'look' different in F#. Also, I think that once you have a monad implementation, the DSL makes it easier to use the implementation in your code.

So F# provides some extra language support for monads.

However, unlike Scala, F# does not have higher-kinded types so you cannot compose two monad implementations together (as easily).

I struggled with monads at first but then I realized that monads are really about function composition. Here is blog post that emphasizes this aspect of monads that may help with the understanding:

http://fwaris.wordpress.com/2011/07/30/understanding-monads/

Thank you Greg! Thank you Charles!

This one was really giving me a blast (and still is). Today I got my copy of D.E.Knuth's "Surreal Numbers", which is an excellent little intro to Conway numbers back from 1974, and I would like to recommend it here. I devoured it in one go and will read it again as soon as possible, then equipped with pencil and paper. The other book, Conway's "On Numbers and Games", appearing in the slides, I have ordered already... and Greg's book is on the list

Now, having settled the praise, here's something that sparked off quite towards the end of this installment. It's about abstracting over the container representation for 'left' and 'right'. Hmm, possibly there's a good thing even in Scala's oddity of non-variant (immutable!) Sets (see ShiNoNoir's link above).

Ok, I got two things, the second about transfinite ordinals. I know, that sounds quite scary/impressive - but it ain't really so (much). I have put together a postscript below (admittedly long for a post, but still...) which I hope establishes the relevant point while presuming virtually nothing. Please also leave your comment on that particular attempt alone, if you have some.

includingthe "first hole" that you poked? That is to say: once we're free to provide any container representation we like, can't we get rid of the A type parameter in GenConWayGame[M[_],A] and theEither[A, ...] in left and right and just "push" that into the M[_]?code. I mean code as data, i.e. we're not going to execute that code but rather want to manipulate it. So ω would just be some (finite!) representation of code that,ifexecuted,wouldgive the empty set for right and for left enumerate the naturals, ad infinitum. Adding 1 to that, for example, would give code that,ifexecuted,wouldgive the empty set for right and for left enumerate {ω,2,3,4,....}. And, even better, we could simply return the equivalent ({ω}, {}). Not so hard to imagine how to representthat, is it? You see, it's calculating (=reasoning about) it,notactually writing it out. We'd like todeferas long as we can - at best forever____

p.s., "

What's that Conway ω, by the way?" (simplifying quite a bit - as Greg mentioned, "there's a lot of devil (detail) in there"):maximalelement (check yourself using the definition of LTE). Hence the choice of the canonical representative is straight-forward: simply use the singleton set with exactly that maximal element for left and the empty set for right. This covers all of the non-negative integers nicely. Now for the fun partfinite? Well, nobody, of course. But that means there is this critter: ({0,1,2,3,4,...}, {}), i.e. empty right and in leftallthe non-negative integers from 4). This actually is a Conway number according to 2), yet any non-negative integer from 4) is LTE it. Check it yourself, you'll see it's trivial. This critter is commonly denoted byωand it was created on the day after infinitely many days (when the integers [and some more, like the rationals] were created), aka day aleph (1). Anyhow, here come the interesting bits: how to actually representωin a program? Obviously we cannot replay the "trick" from 3), as there is no maximal element (although we could agree on a canonical representation that contains just the singleton sets from 4) - but that doesn't help, it's still infinite). However, it's not at all hard to envisionω- or is it?! C'mon, all we're talking about is the pair of a) all the non-negative integers and b) the empty set, that ain't really hard. But wait, what is justthat? It's an English sentence, consisting of... uhm... a number of characters - but definitely finite! And it characterizes this infinite critterω. So...## Remove this comment

## Remove this thread

Close