OneOf

The OneOf library is owned by Harry McIntyre. It seems to be one of the better-known functional libraries out there, and folks I’ve talked to have recommended this one more than any other.

Its stated intention is to provide “F#-like” DUs in C#. To give them a test run, I’ve redeveloped all my code samples from Chapter 6 using OneOf to see how it compares.

First, the CustomerOffering union type looks like this:

var customerOffering = new OneOf<Holiday, HolidayWithMeals, DayTrip>();

Note here that there is no abstract base class. With this library, all the DUs we create are of the type OneOf<T, T, T> or however many types we attach to the union.¹ This makes it easier to declare unions on the fly, without needing to create the additional code infrastructure required by my method.

Since there’s no abstract base class, however, it’s necessary instead to use the built-in OneOf Match() function to collapse the union down to a concrete type. This is how our sample from Chapter 6 determining which format method to call would look:

public string formatCustomerOffering(
    OneOf<Holiday, HolidayWithMeals, DayTrip> c) =>
    c.Match(
        x => this.formatHoliday(x),
        x => formatHolidayWithMean(x),
        x => formatDayTrip(x)
    );

This code is nice and neat, but you should bear a few points in mind when comparing it to our version:

• There’s no default match, as when using a switch expression, so every single member type of the union has to have a switch expression matched. This may not be a problem if we want to ensure that every possible member of the union has a specific handler.

• Use of the switch expression when keyword to examine the values of the properties of the type we’re examining isn’t possible. That logic would have to be written into the Match function somehow.

• Each match type has to have the same return value, unless you convert to yet another union type! This may not be an issue if you’re constructing some sort of feedback message to the end user, however.

To get a concrete, real object out of the union type, we can use a set of functions to check the real type and then convert it over:

var offering = GetCustomerOffering();
if(offering.IsT0)
{
    var holiday = offering.AsT0;
    // do something with the holiday type
}
if(offering.IsT1)
{
    var holidayWithMeals = offering.AsT1;
    // do something with the HolidayWithMeals type
}
if(offering.IsT2)
{
    var dayTrip = offering.AsT2;
    // do something with the DayTrip type
}

Note that this is being handled generically, so the types are simply referred to as T1, T2, etc. The order they’re listed in the definition of the DU determines which number corresponds to which type.

This library has a whole load of built-in classes too, which are there to use in unions. They have names like Some, None, Yes, No, and Maybe. Despite the names, these can’t be used to create a Something<T> class as we did in Chapter 7; they’re just handy types to use when there is no return value and we’d like to return something descriptive to the outside world.

To create a true Maybe with OneOf, we’d need to define our own:

public class Something<T>
{
    public T Value { get; set; }
}

public OneOf<Something<Holiday>,None> GetHoliday() { }

The None class here is out of the OneOf library. It’s only purpose is to signify that no data was found, so it’s perfectly usable here. No Bind() or Map() functions are associated with the OneOf classes, which are purely to be used as DUs; it’s not possible to use an instance of OneOf as a monad.

Nothing is stopping you from writing your own Bind() to extend a OneOf DU into a true monad, however:

public static OneOf<Something<TOut>, None> Bind<TIn, TOut>(
  this OneOf<Something<TIn>, None> @this,
  Func<TIn, TOut> f)
{
    if (!@this.IsT0) return new None();
    var sth = @this.AsT0;
    var returnValue = f(sth.Value);
    return new Something<TOut>
    {
        Value = returnValue
    };
}

OneOf is certainly a nice, easy-to-use, lightweight library. If you feel that the loss in flexibility compared to creating your own custom unions is acceptable, it’s a worthwhile addition to your codebase. I’d certainly have no issues if someone asked to include it on a project I was working on.

One thing to bear in mind is that you can create DUs like a Maybe with OneOf, but you can’t make it a monad—there are no implementations of the Map() or Bind() functions. If you really want the monad functionality, you might need to look into other libraries or make your own.

LanguageExt

Owned by Paul Louth, and found in NuGet as LanguageExt.Core, this library is an attempt to implement as much of the functional paradigm as is possible in C#.

LanguageExt is a very large library of classes, static functions, and other features. I can’t hope to describe all of it here, as that would probably fill an entire chapter! I’ll restrict myself to just presenting the features that match functional content I’ve covered here already, and hopefully give a flavor of how LanguageExt is to use.

Before I begin, most of the functions and types required are part of a large partial class called Prelude. It might be worth adding this line to your global using statements file:

using static LanguageExt.Prelude;

Once that’s done, it should be possible to construct most monads and other structures with a simple function call.

public static Option<string> MakeGreeting(int employeeId) =>
    employeeId.Bind(empRepo.GetById)
        .Map(x => "Hello " + x.Salutation + " " + x.Name);

public Option<Employee> GetById(int id)
{
    try
    {
        var emp = this.DbConnection.GetFromDb(id);
        return emp == null
            ? Option<Employee>.None
            : Option<Employee>.Some(emp);
    }
    catch(Exception e)
    {
        return Option<Employee>.None
    }
}

var result = empRepo.GetById(10);
var message = result.Match(s => "Hi there, " + s.Name,
    () => "I don't know who you are, but Hi all the same");

public string formatName(Either<ChineseName, BritishName> n) =>
    n.Match(
        bn => bn.Honorific + " " + bn.FirstName + " " +
            string.Join(" ", bn.MiddleNames) + " " + bn.LastName,
        cn => cn.FamilyName + " " + cn.GivenName + " " +
            cn.Honorific + " "" + cn.CourtesyName + """);

var getCastForFilm((Film x) => this.castRepo.GetCast(x.Filmid);
var getCastForFilmM = getCastForFilm.Memo(x => x.Id.ToString());

[Fact]
public void memoized_functions_should_not_call_again_with_the_same_parameter()
{
    var timesCalled = 0;
    var add10 = (int x) => { timesCalled++; return x * 10; };
    var add10M = add10.Memo();

    add10M(1);
    add10M(2);
    add10M(1);

    timesCalled.Should().Be(2);
}

using static LanguageExt.Prelude;

var reader = Reader<int, int>(e => e * 100)
    .Map(x => x / 50)
    .Map(x => x.ToString());

var result = reader.Run(100);

var result1 = State<int, int>(x => (10, x))
    .Bind(x => State<int, int>(s => (x * s, s)))
    .Bind(x => State<int, int>(s => (x - s, s)))
    .Bind(x => State<int, int>(s => (x, s - 5)))
    .Bind(x => State<int, int>(s => (x / 5, s)));

var (finalValue, finalState, _) = result1(10);
// finalValue = 18
// finalState = 5

Functional.Maybe

The Functional.Maybe library is currently maintained by Andrey Tsvetkov, based on a now-abandoned project called Data.Maybe by William Casarin.

This project is a fairly lightweight implementation of the Maybe and Either monads, and may well be of interest if those are the only bits of the functional paradigm you’re wanting to inject into your codebase.

Rather than implementing the Maybe monad as a DU via an abstract base class, this library implements it as a readonly struct with a bool property that can be used to determine whether there is a value inside the Maybe.

Here’s an implementation of a Fahrenheit-to-Celsius temperature conversion function using Functional.Maybe:

public string FarenheitToCelsius(decimal input) =>
input.ToMaybe()
    .Select(x => x - 32)
    .Select(x => x * 5)
    .Select(x => x / 9)
    .Select(x => Math.Round(x, 2))
    .Select(x => x.ToString())
    .Value;

To better tie in with the existing .NET LINQ syntax, the Bind() function is called Select() here. Whether this is a confusing overload of an existing term or a comforting use of a familiar term is a decision I leave to you.

This is how you’d use the Maybe as the return type from a function that gets data from an external source—to represent the uncertainty of any data being received back:

public Maybe<Employee> GetById(int id)
{
    try
    {
        var e =  this.DbConnection.GetFromDb(id);
        return e.ToMaybe();
    }
    catch (Exception e)
    {
        return Maybe<Employee>.Nothing;
    }
}

The code is pretty straightforward. You don’t necessarily have to use the ToMaybe() function; Maybe<T> has a constructor, but I find this syntax cleaner.

This method doesn’t use inheritance, and there is no Match() extension method, so the way to move from the Maybe to a real, concrete value is to check for a value and then return whatever you want based on it:

var e = this.EmployeeRepo.GetById(24601);
var message = e.HasValue
    ? "Hello " + e.Value.Name
    : "I don't believe we've met, have we?";

A few extra bits of functional theory are included with the version of Maybe in this library. A Tap() function is also available, here called Do(). The Do() function executes only if the source Maybe has a value, so it’s the equivalent of my OnSomething() function:

var taxData = this.EmployeeRepo.GetById(24601)
    .Do(x => this.logger.LogInfo("got employee " + x.Id)
    .Select(x => this.payrollRepo.GetTaxInfo(x.TaxId));
    .Do(x => "Got his tax too!");

In addition, a nifty Or() function acts like an alt combinator (see “Alt Combinator”), but with the monad flow feature integrated into it.

One big difference from our version is that the parameter set has no params list of functions and also requires that every function provided to the alt combinator has no parameters and returns a Maybe type. The James Bond function from Chapter 5 might work, provided each lookup function returns something like a Maybe<SecretAgent>, like this:

var jbId = "007";
var jamesBond = this.hotelService.ScanGuestsForSpies(jbId)
    .Or(() => this.airportService.CheckPassengersForSpies(jbId))
    .Or(() => this.barService.CheckGutterForDrunkSpies(jbId));

    if(jamesBond.HasValue)
        this.deathTrapService.CauseHorribleDeath(jamesBond);

This code requires a few extra hoops to jump through, but it’s still usable.

Also worthy of mention is that the library comes with an extension method for one of my favorite C# features: the dictionary. Instead of trying to get a key, you can get a Maybe from it instead. I like this idea very much.

The F# Programming Language

Oh, come on. You’re just being silly now!

This said, it’s not a NuGet package, but you can reference .NET projects written in F# from C# projects, so…​yes, I suppose so. This topic is well outside the scope of this book, however.

Summary

Quite a few libraries are available already in NuGet if you want the initial creation of functional structures handled for you. These range from the fully comprehensive (LanguageExt) to those that just supply a few functional features each (OneOf, Functional.Maybe, etc.).

Whether you want to use some, all, or none of these libraries is entirely up to you.

Using none of them will mean you’ll have to develop your own functional classes and extension methods. This is a little more work, but means you won’t be dependent upon a third-party library, and you’ll be able to customize your classes and methods to work however you’d like.

Using a library will save you that effort, but force you to work to the style required by that library. You’ll also be dependent on that library’s development team to continue to produce updates.

As with all decisions, you need to consider the risks and benefits, weigh them, and see which way the scales tilt.

I can’t advise you on this, but I’ll be honest—I don’t use a library. I have my own custom functional library that I port between projects—either in part or in its entirety, depending on what I need to do. Having said that, there’s nothing wrong with using one. The libraries I’ve listed in this chapter are excellent pieces of work, and no doubt will be invaluable to you if you choose to use them.

In the next chapter, I’m going to put everything together into a game you can write and play yourself—entirely in functional-style C#. Have fun!