The Book of F#: Breaking Free with Managed Functional Programming

About the Author

Dave Fancher has been developing software with the .NET Framework for more than a decade. He is a familiar face in the Indiana development community as both a speaker and participant in user groups around the state. In July 2013, Dave was recognized as a Microsoft MVP (Most Valuable Professional) for Visual F#. When not writing code or writing about code at davefancher.com, he can often be found watching a movie or gaming on his Xbox One.

About the Technical Reviewer

Over the last 14 years, Kevin Miller has worked on exciting projects with truly great people while unsuccessfully pleading with compilers to break their steadfast rules. He enjoys studying the inherent beauty of logic, and when inspired by the muses, actually codes something deserving a modicum of pride from time to time. His interests lie in security, distributed systems, and data, but he has a short attention . . . squirrel!

Foreword

I met Dave at the Microsoft MVP Summit in Redmond in 2013. We witnessed something unexpected: F# caught fire. The language hadn’t changed drastically, but the attitudes of the developers at the Summit had. During the past year, MVPs had been learning about functional programming, and there was a new excitement around the language. Over the week, I learned of several C# MVPs who were jumping ship to F#. Dave and I talked about the transformation. We also talked about ethics in the context of object-oriented (OO) and functional programming (FP). Here is my story about that . . .

During college in the early 90s, I was immersed in operations management where the focus was quality, continuous improvement, just-in-time strategy, and waste elimination. W. Edwards Deming was a hero to my professors, and we studied Deming’s huge impact on Japanese manufacturing from the 1950s onward. Finding the root cause of defects and fixing them at the source was the good. Shipping defective product or tacking inspection at the end of the line was the bad. These ideas resonated with me deeply.

Continuous improvement seemed more than just a way to make widgets; it felt like a way to live life. It echoed Socrates’s concept of virtue; it evoked the story of Siddhartha, who sought truth over comfort. These are ideas about what should be, about merit, about substance over rhetoric, about correctness.

After graduation I rolled into a software development career. Depending on the company, it was either clown cars and cowboys, or rigid waterfall. Both were exciting, but no one in either environment was talking about quality or continuous improvement. When I would bring it up, I would get sad smiles from grizzled developers. Their eyes said, Son, don’t you realize this is war? The operating systems were crashy, the dev tools were buggy, and everything was closed source and proprietary. Thucydides said war is a rough master that brings most men’s characters to a level with their fortune. Likewise, when the development environment is bad, most developers will write bad code.

In 2001, a group of conscientious software developers got together in Snowbird, Utah and signed the Agile Manifesto. About a year later I discovered it. From my perspective, it seemed like a retelling of Deming, operations management, and Lean manufacturing. It was the first time in my career that I’d heard developers discussing quality and continuous improvement. There was hope!

After five years of test-driven development, pair programming, the SOLID principles (single responsibility, open/closed, Liskov substitution, interface segregation, and dependency inversion), and Scrum, my hope had mostly worn away. I continued to fight my tools, and it remained difficult to build quality software. Without discipline it was a train wreck. With discipline, process, and diligence, it was a hard slog.

Through pure good luck I encountered Erlang in 2007, and in 2009 I began working with F#. Functional programming consumed me. I learned about immutability, recursion, pattern matching, higher-order functions, referential transparency, code as data, and separation of behavior from data. As I learned and practiced I began to see the huge cost of OO. So much of what made my day-to-day coding life miserable was solvable with Erlang and F#. As I told people about FP, I again received those sad smiles that asked, Don’t you know we are at war? I took it differently this time. I decided, OK, sure. Let’s call it war. I’ll be on the side that’s looking at the root cause of defects. I’ll be on the side that wants to fix the problem at the source.

The next stage for Agile must be to fully unravel itself from OO.

Object-oriented programming had boldly promised to model the world. Well, the world is a scary place where bad things happen for no apparent reason, and in this narrow sense I concede that OO does model the world. OO as we have it mingles data and behavior; the result is low cohesion and tight coupling. In OO, there is shared mutable state, which makes concurrency impossibly difficult. In OO, logic is nondeterministic. In OO, the result of a function doesn’t simply depend on the arguments we pass in. The result may vary depending on arguments passed on previous calls to the function. How about mutations from other functions? How about data passed to the constructor? How about properties and fields? How about access from other threads? With every method call, we worry about the whole environment. Joe Armstrong describes the problem with OO languages like this: They’ve got all this implicit environment that they carry around with them. You wanted a banana, but what you got was a gorilla holding the banana and the entire jungle. OO is a dangerous place.

Alan Kay once said, "I invented the term object-oriented and I can tell you I did not have C++ in mind. What Alan Kay described was message passing, isolation between objects, and polymorphism. That describes the functional programming language Erlang better than it describes Java! So what the devil happened? Were C++, Java, and C# billion-dollar mondegreens (misheard lyrics)? Just imagine Alan Kay as Jimi Hendrix with a whole industry in an OO haze, mouthing, ’Scuse me while I kiss this guy." Who sold us this mess?

I’ll wind down with a lie that OO people who are learning FP tell one another: Learning FP will make you a better OO programmer. It rings true, and in the short run it may even be true, but as you internalize immutability, recursion, pattern matching, higher-order functions, code as data, separation of behavior from data, and referential transparency, you will begin to despise OO. Personally, I went from being a Microsoft C# MVP to feeling guilt every time I created a new class file. Once you understand the defects that can be avoided, it stops being a technical choice and becomes an ethical one.

The good news is F# is a great language, and this is a fantastic book. They both create an easy pathway from the OO world to a cleaner, safer functional world. I’m delighted you’re about to walk this path.

Bryan Hunter

CTO, Firefly Logic

Preface

Ever since I started touting the benefits of F#, people have asked me why I chose to learn F# over other functional languages like Scala, Erlang, or Haskell. This line of questioning presupposes that I intentionally set out to learn a functional language. In reality, adopting F# was an organic progression from C#.

My F# story begins late in the summer of 2010. I was burning out and my career was stagnating. My employer at the time was fairly risk-averse and had proprietary frameworks for nearly every facet of the application. After an extended amount of time in this environment, I lost sight of what I loved about developing software and did the worst thing anyone in this industry can do: I stopped learning.

It was around this time that the company hired a new architect who brought with him not only a wealth of technical knowledge but also something I’d lost: passion for the craft. His excitement reminded me of what I’d forgotten and gave me the kick I needed to get back in the game.

With renewed interest, I started looking at some of the technologies I missed while I was in that rut. Of everything I looked at, the one that really caught my attention was LINQ, a domain-specific language built upon functional principles to provide a unified mechanism for data access across disparate formats. It has been said that LINQ is a gateway drug for functional programming, and in my case, this was definitely true. I’d never really done any true functional programming before LINQ, so it was an exciting new world for me. Like many developers learning LINQ, I was introduced to it through the query syntax, but as my comfort level increased, I gradually started exploring how it worked.

Not long into my studies, I learned that query expressions were added only after some usability studies revealed that developers were confused by the lambda expressions and method chaining syntax. What struck me about this was how natural the method syntax felt. I even found myself favoring it over the query syntax in most cases. (Confession: To this day I can’t seem to remember the method syntax for an outer join.) As I continued to work with LINQ, I began to realize that the method syntax felt natural because it matched the way I think. I didn’t have terms for them at the time, but the functional concepts of delegation, higher-order functions, and composability really matched up with my mental model of how the world works.

It didn’t take long for me to start carrying over the functional concepts I learned from LINQ into other areas of our application. In doing so, I found that the quality of my work was improving and my code was getting more predictable. Despite this newfound power, I found myself getting increasingly frustrated with C#, but I couldn’t pinpoint exactly what was bothering me.

I was mowing the lawn on a hot, summer afternoon when I had my epiphany. On a whim, I’d included Hanselminutes #311 in that day’s yard-work podcast selection. The guests, Richard Minerich and Phillip Trelford, were discussing F#, a functional language built upon the .NET platform. I was already intrigued, but then Phillip made a quip that perfectly summarized one of my gripes about C#’s repetitive nature: Writing C# feels like filling out government forms in triplicate. As the conversation continued, Richard and Phillip touched on several other points, like improved predictability of code and streamlined type creation, that really struck a chord with me. By the end of the podcast, I was hooked and determined to take advantage of this powerful language called F#.

Since that day—despite its reputation as a niche language—F# has become one of the primary tools in my developer toolbox. It has played an important role in each of my recent projects, as my go-to language for business logic, unit testing, and prototyping. I even used F# to successfully orchestrate queue-based communication between services in a distributed application. As you read this book, it is my hope that you’ll recognize how F# can make you more productive and improve the quality of your code, regardless of the type of project you’re working on.

Acknowledgments

Although my name is on the cover, The Book of F# wouldn’t have been possible without the efforts of numerous people.

First, I need to thank the team at No Starch Press. Without them, writing a book would still be an item on my bucket list. In particular, I need to thank Bill Pollock and Alison Law. Bill’s encouragement, especially early in the process, gave this first-time author the confidence to take on this project. Alison’s experience was invaluable as she guided me through the waters of the publishing world and helped me prioritize the work.

To my good friend and official technical reviewer, Kevin Miller: thank you, thank you, thank you. Kevin went well beyond what I ever expected by taking as many as five passes over each chapter and regularly diving into the F# language spec in his attempts to find errors within the text and the code samples. Beyond his technical review duties, Kevin often acted as a sounding board for my sometimes crazy ideas. His dedication, suggestions, and attention to detail helped shape this book, and for that I’m truly grateful.

Another big thank you to Tomas Petricek. His community involvement and willingness to share his deep knowledge of F# was invaluable to me when I began learning the language. Tomas’s technical review of Chapter 11 and Chapter 12 really helped smooth out some of the rough edges, and this book has benefited greatly from his input.

Next, thank you to my friends and coworkers, who put up with months of my talking about F# and the writing process. (Sorry, you haven’t heard the last of it, either!) In particular, I need to thank Brian Kline. Brian read every word of this book as someone wanting to learn F#. No matter how many times I read through a chapter, he always managed to find a few typographical errors or point out areas where different wording would improve the message.

I’d never have had the opportunity to write this book if F# didn’t exist. For that, I thank the F# team for creating such an incredible language. Along those lines, I owe a debt of gratitude to the F# community for being so welcoming and engaging. Without the many community resources available to help people get started with F#, I don’t know that I’d have ever adopted it as part of my toolkit.

Finally, thank you to the people who were affected the most by this project: my family. I need to thank my parents not only for giving me life (as my mother likes to remind me), but also for letting me regularly take over a room in their house and escape into the creative process during weekend visits. Of course, I don’t know if I could have completed this project without the love and support of my wife, Esther, and my daughter, Nadia. Thank you for understanding the late nights and reclusive weekends that were necessary to make this dream a reality. I love you all.

Introduction

From the beginning, one of the promises of the .NET Framework has been language interoperability; that is, developers targeting the platform could write code in one language and interact with code written in another language through the Common Language Infrastructure (CLI).

Early examples often included a library written in C# utilizing a library written in Visual Basic, or vice versa. Ideally, this would allow developers to solve different problems using the best language for the job. In practice, things didn’t really work out that way, as developers tended to adopt either C# or Visual Basic and build entire solutions with that language. This is hardly surprising given that, with few exceptions, the differences between the languages have historically been purely syntactic (and the languages have only grown closer as the platform has matured).

Now, after more than a decade, F# has emerged as the third major language in the .NET ecosystem. But what does F# offer that the traditional .NET languages do not, and why should you care?

F# brings functional programming to .NET development. While both C# and Visual Basic have some functional aspects, they are, first and foremost, object-oriented languages; they’re concerned primarily with behavior and managing an ever-changing system state. In contrast, F# is a functional-first language, concerned with the application of functions to data. This difference has a dramatic impact not only on how you write code, but also on how you think about it.

As you read through this book, you’ll learn how F#’s functional nature enforces a variety of constraints that may seem limiting at first, but once you embrace them you’ll likely find that your code is smaller, more correct, and more predictable. Furthermore, you’ll discover how F#’s many unique constructs simplify common development tasks, thus allowing you to focus on the problem you’re trying to solve rather than the plumbing required by the compiler. These aspects make F# a perfect complement to C# and Visual Basic, often paving the way toward realizing .NET’s goal of mixed-language solutions.

Whom Is This Book For?

I have been developing software professionally with C# on the .NET platform since its earliest public releases back in 2002 and 2003. Thus, I wrote this book for people like me: experienced .NET developers looking to break into functional programming while retaining the safety net of the tools and libraries they’re already using.

While this book is written with an emphasis on .NET development, experienced developers approaching F# from other backgrounds should still find plenty of value within these pages, as the principles covered aren’t typically platform specific.

How Is This Book Organized?

The Book of F# is divided into 12 chapters intended to introduce you to each of the major language features. I recommend that you read this book from beginning to end rather than skipping around, as each chapter builds upon the concepts introduced by its predecessors.

Chapter 1. Provides your first glimpse of F# and describes its place within the .NET ecosystem. In this chapter, you’ll learn what you need to begin coding in F#, how projects are structured, and some of the nuances that can catch newcomers to the language off guard.

Chapter 2. Covers the F# Interactive environment, an indispensable read-evaluate-print loop (REPL) tool that ships with F#. Here you’ll see how F# Interactive can help you explore a problem domain and even let you use F# as a scripting language backed by the full power of the .NET Framework.

Chapter 3. Teaches you about the fundamentals of F#. Topics covered in this chapter include default immutability, bindings, core data types, type inference, imperative flow control, and generics. Even though many of the concepts addressed in this chapter will be familiar to experienced developers, I encourage you to read through it because F# often allows you to use them in unexpected ways.

Chapter 4. Provides an in-depth look at F#’s object-oriented capabilities. In this chapter, you’ll see how to develop rich object models every bit as robust as those developed in more established object-oriented languages like C# or Visual Basic.

Chapter 5. Takes you on a journey into managed functional programming by introducing you to concepts like functions as data, currying, partial application, and delegation. Additionally, you’ll learn about several of the F# data structures typically associated with functional programming.

Chapter 6. Explores how the various .NET collection types, like arrays and sequences, are represented in F#. You’ll also be introduced to several new collection types, including F#’s lists, sets, and maps.

Chapter 7. Introduces one of F#’s most powerful constructs: the match expression. Here you’ll uncover the various ways you can decompose complex types and branch your code, all within a single expression.

Chapter 8. Shows you how to add another degree of safety to your code by enforcing units of measure (such as inches, feet, meters, and so on) on your numeric types.

Chapter 9. Explains quoted expressions—F#’s version of LINQ’s expression trees. Here you’ll see how to compose, decompose, and apply quoted expressions.

Chapter 10. Explores some F#-specific ways to access data, including query expressions and one of F#’s most exciting features: type providers.

Chapter 11. Provides a brief introduction to asynchronous and parallel programming with F#. Topics include consuming the Task Parallel Library from F#, asynchronous workflows, and agent-based programming using MailboxProcessor<'T>.

Chapter 12. Discusses how to create computation expressions (often called monads in other functional languages) to control how data flows from expression to expression.

Additional Resources

As an open source language managed by the F# Software Foundation, F# is backed by a welcoming community of developers around the world, covering a wide range of disciplines. Although I’ve tried to provide comprehensive explanations and examples throughout the book, if you would like to explore a topic in more detail, you may find these resources helpful.

The Book of F# companion page (http://nostarch.com/f_sharp). This is your source for content updates and the code examples used within this book.

The F# Software Foundation(http://fsharp.org/). This should be your first stop. Here you’ll find links to all of the language documentation, including the language reference, the language specification, component design guidelines, and more.

F# for Fun and Profit(http://fsharpforfunandprofit.com/). Here you’ll find a plethora of examples covering virtually every aspect of the language.

Try F#(http://www.tryfsharp.org/). This browser-based tool lets you experiment with the language and learn it through guided tutorials.

Chapter 1. Meet F#

Originally developed at Microsoft Research, Cambridge, F# is a functional-first, multi-paradigm language. In plain terms, that means that while F#’s syntax and constructs emphasize writing code that applies functions to data, it’s also a full-featured, object-oriented language with a few imperative constructs tossed in for good measure.

F# dates back to 2002, but the first major release didn’t appear until Microsoft made version 1.0 available in 2005. F# is descended from the ML language and was heavily inspired by OCaml in particular. Early in its development, the F# team strived to maintain syntactic compatibility with ML, but over time the language has diverged a bit. Gradually, F# has found its place as a first-class citizen of Visual Studio, with project templates available out-of-the-box in every version starting with Visual Studio 2010. F#’s latest release accompanies Visual Studio 2013 and has been designated as version 3.1.

Despite its inclusion in Visual Studio, F# has developed an undeserved reputation as a niche language useful only in academia or highly specialized financial software. As a result, it has failed to secure widespread adoption, particularly in enterprise software, but that seems to be changing as developers are starting to understand the virtues of functional languages. The fact that F# is an open source language licensed under the Apache 2.0 license and there are compilers available on every major platform is also helping the language gain traction. Microsoft continues to contribute heavily to F#, but the language itself is managed by the independent F# Software Foundation.

The goal of this chapter is to give you an idea of how F# programs are organized at both the Visual Studio project and code levels. As you learn the language, you’ll find that F# truly is a general-purpose language capable of meeting the demands of most modern software development tasks.

Unless otherwise noted, the examples in this book were developed with F# 3.1 in Visual Studio 2013 (Professional and Ultimate editions). If, for any reason, you’re not using Visual Studio, don’t fret; the majority of the examples within this book are applicable no matter which platform you’re using.

Note

Although I don’t specifically cover them, if you intend to follow along with a development environment other than Visual Studio, the F# Software Foundation has plenty of resources to help you get started on its website at http://fsharp.org/. You can also try F# in your browser at http://www.tryfsharp.org/.

F# in Visual Studio

Because this book is primarily intended for experienced .NET developers, I’ll assume you already know how to create projects in Visual Studio. I’ll go right into introducing the different F# project templates that are available to you and follow that with a brief discussion about file organization within an F# project.

Project Templates

Each of the Visual F# project templates is listed under the Visual F# category in the New Project dialog, but the category’s location within the list will vary according to your IDE settings. If the Visual F# category isn’t listed immediately under Installed Templates, check under the Other Languages node. If you still don’t see it, make sure the F# components are installed. Figure 1-1 shows each template as it would appear with the IDE configured for F# development and targeting .NET 4.0.

As you can see, there are five templates available. The template names are pretty intuitive, but here’s a rundown:

Console Application. Creates a new command-line application.

Library. Creates a new library you can reference from other applications or libraries.

Figure 1-1. F# project templates in Visual Studio 2013

Tutorial. Is a quick way to peek into what F# has to offer, but it’s not very useful for starting new projects.

Portable Library. Creates a portable class library that can be used by both .NET 4.5 and Windows Store applications.

Portable Library (Legacy). Creates a portable class library that can be used by both .NET 4.0 and Silverlight applications.

Silverlight Library. Creates a new library you can reference in a Silverlight application.

Once you’ve created a project with any of these templates, you should see the familiar Visual Studio interface with the text editor, Solution Explorer, and any other windows you may normally have open. Depending on whether you’ve previously experimented with F#, you may also see the F# Interactive window.

Among the templates that are conspicuously missing are those for Windows Forms applications, WPF applications, and ASP.NET applications. A key reason for the omission is that many of the designer tools haven’t been updated to support generating or understanding F# code. Despite the lack of built-in templates, you can still construct applications with F# using these technologies, but typically you have to do more manual work.

Note

The F# Community Templates repository on GitHub hosts a number of additional templates. At the time of this writing, the repository contains only a handful of templates for Visual Studio, but over time it’s likely that templates for other editors, such as Xamarin Studio, will be added to the mix. You can find the repository at https://github.com/fsharp/FSharpCommunityTemplates/.

Project Organization

When you first see Visual Studio’s project workspace after creating a project from one of the aforementioned templates, you may be tempted to think that an F# project is just like a C# or Visual Basic project. In some regards, it is. For instance, you can start executable projects by pressing F5, the Visual Studio debugger can step through F# code, and files are managed with Solution Explorer. However, project organization in F# is very different from that of the traditional .NET languages. In fact, you’ll probably find that F#’s code structure is almost as foreign as the language itself.

Traditional .NET projects generally follow the convention of one type per file; that is, individual data types are almost always stored in separate files and organized into a folder hierarchy that mirrors the project’s namespaces. Aside from avoiding circular assembly references, there are very few steadfast rules on how or when something can appear within a project. Barring any accessibility modifiers (public, private, and so on), types and members are free to reference each other and their members regardless of where they are defined in the project.

Some rules are meant to be broken, but in this case F# shredded the project organization rulebook and then burned the remains. It is incredibly prescriptive about how projects are organized, and for good reason: F# code is evaluated from top to bottom. This means that not only is the order of declarations within an individual code file significant, but the order of the files within your project is significant as well!

It’s common for new F# programmers to add a new file to the project, fill in some definitions, and then get compiler errors stating that the new definitions are missing. This