TEAM BLOG

Conditional Methods for the Ecstasy Language.

Designing xtclang: Ideas and realizations from our journey.

xtclang conditional methods null references type system

Authored by: Cameron Purdy

Last edited: @January 31, 2024

Conditional Methods

There's a common pattern in software libraries, which is the conditional result. For example, a language may have an iterator type, something that has a method that returns a type T:

T next();

Now, if there is no "next item" to return, the iterator could return some other “magic” value, like -1 or null. Unfortunately, some iterators will be iterating over data that includes a -1, or includes a null value, or both, so “magic” values turns out to be a fairly poor design choice in this instance.

Instead, the iterator type may have to represent the "no next item" as a separate method, which must be called separately; here’s a slightly simplified form of how Java defines an iterator:

interface Iterator<T> {
    boolean hasNext();
    T next();
}

A caller would then use that interface as follows:

while (iter.hasNext()) {
    T value = iter.next();
}

This could be simplified if a language supported more than one return value — just like most languages support more than one parameter to a method. For example, it might look something like this:

(boolean, T) next();

Null References: The Billion-Dollar Mistake

The problem is what to return as a value when the boolean value is false. You could return a null value, but the cost to doing this is one billion dollars (payable to Tony Hoare 🙂).

Ecstasy addresses this common challenge by using conditional return values, as part of a feature called conditional methods.

For example:

interface Iterator<Element> {
    /**
     * Get the next element.
     *
     * @return True iff an element is available
     * @return (conditional) an Element value
     */
    conditional Element next();
}

The next() method is allowed to return True and an element, or False if there is no element. Consuming a conditional method is incredibly simple. For example, here's a helper method on Iterator that “performs the specified action for all remaining elements in the iterator”:

conditional Element untilAny(function Boolean process(Element)) {
    while (Element value := next()) {
        if (process(value)) {
            return True, value;
        }
    }
    return False;
}

As you can see, the while statement uses the conditional method to stay in the loop as long as the conditional result evaluates to True (and the element!), and exits as soon as the conditional result evaluates to False. Similarly, the if, for, and do..while statements all work cleanly and simply with conditional methods.

But there's one other important reason why the next() method in Ecstasy can not return a null value, and that is because Ecstasy fixes “the billion-dollar mistake” by not having a “zero pointer” or “null reference” at all! Instead, Ecstasy represents the absence of an object using an actual object named Null:

/**
 * Nullable is an Enumeration whose only value is the singleton enum value Null.
 */
enum Nullable { Null }

That one line is the actual code that defines the concept of Null in Ecstasy. And here's what it means in practice:

Object   o = Null;    // ok, because Null is actually a real Object!
String   s = Null;    // compile-time error; Null is not a String
Int      i = Null;    // compile-time error; Null is not an Int
Object[] a = Null;    // compile-time error; Null is not an array

In other words, Null is an object just like "Hello world!" is an object, and all of the type rules apply to Null just like they apply to any other object. Among other benefits of this design, developers no longer have to worry about the risk of a NullPointerException or a segfault in their code.

It really is that simple.