Alonzo

Format-String All the Things!

Thu, 29 Oct 2015 00:00:00 -0700

I’ve picked up a practice recently: any time I need to provide a message (typically for errors or logging), I make sure the function in question takes varargs and then pass them to String.format. Most of the time I provide a message, I eventually want to use a format-string and it’s just lame to have to call String.format every time.

throw new UnexpectedIssueException(e, "Could not invoke test method \"%s\".", testName);

/tst/alonzo/unit/RunnableTest.java

Validate.notNull

Tue, 27 Oct 2015 00:00:00 -0700

I’ve added a utility class for Validating preconditions, heavily inspired by the Validate class found in Apache Commons.

/**
 * Throws {@link NullPointerException} if the given object is null, returning the given object
 * if it is not null. The thrown NullPointerException will contain a message created by passing
 * msg and args to {@link String#format(String, Object...)}.
 * @param obj The object to check against null.
 * @param msg The format string to use as the exception message if obj is null.
 * @param args The arguments to msg for use if obj is null.
 * @return obj if it is not null.
 * @throws NullPointerException if obj is null.
 */
public static <T> T notNull(final T obj, final String msg, final Object... args) {
    if (obj == null) {
        throw new NullPointerException(String.format(msg, args));
    }
    return obj;
}

/src/alonzo/common/Validate.java

Semantic correctness is an important part of software design for me. I use strong typing because it’s a cheap (cheaper than finding them at runtime) way of discovering and preventing bugs. In keeping with this ideology, I believe in failing fast. Discovering a bug or error during the running of a program as soon as it appears makes debugging easier (due to quicker root-causing). Ensuring that objects are constructed correctly or that objects to be used abide by expectations makes writing logic around them easier.

I use Validate to ensure that expected preconditions hold, or else fail immediately. Typically I will use Validate assertions to guarantee that an object is correct on construction, or else fail construction. This makes it harder to pass around broken objects, another aspect of failing fast. So far I’ve only needed to check for null. However, it is highly likely that I will be adding to this class in the future.

An Intuitive Formatter

Sat, 24 Oct 2015 00:00:00 -0700

This post is based on code found in 1f0b04e7192

One of the first things I do when I define the syntax for a new language is implement a formatter — code to produce a textual representation of expressions in the language. Humans are intensely visual, so having a way to look at the structures you are constructing in code is a great way of aiding understanding. Further, since this a programming language we’re creating, the ability to print expressions is necessary for the interpreter. If you haven’t read yesterday’s post and are unfamiliar with the lambda calculus, I recommend reading it before proceeding.

Formatting

The interface our formatter needs to implement is as follows: given an OutputStream, output a string representation of the given ASTNode.

/**
 * Format the given {@code ASTNode}, outputting to the given {@code OutputStream}. All character
 * data is formatted to {@code out} using the {@link Charset} this object was constructed with.
 * @param out  The {@code OutputStream} to format {@code root} to.
 * @param root The {@code ASTNode} to format.
 * @throws IOException if {@code out} had an issue being written to.
 */
public abstract void format(final OutputStream out, final ASTNode root) throws IOException;

/src/alonzo/ast/fmt/Formatter.java

Formatting Var

Remember that the definition of a variable (Var) is a sequence of characters, not including the punctuation used for other expression types:

<var> ::= [^()λ. ]+

The test for our formatter is likewise simple. When we have a variable containing a name, the string representation should just be the name. For now, ignore that we’re testing 2 different formatters here, this post only concerns the recursive formatter.

@Test
public void fmtVar() {
    final Var v = new Var("testVariableName");

    assertEquals("testVariableName", iterFmt.format(v));
    assertEquals("testVariableName", recFmt.format(v));
}

/tst/alonzo/ast/fmt/FormatterTest.java

Given the quite simple definition of Var, formatting it is a one-liner:

if (root instanceof Var) {
    out.write(bytes(((Var) root).name()));
}

/src/alonzo/ast/fmt/RecursiveFormatter.java

Formatting Fun

Formatting functions is a bit more tricky than formatting variables. Notice the recursive definition of a function as being an expression that contains another expression:

<function-definition> ::= '(λ' <var> '.' <expr> ')'

But first, the test. Straightforward, as usual:

@Test
public void fmtFun() {
    final Fun f = new Fun(new Var("var"), new Var("body"));

    assertEquals("(λvar.body)", iterFmt.format(f));
    assertEquals("(λvar.body)", recFmt.format(f));
}

/tst/alonzo/ast/fmt/FormatterTest.java

The recursive definition of Fun makes defining the formatter in a recursive manner a really natural and intuitive choice. So, to format a function, we output the punctuation of the function, then recursively call format on the substructures: the parameter and the body of the function:

private void formatFun(final OutputStream out, final Fun fun) throws IOException {
    out.write(bytes("(λ"));
    format(out, fun.parameter());
    out.write(bytes("."));
    format(out, fun.body());
    out.write(bytes(")"));
}

/src/alonzo/ast/fmt/RecursiveFormatter.java

Formatting App

Function application (App) is formatted in much the same way function was. Again, App is recursively defined as being composed of other expressions:

<function-application> ::= '(' <expr> ' ' <expr> ')'

The test for formatting App makes use of all the other ASTNodes, asking the formatter to format an application of the identity function to a free variable y.

@Test
public void fmtApp() {
    final App a = new App(new Fun(new Var("x"), new Var("x")), new Var("y"));

    assertEquals("((λx.x) y)", iterFmt.format(a));
    assertEquals("((λx.x) y)", recFmt.format(a));
}

/tst/alonzo/ast/fmt/FormatterTest.java

The implementation is very similar to Fun, outputting the relevant punctuation, then recursively calling format on the function and argument substructures.

private void formatApp(final OutputStream out, final App app) throws IOException {
    out.write(bytes("("));
    format(out, app.function());
    out.write(bytes(" "));
    format(out, app.argument());
    out.write(bytes(")"));
}

/src/alonzo/ast/fmt/RecursiveFormatter.java

Putting It All Together

With all the pieces of RecursiveFormatter together, we can format arbitrarily complicated lambda calculus expressions. I’ve added a “complicated” test to the suite showing that our formatter can format the Y-combinator:

@Test
public void fmtComplicated() {
    final Fun sub = new Fun(new Var("x"), new App(new Var("f"), new App(new Var("x"), new Var("x"))));
    final Fun ycombinator = new Fun(new Var("f"), new App(sub, sub));

    assertEquals("(λf.((λx.(f (x x))) (λx.(f (x x)))))", iterFmt.format(ycombinator));
    assertEquals("(λf.((λx.(f (x x))) (λx.(f (x x)))))", recFmt.format(ycombinator));
}

/tst/alonzo/ast/fmt/FormatterTest.java

Next time on Alonzo: they taught you not to use recursion in Java; what to do when your stack gets blown?
Stay tuned to find out.

Introduction to the Lambda Calculus

Fri, 23 Oct 2015 00:00:00 -0700

This post is based on code found in 989223b15bb

The Lambda Calculus (λ-calculus) is a theoretical programming language originally used as part of an investigation into the foundations of mathematics. Alonzo Church (the namesake of this project) later published a paper on just the computational part of the λ-calculus. Our project here is to implement a full-featured interpreter for this simple programming language.

Syntax

The λ-calculus has a very simple syntax, making it a great first programming language to implement. There are only 3 forms in the expression-based syntax:

<expr> ::= <var> | <function-definition> | <function-application>

<function-definition> ::= '(λ' <var> '.' <expr> ')'

<function-application> ::= '(' <expr> ' ' <expr> ')'

<var> ::= [^()λ. ]+

This basic BNF description of the syntax can be read as an expression is defined as the following 3 forms. First, an expression can be a <var>, which is defined as a series of characters not including any of '(', ')', 'λ', '.', or ' '. Second, an expression can be a <function-definition>, which consists of the characters '(λ', followed by a <var>, followed by the character '.', followed by an <expr>, followed by the character ')'. Lastly, an expression can be a <function-application>, which consists of the character '(', followed by an <expr>, followed by the character ' ', followed by an <expr>, followed by the character ')'.

This definition comprises the entirety of the syntax of the language. When we get to defining the parser for this language, we will very likely extend this definition to include whitespace between many of the syntax pieces, as extra whitespace enhances readability for humans. For now though, this definition will suffice for giving you a feeling for the different forms the language can take.

Variable Reference

A λ-calculus variable reference is similar in nature to the variable references you are used to in more mainstream programming languages. Like Java for instance:

int varName = 5;
System.out.println("Value = " + varName);

In the code example above, we see the assignment of the value 5 to the variable varName, and then a reference to the variable on the next line where varName is concatenated to the string "Value = ". Like the second line in the Java example, a variable reference syntax form indicates a reference to a variable that was defined “previously” in the λ-calculus program.

We represent a λ-calculus variable like so:

/**
 * Variable reference. An {@link ASTNode} representing a referenced variable.
 */
public class Var extends ASTNode {

    private final String name;

    public Var(final String name) {
        this.name = name;
    }

    public String name() {
        return name;
    }

}

/src/alonzo/ast/Var.java

Our Var has a container for the textual name of the variable, and a way of accessing that name. A key implementation detail here is that I’ve made Var an immutable object, in order to allow referencing the object anywhere (even appearing multiple times in the same tree).

Function Definition

The Lambda Calculus gets its name from the lambda (λ) symbol in the definition of a function. This is also where many mainstream functions get the name lambda for referring to an anonymous-function-as-a-value. Functions in the λ-calculus are a simplified version of the functions you are used to in other languages. These functions only have one parameter, with the body of the function being another expression. Simplicity is the reason for the season with the λ-calculus.

Multi-parameter functions can be simulated: int foo(int x, int y, int z) { return z; } becomes (λx.(λy.(λz.z))) in the λ-calculus. As can be seen in the example, λ-calculus functions are anonymous (not named), and a function of three parameters is instead a function of one parameter, returning a function of one parameter, returning a function of one parameter, returning the final result.

We represent a λ-calculus function as an immutable container for the Var parameter, and the ASTNode body:

/**
 * Function definition. An {@link ASTNode} representing the definition of a function with one
 * parameter.
 */
public class Fun extends ASTNode {

    private final Var parameter;
    private final ASTNode body;

    public Fun(final Var parameter, final ASTNode body) {
        this.parameter = parameter;
        this.body = body;
    }

    public Var parameter() {
        return parameter;
    }

    public ASTNode body() {
        return body;
    }
}

/src/alonzo/ast/Fun.java

Function Application

Function application is the third form a λ-calculus expression can take. It represents the application of a function to one argument. In Java this looks like someFunction(someArgument). In the λ-calculus it looks like (someFunction someArgument). For the sake of removing ambiguity, the application is parenthesized, as “expr1 expr2 expr3” could mean expr3 is the argument to expr2 and the result is the argument to expr1.

We represent a λ-calculus function application as an immutable container for the ASTNode function, and the ASTNode argument:

/**
 * Function application. An {@link ASTNode} representing the application of a function to one
 * argument.
 */
public class App extends ASTNode {

    private final ASTNode function;
    private final ASTNode argument;

    public App(final ASTNode function, final ASTNode argument) {
        this.function = function;
        this.argument = argument;
    }

    public ASTNode function() {
        return function;
    }

    public ASTNode argument() {
        return argument;
    }

}

/src/alonzo/ast/App.java

The reason both the left and right sides of the application are ASTNodes is that, due to the semantics of the language, the left side may only become a function through runtime interpretation of the program.

Semantics

Computation in the λ-calculus is achieved through variable substitution and structural interpretation of the resulting functions. What I mean here is that computation is performed by substituting expressions for variables where possible until there are no more substitutions possible, and then inspecting the resulting expression structure to get an “answer”. We’ll talk more about the semantics of the language once it’s time to implement evaluation. For now, here’s an example program and the result of evaluating it:

((λn.(λf.(λx.(n ((n f) x))))) (λf.(λx.x)))

evaluates to:

(λf.(λx.(f x)))

Here, we see the “successor” function (λn.(λf.(λx.(n ((n f) x))))) given the argument (λf.(λx.x)), the number 0. The result (λf.(λx.(f x))) is the number 1. Don’t stress out too much on how these particular representations of +1 and 0 were picked, just learn from this as a real-world example of a small λ-calculus program. We will cover these representations and evaluation strategies later. Suffice it to say that we take the 0 function and substitute it in the +1 function everywhere the parameter n is, and continue substituting until we get 1.

To be continued…

Ignoring Tests

Sun, 26 Jul 2015 00:00:00 -0700

This post is based on code found in fd9028f3c38

In the course of making a formatter for our lambda calculus terms, I stumbled on a situation where the ability to ignore a test was needed. Let’s see how to add “ignored” tests to our testing framework.

Similar to JUnit, I’ve added an @Ignore annotation for marking tests as ignored. Next, we need to a new kind of TestResult:

/**
 * Objects representing an ignored test result for given tests.
 */
public static class Ignored extends TestResult {
    private Ignored(final String testName) {
        super(testName);
    }
}

/tst/alonzo/unit/TestResult.java

RunnableTest needs to be changed in order to understand ignored tests. When making the change, I chose to not construct the test class instance or run the test method, opting for an early return with no work done. Further, as this addition made RunnableTest.get() too large for my taste, I refactored construction of the test class instance into a method.

if (isIgnoredTest()) {
    return TestResult.ignore(testName);
}

final Object instance = constructTestInstance();

/tst/alonzo/unit/RunnableTest.java

private boolean isIgnoredTest() {
    return method.getAnnotation(Ignore.class) != null;
}

/tst/alonzo/unit/RunnableTest.java

Finally, at the top level of TestRunner, all that’s needed is a simple collection of ignored test results and the addition of an ignored section in the overall result output.

final List<TestResult> ignored = results.stream()
    .filter(r -> r.isIgnored()).collect(Collectors.toList());

/tst/alonzo/unit/TestRunner.java

A good test of any software system is how easy it is to adjust the system incrementally. I’m pleased with how easy it was to adjust our testing framework in this way.

Unit Testing Framework Foundations

Sun, 19 Jul 2015 00:00:00 -0700

This post is based on code found in add2fe75a05

Testing

I’m a big fan of automated testing, for many reasons. It provides the easiest and most reliable way to see if your code is working, aside from strong static typing. Further, in my experience, driving interface design from the perspective of making it easy to test tends to make for good interfaces.

In order to test our interpreter, it will be helpful to have a testing framework which will automate the process of running tests, and collecting and presenting test results. This isn’t strictly necessary, as we could just ad-hoc design our tests, with a println indicating success here and a resultCode indicating failure there. I think we’ll have more confidence in our results if they’re all delivered the same way, through the same testing mechanisms.

Now if you’ve ever designed a testing framework, you’ll have quickly realized that like every other piece of software, having automated tests to ensure your testing framework still works is important. But we’ve got a bit of a quandary. Testing your testing framework seems valuable, but also like we’re getting into a “turtles all the way down” situation. At some point, you have to trust that the code you’re writing is correct. In our case, I started with a dumb test to be driven by the framework, essentially testing correctness of the testing framework manually.

The first test:

public class FooTest {

    @Test
    public void firstTest() {
        assertEquals(0, new Foo().bar());
    }
}

/tst/alonzo/FooTest.java

The call to the test runner:

public static void main(String[] args) {
    new TestRunner()
        .withTest(FooTest.class)
        .run();
}

/tst/alonzo/TestingMain.java

I started with these two classes before writing any of the testing framework code. In general, I believe in the value of test-driven development. Without going too much into TDD and its positives and negatives, here’s a benefit I’ve found from practicing TDD. Driving the code from a test usually results in a better, more usable interface. So, in this instance, I wrote the test the way I wanted to write a test, and wrote the code to run the test in a way that seemed easy to run tests. Honestly, this top-down thinking is one of the hardest things for new developers to really grok and practice. It is key in choosing your abstractions well and in writing interfaces that you actually would want to use.

So far, the architecture of the testing framework is relatively simple. The TestRunner collects tests, then runs them, collecting the TestResults, and finally displaying those results. In order to run the tests, the TestRunner makes use of the RunnableTest class, which does all the heavy lifting. It searches the class for any methods labeled with the @Test annotation, and the constructor. RunnableTest implements the Supplier<TestResult> interface, by running the wrapped test and constructing a result. RunnableTest works in concert with the static methods in Assert which throw AssertionFailureException to indicate a test failure.

Now we have a testing framework with which to test the code we write for the interpreter.

Welcome & Introduction

Sun, 12 Jul 2015 00:00:00 -0700

Welcome

On this blog you will find posts that discuss the project. I will be detailing the design choices, highlighting interesting code, and generally helping anyone interested in the Lambda Calculus understand the language and how to write an interpreter for it.

We’ll be starting from scratch with this project. Partly to satisfy anyone’s curiosity about all of the pieces, and partly because I detest the Java package managers I’ve run across. So, all bets are off — if we need it, we’ll build it.

Here are the things I’m taking for granted:

Program Dependencies

Make

I am using the old-as-the-hills Make for coordinating the building, testing, and cleaning of the project. Yes, I agree, there are better build tools out there. However, I think Make wins for simplicity and ubiquity. Not using a Java package manager means that all code will be in source rather than compiled format, so linking dependencies together can be left to javac.

Java 8

I am using the newest version of Java and the JDK because I want to get more familiar with the new semantics and libraries in Java 8 (yay first-class functions!). My other motivation for using Java is to show what it looks like to implement a functional language (the Lambda Calculus) in an imperative language. Often you’ll see folks implement a toy functional language in another functional language. Some people find this to be cheating in a way, as certain functional languages (OCaml, Haskell) seem better suited to constructing compilers and interpreters.