Table of Contents for

Opa: Up and Running

Variant types, as the name suggests, allow you to express values that can take several different variants. Probably the simplest such type is a boolean value, which is defined in Opa as follows:

type bool = {false} or {true}

The variants are separated with the or keyword and the variants themselves are just regular record types. Lack of a type for a given field implies it is of type void (which we covered in Event Handlers), so the preceding code can also be written as follows:

type bool = {void false} or {void true}

Such void-typed fields make little sense in regular records, as the field value carries no information. However, in variant types they make perfect sense, as their presence is important and differentiates between variants.

In this simple form, with all variants having just one field of type void, those types correspond to enumeration types, as you may know from other programming languages. Here is another example from the standard Opa library:

type Date.weekday = {monday} or {tuesday} or {wednesday} or {thursday}
  or {friday} or {saturday} or {sunday}

However, note that in Opa we are not restricted to such degenerated records. For instance, say we need to keep track of the logged-in user, and suppose we have a User.t type describing the user. We can keep track of the logged-in user with the following type:

type User.logged = {guest} or {User.t user}

Example values of type User.logged are {guest} and {user: u} if u is a value of type User.t. Of course, we are not restricted to single-field records.

But how can we work with such values? How do we figure out which variant was used to construct the value; for instance, to check whether the user is logged in?

This is where pattern matching comes in handy. Pattern matching is a way of analyzing and decomposing values. At first, it can seem deceptively similar to switch statements, which you may know from languages such as JavaScript, C, and Java, but as you will see later in this chapter, pattern matching can do much more than that.

Let’s look at some examples. We’ll start with Boolean values:

function int int_of_bool(bool b) {
  match (b) {
  case {true}: 1
  case {false}: 0
  }
}

Here, the match is followed by an expression (it does not need to be a simple variable) that we want to match against, put in parentheses. This is followed by a number of different matching cases introduced with the case keyword, followed by the matched pattern, a colon, and the expression with the result for that particular case.

Now let’s match a value of type User.logged:

function string greet(User.logged u) {
  name =
    match (u) {
    case {guest}: "guest"
    case {user: user}: User.get_name(user)
    }
  "Hello, {name}"
}

In this second pattern-matching case, user will be matched against the value of the user field in the record u and can be accessed in the expression User.get_name(user). Just as with regular records, you can abbreviate {user: user} to ~{user} in the pattern.

With pattern matching, there are a few things to keep in mind. First, the pattern-matching part of the code is an expression, not a statement (as switch is in many languages). This means it is perfectly permissible to write the previous function as:

function string greet(User.logged u) {
  "Hello, " + match (u) {
              case {guest}: "guest"
              case {user: user}: User.get_name(user)
              }
}

Second, the compiler makes sure that all possible cases are covered by the given patterns, and otherwise will fail with a nonexhaustive pattern-matching error. This means that if at some point you need to add to the program a new feature that requires extending some type with an additional variant, you can safely do so. The compiler will then point out all the places that need to be adjusted because of this change.

Note that in the vocabulary of languages such as Java and C#, pattern-matching combines features of if, switch, instanceof/is, and casting, but without the usual (type) safety issues of the last two operations.

In this section, we will examine at an important extension of variant types: polymorphism. We will start with a simple definition:

type nullable_int = {null} or {int value}

Many programming languages allow a special null value as a value for any type. Not so in Opa. The type in the preceding code describes nullable integers by allowing two types of values: {null} and {value: x} for any integer x.

That seems like a useful definition, but we may need null for values of types other than just int. Repeating it for every single type where we need this feature would be terribly inefficient.

Fortunately, we can do better. Here is a definition from the standard Opa library:

type option('a) = {none} or {'a some}

Here, 'a is a type variable (type variables always begin with a single apostrophe) and the definition of option is parameterized by this type variable. It has two variants: {none}, meaning no value, and {some: x}, representing an existing value x of the parameterized type 'a.

We call such a type a polymorphic type as we can substitute the type variable, 'a, with an arbitrary type to obtain a concrete type. For instance, you can get optional integers by instantiating 'a with int to obtain option(int).

Also note that, thanks to Opa’s type inference, you will not need to spell out the type names in many cases. If you just write {some: 5}, the compiler will be able to figure out that this is a value of type option(int).

It’s important to realize that you can also write polymorphic functions like this one:

function bool is_some(option('a) v) {
  match (v) {
  case {some: _}: true
  default: false
  }
}

The underscore in the second pattern means we do not care about this value. It allows us to avoid the unused variable warning that would be generated if we used a {some: value} pattern with an unused variable value. It also clearly shows that the value itself is irrelevant. Note that we do not inspect the value, which is why the function can retain a fully generic option('a) type for its v argument and allows us to write:

b1 = is_some({some: 5})       // b1 == true
b2 = is_some({some: "Text"})  // b2 == true
b3 = is_some({none})          // b3 == false

Another new feature that we used in the previous example is the catchall default pattern, which always needs to be specified as the last pattern and handles all the remaining cases.

Note that many functions that handle options are already defined in the standard library; one of these is Option.default, which gets the some case and returns the default value of none:

Option.default(default_value, option_value)

option(void) v = none
match (v) {
        case {none}: 1;
}

Warning pattern
File "match1.opa", line 2, characters 1-30, (2:1-4:1 | 23-52)
Incomplete pattern matching: case {some} is missing
Error: Fatal warning: 'pattern'

The option type above has only one type variable, but types with several of them are possible. For instance, here is another type from the standard Opa library:

type outcome('ok, 'ko)= { 'ok success } or { 'ko failure }

This represents an outcome of some operation, which can be either success, with the resultant value, or failure, with an indication of the problem that occurred. The types of the values returned in case of success and in case of failure can be different. For example, an arithmetic operation could produce an int if successful or a string indicating the type of problem that occurred. Such an instance would have type outcome(int, string).

The types you’ve learned about so far allow you to only express values with a fixed, finite structure. But what about things like lists and trees? This is where recursive types come to the rescue.

A list is a finite sequence of values of a given type. In Opa, it is defined as:

type list('a) = {nil} or {'a hd, list('a) tl}

This is a polymorphic type, with list('a) being either an empty list, {nil}, or an element hd of type 'a followed by tl of type list('a). This definition of a type expressed in terms of itself is what gives it the name recursive type.

Traditionally, the first element of a list is called the head and the remainder is called the tail, hence the field names hd and tl, respectively.

So how do we represent a list with three elements: 1, 2, and 7?

l1 = {hd: 1, tl: {hd: 2, tl: {hd: 7, tl: nil}}}

This is not very readable, so Opa supports special syntax for lists that enables us to write the preceding code equivalently as:

l2 = [1, 2, 7]

Opa also offers [head | tail] syntax for a list with a given head and given tail, so we can write:

l3 = [0 | l2]  // == [0, 1, 2, 7]

or even:

l4 = [0, 3 | l2] // == [0, 3, 1, 2, 7]

Recursive types are very useful, so we will conclude this section with an illustration of how to use them to express binary trees (of arbitrary type):

type bin_tree('a) = {leaf} or {'a value, tree('a) left, tree('b) right}

When writing functions that do pattern matching on recursive types, the functions themselves will often use recursion. Since this is a new and very important concept, we will take a closer look at them in the next section.