Main
Posted on 7/25/14

p I recently started learning about the programming language Haskell. I plan to write soon about using it to build a game engine, but before that I want to tackle a neat little feature that’s common in functional languages: The Option Type. p In Haskell it’s called Maybe. In Scala, ‘Option’. Apple’s new language Swift also has optional types, with a caveat– more on that later. p The central idea is that the possibility of having a Null value should be represented at the type level, not at the runtime level. p In C, C++, Obj-C, Java, and other similar languages, the lack of a value is represented by Null. So if your function takes a Thing, you probably need to check if that Thing is really a Thing, or actually a Null (a Nothing). I say probably because sometimes you can be sure you have a Thing, so you don’t need to double check. And checking for that is annoying, so it’s often left out if possible.

pre. // Hypothetical greeter function String greet(String name) { if (name == Null) { //Null checking is annoying return “I don’t know who you are!” } else { return “Greetings,” + name } }

p But sometimes our assumptions are wrong! If we take a function that presumed the value would not be Null, and use it in a new context where the value might actually be Null, we can get a runtime error (hello NullPointerException!). Or maybe we assumed a library function would always return a Thing, but it actually can return a Nothing under certain circumstances. Shame on us for not reading the docs, I suppose. p Dynamic languages like Python, Ruby, Scheme, etc. obviously have no static type checking, so they are prone to the same problems. p The option type solves this problem by requiring us to handle the Nothing case. Here’s a quick Haskell example that turns “Axis” into “Greetings, Axis”.

p First we declare the type of the function. pre. greet :: Maybe String -> String

p In Haskell, a Maybe Thing can either be ‘Nothing’ or ‘Just Thing’. We declare our greet function to be of type Maybe String -> String which means it takes a value that might be a String (or might be Nothing), and returns something that is definitely a String.

p Here’s the definition of greet:

pre. greet maybe_name = case maybe_name of Nothing -> “I don’t know who you are!” Just name -> “Greetings,” ++ name

p Because the actual type of the value is a Maybe, in order to get at the Just value we need to use pattern matching. The compiler forces us to confront the possibility of not having a String. Of course, that’s a bit verbose. More idiomatic Haskell would do the pattern matching in the actual function parameters:

pre. greet Nothing = “I don’t know who you are!” greet (Just name) = “Greetings,” ++ name

p We can simply write two versions of the function. One will do the actual work of the function, and the other will handle the Nothing case.

p So what do we win here? I personally like the pattern matching syntax better than

pre. String greet(String name) { if (name == Null) { … } else { … } }

p But that’s not the big win. The magic is in the return value of our greet function. It’s a String, not a Maybe String! That means we know we will always get a String back from that function. You can display it right in a web page without having to consider the Null case. It actually saves us from having to write error checking code in other places. We only write it when the compiler tells us we need to.

p So Swift also has this feature, but it makes a small concession to the imperative world of programming. From the Swift docs:

p em “Of course, if you are certain of the type of the object (and know that it is not nil), you can force the invocation with the as operator.”

p The question is, if the type says that a value might be nil, how sure can you ever be that the value will never be nil? This sort of assumption may be true when the code is first written, but it tends to break after refactoring. If the value will really truly never be nil, then it shouldn’t have been an Optional in the first place.

p To be fair, the Haskell compiler GHC only generates a warning for not handling a Nothing case, but I do think that’s a big step up from trusting the code as written.

p So, embrace the uncertainty! Learn to love Maybe! Kick Null to the curb!