SAMPLE CHAPTER Stephen Blackheath Anthony Jones FOREWORD BY Heinrich Apfelmus MANNING Functional Reactive Programming by Stephen Blackheath, Anthony Jones Sample Chapter 1 Copyright 2016 Manning Publications brief contents 1 ■ Stop listening! 1 2 ■ Core FRP 26 3 ■ Some everyday widget stuff 60 4 ■ Writing a real application 65 5 ■ New concepts 94 6 ■ FRP on the web 111 7 ■ Switch 131 8 ■ Operational primitives 169 9 ■ Continuous time 186 10 ■ Battle of the paradigms 201 11 ■ Programming in the real world 215 12 ■ Helpers and patterns 232 13 ■ Refactoring 262 14 ■ Adding FRP to existing projects 273 15 ■ Future directions 283 Stop listening! This chapter covers ■ What FRP is ■ What events are, and how they cause trouble ■ What FRP is for: the problem we’re trying to solve ■ The benefits of FRP ■ How an FRP system works ■ A different way of thinking that underlies FRP Welcome to our book! We love functional reactive programming (FRP). Many people like the idea too, yet they aren’t entirely clear what FRP is and what it will do for them. The short answer: it comes in the form of a simple library in a standard pro- gramming language, and it replaces listeners (also known as callbacks) in the widely used observer pattern, making your code cleaner, clearer, more robust, and more maintainable—in a word, simpler. It’s more than this: FRP is a very different way of doing things. It will improve your code and transform your thinking for the better. Yet it’s surprisingly compati- ble with the usual ways of writing code, so it’s easy to factor into existing projects in stages. This book is about the concepts of FRP as they apply to a range of FRP sys- tems and programming languages. 1 2 CHAPTER 1 Stop listening! FRP is based on ideas from functional programming, but this book doesn’t assume any prior knowledge of functional programming. Chapter 1 will lay down some underlying concepts, and in chapter 2 we’ll get into the coding. So stop listening, and start reacting! 1.1 Project, meet complexity wall It seemed to be going so well. The features weren’t all there yet, but development was swift. The boss was happy, the customers were impressed, the investors were optimis- tic. The future was bright. It came out of nowhere … Software quality crumbled. The speed of development went from treacle to molasses. Before long, there were unhappy customers and late nights. What happened? Sooner or later, many big projects hit the complexity wall. The complexities in the program that seemed acceptable compound exponentially: At first you hardly notice, and then—BAM! It hits broadside. The project will then typically go one of four ways: ■ It’s shelved. ■ It’s rewritten from scratch, and a million dollars later, it hits the same wall again. ■ The company staffs up. As the team expands, its productivity shambles off into the realm of the eternal quagmire. (Often the company has been acquired around this time.) ■ It undergoes major refactoring, leading eventually to maintainable code. Refactoring is the only way forward. It’s your primary tool to save a project that has hit the wall, but it’s best used earlier, as part of a development methodology, to prevent disaster before it happens. But this book isn’t about refactoring. It’s about functional reactive programming (FRP), a programming style that works well with refactoring because it can prevent or repair out-of-control complexity. FRP isn’t a methodology, and—apologies if you bought this book under false pretenses—it won’t solve all of your problems. FRP is a specific programming technique to improve your code in an area that just happens to be a common source of complexity (and therefore bugs): event propagation. Simple things taking too long I joined a team that was developing a Java-based configuration tool for an embedded system. The software was difficult to modify to the point where a request for adding a check box to one of the screens was estimated as a two-week job. This was caused by having to plumb the Boolean value through layers of interfaces and abstraction. To solve this, we put together what we’d later discover was a basic FRP system. Adding a check box was reduced to a one-line change. We learned that every piece of logic, every listener, and every edge case you need to write code for is a potential source of bugs. What is functional reactive programming? 3 1.2 What is functional reactive programming? FRP can be viewed from different angles: ■ It’s a replacement for the widely used observer pattern, also known as listeners or callbacks. ■ It’s a composable, modular way to code event-driven logic. ■ It’s a different way of thinking: the program is expressed as a reaction to its inputs, or as a flow of data. ■ It brings order to the management of program state. ■ It’s something fundamental: we think that anyone who tries to solve the prob- lems in the observer pattern will eventually invent FRP. ■ It’s normally implemented as a lightweight software library in a standard pro- gramming language. ■ It can be seen as a complete embedded language for stateful logic. If you’re familiar with the idea of a domain-specific language (DSL), then you can understand FRP as a minimal complete DSL for stateful logic. Aside from the I/O parts, an arbitrarily complex video game (for example) can be written completely in FRP. That’s how powerful and expressive it is. Yet it isn’t all-or-nothing—FRP can be easily introduced into an existing project to any extent you like. 1.2.1 A stricter definition Conal Elliott is one of the inventors of FRP, and this book is about FRP by his defini- tion. We’ll call this true FRP as a shorthand. What is and isn’t FRP? Here’s part of Elliott’s reply to a Stack Overflow post, “Specification for a Functional Reactive Pro- gramming language” (http://mng.bz/c42s): I’m glad you’re starting by asking about a specification rather than implementation first. There are a lot of ideas floating around about what FRP is. For me it’s always been two things: (a) denotative and (b) temporally continuous. Many folks drop both of these properties and identify FRP with various implementation notions, all of which are beside the point in my perspective. By “denotative,” I mean founded on a precise, simple, implementation-independent, compositional semantics that exactly specifies the meaning of each type and building block. The compositional nature of the semantics then determines the meaning of all type-correct combinations of the building blocks. A true FRP system has to be specified using denotational semantics. DEFINITION Denotational semantics is a mathematical expression of the formal meaning of a programming language. For an FRP system, it provides both a formal specification of the system and a proof that the important property of compositionality holds for all building blocks in all cases. 4 CHAPTER 1 Stop listening! Compositionality is a mathematically strong form of the concept of composability that is often recommended in software design. We’ll describe it in detail in chapter 5. This book emphasizes the practice of FRP as expressed through FRP systems you can use right away. Some of the systems we’ll cover aren’t true FRP. As we go, we’ll point out what’s specifically lacking and why it’s so important that an FRP system should be based on denotational semantics. We’ll cover continuous time in chapter 9. 1.2.2 Introducing Sodium The primary vehicle for FRP in this book is the authors’ BSD-licensed Sodium library, which you can find at https://github.com/SodiumFRP. It’s a system with a denota- tional semantics that we give in appendix E. It’s a practical system that has passed through the crucible of serious commercial use by the authors. We’re using Sodium because it’s a practically useful, simple, true FRP system. At the time of writing, there aren’t many systems like this available in nonfunctional lan- guages. There’s minimal variation between FRP systems, so the lessons learned from Sodium are applicable to all systems. To aid in understanding, we’ll use Sodium as a common reference point when discussing other systems. This book is about FRP, and Sodium is the best means to that end available to us. Like anything, Sodium is the product of design decisions. It isn’t perfect, and we don’t wish to promote its use over any other system. We intend Sodium to be four things: ■ A production-ready library you can use in commercial and non-commercial software across a range of programming languages ■ A vehicle to promote the true definition of FRP ■ A reference and benchmark for future innovation ■ A solid learning platform, due to its minimalist design philosophy 1.3 Where does FRP fit in? The lay of the land NOTE This book assumes knowledge of general programming, but not func- tional programming. Further, to use FRP, you only need a subset of the concepts from functional programming, and we’ll explain what you need to know along the way. FRP gives you many of the benefits of functional programming with a shorter learning curve, and you can use it in your existing language. It may sound oversimplified, but it turns out that FRP is the intersection of functional programming and reactive programming—see figure 1.1. Here’s what these technologies are: FP FRP RP ■ Functional programming—A style or paradigm of programming based on functions, in the mathematical sense of the word.