# The Identity monad by Mark Seemann

*Probably one of the least useful monads. An article for object-oriented developers.*

This article is an instalment in an article series about monads.

The Identity functor is another example of a functor that also forms a monad. Contrary to useful monads like list, Maybe, and Either, the Identity monad isn't particularly useful. In Haskell it serves a few niche positions, for example when it comes to monad transformers. It's possible to define abstractions at a higher level in Haskell than it is in many other languages. Some of those abstractions involve monads. The Identity monad can plug into these abstractions as a 'do-nothing' monad, a bit like the Null Object pattern can supply a 'do-nothing' implementation of an interface.

Other languages with which I'm proficient (C#, F#) don't enable that kind of abstraction, and I've never felt the need to actually *use* the Identity monad in those languages. Still, the Identity monad exists mathematically and conceptually, and it can be useful to know of that existence. This implies, like the Null Object pattern, that some abstractions can be simplified by 'plugging in' the Identity monad. The alternative would have had to involve some hand-waving about special cases.

The code in this article continues the implementation shown in the article about the Identity functor.

### SelectMany #

A monad must define either a *bind* or *join* function. In C#, monadic bind is called `SelectMany`

. For `Identity<T>`

the implementation is trivial:

public Identity<TResult> SelectMany<TResult>(Func<T, Identity<TResult>> selector) { return selector(Item); }

This is an instance method on `Identity<T>`

, which means that the `Item`

property has the type `T`

. Since the `selector`

return a new `Identity<TResult>`

, the method can simply return that value.

### Query syntax #

As usual, you can implement C# query syntax with a boilerplate overload of `SelectMany`

:

public Identity<TResult> SelectMany<U, TResult>( Func<T, Identity<U>> k, Func<T, U, TResult> s) { return SelectMany(x => k(x).Select(y => s(x, y))); }

The implementation is the same as in the previous articles in this article series. If it looks a little different than, say, the implementation for the Maybe monad, it's only because this `SelectMany`

overload is an instance method, whereas the Maybe implementation is an extension method.

Query syntax enables syntactic sugar like this:

Identity<int> i = from x in new Identity<int>(39) from y in new Identity<string>("foo") select x + y.Length;

The C# compiler infers that `x`

is an `int`

and `y`

is a `string`

.

### Flatten #

As the monad introduction also points out, if you have monadic bind (`SelectMany`

) you can always implement a function to flatten a nested functor. This function is sometimes called *join* and sometimes (perhaps more intuitively) *flatten*. Here I've chosen to call it `Flatten`

:

public static Identity<T> Flatten<T>(this Identity<Identity<T>> source) { return source.SelectMany(x => x); }

Even though the other methods shown so far have been instance methods, `Flatten`

has to be an extension method, since the source is a nested `Identity<Identity<T>>`

. There's no class of that specific type - only `Identity<T>`

.

If there's one useful aspect of the Identity monad, it may be that it reveals the concept of a nested functor in all its triviality:

Identity<Identity<string>> nested = new Identity<Identity<string>>(new Identity<string>("bar")); Identity<string> flattened = nested.Flatten();

Recall: A monad is a functor you can flatten.

### Return #

Apart from monadic bind, a monad must also define a way to put a normal value into the monad. Conceptually, I call this function *return* (because that's the name that Haskell uses). You don't, however, have to define a static method called `Return`

. What's of importance is that the capability exists. For `Identity<T>`

in C# the idiomatic way would be to use a constructor. This constructor does double duty as monadic *return*:

public Identity(T item) { Item = item; }

In other words, *return* just wraps a value in the `Identity<T>`

container.

### Left identity #

We need to identify the *return* function in order to examine the monad laws. Let's see what they look like for the Identity monad, starting with the left identity law.

[Property(QuietOnSuccess = true)] public void IdentityHasLeftIdentity(Func<int, Identity<string>> h, int a) { Func<int, Identity<int>> @return = i => new Identity<int>(i); Assert.Equal(@return(a).SelectMany(h), h(a)); }

This example is a bit different compared to the previous examples, since it uses FsCheck 2.11.0 and xUnit.net 2.4.0. FScheck can generate arbitrary functions in addition to arbitrary values, so I've simply asked it to generate some arbitrary `h`

functions.

### Right identity #

In a similar manner, we can showcase the right identity law as a test.

[Property(QuietOnSuccess = true)] public void IdentityHasRightIdentity(Func<string, Identity<int>> f, string a) { Func<int, Identity<int>> @return = i => new Identity<int>(i); Identity<int> m = f(a); Assert.Equal(m.SelectMany(@return), m); }

As always, even a property-based test constitutes no *proof* that the law holds. I show it only to illustrate what the laws look like in 'real' code.

### Associativity #

The last monad law is the associativity law that describes how (at least) three functions compose.

[Property(QuietOnSuccess = true)] public void IdentityIsAssociative( Func<int, Identity<string>> f, Func<string, Identity<byte>> g, Func<byte, Identity<TimeSpan>> h, int a) { Identity<string> m = f(a); Assert.Equal(m.SelectMany(g).SelectMany(h), m.SelectMany(x => g(x).SelectMany(h))); }

This property once more relies on FsCheck's ability to generate arbitrary pure functions.

### F# #

While the `Identity`

monad is built into the Haskell standard library, there's no Identity monad in F#. While it can be occasionally useful in Haskell, Identity is as useless in F# as it is in C#. Again, that doesn't imply that you can't define it. You can:

type Identity<'a> = Identity of 'a module Identity = // Identity<'a> -> 'a let get (Identity x) = x // ('a -> 'b) -> Identity<'a> -> Identity<'b> let map f (Identity x) = Identity (f x) // ('a -> Identity<'b>) -> Identity<'a> -> Identity<'b> let bind f (Identity x) : Identity<_> = f x

Here I've repeated the functor implementation from the article about the Identity functor, but now also included the `bind`

function.

You can use such a module to support syntactic sugar in the form of computation expressions:

type IdentityBuilder() = member _.Bind(x, f) = Identity.bind f x member _.Return x = Identity x member _.ReturnFrom x = x let identity = IdentityBuilder ()

This enables you to write code like this:

let i = identity { let! x = Identity "corge" let! y = Identity 47 return y - x.Length }

Here, `i`

is a value of the type `Identity<int>`

.

### Conclusion #

If the Identity monad is useful in languages like C# and F#, I have yet to encounter a use case. Even so, it exists. It is also, perhaps, the most naked illustration of what a functor and monad is. As such, I think it may be helpful to study.

**Next:** The Lazy monad.