*This is the third in a series of posts about monads (part 1, part 2). I happen to be a .NET developer, so I use C# in my examples, but the concept applies to any language that has first-class functions. Code for the series is at github.*

In the last post, we covered over half of the items in Wikipedia's formal definition of a monad:

~~Formally, a monad consists of a type constructor ~~*M* and two operations, *bind* ~~and ~~*return*.
- The operations must fulfill several properties to allow the correct composition of
*monadic* functions (i.e. functions that use values from the monad as their arguments or return value).
~~In most contexts, a value of type ~~*M a* can be thought of as an action that returns a value of type *a*.
~~The ~~*return* operation takes a value from a plain type *a* and puts it into a monadic container of type *M a*.
- The
*bind* operation chains a monadic value of type *M a* with a function of type *a ? M b* to create a monadic value of type *M b*, effectively creating an action that chooses the next action based on the results of previous actions.

Let's break down the requirement for the *Bind* function. It

...chains a monadic value of type *M a*...

That says to me that we need to have an instance method in our monad. Or, we could use an extension method to achieve the same result. I prefer to use an extension method, so that's what we'll do. Let's create an extension method:

public static ??? Bind<T>(this Monad<T> monad, ???)

Not a bad start. Let's skip to the return type. We'll need

...to create a monadic value of type *M b*...

That doesn't look so hard. We've already used our

*Monad<T>* class in place of

*M a*. But, since we already used

*T* we won't be able to use it again. But, since it's a good idea to use standard C# naming conventions when we're writing C# code (when in Rome...), our generic type should at least start with the letter 'T'. How about

*TResult*, since it is the result of our

*Bind* method?

public static Monad<TResult> Bind<T, TResult>(
this Monad<T> monad,
???)

But what of the second parameter? It looks like it needs we need to be connecting

...with a function of type *a ? M b*...

Why, if I didn't know better, I'd say that looks an awful like a lambda expression (spoiler alert: it is). And we already know what

*a* and

*M b* mean to us:

*T* and

*Monad<TResult>*. It would be great if we were able to pass in a lambda expression that takes an

*T* and returns a

*Monad<TResult>*. But what is a lambda expression? Just a convenient way of creating a function. Hmmmm, function. I know - why don't we take a

*Func<T, Monad<TResult>>* as our parameter type! We just put the

*function* in

*functional*. So what does our extension method look like now?

public static Monad<TResult> Bind<T, TResult>(
this Monad<T> monad,
Func<T, Monad<TResult>> resultSelector)

Finally, we'll need to fill in the body. Our requirements state that we need to take our *Monad<T>* and transform it into a *Monad<TResult>* by using a *Func<T, TResult>*. That function needs a <T> argument passed to it. Haven't we seen an instance of *<T>* before? Of course - in the *Value* property of our *Monad<T>* class. With that, I think we have got enough information to fill out our *Bind* method:

public static Monad<TResult> Bind<T, TResult>(
this Monad<T> monad,
Func<T, Monad<TResult>> resultSelector)
{
return resultSelector(monad.Value);
}

I think we're really getting somewhere now! How would we use our spiffy new *Bind* function? I'd think that we would use it something like this:

Monad<int> m1 = 128.ToMonad();
Monad<Type> m2 = m1.Bind(x => x.GetType().ToMonad());
Console.WriteLine(
"The type of the original monad is: {0}.",
m2.Value);

We've taken a Monad of type *int*, and bound it to a Monad of type *Type* by calling *Bind* and passing in a lambda expression that takes a *T* and returns a *Monad<Type>*. There's one thing I don't like about this usage though: the call to *ToMonad()*. I'd prefer it if our *Bind* function had, as its parameter, a *Func<T, TResult>*. But I also want to meet the requirement for being a monad. Why don't we create an overload of *Bind* to do just that? I'd like our existing *Bind* method to remain the source of truth, so we'll have our new one call it.

public static Monad<TResult> Bind<T, TResult>(
this Monad<T> monad,
Func<T, TResult> resultSelector)
{
return monad.Bind(m => resultSelector(m).ToMonad());
}

This is getting a little funky. We're doing a few things here: 1) we're passing a new lambda expression to the other *Bind* method; 2) in the body of the new lambda expression, we're executing the function that was passed in; and 3) we're turning the result of into a *Monad<TResult>* by calling our extension method, *ToMonad*. We're not actually executing the passed-in function, we're passing it into another function that we pass to the other *Bind* method. Clear as mud, right? So why go through all this trouble? To me, it expresses intent better, and I think this makes it worth it. We can use it like this:

Monad<int> m1 = 128.ToMonad();
Monad<Type> m2 = m1.Bind(x => x.GetType());
Console.WriteLine(
"The type of the original monad is: {0}.",
m2.Value);

This is all well and good, but it seems kind of tedious to have to create a new variable each time we call *Bind*. Didn't the requirement mention something about chaining? As in method chaining? Why don't we try that?

var m =
128.ToMonad()
.Bind(x => x.GetType())
.Bind(x => new string(x.ToString().Reverse().ToArray()));
Console.WriteLine(
"The backwards string representation of "
+ "the type of the original monad is: {0}.",
m.Value);

We're taking the number *128* wrapping it in *Monad<int>*, binding it to a *Monad<Type>* with a function that takes any value and returns its type, and binding **that** to a *Monad<string>* with a function that takes any value and returns its string representation backwards. Pretty cool, huh?

We're headed for the home stretch now. It's time to address the final bullet point:

The operations must fulfill several properties to allow the correct composition of *monadic* functions (i.e. functions that use values from the monad as their arguments or return value).

It seems to me like we're already doing this. We're composing a monad from a series of monadic functions. But perhaps we can make our intent more clear - calling

*Bind* over and over again doesn't exactly look pretty. What if we extracted the calls to

*Bind* into methods that expressed their intent more clearly? How about using some extensions methods? Something like this?

public static Monad<Type> ToType<T>(this Monad<T> monad)
{
return monad.Bind(m => m.GetType());
}
public static Monad<string> ToReversedString<T>(
this Monad<T> monad)
{
return monad.Bind(m =>
new string(m.ToString().Reverse().ToArray()));
}

Now we can replace our *Bind* statements:

var m =
128.ToMonad()
.ToType()
.ToReversedString();
Console.WriteLine(
"The backwards string representation of "
+ "the type of the original monad is: {0}.",
m.Value);

That about wraps it up for today. Next time, we'll discuss the three monadic laws.(Hopefully we follow them!)