Understanding Delegates and Higher-Order Functions in C#

by Zoran Horvat
September 07, 2017

With every next release of the C# language specification, we had more and more of the funcitonal concepts at our disposal. In this article, we will focus on delegates as the primary tool for building higher-order functions. The underlying mechanism behind Func delegates and lambdas may be a mystery for you, and this will be the opportunity to clarify that.

Let me put it this way. There are no higher-order functions when it comes to executing code on a computer.

What is the computer doing? It is executing machine instructions one after another. Some of the instructions are jumps. When we call a function in a programming language, that function is compiled into a block of machine instructions. I’m not speaking of byte code and intermediate language. I’m speaking about the ultimate product of all compilation and linking steps – the final binary executable which the target machine can execute. The final product of a function in a language such as C# is the contiguous block of machine instructions.

The function which calls it is also a block of machine instructions, and right in the middle of it there will be a jump instruction pointing to the first instruction in the called function. This jump is the very last step in the process of calling the function. And when the function execution completes, with the result stored in a predetermined location, it will end in another jump instruction. Only this time the jump target will be the machine instruction right after the initial jump. In other words, execution of the calling function will continue at the spot where it was paused.

And that is it. You see, there is no magic behind functions. Then, how do the higher-order functions fit in there? Well, they have to be turned into first-order functions at some point before being executed, quite literally. It is the duty of the compiler to transform higher-order functions into first-order functions so that they can be compiled for execution on the underlying hardware. The basic form of doing that is easy. There are some complications, but we will skip them and cover the principal solution here. The magical words are “delegate” and “closure.” We will cover delegates in this article.

Delegate is pointing to the function, while at the same time keeping record of function’s arguments. And closure is the delegate, accompanied with the environment which contains the delegate’s free variables. Now free variables. Those are the variables used in the function’s body, but not passed to the function as arguments. We say that free variables are coming from environment in which the function executes.

Example will come handy at this point. Take a look at the function which multiplies a value by two:

int f(int x) => 2 * x;

This is the first-order function with no free variables. The only variable it needs is x, and x is passed as the argument. Let’s turn this function into a delegate, using lambda syntax:

Func<int, int> f = x => 2 * x;

When this code compiles, variable f will become a true object, like any other. This object will have a field, and that field will point to the code block which multiplies the argument by two. This object will also somehow encode the fact that there is an integer argument to be prepared before execution can jump to the appointed block of code.

Why the delegates, you may ask? The truth is that with delegates, we have turned the function into an object. We have a common object, like any other in an object-oriented language, and the object is carrying a function with it. That’s the only thing that makes it special. We can assign this object to another variable:

Func<int, int> f = x => 2 * x;
...
var another = f;

Or pass it to another function as an argument:

Func<int, int> f = x => 2 * x;
...
Another(f);

What is f then? Is it a function? Is it a value? Is it an object of some class? Nobody cares, really. The function called Another here is the higher-order function; f in my code is the lambda. Yet all of those are just names for specific concepts. Down at the bottom, all of these are just objects. When you really get to the bottom of it, you will see that there is no distinction between higher-order functions and first-order functions.

Every first-order function can be turned into a delegate, which is an object. And every delegate can be passed as the common argument to another function, which, as the side effect, makes that one a higher-order function. One practical trick related to delegates is that C# helps us invoke them like ordinary functions. Delegate is an object, right? As the object, it exposes a public interface which contains the Invoke method:

Func<int, int> f = x => 2 * x;
...
int y = f.Invoke(5);

Well, this is cumbersome and it also hides the fact that f is supposed to act as the function. That is why C# language comes with the shorthand syntax in which f is treated like a common locally accessible function:

Func<int, int> f = x => 2 * x;
...
int y = f(5);

And that is all that there is, really. Delegate classes and lambdas were invented to help us construct and pass functions like common objects. The way in which we will build on that simple concept is fascinating, though. It will put entire theory and practice of higher-order functions at our disposal. And then, that little question of closures remains.