Scala partial functions (without a PhD)
If you have done some Scala for a while, you know about pattern matching and match/case. Things like:
The first time I saw this kind of things I was a bit puzzled: in which situations could case be used without match? Well, it turns out that a block with a bunch of case inside is one way of defining an anonymous function. There is nothing new with anonymous functions of course, and Scala has a very compact notation for those that doesn’t involve case. But this particular way of defining anonymous functions gives you a lot for free, namely all the good things of pattern matching like casting-done-right, guards, and destructuring. The example above, with foreach, shows how case can be used for destructuring the tuples of the map into key and value components.
But there is more. Consider:
As expected this crashes, because the pattern match doesn’t know what to do when the string “cat” is passed to it. On the other hand, this example doesn’t crash:
So what’s the difference? Does collect just catch the MatchError and proceed? That would be clumsy and inefficient. In fact, the apparent magic lies in the fact that case blocks define special functions called partial functions. Now you might wonder, coming from a “normal” programming language background, what it means, for a function to be “partial”. Well, it comes from mathematics, where it’s opposed to “total” functions.
But even though it comes from math it’s actually simple. Take for example this function:
So you get the idea about some values not “making sense” as the argument of a function because they can’t yield a significant result.
Now if you think about it you will notice lots of situations like this in your programs, where functions are expected to work properly only for some input values. If the function is called with a disallowed value, it will typically crash, yield a special return value, or throw an exception (and this should better be documented). In short, partial function are very common in real-life programs even if you don’t know about it.
So here fraction is defined as a regular function, but conceptually it is a partial function. The good thing is that Scala has built-in support for partial functions thanks to the PartialFunction trait. And here is one way of defining such a partial function:
A PartialFunction must provides a method isDefinedAt, which allows the caller of the partial function to know, beforehand, whether the function can return a result for a given input value:
This takes us back to the use of case to define partial functions. The exact same function can be written:
(Notice that you must specify that the PartialFunction[Int, Int] type. It would be great if Scala had a syntax to make this even more compact but it doesn’t as of Scala 2.11.) And if you call the function:
(Note that there is one visible difference from the outside when you use the case way: you get a MatchError as you usually do with pattern matching.) The idea doesn’t apply only to numbers. In our collect example above, the partial function implicitly defined looks like this:
The function takes an Any as parameter because List(41, "cat") is a List[Any]. But it is only defined for inputs that are of type Int:
Passing a String didn’t go too well, as expected. But now you can check this before calling the function with:
So we now have the explanation for the difference in behavior between collect and map, which is that collect expects a partial function. It asks incAny whether it is defined for 41 and then "cat", and so automatically filters out "cat". Another cool thing here is that the Scala compiler can even infer a clean resulting collection type: List[Int]!
Also, as you notice, if you define the partial function inline, the compiler knows that it’s a partial function and you avoid the explicit PartialFunction trait. Notice that partial functions can lie:
Here liar says incorrectly that it’s defined for "cat". It would probably be better to write:
So now you see how partial functions defined with case can be used for things like collect with a super compact notation. You will see them in other places, including catch expressions. There is another situation in Scala where partial functions are “just there” and you might not know it. Take the following List:
Wouldn’t that mean that the pets function is, hum, only defined for values 0, 1, and 2? Sounds familiar? Wouldn’t it be cool to look at pets as a partial function then? Well you can because in Scala any instance of Seq, Set or Map is actually a partial function. So you can write:
And if you had a list of indexes and wanted to safely collect values for these indexes in a new list, you could write:
Here it works well because collect handles everything for us. But it can be a pain to check isDefinedAt all over the place. If anything, it feels a bit like a null check, and we hate those in Scala. The good news is that in Scala thePartialFunction trait supports the lift method, which converts the partial function to a normal function that doesn’t crash:
As you see the lift returns a function that returns an Option of the value. This allows you to safely process values without null checks and without calling isDefinedAt yourself:
I hope this helps make some sense of partial functions in Scala.