We strongly typed functional programmers pride ourselves on writing robust code, making error conditions explicit through expressive types such as option and result. Yet, of course, we also want our code to run fast. These desires – explicit, statically checked error conditions – and performance are sometimes in contention: every function that wants to return a result of type answer option must use the Some constructor to build successful results. This causes runtime allocation, which eventually triggers latency-causing garbage collection.

This talk describes the design and implementation challenges of taking advantage of an all-0, or null, value to denote error conditions, all without losing the strongly typed nature of option. Our new optional type is named or_null, with constructors This and Null. The key step is to distinguish with-null types from no-null types, as explained in this extended abstract. We have a prototype implementation in a branch of the OCaml compiler.

Software Engineer at Jane Street. I believe that clever application of theory can eliminate a great deal of programmer errors – specifically, I think fancy types and functional programming are the future. I completed my PhD in 2016 at University of Pennsylvania working under Stephanie Weirich; my dissertation topic was the integration of dependent types into the Haskell programming language. My work now centers around improvements to OCaml’s type system to empower more performant programming – without sacrificing safety. In addition, I am a contributor to the Glasgow Haskell Compiler (GHC) and frequent collaborator on its type system and implementation.