Reading 16, Part 1: Recursive Data Types

Before we introduce recursive datatypes — which have a recursive structure of both data and computation — take a minute to review recursive computations.

Just as a recursive function is defined in terms of itself, a recursive datatype is defined in terms of itself. We’ll see the same need for base and recursive cases, which will now appear as different variants of the abstract type.

We’ll start with a classic recursive datatype, the immutable list.

Immutability is powerful not just because of its safety, but also because of the potential for sharing. Sharing actually produces performance benefits: less memory consumed, less time spent copying. Here we’re going to look at how to represent list data structures differently than in our familiar array lists or linked lists.

Let’s define a data type for an immutable list, ImList<E>. The data type has four fundamental operations:

These four operations have a long and distinguished pedigree. They are fundamental to the list-processing languages Lisp and Scheme (where for historical reasons they are called nil, cons, car, and cdr, respectively). They are widely used in functional programming, where you can often find them called head and tail instead of first and rest.

Before we design Java classes to implement this datatype, let’s get used to the operations a bit, using lists of integers. We’ll write lists with square brackets, like [ 1, 2, 3 ], and we’ll write the operations as if they are mathematical functions. Once we get to Java, the syntax will look different but the operations will have the same meaning.

empty() = [ ]
cons(0, empty() ) = [ 0 ]
cons(0, cons(1, cons(2, empty() ) ) ) = [ 0, 1, 2 ]
x ≡ cons(0, cons(1, cons(2, empty() ) ) ) = [ 0, 1, 2 ]
first(x) = 0
rest(x) = [ 1, 2 ]
first(rest(x) ) = 1
rest(rest(x) ) = [ 2 ]
first(rest(rest(x) ) = 2
rest(rest(rest(x) ) ) = [ ]

The fundamental relationship between first, rest, and cons is:

first(cons(elt, lst) ) = elt
rest(cons(elt, lst) ) = lst

What cons puts together, first and rest peel back apart.

Immutable lists in Java

To implement this datatype in Java, we’ll use an interface:

public interface ImList<E> {
    // todo: empty() returning ImList<E>
    public ImList<E> cons(E elt);
    public E first();
    public ImList<E> rest();
}

This interface declares a generic type ImList<E> that can be instantiated for any type E: ImList<Integer>, ImList<String>, etc. The E in these declarations is a placeholder that the compiler will fill in when it checks our code for type safety.

And we’ll write two classes that implement this interface:

• Empty represents the result of the empty operation (an empty list)
• Cons represents the result of a cons operation (an element glued together with another list)

public class Empty<E> implements ImList<E> {
    public Empty() {
    }
    public ImList<E> cons(E elt) {
        return new Cons<>(elt, this);
    }
    public E first() {
        throw new UnsupportedOperationException();
    }
    public ImList<E> rest() {
        throw new UnsupportedOperationException();
    }
}

public class Cons<E> implements ImList<E> {
    private final E elt;
    private final ImList<E> rest;

    public Cons(E elt, ImList<E> rest) {
        this.elt = elt;
        this.rest = rest;
    }
    public ImList<E> cons(E elt) {
        return new Cons<>(elt, this);
    }
    public E first() {
        return elt;
    }
    public ImList<E> rest() {
        return rest;
    }
}

So we have methods for cons, first, and rest, but where is the fourth operation of our datatype, empty?

One way to implement empty is to have clients call the Empty class constructor to obtain empty lists. This sacrifices representation independence — clients have to know about the Empty class!

As we saw in Interfaces, a better way to do it is as a static factory method that takes no arguments and produces an instance of Empty. We can put this static method in the ImList interface along with the other operations. This choice was not possible in previous versions of Java, which is why we still write code like:

List<String> z = new ArrayList<>();

Perhaps someday Java will offer a List.empty() method to obtain a new empty all-purpose List, but not yet. (List.of() and Collections.emptyList() provide immutable empty lists.)

We will go ahead and update our ImList interface with the static empty method:

public interface ImList<E> {
    public static <E> ImList<E> empty() {
        return new Empty<>();
    }
    public ImList<E> cons(E elt);
    public E first();
    public ImList<E> rest();
}

The signature for empty uses an unfamiliar bit of generic type syntax. The E in ImList<E> is a placeholder for the type of elements in an instance of ImList, but empty is a static method: it cannot see instance variables or methods, and it also cannot see the instance type parameter. You can read the declaration of empty as: “for any E, empty() returns an ImList<E>.”

Now that we have all the operations, here’s some actual Java code that parallels the abstract examples we wrote earlier. Hover or tap on each row in the table to update the snapshot diagram:

Java syntax	Functional syntax	Result
ImList<Integer> nil = ImList.empty();	nil = empty()	[ ]
nil.cons(0)	cons(0, nil)	[ 0 ]
nil.cons(2).cons(1).cons(0)	cons(0, cons(1, cons(2, nil)))	[ 0, 1, 2 ]
ImList<Integer> x = nil.cons(2).cons(1).cons(0);	x = cons(0, cons(1, cons(2, nil)))	[ 0, 1, 2 ]
x.first()	first(x)	0
x.rest()	rest(x)	[ 1, 2 ]
x.rest().first()	first(rest(x))	1
x.rest().rest()	rest(rest(x))	[ 2 ]
x.rest().rest().first()	first(rest(rest(x)))	2
x.rest().rest().rest()	rest(rest(rest(x)))	[ ]
ImList<Integer> y = x.rest().cons(4);	y = cons(4, rest(x))	[ 4, 1, 2 ]

The key thing to note here is the sharing of structure that immutable list provides. In the last example above, x and y are sharing their representation of the sublist [ 1, 2 ].

Two classes implementing one interface

public class Empty<E> implements ImList<E> {
    public Empty() {
    }
    public ImList<E> cons(E elt) { return new Cons<E>(elt, this); }
    public E first() { throw new UnsupportedOperationException(); }
    public ImList<E> rest() { throw new UnsupportedOperationException(); }
}

public class Cons<E> implements ImList<E> {
    private E elt;
    private ImList<E> rest;
    public Cons(E elt, ImList<E> rest) {
        this.elt = elt;
        this.rest = rest;
    }
    public ImList<E> cons(E elt) { return new Cons<E> (elt, this); }
    public E first() { return elt; }
    public ImList<E> rest() { return rest; }
}

ImList<String> airports =
        ImList.empty().cons("SFO").cons("IAD").cons("BOS");

The abstract data type ImList, and its two concrete classes Empty and Cons, form a recursive data type. Cons is an implementation of ImList, but it also uses ImList inside its own rep (for the rest field), so it recursively requires an implementation of ImList in order to successfully implement its contract.

To make this fact clearly visible, we’ll write a datatype definition:

ImList<E> = Empty + Cons(elt:E, rest:ImList<E>)

This is a recursive definition of ImList as a set of values. Here’s the high-level meaning: the set ImList consists of values formed in two ways: either by the Empty constructor, or by applying the Cons constructor to an element elt and an ImList rest.

A more detailed reading: ImList<E> is a generic type where for any E, the set ImList<E> consists of the values formed: either by the Empty constructor, or by applying the Cons constructor to a value called elt of type E and a value called rest of type ImList<E>.

The recursive nature of the datatype becomes far more visible when written in a datatype definition.

We can write any ImList value as a term or expression using this definition, e.g. [ 0, 1, 2 ]:

Cons(0, Cons(1, Cons(2, Empty)))

And we can build up the infinite set of all ImList values by starting from the base case that is Empty and recursively applying Cons. For example, with ImList<Boolean>:

ImList<Boolean>

= Empty

+ Cons(true, Empty)
+ Cons(false, Empty)

+ Cons(true, Cons(true, Empty))
+ Cons(true, Cons(false, Empty))
+ Cons(false, Cons(true, Empty))
+ Cons(false, Cons(false, Empty))

+ Cons(true, ...)
+ Cons(true, ...)
+ Cons(true, ...)
+ Cons(true, ...)
+ Cons(false, ...)
+ Cons(false, ...)
+ Cons(false, ...)
+ Cons(false, ...)

+ ...

Formally, a datatype definition has:

• an abstract datatype on the left, defined by its representation (or concrete datatype) on the right
• the representation consists of variants of the datatype combined by a union operator, which we’ll write as +
• each variant is a constructor with zero or more arguments, written with name and type separated by a colon (:).

A recursive datatype definition is a datatype definition where the abstract type (on the left) appears in its own definition (as the type of a constructor argument, on the right). Another example is a binary tree:

Tree<E> = Empty + Node(e:E, left:Tree<E>, right:Tree<E>)

The Tree type is defined as the set of values formed either by its Empty constructor or by its Node constructor, which takes an element e (of type E) and left and right subtrees.

We’ll see more examples below.

When you write a recursive datatype, document the recursive datatype definition as a comment in the interface:

public interface ImList<E> {

    // Datatype definition:
    //   ImList<E> = Empty + Cons(elt:E, rest:ImList<E>)

    // ...

Geology = Core(a:int, b:int, c:int, d:int)
          + Planet(core:Core, a:int, b:int, c:int, d:int)
          + System(geology:Geology, a:int, b:int)

This way of thinking about datatypes — as a recursive definition of an abstract datatype with concrete variants — is appealing not only because it can handle recursive and unbounded structures like lists and trees, but also because it provides a convenient way to describe operations over the datatype, as functions with one case per variant.

First, notice how the datatype definition maps to the abstract interface, concrete variants, and constructors we’ve already seen:

ImList<E>

public interface ImList<E> { ... }

 =

Empty

public class Empty implements ImList {
    public Empty() { }
}

 +

Cons(elt:E, rest:ImList<E>)

public class Cons<E> implements ImList<E> {
    private final E elt;
    private final ImList<E> rest;
    public Cons(E elt, ImList<E> rest) {
        this.elt = elt;
        this.rest = rest;
    }
}

Now: let’s add a new operation by thinking about it as a recursive function with one case per variant: the size of the list, which is certainly an operation we’ll want in ImList. We can define it like this:

size : ImList → int  // returns the size of the list

and then fully specify its meaning by defining size for each variant of ImList:

size(Empty) = 0
size(Cons(elt: E, rest: ImList)) = 1 + size(rest)

This function is recursive. We can think about the execution of size on a particular list as a series of reduction steps:

size(Cons (0, Cons (1, Empty)))
 = 1 + size(Cons (1, Empty))
 = 1 + (1 + size(Empty))
 = 1 + (1 + 0)
 = 1 + 1
 = 2

And the cases from the definition can be translated directly into Java as methods in ImList, Empty, and Cons:

public interface ImList<E> {
    // ...
    public int size();
}

public class Empty<E> implements ImList<E> {
    // ...
    public int size() { return 0; }
}

public class Cons<E> implements ImList<E> {
    // ...
    public int size() { return 1 + rest.size(); }
}

This pattern of implementing an operation over a recursive datatype by

• declaring the operation in the abstract datatype interface
• implementing the operation (recursively) in each concrete variant

is a very common and practical design pattern. It sometimes goes by the unhelpful name interpreter pattern.

Let’s try a few more examples:

isEmpty : ImList → boolean

isEmpty(Empty) = true
isEmpty(Cons(elt: E, rest: ImList)) = false

contains : ImList × E → boolean

contains(Empty, e: E) = false
contains(Cons(elt: E, rest: ImList), e: E) = (elt = e) or contains(rest, e)

get: ImList × int → E

get(Empty, n: int) = undefined
get(Cons(elt: E, rest: ImList), n: int) = if n=0 then elt else get(rest, n-1)

append: ImList × ImList → ImList

append(Empty, list2: ImList) = list2
append(Cons(elt: E, rest: ImList), list2: ImList) = cons(elt, append(rest, list2))

reverse: ImList → ImList

reverse(Empty) = empty()
reverse(Cons(elt: E, rest: ImList)) = append(reverse(rest), cons(elt, empty())

For reverse, it turns out that the recursive definition produces a pretty bad implementation in Java, with performance that’s quadratic in the length of the list you’re reversing. We could rewrite it using an iterative approach if needed.

public interface ImList<‍E> {
    // ...
    /**
     * @return true iff this list is empty
     */
(missing answer)
}

class Empty<‍E> implements ImList<‍E> {
    // ...
    public boolean isEmpty() {
(missing answer)
    }
}

class Cons<‍E> implements ImList<‍E> {
    private final E elt;
    private final ImList<‍E> rest;
    // ...
    public boolean isEmpty() {
(missing answer)
    }
}

public interface ImList<‍E> {
    // ...
    /**
     * @param other list to append to this list
     * @return list with the elements of this followed by the elements of other
     */
(missing answer)
}

class Empty<‍E> implements ImList<‍E> {
    // ...
    public ImList<‍E> append(ImList<‍E> other) {
(missing answer)
    }
}

class Cons<E> implements ImList<E> {
    private E elt;
    private ImList<E> rest;
    // ...

    public ImList<E> append(ImList<E> other) {

    }
}

Tuning the rep

public class Cons<E> implements ImList<E> {
    private final E elt;
    private final ImList<E> rest;
    private int size = 0;
    // rep invariant:
    //   elt != null, rest != null, size >= 0
    //   size > 0 implies size == 1+rest.size()

    // ...
    public int size() { 
        if (size == 0) size = 1 + rest.size();
        return size;
    }
}

Does our Java implementation of ImList still have rep independence? We’ve concealed the Empty contructor behind the static method ImList.empty(), and clients should never need to use the Empty or Cons constructors directly. We can hide them further by making them package-private (declared with neither the public nor private keyword) so that classes outside of ImList’s package cannot see or use them.

We have a great deal of freedom to change our implementation — indeed, we just added a size field to the internal rep of Cons. We could even have an extra array in there to make get() run fast! This might get expensive in space, however, but we are free to make those tradeoffs.

What about an operation like isEmpty above: does that operation break rep independence by revealing the concrete variant to clients? No. The spec of isEmpty is not, e.g., “return true iff this is an Empty instance.” Instead, like any operation of an abstract type, we specify isEmpty abstractly, e.g., “return true iff this list contains no elements.” Any implementation of immutable lists, whether a recursive Empty-plus-Cons implementation, an array-backed list, a linked list, or something else, can support an isEmpty operation with that spec.

Any time you write an ADT, its specs must not talk about the rep. The concrete variants of a recursive ADT are its rep, so the specs must not mention them.

Finally, is there rep exposure because Cons.rest() returns a reference to its internal list? Could a clumsy client add elements to the rest of the list? If so, this would threaten two of Cons’s invariants: that it’s immutable, and that the cached size is always correct. But there’s no risk of rep exposure, because the internal list is immutable. Nobody can threaten the rep invariant of Cons.

It might be tempting to get rid of the Empty class and just use null instead. Resist that temptation.

Using an object, rather than a null reference, to signal the base case or endpoint of a data structure is an example of a design pattern called sentinel objects. The enormous advantage that a sentinel object provides is that it acts like an object in the datatype, so you can call methods on it. So we can call the size() method even on an empty list. If empty lists were represented by null, then we wouldn’t be able to do that, and as a consequence our code would be full of tests like:

if (lst != null) n = lst.size();

which clutter the code, obscure its meaning, and are easy to forget. Better the much simpler

n = lst.size();

which will always work, including when an empty lst refers to an Empty object.

Keep null values out of your data structures, and your life will be happier.

Now that we’re using interfaces and classes, it’s worth taking a moment to reinforce an important point about how Java’s type-checking works. In fact every statically-checked object-oriented language works this way.

There are two worlds in type checking: compile time before the program runs, and run time when the program is executing.

At compile time, every variable has a declared type, stated in its declaration. The compiler uses the declared types of variables (and method return values) to deduce declared types for every expression in the program.

At run time, every object has an actual type, imbued in it by the constructor that created the object. For example, new String() makes an object whose actual type is String. new Empty() makes an object whose actual type is Empty. new ImList() is forbidden by Java, because ImList is an interface — it has no object values of its own, and no constructors.

String hello = "Hello";

List<String> words1 = new ArrayList<>();
words1.add(hello);

ImList<String> words2 = ImList.empty();
words2.cons(hello);

String hello = "Hello";

List<String> words1 = new ArrayList<>();
words1.add(hello);

ImList<String> words2 = ImList.empty();
words2.cons(hello);

Another useful sort of recursive datatype in computer science is for Boolean formulas. For instance, here’s a formula of propositional logic:

(P ∨ Q) ∧ (¬P ∨ R)

which means “either P or Q is true, and either P is false or R is true.”

We can give a datatype definition suitable for representing all formulas of propositional logic.

Formula = Variable(name:String)
          + Not(formula:Formula)
          + And(left:Formula, right:Formula)
          + Or(left:Formula, right:Formula)

(P ∨ Q) ∧ (¬P ∨ R) would be

And( Or(Variable("P"), Variable("Q")),
     Or(Not(Variable("P")), Variable("R")) )

ImSet<E> = ImList<E>

A key operation for Boolean formulas is testing whether they are satisfiable, that is, whether some assignment of true/false values to the variables leads the formula to evaluate to true. There is a simple but slow algorithm for checking satisfiability:

1. Extract the set of variables from the formula.
   We’ve already implemented this with the variables operation.

2. Try all possible assignments of true/false values to those variables.
   We can represent an assignment with an Environment: a list of variables and their values. We could use ImList to implement the Environment, or develop an immutable map type.

3. Evaluate the formula for each environment.
   For this, we’ll define evaluate : Formula × Environment → boolean.

4. Return the first environment in which the formula evaluates to true.

Defining these pieces and putting them together into a satisfiable : Formula → boolean function is an exercise for another time.

Backtracking search with immutability

In addition to the big idea of recursive datatypes, we saw in this reading:

• datatype definitions: a powerful way to think about abstract types, particularly recursive ones
• functions over recursive datatypes: declared in the specification for the type, and implemented with one case per concrete variant
• immutable lists: a classic, canonical example of an immutable datatype

As always, we ask how these ideas make our code safer from bugs, easier to understand, and more ready for change. Look again at the definition and implementation of size() in ImList. The definition is little more than the mathematical definition of size. The code is little more than the definition, with some semicolons to placate the compiler.

If we examine the definitions for further methods — isEmpty, contains, etc. — in each case we see a safe, easy-to-read implementation waiting to be coded. Since we’ve taken the time to specify these operations, if we avoid rep exposure and maintain rep independence, we know our code is ready for change: different clients will be able to reuse our datatype, and we will be able to update the implementation without breaking them.