functional programming
Why Functional Programming?
Functional programs contain no assignment statements, so variables, once given a value, never change. More generally, functional programs contain no side-effects at all. A function call can have no effect other than to compute its result. This eliminates a major source of bugs, and also makes the order of execution irrelevant—since no side-effect can change an expres- sion’s value, it can be evaluated at any time. This relieves the programmer of the burden of pre- scribing the flow of control. Since expressions can be evaluated at any time, one can freely replace variables by their values and vice versa—that is, programs are “referentially transpar- ent.” This freedom helps make functional programs more tractable mathematically than their conventional counterparts.
—John Hughes
“Why Functional Programming Matters”
I call it my billion-dollar mistake ... My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a bil- lion dollars of pain and damage in the last forty years.
—Tony Hoare
Program testing can be a very effective way to show the presence of bugs, but is hopelessly inad- equate for showing their absence.
—Edsger W. Dijkstra
Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don’t improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often.
—Steve McConnell
The proper use of comments is to compensate for our failure to express ourselves in code.
—Robert C. Martin
In programming the hard part isn’t solving problems, but deciding what problems to solve.
—Paul Graham
Object oriented programming makes code understandable by encapsulating moving parts. Functional programming makes code understandable by minimizing moving parts.
—Michael Feathers
Licensed to
Functional Programming in Java
HOW FUNCTIONAL TECHNIQUES IMPROVE YOUR JAVA PROGRAMS
PIERRE-YVES SAUMONT
Licensed to
MANNING
SHELTER ISLAND
For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact
Special Sales Department Manning Publications Co. 20 Baldwin Road
PO Box 761
Shelter Island, NY 11964 Email: [email protected]
©2017 by Manning Publications Co. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps.
Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine.
Manning Publications Co. 20 Baldwin Road
PO Box 761
Shelter Island, NY 11964
Development editor: Technical development editor: Project editor: Copyeditor: Proofreaders: Technical proofreader: Typesetter: Cover designer:
Marina Michaels
Mark Elston
Janet Vail
Andy Carroll
Katie Tennant and Melody Dolab Alessandro Campeis
Dottie Marsico Leslie Haimes
ISBN 9781617292736
Printed in the United States of America
1 2 3 4 5 6 7 8 9 10 – EBM – 22 21 20 19 18 17
Licensed to
1 ■
2 ■
3 ■
4 ■
5 ■
6 ■
7 ■
8 ■
9 ■
10 ■
11 ■
12 ■
13 ■
14 ■
15 ■
brief contents
What is functional programming? 1
Using functions in Java 16
Making Java more functional 57
Recursion, corecursion, and memoization 94 Data handling with lists 124
Dealing with optional data 151
Handling errors and exceptions 176 Advanced list handling 203
Working with laziness 230
More data handling with trees 256
Solving real problems with advanced trees 290
Handling state mutation in a functional way Functional input/output 342
Sharing mutable state with actors 370 Solving common problems functionally 394
321
Licensed to
iii
Licensed to
contents
1.2 Writing useful programs with no side effects 4
1.3 How referential transparency makes programs safer 6
1.4 The benefits of functional programming 7
1.5 Using the substitution model to reason about programs 8
1.6 Applying functional principles to a simple example 9
1.7 Pushing abstraction to the limit 14
1.8 Summary 15
preface xiii acknowledgments xvi about this book xvii
1 What is functional programming? 1
1.1 What is functional programming? 2
2 Using functions in Java 16 2.1 What is a function? 17
Functions in the real world
17
Functional methods
anonymous classes
Polymorphic functions 29 ■ Simplifying the code by using lambdas 31
v
2.2 Functions in Java
22
Licensed to
23 ■ 28 ■
Java functional interfaces and Composing functions 29
vi
CONTENTS
2.3
Advanced function features 33
What about functions of several arguments? 33 ■ Applying curried functions 34 ■ Higher-order functions 35 Polymorphic higher-order functions 36 ■ Using anonymous functions 39 ■ Local functions 41 ■ Closures 42 Partial function application and automatic currying 44
Switching arguments of partially applied functions Recursive functions 49 ■ The identity function 51
Java 8 functional interfaces 52
2.4 2.5 2.6
Debugging with lambdas Summary 56
53
3 Making Java more functional 57
3.1 Making standard control structures functional 58
3.2 Abstracting control structures 59
Cleaning up the code 63 ■ An alternative to if ... else 3.3 Abstracting iteration 71
66
Abstracting an operation on lists with mapping 72
Creating lists 73 ■ Using head and tail operations 74 Functionally appending to a list 75 ■ Reducing and folding lists 75 ■ Composing mappings and mapping compositions 82
Applying effects to lists Building corecursive lists
3.4 Using the right types
82 ■ Approaching functional output 83 84
87
Problems with standard types 87 ■ Defining value types 90 The future of value types in Java 93
3.5 Summary 93
4 Recursion, corecursion, and memoization 94
4.1 Understanding corecursion and recursion 95
Exploring corecursive and recursive addition examples 95 Implementing recursion in Java 96 ■ Using tail call elimination 96 ■ Using tail recursive methods and
functions 97 ■ Abstracting recursion 97 ■ Using a drop-in replacement for stack-based recursive methods 101
4.2 Working with recursive functions 103
Using locally defined functions 104 ■ Making functions tail recursive 104 ■ Doubly recursive functions: the Fibonacci example 105 ■ Making the list methods stack-safe and recursive 108
Licensed to
48
CONTENTS vii
4.3 Composing a huge number of functions 111
4.4 Using memoization 114
Memoization in imperative programming 114 ■ Memoization in recursive functions 115 ■ Automatic memoization 117
4.5 Summary 123
5 Data handling with lists 124
5.1 How to classify data collections 125
Different types of lists 125 ■ Relative expected list performance 126 ■ Trading time against memory space, and time against complexity 127 ■ In-place mutation 128 Persistent data structures 129
5.2 An immutable, persistent, singly linked list implementation 130
5.3 Data sharing in list operations 133
More list operations 135
5.4 Using recursion to fold lists with higher-order functions 140
Heap-based recursive version of foldRight filtering lists 148
5.5 Summary 150
6 Dealing with optional data 151
6.1 Problems with the null pointer 152
6.2 Alternatives to null references 153
6.3 The Option data type 156
146 ■
Mapping and
Getting a value from an Option 158 ■ Applying functions to optional values 160 ■ Dealing with Option composition 161
Option use cases 163 ■ Other ways to combine options Composing List with Option 169
6.4 Miscellaneous utilities for Option 171
167
Testing for Some or None 171 ■ equals and hashcode 172
6.5 How and when to use Option 172
6.6 Summary 175
7 Handling errors and exceptions 176 7.1 The problems to be solved 177
Licensed to
viii
CONTENTS
7.2 7.3
7.4 7.5
7.6
The Either type 178
Composing Either 179
The Result type 181
Adding methods to the Result class 183
Result patterns 184
Advanced Result handling 191
Applying predicates 191 ■ Mapping failures factory methods 195 ■ Applying effects 196 ■ composition 199
Summary 202
192 ■
Advanced result
8 Advanced list handling 203
8.1 The problem with length 204
The performance problem 204 ■ The benefit of memoization 205
The drawbacks of memoization 205 ■ Actual performance
8.2 Composing List and Result 207
Methods on List returning Result 208 ■ Converting from List
- 209
8.3 Abstracting common List use cases 212
Zipping and unzipping lists 212 ■ Accessing elements by their index 215 ■ Splitting lists 217 ■ Searching for sublists 221 ■ Miscellaneous functions for working with lists 222
8.4 Automatic parallel processing of lists 225
207
Not all computations can be parallelized 226 ■ Breaking
the list into sublists 226 ■ Processing sublists in parallel 227
8.5 Summary 229
9 Working with laziness 230
9.1 Understanding strictness and laziness 230
Java is a strict language 231 ■ The problem with strictness 232
9.2 Implementing laziness 233
9.3 Things you can’t do without laziness 234
9.4 Why not use the Java 8 Stream?
9.5 Creating a lazy list data structure Memoizing evaluated values 237 ■
235 236
Manipulating streams 241
Licensed to
Adding
9.6 The true essence of laziness 243
Folding streams 245
9.7 Handling infinite streams 251
9.8 Avoiding null references and mutable fields
9.9 Summary 255
10 More data handling with trees 256 10.1 The binary tree 257
253
function 279 ■
10.6 Mapping trees
10.7 Balancing trees
Which fold implementation to choose 279
281 282
CONTENTS
ix
Balanced and unbalanced trees 258 ■ Size, height, and depth 258 ■ Leafy trees 259 ■ Ordered binary trees or binary search trees (BST) 259 ■ Insertion order 260 Tree traversal order 261
10.2 Implementing the binary search tree 263
10.3 Removing elements from trees 268
10.4 Merging arbitrary trees 270
10.5 Folding trees 275
Folding with two functions 276 ■ Folding with a single
Rotating trees 282
Balancing trees using the Day-Stout-Warren algorithm 285 Automatically balancing trees 287 ■ Solving the right problem 288
10.8 Summary 288
11 Solving real problems with advanced trees 290
11.1 Better performance and stack safety
with self-balancing trees 291
The basic tree structure 291 ■ Inserting an element into the red-black tree 295
11.2 A use case for the red-black tree: maps 300
Implementing Map 301 ■ Extending maps 303 Using Map with noncomparable keys 304
11.3 Implementing a functional priority queue 307
The priority queue access protocol 307 ■ Priority queue use cases 307 ■ Implementation requirements 308 ■ The leftist
Licensed to
x CONTENTS
heap data structure 308 ■ Implementing the leftist heap 309
Implementing the queue-like interface 313
11.4 A priority queue for noncomparable elements 314 11.5 Summary 319
12 Handling state mutation in a functional way 321
12.1 A functional random number generator
322
The random number generator interface 323 Implementing the random number generator 324
12.2 A generic API for handling state 327
Working with state operations 328 ■ Composing state operations 329 ■ Recursive state operations 331
12.3 Generic state handling 333
State patterns 334 ■ Building a state machine 335 When to use state and the state machine 340
12.4 Summary 341
13 Functional input/output 342
13.1 Applying effects in context 343
What are effects? 343 ■ Implementing effects 344 More-powerful effects for failures 346
13.2 Reading data 349
Reading data from the console 349 ■ Reading from a file 354 ■ Testing with input 355
13.3 Really functional input/output 356
How can input/output be made fully functional? 356 Implementing purely functional input/output 357 Combining IO 358 ■ Handling input with IO 359 Extending the IO type 361 ■ Making the IO type stack-safe 364
13.4 Summary 369
14 Sharing mutable state with actors 370 14.1 The actor model 371
Asynchronous messaging 372 ■ Handling parallelization 372 Handling actor state mutation 372
Licensed to
15.1 15.2
15.3
15.4
appendix A appendix B appendix C
index 440
Using assertions to validate data 395 Reading properties from file 399
Loading the property file 400 ■ Reading properties as strings 400 ■ Producing better error messages 402 Reading properties as lists 405 ■ Reading enum
values 406 ■ Reading properties of arbitrary types 407
Converting an imperative program: the XML reader 409
Listing the necessary functions 411 ■ Composing the functions and applying an effect 412 ■ Implementing the functions 412 Making the program even more functional 414 ■ Fixing the argument type problem 417 ■ Making the element-processing function a parameter 418 ■ Handling errors on element
names 420
Summary 421
Using Java 8 functional features 422 Monads 429
Where to go from here 434
CONTENTS xi 14.2 Building the actor framework 373
Limitations of this actor framework
framework interfaces 374 ■ The AbstractActor implementation 376
14.3 Putting actors to work 377
Implementing the ping-pong example 378 ■ A more serious example: running a computation in parallel 379 ■ Reordering the results 385 ■ Fixing the performance problem 388
14.4 Summary 393
15 Solving common problems functionally 394
Licensed to
374 ■ Designing the actor
Licensed to
preface
Writing programs is fun and rewarding. Programming is an activity that many people would do for fun, and yet are paid for. In this sense, a programmer is a bit like an actor, a musician, or a professional football player. It seems like a dream until you, as a programmer, begin to have real responsibilities. Writing games or office applications isn’t really a big deal from this point of view. If your application has a bug, you simply fix it and release a new version. But if you write applications that people depend on, and if you can’t simply release a new version and have your users install it themselves, it’s another story. Of course, Java isn’t meant for writing applications for monitoring nuclear plants or flying airplanes, or any system in which a simple bug could put human life at risk. But if your application is used to manage internet backbones, you wouldn’t like a nasty bug to be discovered one day before the Olympic Games open, causing a TV transmission failure for a whole country. For such applications, you want to be sure that your program can be proven correct.
Most imperative programs can’t be proven correct. Tests only allow us to prove programs incorrect when they fail. Successful tests don’t prove much. What you release are programs that you weren’t able to prove incorrect. With single-threaded programs, extensive tests may let you show that your code is mostly correct. But with multithreaded applications, the number of possible condition combinations makes that impossible. Clearly, we need a different way to write programs. Ideally, it would be a way that allows us to prove that a program is correct. Because this is generally not fully possible, a good compromise is a clear separation between parts of the program that can be proven correct and parts that can’t. This is what functional programming techniques offer.
xiii
Licensed to
xiv
PREFACE
Functional programming has about as many definitions as there are functional programmers. Some say that functional programming is programming with functions. This is true, but it doesn’t help you understand the benefits of this programming par- adigm. More important is the idea that functional programming involves pushing abstraction to the limit. This allows a clear separation between the parts of a program that can be proven correct and the other parts whose output depends on external conditions. This way, functional programs are programs that are less prone to bugs, and in which bugs can only reside in specific, restricted areas.
Many techniques can be employed to reach this goal. The use of immutable data, although not specific to functional programming, is such a technique. If data can’t change, you won’t have any (bad) surprises, no stale or corrupted data, no race condi- tions, no need for locking on concurrent accesses, and no risk of deadlocks. Immutable data can be shared without risk. You don’t need to make defensive copies, and you don’t risk forgetting to do so. Another technique is abstracting control struc- tures so that you don’t have to write the same structures again and again, multiplying the risk of messing with loop indexes and exit conditions. Completely removing the use of null references (whether implicit or explicit) will free you from the infamous NPE (NullPointerException). With all these techniques (and more), you can be confi- dent that if your program compiles, it’s correct (meaning that it has no implementa- tion bugs). This doesn’t remove all possibility of bugs, but it makes things much safer.
Computers have used the imperative paradigm from the beginning, based on mutating values in registers. Java, like many other programming languages known as “imperative languages,” seems to rely heavily on this paradigm, but this isn’t essential. If you’re an experienced Java programmer, you might be surprised to hear that you can write useful programs without ever changing the value of a variable. This isn’t a mandatory condition for functional programming, but it’s so comfortable that func- tional programmers nearly always use immutable data. You might also have difficulty believing that you can write applications without ever using an if ... else structure or a while or for loop. Again, avoiding such structures isn’t a condition for using the functional paradigm, but you can avoid them if you want, and this leads to much safer programs. So even if Java is generally seen as an “imperative language,” it’s not. No lan- guage is imperative, and no language is functional. Believing that they are is like think- ing that English is better for business texts while Italian would be better for singing opera, French for love poetry, and German for philosophy (or whatever combinations you can imagine). Differences may exist, but they’re mostly cultural, and the same is true for programming languages. Java is an imperative language because most Java programmers are imperative programmers, and the Java culture is mostly imperative. In contrast, Haskell programs are generally written in a functional style because pro- grammers choose this language with functional programming in mind. But it’s possi- ble to write imperative programs in Haskell, and it’s possible to write functional programs in Java. The difference is that Haskell is more “functional-friendly” than Java.
Licensed to
PREFACE xv
So the question is, “Should you use Java for functional programming”? Surpris- ingly (given the subject of this book) the answer is no. With the freedom to choose any language, I’ll say that you shouldn’t chose Java for this purpose. But you generally won’t have this freedom. Most of the negative comments I received when writing arti- cles about using Java for functional programming were along the lines of “You should not use Java for this. This is not the way Java was intended to be used,” or “Why are you using Java for this? Better to use Haskell, or Scala, or whatever.”
In reality, you generally don’t have a choice of language. If you work in a company, you probably have to use the corporate language, or at least the one chosen by your team for the project you’re working on. Haskell is never an option from this point of view. Often, you’ll have no choice but to use Java. And if you’re in a position to choose the language, you likely won’t have any choice besides using a language you know, or using a language that allows the reuse of some legacy code, or a language that suits the environment, or some other condition. This book is aimed at you, the Java pro- grammer who has no real choice other than using Java, although you want to benefit from the safety of functional programming.
Using functional programming techniques in Java will often cause you to go against so-called “best practices.” Many of these practices are, in fact, useless, and some are very bad practices indeed. Never catching errors is one of them. As a Java programmer, you probably learned that you shouldn’t be catching OOME (Out Of Memory Error) or other kinds of errors you can’t deal with. Maybe you even learned that you shouldn’t catch NPEs (NullPointerExceptions) because they indicate bugs, and you should let the application crash and fix it. Unfortunately, neither OOME nor NPE will crash the application. They’ll only crash the thread in which they occur, leaving the application in some indeterminate state. Even if they occur in the main thread, they’ll possibly fail to crash the application if some non-daemon threads are running. This “best practice” was true when all applications were single-threaded. It’s now a very bad practice. You should catch all exceptions, although possibly not in a try ... catch block. In func- tional programming, the mantra is, “Always catch, never throw.”
There are many other best practices that will be challenged during our functional programming journey. One of them, although not directly related to Java or impera- tive programming, is, “Don’t reinvent the wheel.” Think about it. Once, someone invented the wheel. At that time, it was probably something roughly circular made of some rigid material and turning on an axle. The wheel has been reinvented many times since then. If it hadn’t, you’d have no cars, no trains, and nearly nothing using wheels. So you should continue trying to reinvent the wheel again and again. Not only will this give us better wheels in the future, but it’s challenging, rewarding, and fun. (And if you believe that modern cars have circular wheels, you’d better think again. No car could ever run on circular wheels!)
Licensed to
acknowledgments
I would like to thank the many people who participated in making this book possible. First, a big thank you to my developmental editor, Marina Michaels. Besides your
wonderful work on the manuscript, it’s been a real pleasure to work with you.
A big thank you, too, to Mark Elston, my technical editor, and to Alessandro Campeis, my technical proofreader, both of whom helped me make this book much
better than I could have done alone.
To all the reviewers, MEAP readers, and everyone else who provided feedback and
comments, thank you! This book would not be what it is today without your help. Spe- cifically, I’d like to thank the following people who all took the time to review and comment on the book: Aditya Kumar, Al Krinker, Andy Kirsch, Andy Knight, Anthony Moralez, Arun Allamsetty, Barry Kern, Boris Vasile, Bruce Hernandez, Charles Feduke, Chris Kirk, David Drummond, Davide Fiorentino lo Regio, Erwin van Eijk, Gualtiero Testa, Ivan Milosavljevic ́, Jan Vorwerk, Jérôme Baton, Joshua McAdams, Julian Templeman, Maria Gemini, Norbert Kuchenmeister, Philippe Charrière, Piotr Bzdyl, Rambabu Posa, Sebastian Hähnel, Sebastian Metzger, Simeon Leyzerzon, Tarin Gamberini, Ursin Stauss, William Wheeler, Zach Schwartz and Zorodzayi Mukuya.
xvi
Licensed to
about this book
This isn’t a book about Java. This book is about functional programming, which is a different way to write software programs. “Different” means different from the “tradi- tional” way of writing software, which is called the imperative paradigm. This book is about applying the functional paradigm to Java programming.
There’s no such thing as a “functional language.” There are only languages that are more-or-less functional-friendly. Although I use Java in this book, you can apply all the principles I teach to any other language. Only the way in which you implement these principles would be different. You can write functional programs in any lan- guage, even those said not to be functional at all; you can similarly write imperative programs with the most functional-friendly languages.
With the release of Java 8, some functional features have been added to the Java language. But just as this book isn’t about Java, it’s also not about these specific Java 8 features. In this book, I make heavy use of some of these features, and I mostly ignore others. If your goal is to learn how to use the functional features of Java 8, this is not the right book. Urma, Fusco, and Mycroft’s Java 8 in Action (Manning, 2014) would be a much better choice.
On the other hand, if you want to learn what functional programming is, how to build functional data structures, and how the functional programming paradigm will help you write better programs (sometimes using the Java 8 features and sometimes avoiding them), this is the book for you.
Audience
This book is intended for readers with some programming experience in Java. A good understanding of Java generics is necessary. If you find yourself not understanding a
xvii
Licensed to
xviii
ABOUT THIS BOOK
Java construction (such as generic constants implemented as methods, or parameter- ized method calls), don’t be afraid: I’ll explain what they mean and why they’re needed.
You don’t need to have prior experience in functional programming, or to be aware of the mathematical theory that underlies it. Chapter 2 will act as a reminder of what a function is, and that’s it. No other math will be used.
I present all functional techniques in relation to their imperative counterparts, so I expect you to have experience with imperative programming in Java.
How to use this book
This book is intended to be read sequentially, because each chapter builds upon the concepts learned in the previous ones. The only exceptions are chapters 14 and 15, in which what you’ll learn in chapters 12 and 13 isn’t used. This means you can skip chapters 12 and 13 if you want; they present more-advanced techniques that are useful to know but that you might prefer not to use in your own programs.
I’ve used the word “read,” but this book isn’t intended to just be read. Very few sec- tions are theory only. To get the most out of this book, read it at your computer key- board, solving the exercises as you go. Each chapter includes a number of exercises with the necessary instructions and hints to help you arrive at the solution. All the code is available as a separate free download from GitHub (http://github.com/fpinjava/ fpinjava) and from the publisher’s website at https://www.manning.com/books/ functional-programming-in-java. Each exercise comes with a proposed solution and JUnit tests that you can use to verify that your solution is correct.
The code comes with all the necessary elements for the project to be imported into IntelliJ (recommended), NetBeans, or Eclipse, although at the time of this writing, Eclipse (Mars 4.5.1) is not yet fully compatible with Java 8. Projects may be imported “from source” or using Gradle. Any version of Gradle may be used, because Gradle is able to download the correct version automatically.
Please note that you’re not expected to understand most of the concepts pre- sented in this book by just reading the text. Doing the exercises is probably the most important part of the learning process, so I encourage you not to skip any exercises. Some might seem quite difficult, and you might be tempted to look at the proposed solutions. It’s perfectly OK to do so, but you should then come back to the exercise and do it without looking at the solution. If you only read the solution, you’ll probably have problems later trying to solve more-advanced exercises.
This approach doesn’t require much tedious typing, because you have nearly noth- ing to copy. Most exercises consist of writing implementations for methods, for which you are given the environment and the method signature. No exercise is longer than a dozen lines of code; the majority are around four or five lines long.
Once you finish an exercise (which means when your implementation compiles), just run the corresponding test to verify that it’s correct.
Licensed to
ABOUT THIS BOOK xix
One important thing to note is that each exercise is self-contained with regard to the rest of the chapter, so code created inside a chapter is duplicated from one exer- cise to the next. This is necessary because each exercise is often built upon the preced- ing one, so although the same class might be used, implementations differ. As a consequence, you shouldn’t look at an exercise before you complete the previous ones, because you’ll see the solutions to yet-unsolved exercises.
You can download the code as an archive, or you can clone it using Git. I highly recommend cloning, since the code is subject to change, and it’s much more efficient to update your code with a simple pull command than to re-download the complete archive.
The code for exercises is organized in modules with names that more or less reflect the chapter titles, rather than the chapter numbers. As a result, IDEs will sort them alphabetically, rather than in the order in which they appear in the book. To help you figure out which module corresponds to each chapter, I’ve provided a list of the chapters with the corresponding module names in the README file accompany- ing the code (http://github.com/fpinjava/fpinjava).
Setting expectations
Functional programming is no more difficult than imperative programming. It’s just different. You can solve the same problems with both paradigms, but translating from one to the other can sometimes be inefficient. Learning functional programming is like learning a foreign language. Just as you can’t efficiently think in one language and translate to another, you can’t think imperatively and translate your code to the functional approach. And just as you have to learn to think in a new language, you have to learn to think functionally. Learning to think functionally doesn’t come with reading alone; it comes with writing code. So you have to practice.
This is why I don’t expect you to understand what’s in this book just by reading it, and why I provide so many exercises; you must do the exercises to fully grasp the con- cepts of functional programming. This isn’t because the topic is so complex that it isn’t possible to understand it through reading alone, but because if you could understand it just by reading (without doing the exercises), you probably wouldn’t need this book.
For all these reasons, the exercises are key to getting the most out of this book. I encourage you to try solving each exercise before you continue reading. If you don’t find a solution, try again rather than going directly to the solution I provide. If you have a hard time understanding something, ask questions on the forum (see the next section). Asking questions and getting answers on the forum will not only help you, it will also help the person answering the question (along with others who have the same question). We all learn by answering questions (mostly our own questions, by the way) much more than by asking them.
Licensed to
xx
ABOUT THIS BOOK
Author Online
Purchase of Functional Programming in Java includes free access to a private web forum run by Manning Publications, where you can make comments about the book, ask technical questions, and receive help from the author and other users, or even pro- vide help to other users. To access the forum and subscribe to it, point your web browser to https://forums.manning.com/forums/functional-programming-in-java. This Author Online page provides information on how to get on the forum once you’re registered, what kind of help is available, and the rules of conduct on the forum.
Manning’s commitment to our readers is to provide a venue where a meaningful dialog among individual readers and between readers and the authors can take place. It’s not a commitment to any specific amount of participation on the part of the authors, whose contribution to the forum remains voluntary. I, as the author of this book, will be monitoring this forum and will answer questions as promptly as possible.
The Author Online forum and the archives of previous discussions will be accessi- ble from the publisher’s website as long as the book is in print.
Licensed to
What is functional programming?
This chapter covers
The benefits of functional programming
Problems with side effects
How referential transparency makes programs safer
Reasoning about programs with the substitution model
Making the most of abstraction
Not everybody agrees on a definition for functional programming (FP). In general terms, functional programming is a programming paradigm, and it’s about pro- gramming with functions. But this doesn’t explain the most important aspect: how FP is different from other paradigms, and what makes it a (potentially) better way to write programs. In his article “Why Functional Programming Matters,” pub- lished in 1990, John Hughes writes the following:
1
Licensed to
2
CHAPTER 1 What is functional programming?
1.1
Functional programs contain no assignment statements, so variables, once given a value, never change. More generally, functional programs contain no side effects at all. A function call can have no effect other than to compute its result. This eliminates a major source of bugs, and also makes the order of execution irrelevant—since no side effect can change an expression’s value, it can be evaluated at any time. This relieves the programmer of the burden of prescribing the flow of control. Since expressions can be evaluated at any time, one can freely replace variables by their values and vice versa—that is, programs are “referentially transparent.” This freedom helps make functional programs more tractable mathematically than their conventional counterparts.1
In the rest of this chapter, I’ll briefly present concepts such as referential transparency and the substitution model, as well as other concepts that together are the essence of functional programming. You’ll apply these concepts over and over in the coming chapters.
What is functional programming?
It’s often as important to understand what something is not, as to agree about what it is. If functional programming is a programming paradigm, there clearly must be other programming paradigms that FP differs from. Contrary to what some might think, functional programming isn’t the opposite of object-oriented programming (OOP). Some functional programming languages are object-oriented; some are not.
Functional programming is sometimes considered to be a set of techniques that supplement or replace techniques found in other programming paradigms, such as
First-class functions
Anonymous functions
Closures
Currying
Lazy evaluation
Parametric polymorphism Algebraic data types
Although it is true that most functional languages do use a number of these tech- niques, you may find, for each of them, examples of functional programming lan- guages that don’t, as well as non-functional languages that do. As you’ll see when studying each of these techniques in this book, it’s not the language that makes pro- gramming functional. It’s the way you write the code. But some languages are more functional-friendly than others.
What functional programming may be opposed to is the imperative programming paradigm. In imperative programming style, programs are composed from elements that “do” something. “Doing” something generally implies an initial state, a transition,
1 John Hughes, “Why Functional Programming Matters,” from D. Turner, ed., Research Topics in Functional Pro- gramming (Addison-Wesley, 1990), 17–42, www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf.
Licensed to
What is functional programming? 3
and an end state. This is sometimes called state mutation. Traditional imperative-style programs are often described as a series of mutations, separated with condition test- ing. For example, an addition program for adding two positive values a and b might be represented by the following pseudo code:
if b == 0, return a
else increment a and decrement b start again with the new a and b
In this pseudo code, you can recognize the traditional instructions of most imperative languages: testing conditions, mutating variables, branching, and returning a value. This code may be represented graphically by a flow chart, such as figure 1.1.
On the other hand, functional programs are composed of elements that “are” something—they don’t “do” something. The addition of a and b doesn’t “make” a result. The addition of 2 and 3, for example, doesn’t make 5. It is 5.
The difference might not seem important, but it is. The main consequence is that each time you encounter 2 + 3, you can replace it with 5. Can you do the same thing in an imperative program? Well, sometimes you can. But sometimes you can’t without changing the program’s outcome. If the expression you want to replace has no other effect than returning the result, you can safely replace it with its result. But how can you be sure that it has no other effect? In the addition example, you clearly see that the two variables a and b have been destroyed by the program. This is an effect of the program, besides returning the result, so it’s called a side effect. (This would be differ- ent if the computation were occurring inside a Java method, because the variables a and b would be passed by value, and the change would then be local and not visible from outside the method.)
b == 0 ?
No
Add 1 to a
Remove 1 from b
Yes Return a
Figure 1.1 A flow chart representing an imperative program as a process that occurs in time. Various things are transformed and states are mutated until the result is obtained.
Licensed to
4
CHAPTER 1 What is functional programming?
One major difference between imperative programming and FP is that in FP there are
no side effects. This means, among other things,
No mutation of variables
No printing to the console or to any device
No writing to files, databases, networks, or whatever No exception throwing
When I say “no side effects,” I mean no observable side effects. Functional programs are built by composing functions that take an argument and return a value, and that’s it. You don’t care about what’s happening inside the functions, because, in theory, nothing is happening ever. But in practice, programs are written for computers that aren’t functional at all. All computers are based on the same imperative paradigm; so functions are black boxes that
Take an argument (a single one, as you’ll see later)
Do mysterious things inside, such as mutating variables and a lot of imperative-
style stuff, but with no effect observable from outside
Return a (single) value
This is theory. In practice, it’s impossible for a function to have no side effects at all. A function will return a value at some time, and this time may vary. This is a side effect. It might create an out-of-memory error, or a stack-overflow error, and crash the appli- cation, which is a somewhat observable side effect. And it will cause writing to mem- ory, registering mutations, thread launching, context switching, and other sorts of things that are indeed effects observable from outside.
So functional programming is writing programs with no intentional side effects, by which I mean side effects that are part of the expected outcome of the program. There should also be as few non-intentional side effects as possible.
Writing useful programs with no side effects
You may wonder how you can possibly write useful programs if they have no side effects. Obviously, you can’t. Functional programming is not about writing programs that have no observable results. It’s about writing programs that have no observable results other than returning a value. But if this is all the program does, it won’t be very useful. In the end, functional programs have to have an observable effect, such as dis- playing the result on a screen, writing it to a file or database, or sending it over a net- work. This interaction with the outside world won’t occur in the middle of a computation, but only when you finish the computation. In other words, side effects will be delayed and applied separately.
Take the example of the addition in figure 1.1. Although it’s described in impera- tive style, it might yet be functional, depending on how it’s implemented. Imagine this program is implemented in Java as follows:
1.2
Licensed to
Writing useful programs with no side effects 5
public static int add(int a, int b) {
while (b > 0) {
a++;
b--; }
return a; }
This program is fully functional. It takes an argument, which is the pair of integers a and b, it returns a value, and it has absolutely no other observable effect. That it mutates variables doesn’t contradict the requirements, because arguments in Java are passed by value, so the mutations of the arguments aren’t visible from outside. You can then choose to apply an effect, such as displaying the result or using the result for another computation.
Note that although the result might not be correct (in case of an arithmetic over- flow), that’s not in contradiction with having no side effects. If values a and b are too big, the program will silently overflow and return an erroneous result, but this is still functional. On the other hand, the following program is not functional:
public static int div(int a, int b) {
return a / b;
}
Although this program doesn’t mutate any variables, it throws an exception if b is equal to 0. Throwing an exception is a side effect. In contrast, the following imple- mentation, although a bit stupid, is functional:
public static int div(int a, int b) {
return (int) (a / (float) b);
}
This implementation won’t throw an exception if b is equal to 0, but it will return a special result. It’s up to you to decide whether it’s OK or not for your function to return this specific result to mean that the divisor was 0. (It’s probably not!)
Throwing an exception might be an intentional or unintentional side effect, but it’s always a side effect. Often, though, in imperative programming, side effects are wanted. The simplest form might look like this:
public static void add(int a, int b) {
while (b > 0) {
a++;
b--; }
System.out.println(a);
}
This program doesn’t return a value, but it prints the result to the console. This is a desired side effect.
Licensed to
6
CHAPTER 1 What is functional programming?
Note that the program could alternatively both return a value and have some
intentional side effects, as in the following example:
public static int add(int a, int b) {
log(String.format("Adding %s and %s", a, b));
while (b > 0) {
a++;
b--; }
log(String.format("Returning %s", a));
return a; }
This program isn’t functional because it uses side effects for logging.
How referential transparency makes programs safer
Having no side effects (and thus not mutating anything in the external world) isn’t enough for a program to be functional. Functional programs must also not be affected by the external world. In other words, the output of a functional program must depend only on its argument. This means functional code may not read data from the console, a file, a remote URL, a database, or even from the system. Code that doesn’t mutate or depend on the external world is said to be referentially transparent.
Referentially transparent code has several properties that might be of some inter- est to programmers:
It’s self-contained. It doesn’t depend on any external device to work. You can use it in any context—all you have to do is provide a valid argument.
It’s deterministic, which means it will always return the same value for the same argument. With referentially transparent code, you won’t be surprised. It might return a wrong result, but at least, for the same argument, this result will never change.
It will never throw any kind of Exception. It might throw errors, such as OOME (out-of-memory error) or SOE (stack-overflow error), but these errors mean that the code has a bug, which is not a situation you, as a programmer, or the users of your API, are supposed to handle (besides crashing the application and eventually fixing the bug).
It won’t create conditions causing other code to unexpectedly fail. For exam- ple, it won’t mutate arguments or some other external data, causing the caller to find itself with stale data or concurrent access exceptions.
It won’t hang because some external device (whether database, file system, or network) is unavailable, too slow, or simply broken.
Figure 1.2 illustrates the difference between a referentially transparent program and one that’s not referentially transparent.
1.3
Licensed to
The benefits of functional programming 7
Objects
Program
Input (argument) Output (result)
Database
Keyboard
Screen
File
A referentially transparent program doesn't interfere with the outside world apart from taking an argument as input and outputting a result. Its result only depends on its argument.
Exception
Objects
Database
Program
Input (argument) Output (result)
Keyboard
Screen
File
A program that isn’t referentially transparent may read data from or write it to elements in the outside world, log to file, mutate external objects, read from keyboard, print to screen, and so on. Its result is unpredictable.
Figure 1.2 Comparing a program that’s referentially transparent to one that’s not
1.4 The benefits of functional programming
From what I’ve just said, you can likely guess the many benefits of functional pro- gramming:
Functional programs are easier to reason about because they’re deterministic. One specific input will always give the same output. In many cases, you might be able to prove your program correct rather than extensively testing it and still being uncertain whether it will break under unexpected conditions.
Functional programs are easier to test. Because there are no side effects, you don’t need mocks, which are generally required to isolate the programs under test from the outside.
Licensed to
8
CHAPTER 1 What is functional programming?
1.5
Functional programs are inherently thread-safe because they avoid mutation of shared state. Once again, this doesn’t mean that all data has to be immutable. Only shared data must be. But functional programmers will soon realize that immutable data is always safer, even if the mutation is not visible externally.
Using the substitution model to
reason about programs
Remember that a function doesn’t do anything. It only has a value, which is only depen- dent on its argument. As a consequence, it’s always possible to replace a function call, or any referentially transparent expression, with its value, as shown in figure 1.3.
= 26
The expression 3 x 2 may be replaced with its value: = 26
The expression 4 x 5 may be replaced with its value: = 26 Figure 1.3 Replacing referentially transparent expressions with their values doesn’t change
the overall meaning.
When applied to functions, the substitution model allows you to replace any function call with its return value. Consider the following code:
public static void main(String[] args) {
int x = add(mult(2, 3), mult(4, 5));
}
public static int add(int a, int b) {
log(String.format("Returning %s as the result of %s + %s", a + b, a, b));
return a + b; }
public static int mult(int a, int b) {
return a * b;
}
Functional programs are more modular because they’re built from functions that have only input and output; there are no side effects to handle, no excep- tions to catch, no context mutation to deal with, no shared mutable state, and no concurrent modifications.
Functional programming makes composition and recombination much easier. To write a functional program, you have to start by writing the various base func- tions you need and then combine these base functions into higher-level ones, repeating the process until you have a single function corresponding to the pro- gram you want to build. As all these functions are referentially transparent, they can then be reused to build other programs without any modifications.
3x2
+
4x5
+
4x5
6
+
20
Licensed to
Applying functional principles to a simple example 9
public static void log(String m) {
System.out.println(m);
}
Replacing mult(2, 3) and mult(4, 5) with their respective return values doesn’t
change the signification of the program:
int x = add(6, 20);
In contrast, replacing the call to the add function with its return value changes the sig- nification of the program, because the log method will no longer be called, and no logging will happen. This might be important or not; in any case, it changes the result of the program.
1.6 Applying functional principles to a simple example
As an example of converting an imperative program into a functional one, we’ll con- sider a very simple program representing the purchase of a donut with a credit card.
Listing 1.1 A Java program with side effects
public class DonutShop {
public static Donut buyDonut(CreditCard creditCard) {
Donut donut = new Donut();
creditCard.charge(Donut.price); B Charges the credit card as a side effect return donut; C Returns the donut
} }
In this code, the charging of the credit card is a side effect B. Charging a credit card probably consists of calling the bank, verifying that the credit card is valid and autho- rized, and registering the transaction. The function returns the donut C.
The problem with this kind of code is that it’s difficult to test. Running the program for testing would involve contacting the bank and registering the transaction using some sort of mock account. Or you’d need to create a mock credit card to register the effect of calling the charge method and to verify the state of the mock after the test.
If you want to be able to test your program without contacting the bank or using a mock, you should remove the side effect. Because you still want to charge the credit card, the only solution is to add a representation of this operation to the return value. Your buyDonut method will have to return both the donut and this representation of the payment.
To represent the payment, you can use a Payment class. Listing 1.2 The Payment class
public class Payment {
public final CreditCard creditCard;
public final int amount;
Licensed to
10
CHAPTER 1 What is functional programming?
public Payment(CreditCard creditCard, int amount) {
this.creditCard = creditCard;
this.amount = amount;
} }
This class contains the necessary data to represent the payment, which consists of a credit card and the amount to charge. Because the buyDonut method must return both a Donut and a Payment, you could create a specific class for this, such as Purchase:
public class Purchase {
public Donut donut;
public Payment payment;
public Purchase(Donut donut, Payment payment) {
this.donut = donut;
this.payment = payment;
} }
You’ll often need such a class to hold two (or more) values, because functional pro- gramming replaces side effects with returning a representation of these effects.
Rather than creating a specific Purchase class, you’ll use a generic one that you’ll call Tuple. This class will be parameterized by the two types it will contain (Donut and Payment). The following listing shows its implementation, as well as the way it’s used in the DonutShop class.
Listing 1.3 The Tuple class public class Tuple
public final T _1;
public final U _2;
public Tuple(T t, U u) {
this._1 = t;
this._2 = u;
} }
public class DonutShop {
public static Tuple
Payment payment = new Payment(creditCard, Donut.price);
return new Tuple<>(donut, payment);
} }
Note that you’re no longer concerned (at this stage) with how the credit card will actually be charged. This adds some freedom to the way you build your application. You could still process the payment immediately, or you could store it for later pro- cessing. You could even combine stored payments for the same card and process them
Licensed to
Applying functional principles to a simple example 11
in a single operation. This would allow you to save money by minimizing the bank fees for the credit card service.
The combine method in the following listing allows you to combine payments. Note that if the credit cards don’t match, an exception is thrown. This doesn’t contra- dict what I said about functional programs not throwing exceptions. Here, trying to combine two payments with two different credit cards is considered a bug, so it should crash the application. (This isn’t very realistic. You’ll have to wait until chapter 7 to learn how to deal with such situations without throwing exceptions.)
Listing 1.4 Composing multiple payments into a single one
package com.fpinjava.introduction.listing01_04;
public class Payment {
public final CreditCard creditCard;
public final int amount;
public Payment(CreditCard creditCard, int amount) {
this.creditCard = creditCard;
this.amount = amount;
}
public Payment combine(Payment payment) {
if (creditCard.equals(payment.creditCard)) {
return new Payment(creditCard, amount + payment.amount);
} else {
throw new IllegalStateException("Cards don't match.");
}
} }
Of course, the combine method wouldn’t be very efficient for buying several donuts at once. For this use case, you could simply replace the buyDonut method with buy- Donuts(intn,CreditCardcreditCard), as shown in the following listing. This method returns a Tuple
Listing 1.5 Buying multiple donuts at once
package com.fpinjava.introduction.listing01_05;
import static com.fpinjava.common.List.fill; import com.fpinjava.common.List;
import com.fpinjava.common.Tuple;
public class DonutShop {
public static Tuple
}
public static Tuple
return new Tuple<>(fill(quantity, () -> new Donut()),
new Payment(cCard, Donut.price * quantity));
Licensed to
12
CHAPTER 1 What is functional programming?
} }
Note that this method doesn’t use the standard java.util.List class because that class doesn’t offer some of the functional methods you’ll need. In chapter 3, you’ll see how to use the java.util.List class in a functional way by writing a small functional library. Then, in chapter 5, you’ll develop a completely new functional List. It’s this list that’s used here. This combine method is somewhat equivalent to the following, which uses the standard Java list:
public static Tuple
return new Tuple<>(Collections.nCopies(quantity, new Donut()),
new Payment(cCard, Donut.price * quantity));
}
As you’ll soon need additional functional methods, you won’t be using the Java list. For the time being, you just need to know that the static List fill(int n, Supplier s) method creates a list of n instances of A by using a special object, Supplier. As its name indicates, a Supplier is an object that supplies an A when its get() method is called. Using a Supplier instead of an A allows for lazy evaluation, which you’ll learn about in the next chapters. For now, you may think of it as a way to manipulate an A without effectively creating it until it’s needed.
Now, your program can be tested without using a mock. For example, here’s a test for the method buyDonuts:
@Test
public void testBuyDonuts() {
CreditCard creditCard = new CreditCard();
Tuple
assertEquals(Donut.price * 5, purchase._2.amount);
assertEquals(creditCard, purchase._2.creditCard);
}
Another benefit of making your program functional is that it’s more easily compos- able. If the same person made several purchases with your initial program, you’d have to contact the bank (and pay the corresponding fee) each time. With the new func- tional version, you can choose to charge the card immediately for each purchase or to group all payments made with the same card and charge it only once for the total.
To group payments, you’ll need to use additional methods from your functional List class (you don’t need to understand how these methods work for now; you’ll study them in detail in chapters 5 and 8):
public Map
Licensed to
Applying functional principles to a simple example 13
This instance method of the List class takes a function from A to B and returns a map of key and value pairs, with keys being of type B and values of type List. In other words, it groups payments by credit cards:
List values()
This is an instance method of Map that returns a list of all the values in the map:
List map(Function
This is an instance method of List that takes a function from A to B and applies it to all elements of a list of A, giving a list of B:
Tuple
This is a method of the List class that takes as its argument a function from A to a tuple of values. For example, it might be a function that takes an email address and returns the name and the domain as a tuple. The unzip method, in that case, would return a tuple of a list of names and a list of domains.
A reduce(Function
This method of List uses an operation to reduce the list to a single value. This opera- tion is represented by Function
Using these methods, you can now create a new method that groups payments by credit card.
Listing 1.6 Grouping payments by credit card
package com.fpinjava.introduction.listing01_06;
import com.fpinjava.common.List;
public class Payment {
public final CreditCard creditCard;
public final int amount;
public Payment(CreditCard creditCard, int amount) {
this.creditCard = creditCard;
this.amount = amount;
}
public Payment combine(Payment payment) {
if (creditCard.equals(payment.creditCard)) {
return new Payment(creditCard, amount + payment.amount);
} else {
throw new IllegalStateException("Cards don't match.");
}
}
Licensed to
14
CHAPTER 1 What is functional programming?
public static List
return payments
.groupBy(x -> x.creditCard)
.values()
.map(x -> x.reduce(c1 -> c2 -> c1.combine(c2)));
}
}
Changes a List
Reduces each List
Changes the Map
Note that you could use a method reference in the last line of the groupByCard method, but I chose the lambda notation because it’s probably (much) easier to read. If you prefer method references, you can replace this line with the following one:
.map(x -> x.reduce(c1 -> c1::combine));
In listing 1.6, the portion after c1 -> is a function taking a single parameter and pass- ing that parameter to c1.combine(). And that’s exactly what c1::combine is—it’s a function taking a single parameter. Method references are often easier to read than lambdas, but not always!
1.7 Pushing abstraction to the limit
As you’ve seen, functional programming consists in writing programs by composing pure functions, which means functions without side effects. These functions may be represented by methods, or they may be first-class functions, such as the arguments of methods groupBy, map, or reduce, in the previous example. First-class functions are simply functions represented in such a way that, unlike methods, they can be manipu- lated by the program. In most cases, they’re used as arguments to other functions, or to methods. You’ll learn in chapter 2 how this is done.
But the most important notion here is abstraction. Look at the reduce method. It takes as its argument an operation, and uses it to reduce a list to a single value. Here, the operation has two operands of the same type. Except for this, it could be any oper- ation. Consider a list of integers. You could write a sum method to compute the sum of the elements; you could write a product method to compute the product of the ele- ments; or you could write a min or a max method to compute the minimum or the maximum of the list. But you could also use the reduce method for all these computa- tions. This is abstraction. You abstract the part that is common to all operations in the reduce method, and you pass the variable part (the operation) as an argument.
But you could go further. The reduce method is a particular case of a more gen- eral method that might produce a result of a different type than the elements of the list. For example, it could be applied to a list of characters to produce a String. You’d need to start from a given value (probably an empty string). In chapters 3 and 5, you’ll learn how to develop this method (called fold). Also note that the reduce method
Licensed to
Summary 15
won’t work on an empty list. Think of a list of integers—if you want to compute the sum, you need to have an element to start with. If the list is empty, what should you return? Of course, you know that the result should be 0, but this only works for a sum. It doesn’t work for a product.
Also consider the groupByCard method. It looks like a business method that can only be used to group payments by credit cards. But it’s not! You could use this method to group the elements of any list by any of their properties, so this method should be abstracted and put inside the List class in such a way that it could be reused easily.
A very important part of functional programming consists in pushing abstraction to the limit. In the rest of this book, you’ll learn how to abstract many things so you never have to define them again. You will, for example, learn how to abstract loops so you won’t have to write loops ever again. And you’ll learn how to abstract paralleliza- tion in a way that will allow you to switch from serial to parallel processing just by selecting a method in the List class.
1.8 Summary
Functional programming is programming with functions, returning values, and having no side effects.
Functional programs are easy to reason about and easy to test.
Functional programming offers a high level of abstraction and reusability.
Functional programs are more robust than their imperative counterparts.
Functional programs are safer in multithreading environments because they
avoid shared mutable state.
Licensed to
Using functions in Java
This chapter covers
Understanding functions in the real world Representing functions in Java
Using lambdas
Working with higher-order functions
Using curried functions
Programming with functional interfaces
To understand how functional programming works, we could use functional com- ponents provided by some functional library, or even the few that have been made available in the Java 8 library. But instead, we’ll look at how you can construct things rather than how to use these provided components. Once you’ve mastered the concepts, it will be up to you to choose between your own functions and the standard Java 8 ones, or to rely on one of the existing external libraries. In this chapter you’ll create a Function very similar to the Java 8 Function. It will be a bit simplified in how it handles type parameters (avoiding wildcards) in order to make the code easier to read, but it will have some powerful capacities that are absent from the Java 8 version. Apart from those differences, they’ll be interchangeable.
16
Licensed to
What is a function? 17
You might have trouble understanding some parts of the code presented in this chapter. That’s to be expected, because it’s very difficult to introduce functions with- out using other functional constructs such as List, Option, and others. Be patient. All the unexplained components will be discussed in the following chapters.
I’ll now explain in greater detail what a function is, both in the real world and in a programming language. Functions aren’t only a mathematical or programming entity. Functions are part of everyday life. We’re constantly modeling the world in which we live, and this is true not only for programming. We construct representations of the world around us, and these representations are often based on objects that mutate their state as time changes. Seeing things this way is human nature. Going from state A to state B takes time, and it has a cost in terms of time, effort, or money.
Consider addition as an example. Most of us see it as a computation that takes time (and sometimes intellectual effort!). It has a starting state, a transition (the computa- tion), and a resulting state (the result of the addition).
To add 345, 765, and 34,524, we certainly need to perform a computation. Some of us can do it in little time, and others will take longer. Some might never succeed, or will get an erroneous result. Some will make the computation in their head; others will need to write it down on paper. All will probably mutate some state to achieve this, whether it’s a sheet of paper or some part of their brain. But to add 2 and 3, we don’t need all this. Most of us have memorized the answer and can give the result immedi- ately, without doing any computation.
This example shows that computation isn’t the essential element here. It’s just a means to calculate the result of a function. But this result existed before we made the computation. We just generally don’t know what this result is beforehand.
Functional programming is just programming using functions. To be able to do this, we first need to know what a function is, both in the real world and in our pro- gramming language of choice.
2.1 What is a function?
A function is generally known as a mathematical object, although the concept is also ubiquitous in everyday life. Unfortunately, in everyday life, we often confuse functions and effects. And what is even more unfortunate is that we also make this mistake when working with many programming languages.
2.1.1 Functions in the real world
In the real world, a function is primarily a mathematic concept. It’s a relation between a source set, called the function domain, to a target set, called the function codomain. The domain and the codomain need not be distinct. A function can have the same set of integer numbers for its domain and its codomain, for example.
WHAT MAKES A RELATION BETWEEN TWO SETS A FUNCTION
To be a function, a relation must fulfill one condition: all elements of the domain must have one and only one corresponding element in the codomain, as shown in figure 2.1.
Licensed to
18
CHAPTER 2 Using functions in Java This has some interesting implications:
There cannot exist elements in the domain with no corresponding value in the codomain.
There cannot exist two elements in the codomain corresponding to the same element of the domain.
There may be elements in the codomain with no corresponding element in the source set.
There may be elements in the codomain with more than one corresponding element in the source set.
The set of elements of the codomain that have a corresponding element in the domain is called the image of the function.
1 2 3 4 5
Domain
10 Codomain
f(x) is a function from N to N.
Codomain
10 Domain
Figure 2.1 illustrates a function.
f(x) = 2 * x
f-1(x) = x / 2
11 22
34 134
5 235
6 The image of 4 6
7 the function 5 7
88 99
Figure 2.1 All elements of a function’s domain must have one and only one corresponding element in the codomain.
You can, for example, define the function
f(x) = x + 1
where x is a positive integer. This function represents the relationship between each positive integer and its successor. You can give any name to this function. In particular, you can give it a name that will help you remember what it is, such as
successor(x) = x + 1
This may seem like a good idea, but you shouldn’t blindly trust a function name. You could alternatively have defined the function as follows:
predecessor(x) = x + 1
Licensed to
f-1(x) isn't a function considering N as the domain. It is, however, a function considering the set of even numbers (the image of f) as the domain.
What is a function? 19
No error occurs here, because no mandatory relationship exists between a function name and the definition of the function. But, obviously, it would be a bad idea to use such a name.
Note that we’re talking about what a function is (its definition) and not what it does. A function does nothing. The successor function doesn’t add 1 to its argument. You can add 1 to an integer to calculate its successor, but you aren’t a function. The function
successor(x)
doesn’t add 1 to x. It is only equivalent to x + 1, which simply means that each time you encounter the expression successor(x), you can replace it with (x + 1).
Note the parentheses that are used to isolate the expression. They aren’t needed when the expression is used alone, but they might be necessary on some occasions.
INVERSE FUNCTIONS
A function may or may not have an inverse function. If f(x) is a function from A to B (A being the domain and B the codomain), the inverse function is noted as f-1(x) and has B as its domain and A as its codomain. If you represent the type of the function as A –> B, the inverse function (if it exists) has the type B –> A.
The inverse of a function is a function if it fulfills the same requirement as any function: having one and only one target value for each source value. As a result, the inverse of successor(x), a relation that you’ll call predecessor(x) (although you could just as well call it xyz), isn’t a function in N (the set of positive integers including 0) because 0 has no predecessor in N. Conversely, if successor(x) is con- sidered with the set of signed integers (positive and negative, noted as Z), the inverse of successor is a function.
Some other simple functions have no inverse. For example, the function
f(x) = (2 * x)
has no inverse if defined from N to N. It has an inverse if you define it as a function
from N to the set of even integers.
PARTIAL FUNCTIONS
A relation that isn’t defined for all elements of the domain but that fulfills the rest of the requirement (no element of the domain can have a relationship with more than oneelement of the codomain) is often called a partial function. The relation predecessor(x) is a partial function on N (the set of positive integers plus 0), but it’s a total function on N*, which is the set of positive integers without 0, and its codomain is N.
Partial functions are important in programming because many bugs are the result of using a partial function as if it were a total one. For example, the relation f(x) = 1/x is a partial function from N to Q (the rational numbers) because it isn’t defined for 0. It’s a total function from N* to Q, but it’s also a total function from N to (Q plus error). By adding an element to the codomain (the error condition), you can trans- form the partial function into a total one. But to do this, the function needs a way to
Licensed to
20
CHAPTER 2 Using functions in Java
return an error. Can you see an analogy with computer programs? You’ll see that turn-
ing partial functions into total ones is an important part of functional programming.
FUNCTION COMPOSITION
Functions are building blocks that can be composed to build other functions. The composition of functions f and g is noted as f ° g, which reads as f round g. If f(x) = x + 2 and g(x) = x * 2, then
f ° g (x) = f(g(x)) = f(x * 2) = (x * 2) + 2
Note that the two notations f ° g (x) and f(g(x)) are equivalent. But writing a com- position as f(g(x)) implies using x as a placeholder for the argument. Using the f ° g notation, you can express a function composition without using this placeholder.
If you apply this function to 5, you’ll get the following: f ° g (5) = f(g(5)) = f(5 * 2) = 10 + 2 = 12
It’s interesting to note that f ° g is generally different from g ° f, although they may sometimes be equivalent. For example:
g ° f (5) = g(f(5)) = g(5 + 2) = 7 * 2 = 14
Note that the functions are applied in the inverse of the writing order. If you write f ° g, you first apply g, and then f. Standard Java 8 functions define the compose() method and the andThen() method to represent both cases (which, by the way, isn’t necessary because f.andThen(g) is the same as g.compose(f), or g ° f).
FUNCTIONS OF SEVERAL ARGUMENTS
So far, we’ve talked only about functions of one argument. What about functions of several arguments? Simply said, there’s no such thing as a function of several argu- ments. Remember the definition? A function is a relation between a source set and a target set. It isn’t a relation between two or more source sets and a target set. A func- tion can’t have several arguments.
But the product of two sets is itself a set, so a function from such a product of sets into a set may appear to be a function of several arguments. Let’s consider the follow- ing function:
f(x, y) = x + y
This may be a relation between N x N and N, in which case, it’s a function. But it has only one argument, which is an element of N x N.
N x N is the set of all possible pairs of integers. An element of this set is a pair of integers, and a pair is a special case of the more general tuple concept used to repre- sent combinations of several elements. A pair is a tuple of two elements.
Tuples are noted between parentheses, so (3, 5) is a tuple and an element of N x N. The function f can be applied to this tuple:
f((3, 5)) = 3 + 5 = 8
Licensed to
What is a function? 21 In such a case, you may, by convention, simplify writing by removing one set of paren-
theses:
f(3, 5) = 3 + 5 = 8
Nevertheless, it’s still a function of one tuple, and not a function of two arguments.
FUNCTION CURRYING
Functions of tuples can be thought of differently. The function f(3, 5) might be con- sidered as a function from N to a set of functions of N. So the previous example could be rewritten as
f(x)(y) = g(y)
where
g(y) = x + y
In such a case, you can write
f(x) = g
which means that the result of applying the function f to the argument x is a new
function g. Applying this g function to y gives the following: g(y) = x + y
When applying g, x is no longer a variable. It doesn’t depend on the argument or on anything else. It’s a constant. If you apply this to (3, 5), you get the following:
f(3)(5) = g(5) = 3 + 5 = 8
The only new thing here is that the codomain of f is a set of functions instead of a set of numbers. The result of applying f to an integer is a function. The result of applying this function to an integer is an integer.
f(x)(y) is the curried form of the function f(x, y). Applying this transformation to a function of a tuple (which you can call a function of several arguments if you pre- fer) is called currying, after the mathematician Haskell Curry (although he wasn’t the inventor of this transformation).
PARTIALLY APPLIED FUNCTIONS
The curried form of the addition function may not seem natural, and you might won- der if it corresponds to something in the real world. After all, with the curried version, you’re considering both arguments separately. One of the arguments is considered first, and applying the function to it gives you a new function. Is this new function use- ful by itself, or is it simply a step in the global calculation?
In the case of an addition, it doesn’t seem useful. And by the way, you could start with either of the two arguments and it would make no difference. The intermediate function would be different, but not the end result.
Licensed to
22
CHAPTER 2 Using functions in Java
2.2
Now consider a new function of a pair of values:
f(rate, price) = price / 100 * (100 + rate)
That function seems to be equivalent to this:
g(price, rate) = price / 100 * (100 + rate)
Let’s now consider the curried versions of these two functions:
f(rate)(price)
g(price)(rate)
You know that f and g are functions. But what are f(rate) and g(price)? Yes, for sure, they’re the results of applying f to rate and g to price. But what are the types of these results?
f(rate) is a function of a price to a price. If rate = 9, this function applies a tax of 9% to a price, giving a new price. You could call the resulting function apply9- percentTax(price), and it would probably be a useful tool because the tax rate doesn’t change often.
On the other hand, g(price) is a function of a rate to a price. If the price is $100, it gives a new function applying a price of $100 to a variable tax. What could you call this function? If you can’t think of a meaningful name, that usually means that it’s use- less, though this depends on the problem you have to solve.
Functions like f(rate) and g(price) are sometimes called partially applied func- tions, in reference to the forms f(rate, price) and g(price, rate). Partially apply- ing functions can have huge consequences regarding argument evaluation. We’ll come back to this subject in a later section.
If you have trouble understanding the concept of currying, imagine you’re travel- ing in a foreign country, using a handheld calculator (or your smartphone) to convert from one currency to another. Would you prefer having to type the conversion rate each time you want to compute a price, or would you rather put the conversion rate in memory? Which solution would be less error prone?
FUNCTIONS HAVE NO EFFECTS
Remember that pure functions only return a value and do nothing else. They don’t mutate any element of the outside world (with outside being relative to the function itself), they don’t mutate their arguments, and they don’t explode (or throw an excep- tion, or anything else) if an error occurs. They can return an exception or anything else, such as an error message. But they must return it, not throw it, nor log it, nor print it.
Functions in Java
In chapter 1, you used what I called functions but were in fact methods. Methods are a way to represent (to a certain extent) functions in traditional Java.
Licensed to
Functions in Java 23
2.2.1 Functional methods
A method can be functional if it respects the requirements of a pure function:
It must not mutate anything outside the function. No internal mutation may be visible from the outside.
It must not mutate its argument.
It must not throw errors or exceptions.
It must always return a value.
When called with the same argument, it must always return the same result.
Let’s look at an example.
Listing 2.1 Functional methods
public class FunctionalMethods {
public int percent1 = 5;
private int percent2 = 9;
public final int percent3 = 13;
public int add(int a, int b) {
return a + b;
}
public setPercent2(int value) {
percent2 = value;
}
}
public int applyTax1(int a) {
return a / 100 * (100 + percent1);
}
public int applyTax2(int a) {
return a / 100 * (100 + percent2);
}
public int applyTax3(int a) {
return a / 100 * (100 + percent3);
}
public List
list.add(i);
return list;
} }
public int mult(int a, Integer b) {
a = 5;
b = 2;
return a * b; }
public int div(int a, int b) {
return a / b;
Licensed to
24
CHAPTER 2 Using functions in Java
Can you say which of these methods represent pure functions? Think for a few min- utes before reading the answer that follows. Think about all the conditions and all the processing done inside the methods. Remember that what counts is what’s visible from the outside. Don’t forget to consider exceptional conditions.
Consider the first method:
public int add(int a, int b) {
return a + b;
}
add is a function because it always returns a value that depends only on its arguments. It doesn’t mutate its arguments and doesn’t interact in any way with the outside world. This method may cause an error if the sum a + b overflows the maximum int value. But this won’t throw an exception. The result will be erroneous (a negative value), but this is another problem. The result must be the same each time the function is called with the same arguments. This doesn’t mean that the result must be exact!
EXACTNESS The term exact doesn’t mean anything by itself. It generally means that it fits what is expected, so to say whether the result of a function implementation is exact, you must know the intention of the implementer. Usually you’ll have nothing but the function name to determine the inten- tion, which can be a source of misunderstanding.
Consider the second method:
public int mult(int a, Integer b) {
a = 5;
b = 2;
return a * b; }
The mult method is a pure function for the same reason as add. This may surprise you, because it seems to be mutating its arguments. But arguments in Java methods are passed by value, which means that values reassigned to them aren’t visible from outside the method. This method will always return 10, which isn’t useful because it doesn’t depend on the arguments, but this doesn’t break the requirements. When the method is called several times with the same arguments, it will return the same value.
By the way, this method is equivalent to a method with no argument. This is a spe- cial case of function: f(x) = 10. It’s a constant.
Now consider the div:
public int div(int a, int b) {
return a / b;
}
The div method isn’t a pure function because it will throw an exception if the divisor is 0. To make it a function, you could test the second parameter and return a value if it’s null. It would have to be an int, so it would be difficult to find a meaningful value, but that’s another problem.
Licensed to
Functions in Java 25
Consider the fourth method:
public int percent1 = 5;
public int applyTax1(int a) {
return a / 100 * (100 + percent1);
}
The applyTax1 method seems not to be a pure function because its result depends on the value of percent1, which is public and can be modified between two function calls. As a consequence, two function calls with the same argument could return dif- ferent values. percent1 may be considered an implicit parameter, but this parameter isn’t evaluated at the same time as the method argument. This isn’t a problem if you use the percent1 value only once inside the method, but if you read it twice, it could change between the two read operations. If you need to use the value twice, you must read it once and keep it in a local variable. This means the method applyTax1 is a pure function of the tuple (a, percent1), but it’s not a pure function of a.
Compare that with the applyTax2 method:
private int percent2 = 9;
public int applyTax2(int a) {
return a / 100 * (100 + percent2);
}
The applyTax2 method is no different. You might see it as a function, because the percent2 property is private. But it’s mutable, and it’s mutated by the setPercent2 method. Because percent2 is accessed only once, applyTax2 can be considered a pure function of the tuple (a, percent2). But if considered as a function of a, it’s not a pure function.
Now consider the sixth method:
public final int percent3 = 13;
public int applyTax3(int a) {
return a / 100 * (100 + percent3);
}
The method applyTax3 is somewhat special. Given the same argument, the method will always return the same value, because it depends only on its arguments and on the percent3 final property, which can’t be mutated. You might think that applyTax3 isn’t a pure function because the result doesn’t depend only on the method’s arguments (the result of a pure function must depend only on its arguments). But no contradic- tion exists here if you consider percent3 as a supplemental argument. In fact, the class itself may be considered a supplemental implicit argument, because all its prop- erties are accessible from inside the method.
Licensed to
26
CHAPTER 2 Using functions in Java
This is an important notion. All instance methods can be replaced with static methods by adding an argument of the type of the enclosing class. So the applyTax3 method may be rewritten as
public static int applyTax3(FunctionalMethods x, int a) {
return a / 100 * 100 + x.percent3;
}
This method may be called from inside the class, passing a reference to this for the arguments, such as applyTax3(this, a). It can also be called from outside, because it’s public, provided a reference to a FunctionalMethods instance is available. Here, applyTax3 is a pure function of the tuple (this, a).
And finally, our last method:
public List
list.add(i);
return list;
}
The append method mutates its argument before returning it, and this mutation is vis-
ible from outside the method, so it isn’t a pure function.
OBJECT NOTATION VS. FUNCTIONAL NOTATION
You’ve seen that instance methods accessing class properties may be considered as having the enclosing class instance as an implicit parameter. Methods that don’t access the enclosing class instance may be safely made static. Methods accessing the enclosing instance may also be made static if their implicit parameter (the enclosing instance) is made explicit.
Consider the Payment class from chapter 1: public class Payment {
public final CreditCard cc;
public final int amount;
public Payment(CreditCard cc, int amount) {
this.cc = cc;
this.amount = amount;
}
public Payment combine(Payment other) {
if (cc.equals(other.cc)) {
return new Payment(cc, amount + other.amount);
} else {
throw new IllegalStateException(
"Can't combine payments to different cards");
} }
}
The combine method accesses the enclosing class’s cc and amount fields. As a result, it
can’t be made static. This method has the enclosing class as an implicit parameter.
Licensed to
Functions in Java 27 You could make this parameter explicit, which would allow you to make the
method static:
public class Payment {
public final CreditCard cc;
public final int amount;
public Payment(CreditCard cc, int amount) {
this.cc = cc;
this.amount = amount;
}
public static Payment combine(Payment payment1, Payment payment2) {
if (payment1.cc.equals(payment2.cc)) {
return new Payment(payment1.cc, payment1.amount + payment2.amount);
} else {
throw new IllegalStateException(
"Can't combine payments to different cards");
} }
}
A static method enables you to make sure no unwanted access exists to the enclosing scope. But it changes the way the method can be used.
If used from inside the class, the static method can be called, passing it the this reference:
Payment newPayment = combine(this, otherPayment);
If the method is called from outside the class, you must use the class name:
Payment newPayment = Payment.combine(payment1, payment2);
This makes little difference, but it all changes when you need to compose method calls. If you need to combine several payments, an instance method written as follows
public Payment combine(Payment payment) {
if (this.cc.equals(payment.cc)) {
return new Payment(this.cc, this.amount + payment.amount);
} else {
throw new IllegalStateException(
"Can't combine payments to different cards");
} }
may be used with object notation:
Payment newPayment = p0.combine(p1).combine(p2).combine(p3);
That’s much easier to read than this:
Payment newPayment = combine(combine(combine(p0, p1), p2), p3);
Combining one more charge in the first case is also simpler.
Licensed to
28
2.2.2
CHAPTER 2 Using functions in Java Java functional interfaces and anonymous classes
Methods can be made functional, but they’re missing something that keeps them from being able to represent functions in functional programming: they can’t be manipulated besides being applied to arguments. You can’t pass a method as an argu- ment to another method. The consequence is that you can’t compose methods with- out applying them. You can compose method applications, but not the methods themselves. A Java method belongs to the class where it’s defined, and it stays there.
You can compose methods by calling them from other methods, but this must be done while writing the program. If you want different compositions depending on particular conditions, you have to lay out these compositions at writing time. You can’t write a program in such a way that the program itself will change during execution. Or can you?
Yes, you can! Sometimes you register handlers at runtime to handle specific cases. You can add handlers to handler collections, or remove them, or change the order in which they’ll be used. How can you do this? By using classes containing the methods you want to manipulate.
In a GUI, you often use listeners to handle specific events such as moving the mouse, resizing a window, or typing text. These listeners are generally created as anonymous classes implementing a specific interface. You can use the same principle to create functions.
Let’s say you want to create a method to triple an integer value. First, you have to define an interface with a single method:
public interface Function {
int apply(int arg);
}
You then implement this method to create your function:
Function triple = new Function() {
@Override
public int apply(int arg) {
return arg * 3;
}
};
This function can then be applied to an argument:
System.out.println(triple.apply(2));
6
I must admit that this isn’t spectacular. A good old method would have been easier to use. If you want to create another function, you can process it exactly the same way:
Function square = new Function() {
@Override
Licensed to
Functions in Java 29
public int apply(int arg) {
return arg * arg;
} };
So far, so good, but what’s the benefit of this?
2.2.3 Composing functions
If you think about functions as methods, composing them seems simple:
System.out.println(square.apply(triple.apply(2)));
36
But this isn’t function composition. In this example, you’re composing function appli- cations. Function composition is a binary operation on functions, just as addition is a binary operation on numbers. So you can compose functions programmatically, using a method:
Function compose(final Function f1, final Function f2) {
return new Function() {
@Override
public int apply(int arg) {
return f1.apply(f2.apply(arg));
}
}; }
System.out.println(compose(triple, square).apply(3));
27
Now you can start seeing how powerful this concept is! But two big problems remain. The first is that our functions can only take integer (int) arguments and return inte- gers. Let’s deal with this first.
2.2.4 Polymorphic functions
To make our function more reusable, you can change it into a polymorphic function by using parameterized types, which are implemented in Java using generics:
public interface Function
U apply(T arg);
}
Given this new interface, you can rewrite our functions as follows:
Function
@Override
public Integer apply(Integer arg) {
return arg * 3;
}
};
Licensed to
30
CHAPTER 2 Using functions in Java
Function
@Override
public Integer apply(Integer arg) {
return arg * arg;
}
};
As you see, we switched from int to Integer because int can’t be used as a type parameter in Java. Hopefully, auto-boxing and auto-unboxing will make the conver- sion transparent.
EXERCISE 2.1
Write the compose method by using these two new functions.
NOTE Solutions follow each exercise, but you should first try to solve the exercise by yourself without looking at the solution. The solution code also appears on the book’s website. This exercise is simple, but some will be quite hard, so it might be difficult to refrain from cheating. Remember that the harder you search, the more you learn.
SOLUTION 2.1
static Function
return new Function
@Override
public Integer apply(Integer arg) {
return f1.apply(f2.apply(arg)); }
}; }
Problem with function compositions
Function composition is a powerful concept, but when implemented in Java, it pres- ents a big danger. Composing a couple of functions is harmless. But think about building a list of 10,000 functions and composing them into a single one. (This could be done through a fold, an operation you’ll learn about in chapter 3.)
In imperative programming, each function is evaluated before the result is passed as the input of the next function. But in functional programming, composing functions means building the resulting function without evaluating anything. Composing func- tions is powerful because functions can be composed without being evaluated. But as a consequence, applying the composed function results in numerous embedded method calls that will eventually overflow the stack. This can be demonstrated with a simple example (using lambdas, which will be introduced in the next section):
int fnum = 10_000; Function
Function
for (int i = 0; i < fnum; i++) {
Licensed to
Functions in Java 31
g = Function.compose(f, g);
};
System.out.println(g.apply(0));
This program will overflow the stack when fnum is around 7,500. Hopefully you won’t usually compose several thousand functions, but you should be aware of this.
2.2.5 Simplifying the code by using lambdas
The second problem you have is that functions defined using anonymous classes are cumbersome to use in coding. If you’re using Java 5 to 7, you’re out of luck, because there’s no other way to go. Fortunately, Java 8 introduced lambdas.
Lambdas don’t change the way the Function interface is defined, but they make implementing it much simpler:
Function
Function
Lambdas aren’t just a syntax simplification. Lambdas have some consequences in terms of code compilation. One of the main differences between lambdas and the tra- ditional way of writing anonymous classes is that the types on the right side of the equals sign can be omitted. This is possible because Java 8 comes with new capabilities regarding type inference.
Prior to Java 7, type inference was possible only when chaining identifier derefer- encing, such as this:
System.out.println();
Here, you don’t need to specify the type of out, and Java is able to find it. If you were
to write this without chaining, you’d have to specify the type:
PrintStream out = System.out;
out.println();
Java 7 added a bit of type inference with the diamond syntax:
List
Here, you don’t need to repeat the type parameter String for the ArrayList because Java is able to infer it by looking at the declaration. The same thing is possible with lambdas:
Function
In this example, the type of x is inferred by Java. But this isn’t always possible. When Java complains that it isn’t able to infer the type, you have to write it explicitly. Then you must use parentheses:
Function
Licensed to
32
CHAPTER 2 Using functions in Java
SPECIFYING FUNCTION TYPES
Although Java 8 introduced lambdas to ease function implementation, it’s missing the same kind of tool to simplify writing function types. The type of a function from an Integer to an Integer is
Function
and the function implementation is written like this:
x -> expression
It would be nice to be able to apply the same simplification to the type, which would allow you to write the whole thing as follows:
Integer -> Integer square = x -> x * x;
Unfortunately, this isn’t possible in Java 8, and it’s something you can’t add yourself.
EXERCISE 2.2
Write a new version of the compose method by using lambdas.
SOLUTION 2.2
Replacing anonymous classes with lambdas is straightforward. Here’s the code of the first version of the compose method:
static Function
return new Function
public Integer apply(Integer arg) {
return f1.apply(f2.apply(arg));
}
}; }
All you have to do is replace the return value of the compose method with the argu- ment of the anonymous class’s apply method, followed by an arrow (->) and the return value of the apply method:
static Function
return arg -> f1.apply(f2.apply(arg)); }
You can use any name for the argument. Figure 2.2 shows this process.
Licensed to
Advanced function features 33 public static final Function
return new Function
@Override
public Integer apply(Integer arg) {
return f1.apply(f2.apply(arg)) ; }
}; }
final Function
public static final Function
return arg -> f1.apply(f2.apply(arg)); }
Figure 2.2 Replacing anonymous classes with lambdas
2.3 Advanced function features
You’ve seen how to create apply and compose functions. You’ve also learned that func- tions can be represented by methods or by objects. But you haven’t answered a funda- mental question: why do you need function objects? Couldn’t you simply use methods? Before answering this question, you have to consider the problem of the functional representation of multiargument methods.
2.3.1 What about functions of several arguments?
In section 2.1.1, I said that there are no functions of several arguments. There are only functions of one tuple of arguments. The cardinality of a tuple may be whatever you need, and there are specific names for tuples with a few arguments: pair, triplet, quar- tet, and so on. Other possible names exist, and some prefer to call them tuple2, tuple3, tuple4, and so forth. But I also said that arguments can be applied one by one, each application of one argument returning a new function, except for the last one.
Let’s try to define a function for adding two integers. You’ll apply a function to the first argument, and this will return a function. The type will be as follows:
Function
This may seem a bit complicated, particularly if you think that it could have been writ- ten like this:
Integer -> Integer -> Integer
Note that because of associativity, this is equivalent to
Integer -> (Integer -> Integer)
Licensed to
34
CHAPTER 2 Using functions in Java
2.3.2
where the left Integer is the type of the argument, and the element between paren- theses is the return type, which obviously is a function type. If you remove the word Function from Function
This is exactly the same. The Java way of writing function types is much more verbose but not more complex.
EXERCISE 2.3
Write a function to add two Integers.
SOLUTION 2.3
This function will take an Integer as its argument and return a function from Integer to Integer, so the type will be Function
Function
You can see that you’ll soon have problems with the length of the lines! Java has no type aliases, but you can achieve the same result through inheritance. If you have many functions to define with the same type, you can extend it with a much shorter identifier, like this:
public interface BinaryOperator extends
Function
BinaryOperator add = x -> y -> x + y;
BinaryOperator mult = x -> y -> x * y;
The number of arguments isn’t limited. You can define functions with as many argu- ments as you need. As I said in the first part of this chapter, functions such as the add function or the mult function you just defined are said to be the curried form of the equivalent functions of tuples.
Applying curried functions
You’ve seen how to write curried function types and how to implement them. But how do you apply them? Well, just like any function. You apply the function to the first argument, and then apply the result to the next argument, and so on until the last one. For example, you can apply the add function to 3 and 5:
System.out.println(add.apply(3).apply(5));
8
Here, you’re again missing some syntactic sugar. It would be great if you could apply a function just by writing its name followed by its argument. It would allow coding, as in Scala:
add(3)(5)
Licensed to
Advanced function features 35
Or even better, as in Haskell:
add 3 5
Perhaps in a future version of Java?
2.3.3 Higher-order functions
In section 2.14, you wrote a method to compose functions. That method was a func- tional one, taking as its argument a tuple of two functions and returning a function. But instead of using a method, you could use a function! This special kind of function, taking functions as its arguments and returning functions, is called a higher-order func- tion (HOF).
EXERCISE 2.4
Write a function to compose the two functions square and triple used in exercise 2.2.
SOLUTION 2.4
This exercise is easy if you follow the right procedure. The first thing to do is to write the type. This function will work on two arguments, so it’ll be a curried function. The two arguments and the return type will be functions from Integer to Integer:
Function
You can call this T. You want to create a function taking an argument of type T (the first argument) and returning a function from T (the second argument) to T (the return value). The type of the function is then as follows:
Function
If you replace T with its value, you obtain the real type:
Function
Function
Function
The main problem here is the line length! Let’s now add the implementation, which is much easier than the type:
x -> y -> z -> x.apply(y.apply(z));
The complete code is shown here:
Function
Function
Function
x -> y -> z -> x.apply(y.apply(z));
You can write this code on a single line! Let’s test this code with the square and triple functions:
Function
Licensed to
36
CHAPTER 2 Using functions in Java Function
Function
In this code, you start by applying the first argument, which gives you a new function to apply to the second argument. The result is a function, which is the composition of the two function arguments. Applying this new function to (for example) 2 gives you the result of first applying triple to 2 and then applying square to the result (which corresponds to the definition of function composition):
System.out.println(f.apply(2));
36
Pay attention to the order of the parameters: triple is applied first, and then square is applied to the result returned by triple.
Polymorphic higher-order functions
Our compose function is fine, but it can compose only functions from Integer to Integer. It would be much more interesting if you could compose any types of func- tions, such as String to Double or Boolean to Long. But that’s only the beginning. A fully polymorphic compose function would allow you to compose Function
EXERCISE 2.5 (HARD)
Write a polymorphic version of the compose function.
HINT
You may face two problems in trying to solve this exercise. The first is the lack of poly- morphic properties in Java. In Java, you can create polymorphic classes, interfaces, and methods, but you can’t define polymorphic properties. The solution is to store the function in a method, class, or interface, instead of in a property.
The second problem is that Java doesn’t handle variance, so you may find yourself trying to cast a Function
SOLUTION 2.5
The first step seems to be to “generify” the example of exercise 2.4:
Function
Function
f -> g -> x -> f.apply(g.apply(x));
But this isn’t possible, because Java doesn’t allow standalone generic properties. To be generic, a property must be created in a scope defining the type parameters. Only
2.3.4
Licensed to
Advanced function features 37
Variance
Variance describes how parameterized types behave in relation to subtyping. Covari- ance means that Matcher