by Zoran Horvat
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.
If you wish to learn more, please watch my latest video courses
In this course, you will learn the basic principles of object-oriented programming, and then learn how to apply those principles to construct an operational and correct code using the C# programming language and .NET.
As the course progresses, you will learn such programming concepts as objects, method resolution, polymorphism, object composition, class inheritance, object substitution, etc., but also the basic principles of object-oriented design and even project management, such as abstraction, dependency injection, open-closed principle, tell don't ask principle, the principles of agile software development and many more.
In this course, you will learn how design patterns can be applied to make code better: flexible, short, readable.
You will learn how to decide when and which pattern to apply by formally analyzing the need to flex around specific axis.
This course begins with examination of a realistic application, which is poorly factored and doesn't incorporate design patterns. It is nearly impossible to maintain and develop this application further, due to its poor structure and design.
As demonstration after demonstration will unfold, we will refactor this entire application, fitting many design patterns into place almost without effort. By the end of the course, you will know how code refactoring and design patterns can operate together, and help each other create great design.
In four and a half hours of this course, you will learn how to control design of classes, design of complex algorithms, and how to recognize and implement data structures.
After completing this course, you will know how to develop a large and complex domain model, which you will be able to maintain and extend further. And, not to forget, the model you develop in this way will be correct and free of bugs.
Zoran Horvat is the Principal Consultant at Coding Helmet, speaker and author of 100+ articles, and independent trainer on .NET technology stack. He can often be found speaking at conferences and user groups, promoting object-oriented and functional development style and clean coding practices and techniques that improve longevity of complex business applications.