Does an IO monad make sense in a language like C#

Question

After spending a lot of time reading and thinking, I think I have finally grasped what monads are, how they work, and what they\'re useful for. My main goal was to figure ou

Answer 1

At work, we use monads to control IO in our C# code on our most important pieces of business logic. Two examples are our financial code and code that finds solutions to an optimization problem for our customers.

In our financial code, we use a monad to control IO writing to and reading from our database. It essentially consists of a small set of operations and an abstract syntax tree for the monad operations. You could imagine it's something like this (not actual code):

interface IFinancialOperationVisitor : IMonadicActionVisitor {
    R GetTransactions(GetTransactions op);
    R PostTransaction(PostTransaction op);
}

interface IFinancialOperation {
    R Accept(IFinancialOperationVisitor visitor);
}

class GetTransactions : IFinancialOperation>> {
    Account Account {get; set;};

    public R Accept(IFinancialOperationVisitor visitor) {
        return visitor.Accept(this);
    }
}

class PostTransaction : IFinancialOperation> {
    Transaction Transaction {get; set;};

    public R Accept(IFinancialOperationVisitor visitor) {
        return visitor.Accept(this);
    }
}

which is essentially the Haskell code

data FinancialOperation a where
     GetTransactions :: Account -> FinancialOperation (Either Error [Transaction])
     PostTransaction :: Transaction -> FinancialOperation (Either Error Unit)

along with an abstract syntax tree for the construction of actions in a monad, essentially the free monad:

interface IMonadicActionVisitor {
    R Return(T value);
    R Bind(IMonadicAction input, Func> projection);
    R Fail(Errors errors);
}    

// Objects to remember the arguments, and pass them to the visitor, just like above

/*
Hopefully I got the variance right on everything for doing this without higher order types, 
which is how we used to do this. We now use higher order types in c#, more on that below. 
Here, to avoid a higher-order type, the AST for monadic actions is included by inheritance 
in 
*/

In the real code, there are more of these so we can remember that something was built by .Select() instead of .SelectMany() for efficiency. A financial operation, including intermediary computations still has type IFinancialOperation. The actual performance of the operations is done by an interpreter, which wraps all the database operations in a transaction and deals with how to roll that transaction back if any component is unsuccessful. We also use a interpreter for unit testing the code.

In our optimization code, we use a monad for controlling IO to get external data for optimization. This allows us to write code that is ignorant of how computations are composed, which lets us use exactly the same business code in multiple settings:

• synchronous IO and computations for computations done on demand
• asynchronous IO and computations for many computations done in parallel
• mocked IO for unit tests

Since the code needs to be passed which monad to use, we need an explicit definition of a monad. Here's one. IEncapsulated essentially means TClass. This lets the c# compiler keep track of all three pieces of the type of monads simultaneously, overcoming the need to cast when dealing with monads themselves.

public interface IEncapsulated
{
    TClass Class { get; }
}

public interface IFunctor where F : IFunctor
{
    // Map
    IEncapsulated Select(IEncapsulated initial, Func projection);
}

public interface IApplicativeFunctor : IFunctor where F : IApplicativeFunctor
{
    // Return / Pure
    IEncapsulated Return(A value);
    IEncapsulated Apply(IEncapsulated> projection, IEncapsulated initial);
}

public interface IMonad : IApplicativeFunctor where M : IMonad
{
    // Bind
    IEncapsulated SelectMany(IEncapsulated initial, Func> binding);
    // Bind and project 
    IEncapsulated SelectMany(IEncapsulated initial, Func> binding, Func projection);
}

public interface IMonadFail : IMonad {
    // Fail
    IEncapsulated Fail(TError error);
}

Now we could imagine making another class of monad for the portion of IO our computations need to be able to see:

public interface IMonadGetSomething : IMonadFail {
    IEncapsulated GetSomething();
}

Then we can write code that doesn't know about how computations are put together

public class Computations {

    public IEncapsulated> GetSomethings(IMonadGetSomething monad, int number) {
        var result = monad.Return(Enumerable.Empty());
        // Our developers might still like writing imperative code
        for (int i = 0; i < number; i++) {
            result = from existing in r1
                     from something in monad.GetSomething()
                     select r1.Concat(new []{something});
        }
        return result.Select(x => x.ToList());
    }
}

This can be reused in both a synchronous and asynchronous implementation of an IMonadGetSomething<>. Note that in this code, the GetSomething()s will happen one after another until there's an error, even in an asynchronous setting. (No this is not how we build lists in real life)