2.1 An intrinsically typed interpreter

A well typed interpreter needs a language of types. For the sake of simplicity, we will consider a simple universe with natural numbers, booleans, and functions:

Any element of this universe can be mapped to its corresponding Agda type. We will sometimes refer to this as the denotation or interpretation of our (object) types:

With our types in place, we can now define the expression language that is the object of our study.

Our expressions consist of (natural number) values, additions, conditional statements, and application. We could add numerous other operations – such as Boolean constants, comparisons, other arithmetic operations, and so forth – none of which would require any novel insight when performing the upcoming calculations. We have chosen to keep the language small, yet capturing several different language constructs. In contrast to other compiler calculations (Bahr & Hutton, Reference Bahr and Hutton2015), we have chosen to include different types, including functions and a polymorphic language construct. Note that, although we have a single node for applications – rather than make each operator store its recursive arguments – this is not an essential design choice, but allows for parts of the calculation to be reused when considering the lambda calculus. The source language is chosen to exhibit various programming language features, rather than be particularly expressive. There is, for example, no way to write a boolean valued expression with only this choice of constructors.

We can reap the rewards of our well typed syntax when defining an interpreter. The type of our ${eval}$ function maps expressions to their corresponding values:

The tagless interpreter relies on the static type structure: each operator of the expression language is mapped to its Agda counterpart; the ${app}$ constructor is mapped to Agda’s application. The types structure imposed on our expression language ensures this definition type checks.

2.2 Stack-based interpreters

With this interpreter in place, we can now start working towards our calculation. The stack machine that we will calculate will use the same types – but we will assign them a different meaning. We aim to derive a stack-based evaluator where a function’s arguments are stored on a stack. To type such stacks, we extend the meaning of our types to work over lists of types, storing an element of the corresponding type:

Now we can define an alternative meaning for our types, mapping types to stack-based functions. Each such stack-based function expects its arguments pushed on the top of the stack, replacing them with the result of the function call:

This definition uses two auxiliary functions, ${args}$ and ${result}$ , that compute the shape of the argument stack and resulting stack, respectively:

At this point, an example is in order. Previously, we interpreted our object type ${nat}$ as Agda’s natural numbers, ${{\mathbb{N}}}$ . With the stack-based interpretation of types, however, this becomes a function from stacks to stacks:

Rather than return a natural number directly, we now expect an input stack and produce an output stack with a natural number on it. More generally, a function type ${a}\;{{\Rightarrow}}\;{b}$ becomes stack transformer, taking the arguments ${a}$ on the top of the input stack, producing an output stack storing a value of type ${b}$ on its top. In contrast to most stack-based semantics, the values stored on the stack will be functions themselves, rather than a natural number. We will revisit the higher-order nature of the values stored on the stack in the discussion towards the end of this paper.

Equivalence of type denotations

The two denotations we have defined for our types are equivalent. We can define the conversion in either direction by induction on the type structure:

At base types, ${{nat}}$ and ${{bool}}$ , the conversions are straightforward. The conversion to stack-based types pushes the argument value on the top of the stack. In the opposite direction, the stack-based semantics is run on an empty stack, ${{tt}}$ , before projecting out the desired value from the top of resulting stack. The case for function types is more involved. Let us look at both cases in more detail:

• • The ${{{\alpha}}}$ function converts a function in direct style to its stack-based equivalent. If we ignore the conversions ${{{\alpha}}}$ and ${{{\gamma}}}$ on the right-hand side of the definition, we see that top of the stack ${{x}}$ , is fed into ${{f}}$ , before recursing and feeding any remaining stack arguments into the result.

• • Conversely, the ${{{\gamma}}}$ function converts a stack-based function to one in direct style. Once again, we begin by ignoring the conversions ${{{\alpha}}}$ and ${{{\gamma}}}$ that occur in the function definition. The lambda bound argument ${{x}}$ is pushed on to the stack ${{{\xi}}}$ ; the resulting stack is then passed to the function ${{f}}$ . The two conversions ensure that the top of the stack stores a values of type ${{{[\![}}\;{a}\;]\!]_\mathsf{s}}$ and the lambda’s body returns a value of type ${{{[\![}}\;{b}\;{{]\!]}}}$ as required.

These functions combine two ideas that can be found in the literature. The names are borrowed from Meijer (Reference Meijer1992), who refers to these functions as the abstraction and concretization functions respectively. In his thesis, he shows how these functions form a generalized form of ${{curry}}$ and ${{uncurry}}$ , recursively rearranging a function’s arguments in the appropriate fashion. The ${{curry}}$ and ${{uncurry}}$ functions typically have the following type:

The ${{{\alpha}}}$ and ${{{\gamma}}}$ functions defined above, however, are recursive: any (additional) arguments are recursively (un)curried. Although the function types we have encountered so far (arising from addition and conditionals in our source language) are first order, this will no longer be the case once we add lambda abstractions.

The types of the ${{{\alpha}}}$ and ${{{\gamma}}}$ functions from Meijer’s thesis have been generalized, inspired by recent work on categorical compiler calculation by Elliott (Reference Elliott2020). Where Meijer’s original definition did not account for (arbitrary) stacks, Elliott states that ‘the essence of stack computation’ is captured by the following type:

${{a}\;{{\rightarrow}}\;{b}\;\;\;{{\cong}}\;\;\;{{\forall}}\;{{\sigma}}\;{{\rightarrow}}\;({a}\;{{\times}}\;{{\sigma}})\;{{\rightarrow}}\;({b}\;{{\times}}\;{{\sigma}})}$

By repeatedly uncurrying and accounting for the ambient stack, we arrive at the definition of ${{{\alpha}}}$ and ${{{\gamma}}}$ above.

Finally, we assert that these two functions are mutual inverses:

Proving these equalities directly in Agda, however, is not possible. In particular, they rely on both function extensionality and parametricity, both of which are admissible but not provable in Agda. We can complete this proof, provided we add these as postulates. In what follows, we will leave the arguments to both ${{{\alpha}}}$ and ${{{\gamma}}}$ implicit, as these are (usually) inferred by Agda automatically.

2.3 Calculating a stack-based interpreter

The problem of finding a stack-based interpreter for evaluating our language boils down to finding a function mapping expressions to their ‘stack machine’ semantics. That is, we would like to uncover a function with the following type:

Of course, not any such function will do. In particular, it should satisfy the following property:

This specification suffices to determine the definition of our next interpreter. The calculation proceeds by induction on the expression, unfolding the definitions of ${{eval}}$ and ${{{\alpha}}}$ . We will present each case individually; the derivations we provide have been checked by Agda – but we have replaced the proofs terms by comments explaining each step. In the final step of each calculation, we can read off the definition of the ${{stack-eval}}$ function for that particular case.

Constant values

The case for values is entirely straightforward:

Unsurprisingly, the stack-based evaluation of a value simply pushes the value on top of the stack. After each of our calculations, we define a separate function handling that constructor – which we will reuse later when calculating the corresponding compiler. In this case, the calculation above gives rise to the following function that pushes its argument on to the input stack:

Addition

The case for addition is not much harder.

One advantage of defining addition as a leaf in the abstract tree of our expression language, rather than a node with two sub-expressions, is that the calculation of addition does not require induction, but follows trivially: we only need to unfold the definitions of ${{eval}}$ and ${{{\alpha}}}$ . The corresponding operation for our stack-based interpreter adds the numbers on the top of the stack:

Conditionals

The case for conditional statements is a bit more complicated. Here Agda sometimes struggles to instantiate the (implicitly quantified) type of the two conditional branches. Furthermore, the calculation uses two lemmas to apply a function and pass an argument to both branches.

From the last line, we can read off the conditional operation for our target interpreter:

Application

The case for applications is arguably the most interesting: it is here that we need to use our induction hypotheses.

The derivation proceeds by unfolding the definition of ${{eval}}$ . There is one creative step: to apply our induction hypothesis, we introduce a (spurious) function application of ${{{\gamma}}\;{{\circ}}\;{{\alpha}}}$ on the second argument of the application constructor. The remainder of the calculation then proceeds immediately. Generalizing the last line of our calculation, we read off the following application operation for stack-based computations:

This exemplifies stack-based computations, where function application amounts to pushing an argument on to a stack, before executing the function itself.

Collecting all the definitions above yields the following stack-based evaluator:

This is a slight variation of the stack machine given by McKinna & Wright (Reference McKinna and Wright2006). There are several minor differences: their machine also uses a no-op operation; the conditional operation presented here is not recursive – but rather the ${{app}}$ constructor is the only way to assemble larger expressions.

2.4 Transforming to continuation passing style

Although we have calculated a stack-based interpreter, we have not yet derived a compiler. To do so requires two further steps. First, we calculate a new version of our interpreter, written in continuation passing style, thereby fixing the order of evaluation of application nodes. In the next section, we will derive our compiler from this version. These two steps will produce a linear sequence of instructions for a stack machine, in contrast to the stack-based evaluator from the previous section.

The type of the CPS-transformed version of our stack-based interpreter should take an extra continuation as its argument:

Once again, not all such functions will do. In particular, the next version of our interpreter should satisfy the following specification:

The calculation itself of this interpreter is largely mechanical. We illustrate the calculation using two illustrative cases: constants and applications. In the case for constants, the ‘calculation’ merely unfolds the definition of ${{stack-eval}}$ :

Just as we saw previously, it will be useful to introduce a separate auxiliary function for each case of the CPS-transformed stack-based interpreter. In the case for constants, this function applies the continuation to the corresponding stack operator:

Similar immediate calculations for addition and conditionals immediately give rise to two other functions for our next interpreter:

The more interesting case is that for applications. After unfolding the definition of ${{stack-eval}}$ , it is not immediately obvious how to apply our induction hypotheses. By introducing an additional step swapping the arguments of ${{apply}}$ , we lift out the ${{stack-eval}\;{e{_1}}}$ , bringing the expression into the desired form.

The rest of the calculation follows directly. We read off the required auxiliary function from the last step:

In this calculation, we fix the evaluation order. Here we have opted to first evaluate ${{e{_1}}}$ and then evaluate ${{e{_2}}}$ ; alternatively, we could have chosen the reverse order, first applying the induction hypothesis for ${{e{_2}}}$ before using that for ${{e{_1}}}$ , changing the order in which the arguments to ${{app}}$ are evaluated. The observation that CPS-transforming fixes the evaluation order dates back to Reynolds (Reference Reynolds1972).

To complete the definition of our stack-based evaluator in continuation passing style, we collect all the derived functions in a single definition.

We can recover our original stack-based evaluator by passing the identity function as the initial continuation.

The next two subsections describe different further transformations on our stack-based interpreter in continuation passing style. In the next section, we will derive a compiler, essentially introducing an intermediate data structure representing the code for the ${{stack-cps}}$ evaluator. The final section defunctionalizes this evaluator, producing a tail-recursive abstract machine (Reynolds, Reference Reynolds1972; Ager et al., Reference Ager, Biernacki, Danvy and Midtgaard2003; McBride, Reference McBride2008).

2.5 Calculating a compiler

To recover the compiler proposed by McKinna and Wright, we create an intermediate datatype for our instruction set. This reifies the instructions for the evaluator presented in the previous section as a separate datatype. The resulting transformation is a form of ‘reforestation’, inverse to deforestation (Wadler, Reference Wadler1988), that introduces an intermediate datatype between the syntax and stack machine semantics. In this final step, we introduce a data type for our instruction set:

The constructors of this data type are read off from our previous evaluator; we will calculate a new function that executes these instructions:

The definition of ${{exec}}$ will be calculated from the following specification:

Here the code ${{c}}$ plays the role of the continuation that we saw previously. Intuitively, this property states that executing compiled code should produce the same result as evaluating an expression directly using our stack-based evaluator.

The ${{Code}}$ data type has one constructor for each of the functions passed to the ${{stack-cps}}$ evaluator from the previous section:

The type of each constructor is determined by the corresponding branch in the ${{machine-cps}}$ function. Compare, for example, the type of ${{push-c}}$ function with the corresponding ${{PUSH}}$ constructor:

The continuation argument has become the remaining code to execute. A more complicated example is that for applications, giving rise to the ${{APP}}$ constructor:

Once again, the continuation argument determines the type of the remaining code; any additional arguments, such as the values of type ${{a}}$ and ${{a}\;{{\Rightarrow}}\;{b}}$ , will now be found on the stack rather than passed explicitly. Finally, the ${{HALT}}$ instruction corresponds to the identity function used as the initial continuation to kick off ${{stack-cps}}$ .

The compilation itself simply maps each language construct to the corresponding stack machine operation, using an additional ${{Code}}$ argument rather than the continuation. The only interesting case is that for applications, where the codes of both sub-expressions are compiled one after the other.

Once again, the top-level compiler starts with an initially empty code continuation:

To prove that our compiler is correct, we calculate the execution semantics of our code. There is little creativity involved at this point: each target instruction should call the corresponding operation that we have derived previously. The desired type of the corresponding ${{exec}}$ maps code to stack-machine operations:

The specification given at the beginning of this section is more general than necessary. Rather than reason about the top-level ${{compile}}$ function directly, we formulate a more general property in terms of ${{compile-acc}}$ . All that remains is to calculate the ${{exec}}$ function that satisfies this specification. To illustrate the calculation, we cover the two cases for constants and application.

The case for constants follows immediately after expanding definitions:

Note that we expand definitions on both sides of the equation: unfolding the definition ${{stack-eval}}$ on the right and and ${{compile-acc}}$ on the left.

The case for applications is not much harder. After unfolding definitions and applying our induction hypotheses, the desired definition reveals itself immediately:

Assembling these calculations into a single definition shows how executing code maps every constructor to the operation derived for our stack machine:

Finally, instantiating the code argument to ${{HALT}}$ , lets us formulate our main correctness result, relating compiled code to the original direct evaluator from Section 2.1:

This concludes the derivation of the correct compiler in several steps. Starting from an intrinsically typed interpreter, via a direct stack-based interpreter and one in continuation passing style, to our final compiler.

Higher-order stacks

One drawback of this construction is that the stacks store higher-order values – as opposed to the first-order stacks that appear in typical compiler calculations. The reason for this is twofold. First, the expression language may contain partial applications (of additions or conditionals). These partial applications must be stored on the stack during evaluation; as a result, the stack contains functional values. Second, the arguments of a function in our ‘stack semantics’ are themselves – recall the following clause of our stack semantics:

To restrict ourselves to first-order data on the stack, we would need to replace ${{{[\![}}\;{a}\;]\!]_\mathsf{s}}$ in this definition with a (first-order) representation of the argument type. In the expression language, we have seen so far, partial applications may be defunctionalized to their first-order representation; in the lambda calculus presented in the next section, we would need to represent such higher-order arguments by the corresponding closure. As different languages require different first-order data representations, we have used the definition above – at the expense of having a machine that stores higher-order values on the stack.

Calculating compilers

This section has derived the semantics of the virtual machine, namely the ${{exec}}$ function, rather than the compiler we set out to calculate. Arguably, the compiler is the least interesting part of our calculation: the target language’s constructors and their types are determined by functions calculated in the previous section. The compiler itself merely maps each language construct to its corresponding target operation. To also calculate the compiler, we need to specify its intended behaviour. To do so, we begin by defining the function that maps a series of instructions to their corresponding semantics, that is, the composition of the corresponding CPS-transformed function from the previous section:

We now specify the intended behaviour of the compiler in terms of the stack-based CPS-transformed evaluator derived in the previous section:

In particular, combining the specifications from all the previous sections establishes the familiar correctness statement:

2.6 A tail recursive machine

The previous section demonstrated how to derive a compiler from the stack-based interpreter in continuation passing style. This introduced a separate data type for code, where each constructor is a placeholders for a stack machine operation. In this section, we demonstrate how defunctionalizing the continuations leads to a tail recursive abstract machine – a transformation that has been explored extensively in the literature (Reynolds, Reference Reynolds1972; Ager et al., Reference Ager, Biernacki, Danvy and Midtgaard2003; McBride, Reference McBride2008), albeit rarely in the intrinsically typed setting. Even though we have already derived our correct compiler, this establishes the connection with similar techniques commonly found in the literature. This section serves to highlight the differences between the calculation of compiler and abstract machines.

Defunctionalizing the intrinsically typed stack-based evaluator in continuation passing style, defined in Section 2.4, is a bit of a puzzle. Even if similar derivations have been done before in the simply typed setting, ensuring the type indices line up nicely in this development requires some thought. To derive our final, tail recursive machine requires three definitions:

The datatype K represents our defunctionalized continuations; the function ${{continue}}$ applies such a defunctionalized continuation to an argument value; finally, the ${{exec-cps}}$ function corresponds to our tail recursive abstract machine. Once these types are in place, the definition of the remaining ingredients follows readily enough.

The CPS-transformed machine uses three continuations: the identity function and one for each argument of an application. Correspondingly, the datatype representing the defunctionalized continuations has three constructors:

The names of the constructors are inspired by existing work on deriving abstract machines by Ager et al. (Reference Ager, Biernacki, Danvy and Midtgaard2003). The ${{ARG}}$ constructor stores an (unevaluated) function argument; the ${{FUN}}$ constructor applies a function to the top of the stack. Last but not least, the ${{STOP}}$ constructor corresponds to the identity function, used as the initial continuation.

To assign meaning to these defunctionalized continuations, we define the ${{continue}}$ function – mapping each value in ${{K}}$ to the appropriate function:

Each of these cases corresponds to one of the continuations used previously. The ${{STOP}}$ constructor halts the recursion and returns the value that has been computed. The ${{ARG}}$ constructor evaluates the second argument of an application, once the first has been fully evaluated. The ${{FUN}}$ constructor applies the functional value stored to the value on the top of the stack.

To complete the definition of our abstract machine, we define a tail-recursive function that uses our ${{K}}$ data type, rather than the continuations used previously.

In the base cases, we reuse the instructions from the stack-based evaluator that we calculated previously and call the ${{continue}}$ function to apply the continuation. In the case for applications, we store the second expression in our defunctionalized continuation and continue evaluating the first argument. The top-level abstract machine executes an expression, starting with an empty continuation.

Unfortunately, these definitions do not pass Agda’s termination check. The problematic call is the ${{ARG}}$ branch of the ${{continue}}$ function: here we recurse over the expression ${{e}}$ with a larger defunctionalized continuation. Although this expression ${{e}}$ was originally a structurally smaller sub-expression, arising from the last clause of the ${{exec-cps}}$ function, Agda’s termination checker is unable to see that the recursion will terminate. Using a suitable well-founded relation, we could prove termination (Tomé Cortiñas & Swierstra, Reference Tomé Cortiñas and Swierstra2018), but we will refrain from doing so here.

Under the assumption that these functions terminate, we can prove following correctness result, relating the stack machine we calculated with its CPS-transformed and defunctionalized tail recursive variant:

The proof follows immediately by induction on the argument expression. Fixing the definitions of ${{K}}$ and ${{continue}}$ , we should be able to calculate the definition of ${{exec-cps}}$ , just as we calculated the execution of code in the previous section.