{"id":3096,"date":"2013-04-03T10:53:21","date_gmt":"2013-04-03T10:53:21","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/pfxteam\/2013\/04\/03\/tasks-monads-and-linq\/"},"modified":"2013-04-03T10:53:21","modified_gmt":"2013-04-03T10:53:21","slug":"tasks-monads-and-linq","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/tasks-monads-and-linq\/","title":{"rendered":"Tasks, Monads, and LINQ"},"content":{"rendered":"

A few years back, Wes Dyer wrote a great post on monads<\/a>, and more recently, Eric Lippert wrote a terrific blog series exploring monads and C#<\/a>. In that series, Eric alluded to Task<TResult> several times, so I thought I’d share a few related thoughts on Task<TResult> and the async\/await keywords.<\/p>\n

As both Wes and Eric highlight, a monad is a triple consisting of a type, a Unit function (often called Return), and a Bind function. If the type in question is Task<T>, what are its Unit and Bind functions? <\/p>\n

The Unit operator takes a T and “amplifies” it into an instance of the type:<\/p>\n

\n

public static<\/font> M<\/font><T> Unit<T>(this<\/font> T value);<\/font><\/p>\n<\/blockquote>\n

That’s exactly what Task.FromResult does, producing a Task<T> from a T, so our Unit method can easily be implemented as a call to FromResult:<\/p>\n

\n

public static<\/font> Task<\/font><T> Unit<T>(this<\/font> T value)
{
    return<\/font> Task<\/font>.FromResult(value);
}<\/font><\/p>\n<\/blockquote>\n

What about Bind? The Bind operator takes the instance of our type, extracts the value from it, runs a function over that value to get a new amplified value, and returns that amplified value:<\/p>\n

\n

public static<\/font> M<\/font><V> Bind<U, V>(
    this<\/font> M<\/font><U> m, Func<\/font><U, M<\/font><V>> k);<\/font><\/p>\n<\/blockquote>\n

If you squint at this, and if you’ve read my previous blog post Implementing Then with Await<\/a>, the structure of this declaration should look eerily like the last overload of Then discussed:<\/p>\n

\n

public static<\/font> Task<\/font><TNewResult> Then<TResult, TNewResult>(
    this<\/font> Task<\/font><TResult> task, Func<\/font><TResult, Task<\/font><TNewResult>> continuation);<\/font> <\/p>\n<\/blockquote>\n

In fact, other than the symbols chosen, they’re identical, and we can implement Bind just as we implemented Then:<\/p>\n

\n

public static async<\/font> Task<\/font><V> Bind<U, V>(
    this<\/font> Task<\/font><U> m, Func<\/font><U, Task<\/font><V>> k)
{
    return await<\/font> k(await<\/font> m);
}<\/font><\/p>\n<\/blockquote>\n

This is possible so concisely because await and async are so close in nature to the monadic operators. When you write an async function that returns Task<V>, the compiler expects the body of the method to return a V, and it lifts (or amplifies) that V into the Task<V> that’s returned from the method call; this is basically Unit (async, of course, also handles the creation and completion of the returned Task for the case where an exception propagates out of the body of the async method). Further, a core piece of the Bind operator is in extracting the value from the supplied instance, and that’s nicely handled by await.<\/p>\n

\n

static<\/font> M<\/font><C> SelectMany<A, B, C>(
    this<\/font> M<\/font><A> monad,
    Func<\/font><A, M<\/font><B>> function,
    Func<\/font><A, B, C> projection)
{
    return<\/font> monad.Bind(
        outer => function(outer).Bind(
            inner => projection(outer, inner).Unit()));
}<\/font><\/p>\n<\/blockquote>\n

Sure enough, with our Bind and Unit implementations around Task<T>, we can substitute in “Task” for “M”, and it “just works”:<\/p>\n

\n

static<\/font> <\/font>Task<\/font><C> SelectMany<A, B, C>(
<\/font>    this<\/font> Task<\/font><A> monad,<\/font>
    Func<A, Task<\/font><B><\/font>> function,
    Func<A, B, C> projection)
<\/font>{
    return monad.Bind(
        outer => function(outer).Bind(
            inner => projection(outer, inner).Unit()));
}<\/font><\/font><\/p>\n<\/blockquote>\n

What does it mean here to “just work”? It means we can start writing LINQ queries using the C# query comprehension syntax with operators that rely on SelectMany, e.g.<\/p>\n

\n

int<\/font> c = await<\/font> (from<\/font> first in<\/font> Task<\/font>.Run(() => 1)
               from<\/font> second in<\/font> Task<\/font>.Run(() => 2)
               select<\/font> first + second);
Console<\/font>.WriteLine(c == 3); \/\/ will output True<\/font><\/font><\/p>\n<\/blockquote>\n

Of course, we can implement SelectMany without Bind and Unit, just using async\/await directly:<\/p>\n

\n

static async<\/font> Task<\/font><C> SelectMany<A, B, C>(
    this<\/font> Task<\/font><A> task,
    Func<\/font><A, Task<\/font><B>> function,
    Func<\/font><A, B, C> projection)
{
    A a = await<\/font> task;
    B b = await<\/font> function(a);
    return<\/font> projection(a, b);
}<\/font><\/p>\n<\/blockquote>\n

In fact, we can implement many of the LINQ query operators simply and efficiently using async\/await. The C# specification<\/a> section 7.16.3 lists which operators we need to implement to support all of the C# query comprehension syntax, i.e. all of the LINQ contextual keywords in C#, such as select and where. Some of these operators, like OrderBy, make little sense when dealing with singular values as we have with Task<T>, but we can easily implement the others. This enables using most of the C# LINQ query comprehension syntax with Tasks:<\/p>\n

\n

public static async<\/font> Task<\/font><V> SelectMany<T, U, V>(
    this<\/font> Task<\/font><T> source, Func<\/font><T, Task<\/font><U>> selector, Func<\/font><T, U, V> resultSelector)
{
    T t = await<\/font> source;
    U u = await<\/font> selector(t);
    return<\/font> resultSelector(t, u);
} <\/p>\n

public static async<\/font> <\/font>Task<\/font><U> Select<T, U>(
    this<\/font> Task<\/font><T> source, Func<\/font><T, U> selector)
{
    T t = await<\/font> source;
    return<\/font> selector(t);
} <\/p>\n

public static async<\/font> Task<\/font><T> Where<T>(
    this<\/font> Task<\/font><T> source, Func<\/font><T, bool<\/font>> predicate)
{
    T t = await<\/font> source;
    if<\/font> (!predicate(t)) throw new<\/font> OperationCanceledException<\/font>();
    return<\/font> t;
} <\/p>\n

public static async<\/font> Task<\/font><V> Join<T, U, K, V>(
    this<\/font> Task<\/font><T> source, Task<\/font><U> inner,
    Func<\/font><T, K> outerKeySelector, Func<\/font><U, K> innerKeySelector,
    Func<\/font><T, U, V> resultSelector)
{
    await<\/font> Task<\/font>.WhenAll(source, inner);
    if<\/font> (!EqualityComparer<\/font><K>.Default.Equals(
        outerKeySelector(source.Result), innerKeySelector(inner.Result)))
            throw new<\/font> OperationCanceledException<\/font>();
    return<\/font> resultSelector(source.Result, inner.Result);
} <\/p>\n

public static async<\/font> Task<\/font><V> GroupJoin<T, U, K, V>(
    this<\/font> Task<\/font><T> source, Task<\/font><U> inner,
    Func<\/font><T, K> outerKeySelector, Func<\/font><U, K> innerKeySelector,
    Func<\/font><T, Task<\/font><U>, V> resultSelector)
{
    T t = await<\/font> source;
    <\/font>return<\/font> resultSelector(t,
        inner.Where(u => EqualityComparer<\/font><K>.Default.Equals(
            outerKeySelector(t), innerKeySelector(u))));
<\/font>} <\/p>\n

public static async<\/font> Task<\/font><T> Cast<T>(this<\/font> Task<\/font> source)
{
    await<\/font> source;
    return<\/font> (T)((dynamic<\/font>)source).Result;
}<\/font><\/p>\n<\/blockquote>\n

Interestingly, Task<TResult> already has the members necessary to be considered “comonadic.” As Brian Beckman discusses in his precis<\/a>, a comonad is the dual of a monad, a triple consisting of the type and two operators: Extract (the flip of Unit\/Return) and Extend (the flip of Bind). Here I’ve taken a few liberties with the signatures from what Brian outlines, such as swapping the order of some of the parameters:<\/p>\n

\n

public<\/font> T Extract<T>(this<\/font> W<\/font><T> self);
public<\/font> W<\/font><U> Extend<T, U>(this<\/font> W<\/font><T> self, Func<\/font><W<\/font><T>, U> func);<\/font><\/p>\n<\/blockquote>\n

Task<TResult> already supports Extract, it’s just called Result:<\/p>\n

\n

public<\/font> TResult Result;<\/font><\/p>\n<\/blockquote>\n

And it already supports Extend, it’s just called ContinueWith:<\/p>\n

\n

public<\/font> Task<\/font><TNewResult> ContinueWith<TNewResult>(
    Func<\/font><Task<\/font><TResult>, TNewResult> func);<\/font><\/p>\n<\/blockquote>\n

(In truth, to correctly implement all of the comonadic laws Brian outlines, we’d likely want to tweak both of these with a thin layer of additional code to modify some corner cases around exceptions and cancellation, due to how Result propagates exceptions wrapped in AggregateException and how ContinueWith tries to match thrown OperationCanceledExceptions against the CancellationToken supplied to ContinueWith. But the basic idea stands.)<\/p>\n

Most of the posts I write on this blog are about practical things. So, is any of this really useful in everyday coding with Tasks and async\/await? Would you actually want to implement and use the LINQ surface area directly for Tasks? Eh, probably not. But it’s a fun to see how all of these things relate.<\/p>\n

(Update 4\/3\/2013: Thanks to Aaron Lahman for pointing out the bug I had in my GroupJoin implementation.  Fixed.)<\/em><\/p><\/p>\n","protected":false},"excerpt":{"rendered":"

A few years back, Wes Dyer wrote a great post on monads, and more recently, Eric Lippert wrote a terrific blog series exploring monads and C#. In that series, Eric alluded to Task<TResult> several times, so I thought I’d share a few related thoughts on Task<TResult> and the async\/await keywords. As both Wes and Eric […]<\/p>\n","protected":false},"author":360,"featured_media":58792,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[7908],"tags":[7925,36,7909,7912],"class_list":["post-3096","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-pfxteam","tag-net-4-5","tag-async","tag-parallel-extensions","tag-task-parallel-library"],"acf":[],"blog_post_summary":"

A few years back, Wes Dyer wrote a great post on monads, and more recently, Eric Lippert wrote a terrific blog series exploring monads and C#. In that series, Eric alluded to Task<TResult> several times, so I thought I’d share a few related thoughts on Task<TResult> and the async\/await keywords. As both Wes and Eric […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/3096","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/360"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=3096"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/3096\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/58792"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=3096"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=3096"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=3096"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

In Eric’s last post on monads<\/a>, he talks about some of the C# LINQ operators, and how they can easily be implemented on top of types that correctly implement a Unit and a Bind method:<\/p>\n