Function composition in C#

When we refactor code how can we be confident that we don't break anything?

3 of the most important things that allow us to refactor fearlessly are:

Side effect free - or pure - expressions
Statically typed expressions
Tests

In this article we will solely focus on the aspect of side effects and strictly speaking on how to identify them. Being able to identify side effects in our programs clearly is the precondition for eliminating them.

Why avoid side effects?

Continue reading →

Have you ever wanted to try out PureScript but were lacking a good way to get started?

If you

Have some prior functional programming knowledge - maybe you know Haskell,Elm,F#,or Scala,etc.
Want to solve a small task with PureScript
And want to get started quickly

This post is for you!

In this post we will walk through setting up and implementing a small exemplary PureScript application from scratch.

Continue reading →

In this article I would like to present a minimal implementation of a music data type and everything that is needed to turn that into audible sound from an Elm application.

We will see how to transcribe an existing composition - an excerpt from Chick Corea's Children's Songs No. 6 - and listen to the result right here,embedded in this article.

From a music data type to performance

My colleague Jonas recently pointed out the presentation Making Algorithmic Music by Donya Quick to me. Donya Quick shows how she uses the Haskell library Euterpea to produce algorithmic music.

It got me really excited about the idea of porting this to Elm and to be able to use this in web applications.

In the following we will see the core data types and algorithms from Euterpea ported to Elm. To focus on the core concepts the implementation is stripped down to the minimum that is required to transcribe and perform an existing polyphonic piece of music (for a single instrument).

Continue reading →

This post is about how to implement well structured,and purely functional command line applications in Scala using PureApp.

PureApp originated in an experiment while refactoring out some glue code of an interactive command line application. At the same time it was inspired by the Elm Architecture Pattern,and scalaz's SafeApp,as well as scalm.

To show the really cool things we can do with PureApp,we will implement a self-contained example application from scratch.

This application translates texts from and into different languages. And it provides basic user interactions via the command line.

The complete source code is compiled with tut. Every output (displayed as code comments) is generated by tut.
Continue reading →

In this post we will see how applicatives can be used for validation in Scala. It is an elegant approach. Especially when compared to an object-oriented way.

Usually when we have operations that can fail,we have them return types like Option or Try. We sequence operations and once there is an error the computation is short circuited and the result is a None or a Failure.

Applicatives allow us to compose independent operations and evaluate each one. Even if an intermediate evaluation fails. This allows us to collect error messages instead of returning only the first error that occurred.

A classic example where this is useful is the validation of user input. We would like to return a list of all invalid inputs rather than aborting the evaluation after the first error.

Scala Cats provides a type that does exactly that. So let's dive into some code and see how it works.

Continue reading →

After some initial struggles,the chapter Functional Parsers from the great book Programming in Haskell by Graham Hutton,where a basic parser library is built from scratch,significantly helped me to finally understand the core ideas of parser combinators and how to apply them to other programming languages other than Haskell as well.

While I recently revisited the material and started to port the examples to Scala I wasn't able to define a proper monad instance for the type Parser[A].

The type Parser[A] alias was defined like this:

type Parser[A] = String =>Option[(A,String)] // defined type alias Parser

To test the monad laws with discipline I had to provide an instance of Eq[Parser[A]]. Because Parser[A] is a function,equality could only be approximated by showing degrees of function equivalence,which is not a trivial task.

Also the implementation of tailRecM was challenging. (I couldn't figure it out.)

Using existing abstractions

Continue reading →

Most config libraries use a stringly typed approach.

Some handle runtime failures due to invalid configuration schemas by leveraging data types like Option or Result to represent missing values or errors. This allows us to handle these failures by either providing default values or by providing decent error messages.

This is a good strategy that we should definitely stick to.

However,the problem with default values is that we might not even notice if the configuration is broken. This could potentially fail in production. In any case an error e.g. due to a misspelled config property will be observable at runtime at the earliest.

Wouldn't it be a great user experience (for us developers) if the compiler told us if the configuration schema is invalid? Even better,imagine we could access the configuration data in a strongly typed way like any other data structure,and with autocompletion.

Moreover,what if we didn't have to write any glue code,not even when the configuration schema changes?

This can be done with the costs of an initial setup that won't take more than probably around 5 minutes.

Continue reading →

In this post I will look at a practical example where the combined application (through monad transformers) of the state monad and the either monad can be very useful.

I won't go into much theory,but instead demonstrate the problem and then slowly build it up to resolve it.

You don't have to be completely familiar with all the concepts as the examples will be easy to follow. Here is a very brief overview:

Continue reading →

If your API overflows with Boolean parameters,this is usually a bad smell.

Consider the following function call for example:

toContactInfoList(csv,true,true)

When looking at this snippet of code it is not very clear what kind of effect the two Boolean parameters will have exactly. In fact,we would probably be without a clue.

We have to inspect the documentation or at least the parameter names of the function declaration to get a better idea. But still,this doesn't solve all of our problems.

The more Boolean parameters there are,the easier it will be for the caller to mix them up. We have to be very careful.

Moreover,functions with Boolean parameters must have conditional logic like if or case statements inside. With a growing number of conditional statements,the number of possible execution paths will grow exponentially. It will become more difficult to reason about the implementation code.

Can we do better?

Sure we can. Lambdas and combinators come to the rescue and I'm going to show this with a simple example,a refactoring of the function from above.

This post is based on a great article by John A De Goes,Destroy All Ifs — A Perspective from Functional Programming.

I'm going to take John's ideas that he backed up with PureScript examples and present how the same thing can be elegantly achieved in Scala.

Continue reading →

I'm currently working on an sbt plugin that generates Scala case classes at compile time to model JSON API responses for easy deserialization especially with the Scala play-json library.

The plugin makes it possible to access JSON documents in a statically typed way including auto-completion. It takes a sample JSON document as input (either from a file or a URL) and generates Scala types that can be used to read data with the same structure.

Let's look at a basic example,an app that prints the current Bitcoin price to the console.

Continue reading →

Function composition is about the essence of programming. Complex problems can be solved by decomposing them into many smaller problems that each can be worked out easily. Finally those small pieces have to be put together to form the overall solution. One way of combining these small pieces is function composition.

Also function composition is a great tool that makes the code more compact and reduces noise. Because of the concise syntax there are fewer possibilities to make mistakes like mixing up parameters e.g.

In this post I will show how function composition can be implemented in C# and how it is related to currying and partial application. Also I will discuss the pros and cons of function composition in C# and point out an alternative. All C# source code from this post can be downloaded here.

Definition

Function composition is defined like this: $(f \circ g)(x) = f(g(x))$ . The composition operator $\circ$ combines the functions $f$ and $g$ so that the output of $g$ is pipelined into $f$ which creates an entirely new function. It is important that the input and output types match. A function g of type (a -> b) can be composed with a function f of type (b -> c) because the result of g is of type b which is the input type for f. The composed function therefore takes an argument of type a (which is the input type of g) and produces a c (which is the output type of f). In C# notation a function g of type Func<T1, T2> can be composed with a function f of type Func<T2, T3> to produce a function of type Func<T1, T3>.

In functional languages composition is usually a built-in higher-order function or operator. In Haskell the dot . is the composition operator. E.g. The functions f and g can be composed to create a new function h like this:

> let h = f . g

The type signatures of the composition operators have to be in Haskell notation:
(b -> c) -> (a -> b) -> a -> c

or in C# notation:
<Func<T2, T3>, Func<T1, T2>, Func<T1, T3>>

Implementation in C#

Since the composition operator is an infix operator we can imitate this in C# with extension methods. Here is the composition function in C#:

public static Func<T1, T3> Compose<T1, T2, T3>(this Func<T2, T3> f, Func<T1, T2> g)
{
    return x => f(g(x));
}

The following example shows how the composition function can be used:

var f = new Func<string, IEnumerable<string>>(s => s.Split(new[] {' '}));
var g = new Func<string, string>(s => s.ToUpper());

var h = f.Compose(g);

Assert.That(h("foo bar"), Is.EqualTo(new[]{ "FOO", "BAR" }));

Currying

In Haskell and F# functions are curried by default. That means that multiple input parameters can be applied to a function one by one. Each application of an argument returns a new curried function until the last argument is applied. By partially applying arguments it is possible to create functions that can easily be composed.

A function that takes a number, adds 1 and multiplies the result by 2 can be composed of the partially applied functions (+) and (*) like this in Haskell:

> let add1AndMultiplyBy2 = (* 2) . (+ 1)

To be able to do this in C# nicely we need extension methods that convert uncurried functions to their curried form. E.g. a function of type Func<T1, T2, T3> in curried form will have the signature Func<T1, Func<T2, T3>>. When the first argument T1 is applied the result is a function of type Func<T2, T3>. Next the argument T2 can be applied and the result of that is a value of type T3.

Here are all the extension methods for converting functions with up to 16 input parameters. The example above can now be translated into C#:

// first we have to create curried versions of add and multiply
var add = new Func<int, int, int>((x, y) => x + y).Curry();
var multiply = new Func<int, int, int>((x, y) => x * y).Curry();

var add1AndMultiplBy2 = multiply(2).Compose(add(1));

Note that also uncurried functions can be partially applied. But the syntax is way more clumsy:

var add1AndMultiplBy2 = new Func<int, int>(x => multiply(2, x))
    .Compose(new Func<int, int>(x => add(x, 1)));

Function composition in practice

Let's examine a problem and it's solution in Haskell.

Problem:

Create a function that reverses all the words in a given string while the order of words has to stay the same.

Example:

> reverseWords "Foo bar" -- should return "ooF rab"

Solution:

> let reverseWords = unwords . map reverse . words

The input for unwords is the output of map reverse (where map reverse is a partially applied function). The input for map reverse again is the output of words. (All of these functions are defined in the standard Haskell Prelude module).

In order to translate this to C# we first need to define the four functions: Words, Unwords, Map and Reverse.

static readonly Func<string, IEnumerable<string>> Words =
    s => s.Split(new[] { ' ' }, StringSplitOptions.RemoveEmptyEntries);

static readonly Func<Func<string, string>, IEnumerable<string>, IEnumerable<string>> Map =
    (f, list) => list.Select(f);

static readonly Func<string, string> Reverse =
    s => new String(s.Reverse().ToArray());

static readonly Func<IEnumerable<string>, string> Unwords =
    list => String.Join(" ", list);

Now we can compose these functions and check if the created function processes the input string correctly:

var reverseWords = Unwords
    .Compose(Map.Curry()(Reverse))
    .Compose(Words);

Assert.That(reverseWords("Foo bar"), Is.EqualTo("ooF rab"));

Evaluation of function composition in C#

The C# version with function composition looks quite good.

The code is mostly declarative and therefore easy to understand
No types have to be specified because type inference works well
Function arguments don't have to be mentioned explicitly (which is also called pointfree style)

Still there are some drawbacks:

Readability
Compared to Haskell or F# readability is not quite as good. The code is not as concise and compact as it theoretically could be because of several reasons:

The composition function has to have a name and cannot simply be a symbol (e.g. an overloaded operator)
Parameters have to be enclosed in parentheses
Currying has to be done explicitly
(Note that Map could have been defined in curried form easily. But this isn't always possible as many functions come from other libraries that cannot be changed.)

Order of application
With function composition as it is defined in mathematics and in Haskell and as it is shown here the order of application is from right to left. But as we read the code from left to right this can be confusing.

Off course the solution to this is easy. We could implement a "forward composition" function as exists in F# with the (>>) operator.

Usability
Functions have to be defined as (or assigned to) Func<...> delegates as properties, fields or local variables in order to apply composition. This is not always handy because "normal" methods have to be converted.

Composition vs. pipelining

An alternative to function composition is pipelining. In F# pipelining can be done with the forward pipe operator |> which passes the result of the function on the left side to the function on the right side. Here is the example from above in F# using pipelining:

> "Foo bar" |> words |> Array.map reverse |> unwords;;
val it : string = "ooF rab"

Pipelining in C# can be done with the help of extension methods. If we define the functions from the example above as extension methods we can compose the reverseWords function using the dot notation:

(Note that we don't need Map here because Select does the same thing.)

Func<string, string> reverseWords =
    s => s.Words()
        .Select(StringExtensions.Reverse)
        .Unwords();

The pros are:

Simple infix operator
Application from left to right
It works without partial application
It is more idiomatic to the C# language

Here is a brief comparison of the two approaches.

	Function composition	Pipelining
Simple operator (symbol)	NO	YES
Infix notation	YES	YES
Pointfree style	YES	NO
Application from left to right	YES (with forward composition)	YES
Works without partial application	NO (not with multiple parameter functions)	YES
Idiomatic	NO (this is arguable)	YES

Conclusion

We've seen that function composition can easily be done in C#. Nevertheless it still doesn't feel as natural as it does in functional languages like F# or Haskell because the syntax is not as nice and clean.

If we want to do functional programming in C# a good alternative to function composition is pipelining with the use of extension methods.

Anyway if you want to get into functional programming and try to understand function composition, currying, partial application and higher-order functions it can be a good starting point and a good exercise to implement all of this in C# or in whatever language you are comfortable with.

All C# source code from this post can be downloaded here.

Leif Battermann

Functional Programming Fu

Identify Side Effects And Refactor Fearlessly

Why avoid side effects?

PureScript Case Study And Guide For Newcomers

Elm And The Algorithm Of Music

From a music data type to performance

Interactive Command Line Applications In Scala –Well Structured And Purely Functional

How To Use Applicatives For Validation In Scala And Save Much Work

Parsers in Scala built upon existing abstractions

Using existing abstractions

Strongly Typed Configuration Access With Code Generation

Error and state handling with monad transformers in Scala

Use lambdas and combinators to improve your API

Modelling API Responses With sbt-json –Print Current Bitcoin Price

Leif Battermann

Functional Programming Fu

Definition

Implementation in C#

Currying

Function composition in practice

Evaluation of function composition in C#

Composition vs. pipelining

Conclusion