2.1 Continuation style TRMc

Our new tail-recursive version of map may not consume any extra stack space, but it achieves this at the cost of allocating many intermediate closures in the heap, that each allocate a node for the final result list. The TRMc translation is based on the insight that for many contexts around a tail-recursive call, we can often use more efficient implementations than function composition. In this paper, we are going to abstract over particular constructor contexts and instead represent abstract program contexts as with three operations. First, the expression creates such contexts which can contain a single hole denoted as for example, We can see here that the context type is parameterized by the type of the hole , which for our purposes must match the result type as well. Furthermore, we can compose and apply these abstract contexts as:

Our general TRMC translation can convert a function like map automatically to a tail-recursive version by recognizing that each recursive invocation to map is under a constant constructor context (Section 6), leading to:

This is essentially equivalent to our manually translated CPS-style map function where we replaced function application and composition with context application and context composition, and the identity function with

Thus, an obvious way to give semantics to our abstract contexts is to represent them as functions , where a context expression is interpreted as a function with a single parameter for the hole, for example, (and therefore ). Context application and composition then map directly onto function application and composition:

Of course, using such semantics is equivalent to our original manual implementation and does not improve efficiency.

2.2 Linear continuation style

The insight of Risch (Reference Risch1973) and Friedman & Wise (Reference Friedman and Wise1975) that leads to increased efficiency is to observe that the transformation always uses the abstract context ${\textit{k}}$ in a linear way, and we can implement the composition and application by updating the context holes in-place. Following the implementation strategy of Minamide (Reference Minamide1998) for their hole-calculus, we can represent our abstract contexts as a Minamide tuple with a res field pointing to the final result object, and a hole field which points directly at the field containing the hole inside the result object. Assuming an assignment primitive , we can then implement composition and application efficiently as:

where the empty is represented as (since we do not yet have an address for the hole field). If we inline these definitions in the mapk function, we can see that we end up with a very efficient implementation where each new cell is directly appended to the partially build final result list. In our actual implementation, we optimize a bit more by defining the type as a value type with only the constructor where we represent the case with a hole field containing a null pointer. Such a tuple is passed at runtime in two registers and leads to efficient code where the in the app function, for example, just zero-compares a register (see Section 7.3). Section 9 shows detailed performance figures that show that the TRMc transformation always outperforms alternative implementations (for linear control flow).

2.3 First-class constructor contexts

The constructor context can be implemented using in-place updates since the TRMC conversion guarantees it is used linearly. However, it turns out this also makes the conversion invalid if the host language has advanced control primitives like or general algebraic effect handlers (as in Koka). For example, for the map function, the passed in function f might resume multiple times. We describe this issue in detail in Section 7.1. As we show in this paper, we can compile constructor contexts in such a way that we are able to detect if a context is used nonlinearly and, in such case, fall back to copying the context path at runtime to maintain correct semantics (Section 7.2). This still gives us the in-place update efficiency in the usual case but now also handles nonlinear usage.

Furthermore, this fully encapsulates the imperative implementation of constructor contexts behind a purely functional interface, and we can expose these contexts as first-class values in the language. This allows us to write the result of the TRMc transformation manually. In Koka, first-class constructor contexts are written as a expression with a single hole denoted by an underscore _(Lorenzen et al., Reference Lorenzen, Leijen, Swierstra and Lindley2024). For example, we can write a list constructor context as or a binary tree constructor context as . The composition operation is written as , while application is written as . For example, the expression evaluates to and then to . Using these context expressions, we can directly implement the TRMC transformed map function in Koka:

These constructor context are quite efficient (see Lorenzen et al., Reference Lorenzen, Leijen, Swierstra and Lindley2024 and Section 7.3), and the Koka compiler implements the automatic TRMc conversion as a source-to-source transformation using the first-class constructor contexts directly. We give further examples of the programming with first-class constructor contexts in Section 8.

3.1 Abstract contexts

Before we start calculating our general TRMC transformation, we first define abstract contexts as an abstract type ${\textit{ctx}~\tau{}}$ in our calculus. There are three context operations: creation (as ${\mathsf{ctx}}$ ), application (as ${\mathsf{app}}$ ), and composition (as ${({\bullet})}$ ). These are not available to the user but instead are only generated as the target calculus of our TRMC translation. We extend the calculus as follows:

where we assume that the abstract context operations are always terminating. In order to reason about contexts as an abstract type, we assume two context laws. The first one relates the application with the construction of a context:

The second law states that composition of contexts is equivalent to a composition of applications:

When we instantiate to a particular implementation context, we need to show the context laws are satisfied. In such case, we only need to show this for terminating expressions ${\textit{e}}$ , since if ${\textit{e}~\!\!\Uparrow{}}$ , the laws hold by definition. In particular, for ${(\textit{appctx})}$ it follows directly that ${\mathsf{app}~\textit{k}~\textit{e}~\!\!\Uparrow{}}$ and ${\mathsf{E}[\textit{e}]~\!\!\Uparrow{}}$ . Of particular note is that the latter only holds for ${\mathsf{E}}$ contexts since they guarantee that the hole is first in the evaluation order and that is one reason why evaluation contexts are the maximum context possible for our TRMC translation. Similarly, for ${(\textit{appcomp})}$ it follows directly that ${(\textit{app}~(\textit{k}_{1}~{\bullet}~\textit{k}_{2})~\textit{e})~\!\!\Uparrow{}}$ and ${\mathsf{app}~\textit{k}_{1}~(\mathsf{app}~\textit{k}_{2}~\textit{e})~\!\!\Uparrow{}}$ .

3.2 Calculating a general tail-recursion-modulo-contexts algorithm

In this section, we are going to calculate a general TRMC translation algorithm from its specification. The algorithm is calculated assuming an abstract context where the context laws hold. Eventually, the algorithm needs to be instantiated in the compiler to particular contexts (like constructor contexts), with a particular implementation of context application and composition. We show many such instantiations in Sections 4 and 6.

For clarity, we use single parameter functions for proofs and derivations (but of course the results extend straightforwardly to multiple parameter functions). Now consider a function ${\textit{f}~\textit{x}~=~\textit{e}_\textit{f}}$ with its TRMC transformed version denoted as ${\textit{f}'}$ :

\begin{align*}\textit{f}'~\textit{x}~\textit{k}~=~{[\![}\textit{e}_\textit{f}{]\!]}_{\textit{f},\textit{k}}~\quad (\textit{k}{\!\not\strut\!\!\in} \mathsf{fv}(\textit{e}_\textit{f}))\end{align*}

Our goal is to calculate the static TRMC transformation algorithm ${{[\![}\_{]\!]}_{\textit{f},\textit{k}}}$ from its specification, where ${\textit{f}}$ is the function we intend to transform and ${\textit{k}}$ is a fresh variable representing the context. The first question is then how we should even specify the intended behavior of such function?

We can follow the standard approach for reasoning about continuation passing style (CPS) here. For example, Gibbons (Reference Gibbons2022) calculates the CPS version of the factorial function, called ${\textit{fact}'}$ , from its specification as: ${\textit{k}~(\textit{fact}~\textit{n})~\cong{}~\textit{fact}'~\textit{n}~\textit{k}}$ , and similarly, Hutton (Reference Hutton2021) calculates the CPS version of an evaluator from its specification as: ${\mathsf{exec}~\textit{k}~(\textit{eval}~\textit{e})~\cong{}~\textit{eval}'~\textit{e}~\textit{k}}$ . Following that approach, we use ${\;\mathsf{app}~\textit{k}~(\textit{f}~\textit{e})~\cong{}~\textit{f}'~\textit{e}~\textit{k}\;}$ (a) as our initial specification. This seems a good start since it implies:

and we can thus replace any applications of ${\textit{f}~\textit{e}}$ in the program with applications to the TRMC translated ${\textit{f}'}$ instead as ${\textit{f}'~\textit{e}~(\mathsf{ctx}~\square{})}$ .

Unfortunately, the specification is not yet specific enough to calculate with as it does not include the translation function ${{[\![}\_{]\!]}_{\textit{f},\textit{k}}}$ itself which limits what we can derive. Can we change this? Let’s start by deriving how we can satisfy our initial specification (a):

This suggests a more general specification as ${\;\mathsf{app}~\textit{k}~\textit{e}~\cong{}~{[\![}\textit{e}{]\!]}_{\textit{f},\textit{k}}\;}$ (b) (for any ${\textit{e}}$ ) which both implies our original specification but also includes the translation function now. The improved specification directly gives us a trivial solution for the translation as:

That is not quite what we need for general TRMC though since this does not translate any tail calls modulo a context in ${\textit{e}}$ at all. However, we can be more specific by matching on the shape of ${\textit{e}}$ . In particular, we can match on general tail-modulo-context calls in the expression ${\textit{e}}$ if it has the shape ${\mathsf{E}[\textit{f}~\textit{e}_{1}]}$ . We can then calculateFootnote ¹ :

Effectively, we replace all direct tail-recursive calls in the original function ${\textit{f}}$ to tail-recursive calls in our translated function ${\textit{f}'}$ by just extending the continuation parameter ${\textit{k}}$ . Together with our earlier equation, we now have an initial specification of our transation function:

Note that the equations overlap – for a particular instance of the algorithm we generally constrain the ${(\textit{tail})}$ rule to only apply for certain contexts ${\mathsf{E}}$ constrained by some particular ${(\star)}$ condition (e.g., constructor contexts), falling back to ${(\textit{base})}$ otherwise. Similarly, the ${(\textit{tail})}$ case allows a choice in where to apply the tail call for expressions like ${\textit{f}~(\textit{f}~\textit{e})}$ for example and a particular instantiation of ${(\star)}$ should disambiguate for an actual algorithm. By default, we assume that any instantiation matches on the innermost application of ${\textit{f}}$ (for reasons discussed in Section 4.2).

This is still a bit constrained, as these equations do not consider any evaluation contexts ${\mathsf{E}}$ where the recursive call is under a ${\mathsf{let}}$ or ${\mathsf{match}}$ expression. We can again match on these specific forms of ${\textit{e}}$ . For example, ${\mathsf{let}~\textit{x}~=~\textit{e}_{0}~\mathsf{in}~\textit{e}_{1}}$ where ${\textit{e}_{0}~{\neq}~\mathsf{E}[\textit{f}~\textit{e}']}$ (so it does not overlap with ${\mathsf{E}}$ contexts):

Unfortunately, this rule is still too restrictive in general as it does not apply when the let-statement is itself under a context ${\mathsf{E}}$ . For example, we might encounter an expression like:

\begin{align*}\mathsf{let}~\textit{x}~=~(\mathsf{let}~\textit{y}~=~\textit{e}_{0}~\mathsf{in}~\textit{f}~\textit{x}~\textit{y})~\mathsf{in}~\textit{e}_{1}\end{align*}

Here, the recursive call is under the let-binding of ${\textit{x}}$ (as ${\mathsf{E}[\mathsf{let}~\textit{y}~=~\textit{e}_{0}~\mathsf{in}~\textit{f}~\textit{x}~\textit{y}]}$ ), but the ${\textit{y}~=~\textit{e}_{0}}$ binding prevents the recursive call ${\textit{f}~\textit{x}~\textit{y}}$ to be the focus of the evaluation context. This situation occurs whenever an expression is not in A-normal form (Flanagan et al., Reference Flanagan, Sabry, Duba and Felleisen1993), and these cannot be optimized by the rules outlined so far (and neither by the rules as presented in earlier work Leijen & Lorenzen, Reference Leijen and Lorenzen2023). Instead, we need to consider the general case where the let-binding appears under a context ${\mathsf{E}}$ . Assuming that the variables bound in let-bindings and matches are fresh, we can calculate:

Effectively we have lifted out the let-binding from the evaluation context. We can do the same for matches:

This form of specification essentially performs A-normalization whenever necessary to create further opportunities to match on tail-recursive calls. Our presentation follows the approach of Maurer et al. (Reference Maurer, Downen, Ariola and Jones2017), who describe the positions in a term that occur last in an evaluation order as tail contexts ${\mathsf{T}}$ . They show that A-normalization can be achieved by commuting the ${\mathsf{E}}$ and ${\mathsf{T}}$ contexts whenever possible. This is exactly the approach taken here, where we commute single let-bindings and matches under ${\mathsf{E}}$ contexts to the front of the term. A potential drawback of the ${\mathsf{match}}$ normalization is that it duplicates the evaluation context ${\mathsf{E}}$ in each of the branches. Maurer et al. (Reference Maurer, Downen, Ariola and Jones2017) also show how join points can be used to avoid code duplication in such case.

This leaves one last expression form to consider: the application of a function to an argument. Using the intuition of commuting tail contexts, we might define ${{[\![}~\mathsf{E}[\textit{e}_{0}~\textit{e}_{1}]~{]\!]}_{\textit{f},\textit{k}}~=~\textit{e}_{0}~{[\![}~\mathsf{E}[\textit{e}_{1}]~{]\!]}_{\textit{f},\textit{k}}}$ . However, while ${\textit{e}_{0}}$ can now be evaluated early, the application itself depends on the result of our transformation. Thus, we need to be a bit more careful and instead calculate:

In this general form, we need to strengthen our requirement that ${\textit{e}_{0}~{\neq}~\mathsf{E}[\textit{f}~\textit{e}']}$ to ensure that it does not overlap with our newly calculated rules. We write ${\textit{e}_{0}~\neq \mathsf{X}[\textit{f}~\textit{e}']}$ to mean that ${\textit{e}_{0}}$ cannot have a recursive call under an expression context ${\mathsf{X}}$ . The expression context ${\mathsf{X}[\textit{e}]}$ matches all possible expressions that contain ${\textit{e}}$ , unless ${\textit{e}}$ occurs in ${\mathsf{X}[\textit{e}]}$ exclusively under lambdas.

3.3 The tail-recursion-modulo-contexts algorithm

Figure 2 shows all five of the calculated equations for our generic tail recursion modulo contexts transformation (extended to multiple parameters). We can instantiate this algorithm by defining the context type ${\textit{ctx}~\alpha{}}$ , the context construction ( ${\mathsf{ctx}}$ ), composition ${({\bullet})}$ , and application ( ${\mathsf{app}}$ ) operations, and finally the ${(\star)}$ condition constrains the allowed context ${\mathsf{E}}$ to fit the particular context type.

Fig. 2. Calculated algorithm for general selective tail recursion modulo context transformation. It is parameterized by the ( $\star$ ) condition, the composition ( $\bullet$ ), and application (app) operations.

As remarked in Section 3.2, our equationally derived algorithm relied on a (single) non-inductive step, but we can still show formally that the algorithm is indeed sound:

See Appendix B.1 for the proof. Thanks to the A-normalization, we can also show that the TRMC algorithm exhaustively optimizes recursive calls:

There are two types of recursive calls that cannot be optimized by our algorithm: First, we do not optimize recursive calls inside lambdas. This is a necessary restriction, since it is impossible in general to push the accumulated context ${\textit{k}}$ under a lambda. Second, our algorithm will only optimize the first recursive call(s) in the evaluation order. If those are followed by further recursive calls, the evaluation context ${\mathsf{E}}$ stored as ${\mathsf{ctx}~\mathsf{E}}$ in the ${(\textit{tail})}$ rule may still contain unoptimized recursive calls. We will revisit this problem in Section 4.2. To see our algorithm in action, let’s consider the ${\textit{map}}$ function again:

\begin{align*}\textit{map}~\textit{xs}~\textit{f}~=~\mathsf{match}~\textit{xs}~\{~&~\textit{Nil}~{\rightarrow}~\textit{Nil}\\&~\textit{Cons}~\textit{x}~\textit{xx}~{\rightarrow}~\textit{Cons}~(\textit{f}~\textit{x})~(\textit{map}~\textit{xx}~\textit{f})~\}\end{align*}

When translating this function, we first use the ${(\textit{tmatch})}$ rule with ${\mathsf{E}~=~\square{}}$ to descend into the branches of the match. In the ${\textit{Nil}}$ branch, the ${(\textit{base})}$ rule applies. In the ${\textit{Cons}}$ branch, we use the ${(\textit{tapp})}$ rule (again with ${\mathsf{E}~=~\square{}}$ ) to bind the call to ${\textit{f}~\textit{x}}$ . We then use the ${(\textit{tail})}$ rule to optimize the recursive call to map xx f:

\begin{align*}\textit{map}'~\textit{xs}~\textit{f}~\textit{k}~=~\mathsf{match}~\textit{xs}~\{~&~\textit{Nil}~{\rightarrow}~\mathsf{app}~\textit{k}~\textit{Nil}\\&~\textit{Cons}~\textit{x}~\textit{xx}~{\rightarrow}~\mathsf{let}~\textit{c}~=~\textit{Cons}~(\textit{f}~\textit{x})~\mathsf{in}~\textit{map}'~\textit{xx}~\textit{f}~(\textit{k}~{\bullet}~(\mathsf{ctx}~(\textit{c}~\square{})))~\}\end{align*}

However, for Constructor Contexts (Section 6), it is useful to keep the ${\textit{Cons}}$ constructor in the context passed to ${\textit{map}}$ . In our pratical implementation, we therefore modify the ${(\textit{tapp})}$ rule slightly to extract the arguments instead of the entire partially applied function. Our final transformation for ${\textit{map}}$ is then:

\begin{align*}\textit{map}'~\textit{xs}~\textit{f}~\textit{k}~=~\mathsf{match}~\textit{xs}~\{~&~\textit{Nil}~{\rightarrow}~\mathsf{app}~\textit{k}~\textit{Nil}\\&~\textit{Cons}~\textit{x}~\textit{xx}~{\rightarrow}~\mathsf{let}~\textit{y}~=~\textit{f}~\textit{x}~\mathsf{in}~\textit{map}'~\textit{xx}~\textit{f}~(\textit{k}~{\bullet}~(\mathsf{ctx}~(\textit{Cons}~\textit{y}~\square{})))~\}\end{align*}

4.1 Modulo evaluation contexts

If we use ${\textit{true}}$ for the ${(\star)}$ condition, we can translate any recursive tail modulo evaluation context functions. Representing our abstract context directly as an ${\mathsf{E}}$ context is usually not possible though as ${\mathsf{E}}$ contexts generally contain code. The usual way to represent an arbitrary evaluation context ${\mathsf{E}}$ is simply as a (continuation) function ${\lambda \textit{x}.~\mathsf{E}[\textit{x}]}$ with a context type ${\textit{ctx}~\alpha{}~=~\alpha{}~{\rightarrow}~\alpha{}}$ :

This is an intuitive definition where ${\mathsf{ctx}~\square{}}$ corresponds to the identity function and context composition to function composition. If we apply the TRMC translation, we are essentially performing a selective CPS translation where the context ${\mathsf{E}}$ is represented as the continuation function. We can verify that the context laws hold for this instantiation (where we can assume ${\textit{e}}$ is terminating):

As a concrete example, let’s apply the modulo evaluation context to the ${\textit{map}}$ function:

\begin{align*}\textit{map}~\textit{xs}~\textit{f}~=~\mathsf{match}~\textit{xs}~\{~&~\textit{Nil}~{\rightarrow}~\textit{Nil}\\&~\textit{Cons}~\textit{x}~\textit{xx}~{\rightarrow}~\mathsf{let}~\textit{y}~=~\textit{f}~\textit{x}~\mathsf{in}~\textit{Cons}~\textit{y}~(\textit{map}~\textit{xx}~\textit{f})~\}\end{align*}

which translates to:

\begin{align*}\textit{map}'~\textit{xs}~\textit{f}~\textit{k}~=~\mathsf{match}~\textit{xs}~\{~&~\textit{Nil}~{\rightarrow}~\mathsf{app}~\textit{k}~\textit{Nil}\\&~\textit{Cons}~\textit{x}~\textit{xx}~{\rightarrow}~\mathsf{let}~\textit{y}~=~\textit{f}~\textit{x}~\mathsf{in}~\textit{map}'~\textit{xx}~\textit{f}~(\textit{k}~{\bullet}~(\mathsf{ctx}~(\textit{Cons}~\textit{y}~\square{})))~\}\end{align*}

and which the compiler can further simplify into:

\begin{align*}\textit{map}'~\textit{xs}~\textit{f}~\textit{k}~=~\mathsf{match}~\textit{xs}~\{~&~\textit{Nil}~{\rightarrow}~\textit{k}~\textit{Nil}\\&~\textit{Cons}~\textit{x}~\textit{xx}~{\rightarrow}~\mathsf{let}~\textit{y}~=~\textit{f}~\textit{x}~\mathsf{in}~\textit{map}'~\textit{xx}~\textit{f}~(\lambda \textit{x}.~\textit{k}~(\textit{Cons}~\textit{y}~\textit{x}))~\}\end{align*}

where we derived exactly the standard CPS style version of map as shown in Section 2. A general evaluation context transformation creates more opportunities for tail-recursive calls, but this also happens at the cost of potentially heap allocating continuation closures. As such, it is not common for strict languages to use this instantiation. The exception would be languages like scheme that always guarantee tail calls, but in that case the modulo evaluation contexts instantiation is already subsumed by general CPS conversion.

4.2 Nested translation of modulo evaluation contexts

The current instantiation is already very general as it applies to any ${\mathsf{E}}$ context, but we can do a little better. While the innermost non-tail call ${\mathsf{E}[\textit{f}~\textit{e}]}$ becomes ${\textit{f}'~\textit{e}~(\textit{k}~{\bullet}~\mathsf{ctx}~\mathsf{E})}$ , the context ${\mathsf{E}}$ may contain itself further recursive calls to ${\textit{f}}$ . Since ${\textit{k}}$ is just a variable this allocates a closure for each composition ${({\bullet})}$ and invokes every nested call ${\textit{f}~\textit{e}}$ with an empty context as ${\textit{f}'~\textit{e}~(\mathsf{ctx}~\square{})}$ before composing with ${\textit{k}}$ . This is not ideal, and in the classic CPS translation this is avoided by passing ${\textit{k}}$ itself into the closure for ${\mathsf{ctx}~\mathsf{E}}$ directly. Fortunately, we can achieve the same by specializing the compose function using the specification (b):

That is, in the compiler, instead of generating ${\textit{k}~{\bullet}~(\mathsf{ctx}~\mathsf{E})}$ , we invoke the TRMC translation recursively in the ${(\textit{tail})}$ case and generate ${\lambda \textit{x}.~{[\![}\mathsf{E}[\textit{x}]{}{]\!]}_{\textit{f},\textit{k}}}$ instead. This avoids the allocation of function composition closures and directly passes the continuation ${\textit{k}}$ to any nested recursive calls.

4.3 Modulo defunctionalized evaluation contexts

In order to better understand the shapes that evaluation contexts can take, we want to consider the defunctionalization (Reynolds, Reference Reynolds1972; Danvy & Nielsen, Reference Danvy and Nielsen2001) of the general evaluation context transformation. It turns out that this yields an interesting context in its own right. First, we observe that in any recursive function the evaluation context can only take a finite number of shapes depending on the number of recursive calls. We write this as:

\begin{align*}\mathsf{E}~:{}:={}~\square{}{\mid}{}\mathsf{E}_1{\mid}{}{\dots}{\mid}{}\mathsf{E}_\textit{n}\end{align*}

We define an accumulator datatype by creating a constructor ${\textsf{H}}$ for the ${\square{}}$ context and for each ${\mathsf{E}_\textit{i}}$ a constructor ${\mathsf{A}_\textit{i}}$ that carries the free variables of ${\mathsf{E}_\textit{i}}$ . The compiler then generates an ${\mathsf{app}}$ function where we interpret ${\mathsf{A}_\textit{i}}$ by evaluating ${\mathsf{E}_\textit{i}}$ with the stored free variables:

Just as we saw in Section 4.2, we need to use the translated evaluation context in the definition of ${\mathsf{app}}$ to translate nested calls. The context laws now follow by induction – see Appendix B.2 in the supplement for the derivations.

Applying this instantiation to the map function, we obtain:

In the ${\textit{Cons}}$ branch, we have inlined ${\textit{k}~{\bullet}~(\mathsf{A}_{1}~\textit{y}~\textsf{H})}$ . The ${\textit{app}}$ function interprets ${\mathsf{A}_{1}}$ by calling itself recursively on the stored evaluation context:

\begin{align*}\textit{app}~\textit{k}~\textit{xs}~=~\mathsf{match}~\textit{k}~\{~\textsf{H}~{\rightarrow}~\textit{xs};~\mathsf{A}_{1}(\textit{y},~\textit{k}')~{\rightarrow}~\textit{app}~\textit{k}'~(\textit{Cons}~\textit{y}~\textit{xs})~\}\end{align*}

As we can see, using the modulo defunctionalized evaluation context translation, we derived exactly the accumulator version of the map function that reverses the accumulated list in the end (where app is reverse)! In particular, for the special case where all evaluation contexts are constructor contexts ${\textit{C}^\textit{m}~\textit{x}_1~{\dots}~(\textit{f}~{\dots})~{\dots}~\textit{x}_\textit{m}}$ (as is the case for map), the accumulator datatype stores a path into the data structure we are building and thus essentially becomes a zipper structure (Huet, Reference Huet1997).

This defunctionalized approach might resemble general closure conversion at first (Appel, Reference Appel1991): In both approaches, we store the free variables in a datatype. However, in closure conversion the datatype typically also contains a machine code pointer and one jumps to the code by calling this pointer, while in our case we match on the specialized constructors (similar to the approach of Tolmach & Oliva, Reference Tolmach and Oliva1998).

4.3.1 Reuse

As the defunctionalization makes the evaluation context explicit, we can optimize it further. As Sobel & Friedman (Reference Sobel and Friedman1998) note, the defunctionalized closure is only applied once and we can reuse its memory for other allocations. This can happen automatically in languages with reuse analysis such as Koka (Lorenzen & Leijen, Reference Lorenzen and Leijen2022), Lean (Ullrich & de Moura, Reference Ullrich and de Moura2019), or OPAL (Didrich et al., Reference Didrich, Fett, Gerke, Grieskamp and Pepper1994). In particular, in the app function, the match:

\begin{align*}\mathsf{A}_{1}~\textit{y}~\textit{k}'~{\rightarrow}~\textit{app}~\textit{k}'~\textit{Cons}(\textit{y},~\textit{xs})\end{align*}

can reuse the ${\mathsf{A}_{1}}$ in-place to allocate the ${\textit{Cons}}$ node if the ${\mathsf{A}_{1}}$ is unique at runtime. In our case, the context is actually always unique (we show this formally in Section 6.1), and the ${\mathsf{A}_{1}}$ nodes are always reused! Even better, if the initial list is unique, we also reuse the initial ${\textit{Cons}}$ cell for the ${\mathsf{A}_{1}}$ accumulator itself in ${\textit{map}'}$ and no allocation takes place at all – the program is functional but in-place (Xie et al., Reference Xie and Leijen2021; Lorenzen et al., Reference Lorenzen, Leijen and Swierstra2023).

4.4 Modulo associative operator contexts

In the previous instantiations, we considered general evaluation contexts. However, we can often derive more efficient instantiations by considering more restricted contexts. A particularly nice example are monoidal contexts. For any monoid with an associative operator ${{\odot}~:{}~\tau{}~{\rightarrow}\tau{}~{\rightarrow}~\tau{}}$ and a unit value ${\textit{unit}~:{}~\tau{}}$ , we can define a restricted operator context as:

\begin{align*}\mathsf{A}~:{}:={}~\square{}{\mid}{}\textit{v}~{\odot}~\mathsf{A}\end{align*}

For a concrete example, consider the ${\textit{length}}$ function defined as:

\begin{align*}\textit{length}~\textit{xs}~=~\mathsf{match}~\textit{xs}~\{~\textit{Cons}~\textit{x}~\textit{xx}~{\rightarrow}~1~+~\textit{length}~\textit{xx};~\textit{Nil}~{\rightarrow}~0~\}\end{align*}

which applies for integer addition ( ${{\odot}~=~+,~\textit{unit}~=~0}$ ). The idea is now to define a compile time fold function ${(|\_|)}$ over a context ${\mathsf{A}}$ to always reduce the context to a single element of type ${\tau{}}$ :

We can now instantiate the abstract contexts by defining the ${(\star)}$ condition to constrain the ${\mathsf{E}}$ context to ${\mathsf{A}}$ , and the context type to ${\textit{ctx}~\tau{}~=~\tau{}}$ , where we use the fold operation to represent contexts always as a single element of type ${\tau{}}$ :

The context laws hold for this definition. For composition, we can derive:

and for context application we have:

We proceed by induction over ${\mathsf{A}}$ .

Common instantiations include integer addition ( ${{\odot}~=~+,~\textit{unit}~=~0}$ ) and integer multiplication ( ${{\odot}~=~\times,~\textit{unit}~=~1}$ ). The TRMC algorithm with ${\mathsf{A}}$ contexts instantiated with integer addition translates the previous ${\textit{length}}$ function to the following tail-recursive version:

\begin{align*}\textit{length}'~\textit{xs}~\textit{k}~=~\mathsf{match}~\textit{xs}~\{~\textit{Cons}~\textit{x}~\textit{xx}~{\rightarrow}~\textit{length}'~\textit{xx}~(\textit{k}~{\bullet}~(\mathsf{ctx}~(1~+~\square{})));~\textit{Nil}~{\rightarrow}~\mathsf{app}~\textit{k}~0~\}\end{align*}

The intention is that the fold function is performed by the compiler, and the compiler can simplify this further as:

\begin{align*}\textit{k}~{\bullet}~(\mathsf{ctx}~(1~+~\square{}))~=~\textit{k}~+~(\mathsf{ctx}~(1~+~\square{}))~=~\textit{k}~+~(|1+\square{}|)~=~\textit{k}~+~1\end{align*}

such that we end up with:

\begin{align*}\textit{length}'~\textit{xs}~\textit{k}~=~\mathsf{match}~\textit{xs}~\{~\textit{Cons}~\textit{x}~\textit{xx}~{\rightarrow}~\textit{length}'~\textit{xx}~(\textit{k}~+~1);~\textit{Nil}~{\rightarrow}~\textit{k}~\}\end{align*}

This time we derived exactly the text book accumulator version of ${\textit{length}}$ .

4.4.1 Using right biased contexts

Our defined context only allows the recursive call on the left, but we can also define a right biased context:

\begin{align*}\mathsf{A}~:{}:={}~\square{}{\mid}{}\mathsf{A}~{\odot}~\textit{v}\end{align*}

with the fold defined as:

We can now compose in the opposite order:

We can again show that the context laws hold for this definition (see Appendix B.3 in the supplement). As an example, we can instantiate ${{\odot}}$ as list append ${{+\!\!+}}$ with the empty list as the unit element to transform the ${\textit{reverse}}$ function:

\begin{align*}\textit{reverse}~\textit{xs}~=~\mathsf{match}~\textit{xs}~\{~\textit{Cons}~\textit{x}~\textit{xx}~{\rightarrow}~\textit{reverse}~\textit{xx}~{+\!\!+}~[\textit{x}];~\textit{Nil}~{\rightarrow}~[]~\}\end{align*}

First, our TRMC algorithm transforms it into:

\begin{align*}\textit{reverse}'~\textit{xs}~\textit{k}~&~=~\mathsf{match}~\textit{xs}~\{~\textit{Cons}~\textit{x}~\textit{xx}~{\rightarrow}~\textit{reverse}'~\textit{xx}~(\textit{k}~{\bullet}~(\mathsf{ctx}~(\square{}~{+\!\!+}~[\textit{x}])));~\textit{Nil}~{\rightarrow}~\mathsf{app}~\textit{k}~[]~\}\end{align*}

and with our instantiated context, this simplifies to:

\begin{align*}\textit{reverse}'~\textit{xs}~\textit{k}~&~=~\mathsf{match}~\textit{xs}~\{~\textit{Cons}~\textit{x}~\textit{xx}~{\rightarrow}~\textit{reverse}'~\textit{xx}~([\textit{x}]~{+\!\!+}~\textit{k});~\textit{Nil}~{\rightarrow}~[]~{+\!\!+}~\textit{k}~\}\end{align*}

Using right-biased contexts, we derived the text book accumulator version of reverse. This shows that our general TRMC algorithm can be instantiated to eliminate append calls automatically as first proposed by Hughes (Reference Hughes1986) and Wadler (Reference Wadler1987).

4.5 Modulo monoid contexts

To handle general monoids, we need to consider recursive calls on both sides of the associative operation:

\begin{align*}\mathsf{A}~:{}:={}~\square{}{\mid}{}\textit{v}~{\odot}~\mathsf{A}{\mid}{}\mathsf{A}~{\odot}~\textit{v}\end{align*}

This context ${\mathsf{A}}$ expresses arbitrarily nested applications of ${{\odot}}$ . As monoid operations may not be commutative, we cannot use a single element to represent the context. Instead, we need to use a product context where we accumulate the left and right context separately:

which we compose as:

We can again show that the context laws hold for this definition (see Appendix B.4 in the supplement).

4.6 Modulo semiring contexts

We can also combine the associative operators of two monoids, as long as one distributes over the other. This is the case for semirings in particular (although we do not need commutativity of ${+}$ ). Semiring contexts are relatively common in practice. For example, consider the following hashing function for a list of integers as shown by Bloch (Reference Bloch2008):

\begin{align*}\textit{hash}~\textit{xs}~=~\mathsf{match}~\textit{xs}~\{~\textit{Cons}~\textit{x}~\textit{xx}~{\rightarrow}~\textit{x}~+~31*(\textit{hash}~\textit{xx})~;~\textit{Nil}~{\rightarrow}~17~\}\end{align*}

Implementing modulo semiring contexts in a compiler may be worthwhile as deriving a tail-recursive version manually for such contexts is not always straightforward (and the interested reader may want to pause here and try to rewrite the ${\textit{hash}}$ function in a tail-recursive way before reading on).

We can define a general context for semirings as:

\begin{align*}\mathsf{A}~:{}:={}~\square{}{\mid}{}\textit{v}~+~\mathsf{A}{\mid}{}\textit{v}~*~\mathsf{A}{\mid}{}\mathsf{A}~+~\textit{v}{\mid}{}\mathsf{A}~*~\textit{v}\end{align*}

For simplicity, we assume we have a commutative semiring where both addition and multiplication commute. This allows us to use again a product representation at runtime where we accumulate the additions and multiplications separately (and without commutativity we need a quadruple instead). In the definition of the fold, we take into account that the multiplication distributes over the addition:

Finally, to compose the contexts we need to use distributivity again. Note how the ${(\textit{scomp})}$ rule mirrors the definition of ${(|\mathsf{A}|)}$ above:

We can show the context laws hold for these definitions:

and

-1em We proceed by induction over ${\mathsf{A}}$ (where we compress some cases for brevity):

When we apply this to the hash function, we derive the tail-recursive version as:

\begin{align*}\textit{hash}'~\textit{xs}~\textit{k}~=~\mathsf{match}~\textit{xs}~\{~\textit{Cons}~\textit{x}~\textit{xx}~{\rightarrow}~\textit{hash}'~\textit{xx}~(\textit{k}~{\bullet}~(\mathsf{ctx}~(\textit{x}~+~31*\square{})));~\textit{Nil}~{\rightarrow}~\mathsf{app}~\textit{k}~17~\}\end{align*}

which further simplifies to:

\begin{align*}\textit{hash}'~\textit{xs}~(\textit{l},\textit{r})~=~\mathsf{match}~\textit{xs}~\{~\textit{Cons}~\textit{x}~\textit{xx}~{\rightarrow}~\textit{hash}'~\textit{xx}~(\textit{l}~+~\textit{r}*\textit{x},~\textit{r}*31);~\textit{Nil}~{\rightarrow}~\textit{l}~+~\textit{r}*17~\}\end{align*}

The final definition may not be quite so obvious, and we argue that the modulo semiring instantiation may be a nice addition to any optimizing compiler. Indeed, it turns out that GCC implements this optimization (Dvořák, Reference Dvořák2004) for integers and floating point numbers (if –fast-math is enabled to allow the assumption of associativity). This implementation specifically creates two local accumulators for addition and multiplication and uses a direct while loop to compile the tail-recursive calls.

4.7 Modulo exponent contexts

As a final example of an efficient representation of contexts, we consider exponent contexts that consist of a sequence of calls to a function ${\textit{g}}$ :

\begin{align*}\mathsf{E}~:{}:={}~\square{}{\mid}{}\textit{g}~\mathsf{E}\end{align*}

If we use a defunctionalized evaluation context from Section 4.3, we derive a datatype that is isomorphic to the peano-encoded natural numbers: the continuation counts how often we still have to apply ${\textit{g}}$ . As such, we can represent it more efficiently by an integer, where we fold an evaluation context into a count:

We can define the primitive operations as:

where ${\mathsf{app}~\textit{k}~\textit{e}}$ applies the function ${\textit{g}}$ to its argument ${\textit{k}}$ times. See Appendix B.5 in the supplement for the derivations that show the context laws hold for this definition.

Note that if ${\textit{g}}$ is the enclosing function ${\textit{f}}$ , then the ${(\textit{xapp})}$ specification is not tail-recursive. In that case, we can again use specification (b) to replace ${\mathsf{app}~\textit{k}~(\textit{g}~\textit{e})}$ by ${{[\![}\textit{g}~\textit{e}{]\!]}_{\textit{f},\textit{k}}}$ at compile time (as shown in Section 4.2). A nice example of such an exponent context is given by Wand (Reference Wand1980) who considers McCarthy’s 91-function:

\begin{align*}\textit{g}~\textit{x}~=~\mathsf{if}~\textit{x}>10{}0~\mathsf{then}~\textit{x}-10~\mathsf{else}~\textit{g}~(\textit{g}~(\textit{x}+11))\end{align*}

Using the exponent context with the recursive ${(\textit{xapp})}$ , we obtain a mutually tail-recursive version:

\begin{align*}\textit{g}'~\textit{x}~\textit{k}~~&~=~\mathsf{if}~\textit{x}>10{}0~\mathsf{then}~\textit{app}~\textit{k}~(\textit{x}-10)~\mathsf{else}~\textit{g}'~(\textit{x}+11)~(\textit{k}+1)\\\textit{app}~\textit{k}~\textit{e}~&~=~\mathsf{if}~\textit{k}=0~\mathsf{then}~\textit{e}~\mathsf{else}~\textit{g}'~\textit{e}~(\textit{k}-1)\end{align*}

5.1 A basic expression evaluator

To motivate the composition of contexts, we consider a basic arithmetic expression evaluator in the style of Hutton (Reference Hutton2021):

The + suggests the use of a monoid context. However, this does not apply directly, since we have two recursive calls to eval instead of just one. The best we can do is to ignore the first recursive call and treat it as a regular value. Then we would obtain:

However, we have not quite achieved a tail-recursive version yet. Like Hutton (Reference Hutton2021), we can achieve this by using defunctionalized evaluation contexts:

This version is now tail-recursive, but it is also more complex than the original version and involves the allocation of and constructors. In particular, the constructor seems superfluous, as it corresponds to the context app(k,addacc + eval(e2)), which we optimized using the monoid contexts earlier. In this section, we want to combine the two approaches to obtain a more efficient version, where we use both an accumulator and a monoid context:

This version has the best of both worlds: it is fully tail-recursive and only needs to allocate a defunctionalized continuation for the left recursive call (where we need to keep track of the expression e2), while the right recursive call is efficiently handled by the monoid context.

5.2 Swapping contexts

To achieve this transformation in general, we need to be able to compose two contexts. For two contexts ${\mathsf{E}_{1}}$ and ${\mathsf{E}_{2}}$ , we can define their product context, which consists of tuples of the two contexts. We can apply a product context to an expression by applying each context in turn:

\begin{align*}(\textit{papp})~\quad \mathsf{app}~(\textit{l},~\textit{r})~\textit{e}~=~\mathsf{app}~\textit{l}~(\mathsf{app}~\textit{r}~\textit{e})\end{align*}

But how would we compose two product contexts? We would like to turn a composition of tuples into a tuple of compositions as ${(\textit{l}_{1},~\textit{r}_{1})~{\bullet}~(\textit{l}_{2},~\textit{r}_{2})~=~(\textit{l}_{1}~{\bullet}~\textit{l}_{2},~\textit{r}_{1}~{\bullet}~\textit{r}_{2})}$ . We can try to calculate this directly:

… but now we are stuck. Here, ${\textit{l}_{1},\textit{l}_{2}}$ belong to the context ${\mathsf{E}_{1}}$ and ${\textit{r}_{1},\textit{r}_{2}}$ to ${\mathsf{E}_{2}}$ . In order to make progress, we have to swap the inner contexts ${\textit{r}_{1}}$ and ${\textit{l}_{2}}$ . But this is not always going to be possible! Instead, we need to parameterize the product context with a swap operation:

\begin{align*}(\textit{appswap})~\quad \mathsf{app}~\textit{l}~(\mathsf{app}~\textit{r}~\textit{e})~\quad =~\mathsf{app}~\textit{r}'~(\mathsf{app}~\textit{l}'~\textit{e})~\quad \mathsf{where}~(\textit{l}',~\textit{r}')~=~\mathsf{swap}(\textit{l},~\textit{r})\end{align*}

If the contexts are connected in this sense, we can continue to calculate their composition:

This gives us a definition for product contexts: we can fold any context ${\mathsf{E}~=~\mathsf{E}_{1}{\mid}{}\mathsf{E}_{2}}$ by composing the folds of ${\mathsf{E}_{1}}$ and ${\mathsf{E}_{2}}$ :

With this definition in hand, we can now derive several contexts from the previous section from the more basic contexts we defined earlier.

5.2.1 Modulo monoid contexts

We motivated the Modulo Monoid Contexts in Section 4.5 as the composition of a left-biased and a right-biased context. In fact, we can now derive this context as the product context of a left-biased and right-biased contexts, with ${\textit{swap}(\textit{l},~\textit{r})~=~(\textit{r},~\textit{l})}$ . This follows the swap law since:

\begin{align*}\quad &~\mathsf{app}~\textit{l}~(\mathsf{app}~\textit{r}~\textit{e})\\=~\;\;~&~\textit{l}~{\odot}~(\textit{e}~{\odot}~\textit{r})\\=~\;\;~&~(\textit{l}~{\odot}~\textit{e})~{\odot}~\textit{r}\\=~\;\;~&~\mathsf{app}~\textit{r}~(\mathsf{app}~\textit{l}~\textit{e})\end{align*}

With this, we get exactly the previous definition of ${(\textit{acomp})}$ of Modulo Monoid Contexts.

5.2.2 Modulo semiring contexts

Similarly, we can derive the semiring context (Section 4.6) as the composition of two left-biased contexts for its addition ( ${\textit{l}}$ ) and multiplication ( ${\textit{r}}$ ). Here, the swap operation is given by ${\textit{swap}(\textit{r},~\textit{l})~=~(\textit{r}~*~\textit{l},~\textit{r})}$ :

\begin{align*}\quad &~\mathsf{app}_*~\textit{r}~(\mathsf{app}_+~\textit{l}~\textit{e})\\=~\;\;~&~\textit{r}~*~(\textit{l}~+~\textit{e})\\=~\;\;~&~(\textit{r}~*~\textit{l})~+~(\textit{r}~*~\textit{e})\\=~\;\;~&~\mathsf{app}_+~(\textit{r}~*~\textit{l})~(\mathsf{app}_*~\textit{r}~\textit{e})\end{align*}

With this, we get exactly the previous definition of ${(\textit{scomp})}$ and it our new context corresponds to the semiring contexts we defined earlier. For this definition to work, it is important though that the left-biased context for the addition is in the first component of the tuple with multiplication in the second. That allows us to define a swap operation that uses the distributivity of the semiring to swap the contexts. We could not define a swap operation if multiplication is in the first component, since this would require us to move an addition under a multiplication, which is only possible if the semiring has multiplicative inverses.

5.3 Composing (defunctionalized) evaluation contexts

(Defunctionalized) evaluation contexts are the only contexts introduced in the last section that can reliably make all recursive calls tail-recursive. For this reason, they are particularly attractive for composition with other contexts that lead to faster code in practice but only apply in more limited cases. Thankfully, this is easily possible, since we can swap an arbitrary context ${\textit{r}}$ with a general evaluation context ${\textit{l}}$ by storing it in a closure:

\begin{align*}\textit{swap}~(\textit{r},~\textit{l})~=~((\lambda \textit{x}.~\mathsf{app}~\textit{r}~\textit{x})~{\bullet}~\textit{l},~\mathsf{ctx}~\square{})\end{align*}

We can verify that this definition fulfills the swap law:

The same approach can also be used for defunctionalized evaluation contexts. Analogous to creating a fresh closure, we could create a special constructor to store an application of the other context. However, to avoid allocations and to enable a nested translation (Section 4.2), we integrate the restricted context into the constructors.

We define the extended accumulator datatype by creating a constructor ${\textsf{H}}$ for the ${\square{}}$ context and for each ${\mathsf{E}_\textit{i}}$ a constructor ${\mathsf{A}_\textit{i}}$ that carries the free variables of ${\mathsf{E}_\textit{i}}$ and the inner context ${\textit{k}'}$ . The compiler then generates an ${\mathsf{app}}$ function where we interpret ${\mathsf{A}_\textit{i}}$ by evaluating ${\mathsf{E}_\textit{i}}$ with the stored free variables:

Then we can define the swap operation as:

This definition again fulfills the swap law. Case ${\textsf{H}}$ :

Case ${\mathsf{A}_\textit{i}~\textit{x}_1~{\dots}~\textit{x}_\textit{m}~\textit{k}'~\textit{k}_{2}}$ :

5.4 Extending the expression evaluator

We can use this insight to derive a tail-recursive expression evaluator which supports multiplication as well, where we compose a defunctionalized evaluation context with a semiring context. First, we add a new constructor (e1,e2) to our expression datatype which encodes the multiplication eval(e1) * eval(e2). We then create a datatype accum which stores the defunctionalized evaluation contexts when descending into the first expression e1. These constructors contain both the second expression e2 and the semiring context (a, m). When descending into e1, we store the current semiring context in the constructor and continue with the semiring context ${\mathsf{ctx}~\square{}~=~(0,~1)}$ :

This calculation directly follows the recipe for composing with defunctionalized evaluation contexts and can thus be derived algorithmically. Our full implementation becomes:

In contrast, a translation using just defunctionalized evaluation contexts would require two more constructors (just as in the basic example). Unfortunately though, now that we store the semiring context in accum, our constructors carry a few more elements than the constructors of expr. In a language like Koka, which can reuse constructors of equal size (Xie et al., Reference Xie and Leijen2021; Lorenzen & Leijen, Reference Lorenzen and Leijen2022), it would be preferable to obtain constructors of the same size as expr, since we could then hope to avoid the allocation of and by reusing the memory of and . This is often possible when using non-composed defunctionalized evaluation contexts and Lorenzen et al. (Reference Lorenzen, Leijen and Swierstra2023) show that it is guaranteed to work if the original function has the shape of a map or fold (like eval). Alas, the same is not true for composed contexts, since we need to store the additional semiring context. However, using composed contexts like here can still avoid allocations in languages that lack reuse analysis.

Finally, we can reduce the number of elements stored in the constructors and obtain a more natural version of the evaluator by using the distributivity law to push the semiring context into the expression. For the

case, we calculate:

At this point, the recursive call to ${\mathsf{eval}~\textit{e}_{1}}$ is under a semiring context ${({\textit{a}},\textit{m})}$ and an evaluation context ${\square{}~+~\textit{m}~*~\mathsf{eval}~\textit{e}_{2}}$ . We thus have to store an extra m in our

constructor:

It turns out that in this version, the semiring context stored in the accumulated datatype is always going to be (0,1), so we can simplify the definition by omitting it. We thus obtain the implementation:

This version is slightly more efficient than the previous one, but the constructors are still too big for reuse analysis to apply. Furthermore, it is unclear whether we can derive this algorithmically as well. Instead, we will stick with the more general version that can be derived directly from the composition of contexts and extend it to derive an evaluator that can also handle subtraction and division.

To extend the expression evaluator to support division, we might try to add a new context for division and show how to compose it with the semiring context. However, this is not straightforward, since ${({\textit{a}}~+~\square{})^{-1}}$ cannot be simplified to ${{\textit{a}}'~+~\square{}^{-1}}$ for any other ${{\textit{a}}'}$ : the inverse of the sum depends on the ${\square{}}$ , which is not yet known, and there is no general rule for exchanging the inverse operation with addition. Instead, we need to use an idea from the theory of continued fractions.

5.5 Aside: Continued fractions

Continued fractions are a representation of the rational (or real) numbers that arises from the Euclidean algorithm. They consist of a sequence of nested additions and fractions with numerator 1. For example, we can calculate the continued fraction of 4.24 as:

\begin{align*}4.24~&=~4~+~\frac{24}{10{}0}\\~&=~4~+~\cfrac{1}{\frac{10{}0}{24}}~=~4~+~\cfrac{1}{4~+~\cfrac{4}{24}}~=~4~+~\cfrac{1}{4~+~\cfrac{1}{6}}~=~4~+~\cfrac{1}{4~+~\cfrac{1}{\cfrac{6}{1}}}~=~4~+~\cfrac{1}{4~+~\cfrac{1}{5~+~\cfrac{1}{1}}}\end{align*}

We can write such a (long-form) continued fraction (with the final ‘1’ left implicit) as ${[4,~4,~5]}$ . Then we can compute its floating point representation with a simple recursive algorithm:

This algorithm is not tail-recursive, and it might be quite difficult to make tail-recursive without further insight (and without resorting to general evaluation contexts). However, it is well known that continued fractions can be calculated by their convergents, which is a sequence ${\textit{h}_\textit{n},~\textit{k}_\textit{n}}$ with ${\mathsf{frac}([{\textit{a}}_0,~{\dots},~{\textit{a}}_\textit{n}])~=~\textit{h}_\textit{n}~/~\textit{k}_\textit{n}}$ . The convergents start with ${\textit{h}_{-2}~=~0}$ , ${\textit{h}_{-1}~=~1}$ , ${\textit{k}_{-2}~=~1}$ , and ${\textit{k}_{-1}~=~0}$ and are further calculated by:

\begin{align*}\dfrac{\textit{h}_\textit{n}}{\textit{k}_\textit{n}}~=~\dfrac{{\textit{a}}_\textit{n}*\textit{h}_{\textit{n}-1}~+~\textit{h}_{\textit{n}-2}}{{\textit{a}}_\textit{n}*\textit{k}_{\textit{n}-1}~+~\textit{k}_{\textit{n}-2}}\end{align*}

This gives us a tail-recursive algorithm to calculate the continued fraction (where we write h1 for ${\textit{h}_{\textit{n}-1}}$ , h2 for ${\textit{h}_{\textit{n}-2}}$ and equivalent for k1 and k2):

It turns out that we can use the same idea to define a general context that applies to arbitrary sequences of addition, multiplication, and inverses.

5.6 Modulo fields context

Using the insight from continued fractions, we can define general field contexts that support not only addition and multiplication but also additive and multiplicative inverses. We define the context ${\textit{F}}$ as:

\begin{align*}\textit{F}~:{}:={}~\square{}{\mid}{}{\textit{a}}~+~\textit{F}{\mid}{}\textit{m}~*~\textit{F}{\mid}{}\textit{F}^{-1}\end{align*}

It turns out that we use the same convergent representation as for continued fractions, where we keep four numbers:

\begin{align*}\dfrac{\textit{x}*\textit{h}_{1}~+~\textit{h}_{2}}{\textit{x}*\textit{k}_{1}~+~\textit{k}_{2}}\end{align*}

and define the fold operation as:

We can apply a field context to an expression by substituting the expression for ${\textit{x}}$ . Similarly, we can compose two field contexts by substituting the second context into the first context and simplifying the expression. Our context is defined as:

and the context laws hold.

5.7 An advanced expression evaluator

Using the field contexts, we can extend our expression evaluator to support arbitrary field operations. Our implementation arises directly from the obvious expression evaluator which folds the expression into a rational number:

We can directly define the field context as a datatype, where we define empty(), add(a), mul(a), and inv() to correspond to the fold operations:

Then we use the TRMC algorithm with the composition of defunctionalized contexts and field contexts to obtain a tail-recursive version that uses a field context for the field operations and a defunctionalized context for the recursive calls that leave an expression to be evaluated:

The final derived program is actually quite sophisticated and fully tail-recursive. We believe that deriving this algorithm manually would be nontrivial. Moreover, it only allocates a small amount of memory while descending the left-spine. In contrast, a simple application of defunctionalized contexts without field contexts would require us to allocate a constructor even in the cases, which would be less efficient.

6.1 Minamide

Minamide (Reference Minamide1998) presents a “hole calculus” that can directly express our contexts in a functional way but also allows an efficient in-place updating implementation. Using the hole calculus as our target calculus, we can instantiate the translation function using Minamide’s system. We define the context type as a “hole function” ( ${{\hat{\lambda}} \textit{x}.~\textit{e}}$ ), where ${\textit{ctx}~\alpha{}}$ ${\equiv{}}$ ${\textit{hfun}~\alpha{}~\alpha{}}$ . and instantiate the context operations to use the primitives as given by Minamide (Reference Minamide1998):

Satisfyingly, our primitives turn out to map directly to the hole calculus primitives. The reduction rules for ${\textit{happ}}$ and ${\textit{hcomp}}$ specialized to our calculus are (Minamide, Reference Minamide1998, fig. 5):

This means that for any context ${\textit{k}}$ , we have ${\textit{k}~\cong{}~{\hat{\lambda}} \textit{x}.~\mathsf{K}[\textit{x}]}$ (1). We can now show that our context laws are satisfied for this system, with composition:

and application:

The hole calculus is restricted by a linear-type discipline where the contexts ${\textit{ctx}~\alpha{}}$ ${\equiv{}}$ ${\textit{hfun}~\alpha{}~\alpha{}}$ have a linear type. This is what enables an efficient in-place update implementation while still having a pure functional interface. For our needs, we need to check separately that the translation ensures that all uses of a context ${\textit{k}}$ are indeed linear. Type judgments in Minamide’s system (Minamide, Reference Minamide1998, fig. 4) are denoted as

where ${\Gamma{}}$ is the normal type environment, and ${\textit{H}}$ for linear bindings containing at most one linear value. The type environment ${\Gamma{}}$ can itself contain linear values with a linear type (like ${\textit{hfun}}$ ) but only pass those linearly to a single premise. The environment restricted to nonlinear values is denoted as ${\Gamma{}|_{\mathsf{N}}}$ . We can now show that our translation can indeed be typed under the linear type discipline:

To show this, we need a variant of the general replacement lemma (Hindley & Seldin, Reference Hindley and Seldin1986, Lemma 11.18; Wright & Felleisen, Reference Wright and Felleisen1994, Lemma 4.2) to reason about linear substitution in an evaluation context:

Interestingly, this lemma requires constructor contexts and we would not be able to derive the Lemma for general contexts as the linear type environment is not propagated through applications. The proofs can be found in Appendix B.7 in the supplement, which also contains the full type rules adapted to our calculus.

6.2 In-place update

The instantiation with Minamide’s system is using fast in-place updates and proven sound, but it is still a bit unsatisfactory as how such in-place mutation is done (or why this is safe) is only described informally. In Minamide’s system, a suggested implementation for a context is as a tuple ${\langle\mkern1mu{}\mathsf{K},\textit{x}{@}\textit{i}\mkern2mu\rangle{}}$ where ${\mathsf{K}}$ is (a pointer to) a context and ${\textit{x}{@}\textit{i}}$ is the address of the hole as the ${\textit{i}{\textit{th}}}$ field of object ${\textit{x}}$ (in ${\mathsf{K}}$ ). The empty tuple ${\langle\mkern1mu{}\mkern2mu\rangle{}}$ is used for an empty context ( ${\square{}}$ ). Composition and application directly update the hole pointed to by ${\textit{x}{@}\textit{i}}$ by overwriting the hole with the child context or value.

In contrast, Bour et al. (Reference Bour, Clément and Scherer2021) show a TRMC translation for OCaml that uses destination passing style which makes it more explicit how the in-place update of the hole works. In particular, the general construct ${\textit{x}.\textit{i}~:={}~\textit{v}}$ overwrites the ${\textit{i}{\textit{th}}}$ field of any object ${\textit{x}}$ with ${\textit{v}}$ . To gain more insight of why in-place update is possible and correct, we are going to use the explicit heap semantics of Perceus (Xie et al., Reference Xie and Leijen2021; Lorenzen & Leijen, Reference Lorenzen and Leijen2022). In such semantics, the heap is explicit and all objects are explicitly reference counted. Using the Perceus derivation rules, we can soundly translate our current calculus to the Perceus target calculus where the reference counting instructions ( ${\mathsf{dup}}$ and ${\mathsf{drop}}$ ) are derived automatically by the derivation rules (Xie et al., Reference Xie and Leijen2021, fig. 5). The Perceus heap semantics reduces the derived expressions using reduction steps of the form ${\textit{H}{\mid}{}\textit{e}_{1}~\;~{\longmapsto}_\textit{r}~\;~\textit{H}'{\mid}{}\textit{e}_{2}}$ , which reduces a heap ${\textit{H}}$ and an expression ${\textit{e}}$ to a new heap ${\textit{H}'}$ and expression ${\textit{e}_{2}}$ (Xie et al., Reference Xie and Leijen2021, fig. 7). The heap ${\textit{H}}$ maps objects ${\textit{x}}$ with a reference count ${\textit{n}\geqslant{}1}$ to values, denoted as ${\textit{x} \mapsto^{\textit{n}} \textit{v}}$ . In this system, we can express in-place updates directly, and it turns out we can even calculate the in-place updating reduction rules for ${\mathsf{comp}}$ and ${\mathsf{app}}$ from the context laws. Before we do that though, we first need to establish some terminology and look carefully at what “in-place update” actually means.

6.2.1 The essence of in-place update

Let’s consider a generic copy function, ${(\textit{x}.\textit{i}~\mathsf{as}~\textit{y})}$ , that changes the ${\textit{i}{\textit{th}}}$ field of an object ${\textit{x}}$ to ${\textit{y}}$ , for any generic constructor ${\textit{C}}$ :

\begin{align*}\textit{x}.\textit{i}~\mathsf{as}~\textit{y}~~=~\mathsf{match}~\textit{x}~\{~\textit{C}^\textit{k}~\textit{x}_1~{\dots}~\textit{x}_\textit{i}~{\dots}~\textit{x}_\textit{k}~{\rightarrow}~\textit{C}^\textit{k}~\textit{x}_1~{\dots}~\textit{y}~{\dots}~\textit{x}_\textit{k}~\}\end{align*}

When we apply the Perceus algorithm (Xie et al., Reference Xie and Leijen2021), we need to insert a single drop:

\begin{align*}\textit{x}.\textit{i}~\mathsf{as}~\textit{y}~~=~\mathsf{match}~\textit{x}~\{~\textit{C}^\textit{k}~\textit{x}_1~{\dots}~\textit{x}_\textit{i}~{\dots}~\textit{x}_\textit{k}~{\rightarrow}~\mathsf{drop}~\textit{x}_\textit{i};~\textit{C}^\textit{k}~\textit{x}_1~{\dots}~\textit{y}~{\dots}~\textit{x}_\textit{k}~\}\end{align*}

In the special case that ${\textit{x}}$ is unique at runtime (i.e., the reference count of ${\textit{x}}$ is 1), we can now derive the following:

And this is the essence of in-place mutation: when an object is unique, an in-place update corresponds to allocating a fresh copy, discarding the original (due to the uniqueness of ${\textit{x}}$ ), and ${\alpha{}}$ -renaming to reuse the original “address”.

We will write ${(\textit{x}.\textit{i}~:={}~\textit{z})}$ for ${(\textit{x}.\textit{i}~\mathsf{as}~\textit{z})}$ in the special case of updating a field in a unique constructor, where we can derive the following reduction rule:

\begin{align*}(\textit{assign})\quad \textit{H},~\textit{x} \mapsto^{1} \textit{C}~{\dots}~\textit{x}_\textit{i}~{\dots}{\mid}{}\textit{x}.\textit{i}~:={}~\textit{y}~~\quad {{\longrightarrow_{\textsf{r}}^*}}~\quad \textit{H},~\textit{x} \mapsto^{1} \textit{C}~{\dots}~\textit{y}~{\dots}{\mid}{}\mathsf{drop}~\textit{x}_\textit{i};~\textit{x}\end{align*}

and in the case the field is a ${{{\square}}}$ , we can further refine this to:

\begin{align*}(\textit{assignn})\quad \textit{H},~\textit{x} \mapsto^{1} \textit{C}~{\dots}~{{\square}}_\textit{i}~{\dots}{\mid}{}\textit{x}.\textit{i}~:={}~\textit{y}~~\quad {{\longrightarrow_{\textsf{r}}^*}}~\quad \textit{H},~\textit{x} \mapsto^{1} \textit{C}~{\dots}~\textit{y}~{\dots}{\mid}{}\textit{x}\end{align*}

For convenience, we will from now on use the notation ${\textit{C}~{\dots}~\textit{x}_\textit{i}~{\dots}}$ , and ${\textit{C}~{\dots}~{{\square}}_\textit{i}~{\dots}}$ to denote the ${\textit{i}{\textit{th}}}$ field in a constructor if there is no ambiguity.

6.2.2 Linear chains

We need a bit more generality to express hole updates in contexts. In particular, we will see that all objects along the path from the top of the context to the hole are unique by construction. We call such unique path a linear chain, denoted as ${[\textit{H}]^\textit{n}_\textit{x}}$ :

\begin{align*}[\textit{H}]^\textit{n}_\textit{x}~=~[\textit{x} \mapsto^{\textit{n}} \textit{v}_{0},~\textit{x}_{1} \mapsto^{1} \textit{v}_{1},~{\dots},~\textit{x}_\textit{m} \mapsto^{1} \textit{v}_\textit{m}]^\textit{n}_\textit{x}~\quad (\textit{m}~\geqslant{}~0)\end{align*}

where for all ${\textit{x}_\textit{i}\in (\mathsf{dom}(\textit{H})~-~\{\textit{x}\})}$ , we have ${\textit{x}_\textit{i}\in \mathsf{fv}(\textit{v}_{\textit{i}-1})}$ (and therefore for all ${\textit{y}\in \mathsf{dom}(\textit{H})}$ we have ${\mathsf{reachable}(\textit{H},\textit{x})}$ ). Since the objects in ${\textit{H}}$ besides ${\textit{x}}$ are all unique and not reachable otherwise, we also say that ${\textit{x}}$ dominates ${\textit{H}}$ . When the dominator is also unique, we call it a unique linear chain (of the form ${[\textit{H}]^1_\textit{x}}$ ). We can define linear chains inductively as well since a single object always forms a linear chain:

\begin{align*}(\textit{linearone})~~\quad \textit{x} \mapsto^{\textit{n}} \textit{v}~~=~[\textit{x} \mapsto^{\textit{n}} \textit{v}]^\textit{n}_\textit{x}\end{align*}

and we can always extend with a unique linear chain:

\begin{align*}(\textit{linearcons})~\quad \textit{x} \mapsto^{\textit{n}} {\dots}~\textit{z}~{\dots},~[\textit{H}]^1_\textit{z}~~=~[\textit{x} \mapsto^{\textit{n}} {\dots}~\textit{z}~{\dots},\textit{H}]^\textit{n}_\textit{x}\end{align*}

Using ${(\textit{linearcons}}$ ) we can derive that we can append a unique linear chain as well:

\begin{align*}(\textit{linearapp})~~\quad [\textit{H}_{1},\textit{y} \mapsto^{1} {\dots}~\textit{z}~{\dots}]^\textit{n}_\textit{x},~[\textit{H}_{2}]^1_\textit{z}~~=~[\textit{H}_{1},\textit{y} \mapsto^{1} {\dots}~\textit{z}~{\dots},\textit{H}_{2}]^\textit{n}_\textit{x}\end{align*}

6.2.3 Contexts as a linear chain

To simplify the proofs, we assume in this subsection that all fields in ${\mathsf{K}}$ contexts are variables:

\begin{align*}\mathsf{K}~:{}:={}~\square{}{\mid}{}\textit{C}~\textit{x}_{1}~{\dots}~\mathsf{K}~{\dots}~\textit{x}_\textit{n}\end{align*}

since we can always arrange any ${\mathsf{K}}$ to have this form by let-binding the values ${\textit{v}}$ . It turns out that a constructor context then always evaluates to a unique linear chain:

Lemma 2. (Contexts evaluate to unique linear chains)

For any ${\mathsf{K}}$ , we have ${\textit{H}{\mid}{}\mathsf{K}[\textit{C}~{\dots}~\square{}_\textit{i}~{\dots}]~~{{\longrightarrow_{\textsf{r}}^*}}~~\textit{H},~[\textit{H}',\textit{y} \mapsto^{1} \textit{C}~{\dots}~{{\square}}_\textit{i}~{\dots}]^1_\textit{x}{\mid}{}\textit{x}}$ .

We can show this by induction on the shape of ${\mathsf{K}}$ (Appendix B.8 in the supplement).

6.2.4 Calculating the fold

Following Minamide’s approach, we are going to denote our contexts as a tuple ${\langle\mkern1mu{}\textit{x},\textit{y}{@}\textit{i}\mkern2mu\rangle{}}$ where ${\textit{x}}$ is (a pointer to) a constructor context and ${\textit{y}{@}\textit{i}}$ is the address of the hole as the ${\textit{i}{\textit{th}}}$ field of object ${\textit{y}}$ . We define ${\mathsf{ctx}~\mathsf{K}~=~(|\mathsf{K}|)}$ . For an empty context, we use an empty tuple ( ${(|\square{}|)~=~\langle\mkern1mu{}\mkern2mu\rangle{}}$ ), but otherwise we can specify the fold as:

\begin{align*}(\textit{foldspec})\quad \textit{H}{\mid}{}(|\mathsf{K}[\textit{C}~{\dots}~\square{}_\textit{i}~{\dots}]|)~~\cong{}~~\textit{H}{\mid}{}\mathsf{let}~\textit{x}~=~\mathsf{K}[\textit{C}~{\dots}~{{\square}}_\textit{i}~{\dots}]~\mathsf{in}~\langle\mkern1mu{}\textit{x},[\textit{x}]@{\textit{i}}\mkern2mu\rangle{}\end{align*}

where we use the notation ${{}[\textit{x}]}$ do denote the last object of the linear chain formed by ${\mathsf{K}}$ (Lemma 2). We can now calculate the definition of ${(|\_|)}$ from its specification (see Appendix B.9 in the supplement), where we get following definition for ${(|\_|)}$ :

This builds up the context using ${\mathsf{let}}$ bindings, while propagating the address of the hole. As before, the intention is that the compiler expands the fold statically. For example, the ${\textit{map}}$ function translates to:

where ${\textit{z}{@}2}$ correctly denotes the address of the hole field in the context.

6.2.5 Updating a context

Before we can define in-place application, we need an in-place substitution operation ${\mathsf{subst}~\langle\mkern1mu{}\textit{x},\textit{y}{@}\textit{i}\mkern2mu\rangle{}~\textit{z}}$ that substitutes ${\textit{z}}$ at the hole (at ${\textit{y}{@}\textit{i}}$ ) in the context ${\textit{x}}$ . Note that in our representation of a context as a tuple ${\langle\mkern1mu{}\textit{x},\textit{y}{@}\textit{i}\mkern2mu\rangle{}}$ we treat ${\textit{y}{@}\textit{i}}$ purely as an address and do not reference count ${\textit{y}}$ as such. The ${\textit{y}}$ part is a “weak” pointer, and we cannot use it directly without also having an “real” reference. This means that if we want to define an in-place substitution, we cannot define it directly as ${\textit{y}.\textit{i}~:={}~\textit{z}}$ (since we have no real reference to ${\textit{y}}$ ). Instead, we are going to calculate an in-place updating substitution from its specification:

\begin{align*}(\textit{subspec})~\textit{H},[\textit{H}',\textit{y} \mapsto^{1} \textit{C}~{\dots}~{{\square}}_\textit{i}~{\dots}]^1_\textit{x}~{\mid}{}\mathsf{subst}~\langle\mkern1mu{}\textit{x},\textit{y}{@}\textit{i}\mkern2mu\rangle{}~\textit{z}~~\cong{}~~\textit{H},[\textit{H}',\textit{y} \mapsto^{1} \textit{C}~{\dots}~\textit{z}~{\dots}]^1_\textit{x}~{\mid}{}\textit{x}\end{align*}

We do this by induction of the shape of the linear chain. For the singleton case, we have:

and for the extension we have:

This leads to the following inductive definition of ${\mathsf{subst}}$ :

That is, to update the last element of the chain in-place, we need traverse down while separating the links such that when we reach the final element it has a unique reference count and can be updated in-place. We then traverse back up fixing up all the links again. Of course, we would not actually use this implementation in practice – the derivation here just shows that the substitution specification is sound, and we can thus implement the ${(\textit{subspec})}$ reduction by instead using the tuple address ${\textit{y}{@}\textit{i}}$ directly to update the hole in-place. In essence, due to the uniqueness of the elements in the chain, the ${\textit{y}}$ is uniquely reachable through ${\textit{x}}$ , and thus it is safe to use it directly in this case.

6.2.6 Calculating application and composition

With the specification for fold and in-place substitution, we can use the context laws to calculate the in-place updating version of application and composition. Starting with application, we can calculate (for ${\mathsf{K}~{\neq}~\square{}}$ ):

And thus we define application directly in terms of in-place substitution as:

\begin{align*}(\textit{uapp})~~\textit{H}{\mid}{}\mathsf{app}~\langle\mkern1mu{}\textit{x},\textit{y}@{\textit{i}}\mkern2mu\rangle{}~\textit{z}~~\quad {{\longrightarrow_{\textsf{r}}}}~\quad \textit{H}{\mid}{}\mathsf{subst}~\langle\mkern1mu{}\textit{x},\textit{y}@{\textit{i}}\mkern2mu\rangle{}~\textit{z}\end{align*}

We arrived exactly at the “obvious” implementation where the hole inside a unique context is updated in-place in constant time. This also corresponds to the informal implementation given in Section 2.3. For composition, it turns out we can define it in terms of applications:

\begin{align*}(\textit{ucomp})~&~\textit{H}{\mid}{}\langle\mkern1mu{}\textit{x}_{1},\textit{y}_{1}@{\textit{i}}\mkern2mu\rangle{}~{\bullet}~\langle\mkern1mu{}\textit{x}_{2},\textit{y}_{2}@{\textit{j}}\mkern2mu\rangle{}~~\quad {{\longrightarrow_{\textsf{r}}}}~\quad \textit{H}{\mid}{}\langle\mkern1mu{}\mathsf{app}~\langle\mkern1mu{}\textit{x}_{1},\textit{y}_{1}@{\textit{i}}\mkern2mu\rangle{}~\textit{x}_{2},~\textit{y}_{2}@{\textit{j}}\mkern2mu\rangle{}\end{align*}

where the derivation is in Appendix B.10 in the supplement. Again we arrived at the efficient translation where the hole in the first unique context is updated in-place (and in constant time) with a pointer to the second context. The full rules for application and composition are (with the derivations for the empty contexts in Appendix B.10 in the supplement):

Note that ${(\textit{ucompr})}$ is not really needed since by construction our translation never generates empty contexts for the second argument. The rules also correspond to the informal implementation given in Section 2.3 where

was used to represent the empty tuple.

With these definitions, we still need to show that we can be efficient and that we never get stuck. For efficiency, we need to show that a context ${\langle\mkern1mu{}\textit{x},\textit{y}@{\textit{i}}\mkern2mu\rangle{}}$ is always a linear chain so we don’t have to check that at runtime in ${(\textit{subspec})}$ . This follows by construction since any initial context ${\mathsf{ctx}~\mathsf{K}}$ is a linear chain (Lemma 2), and any composition as well ${(\textit{ucomp})}$ . Second, the reference count of the dominator should always be 1 or otherwise ${(\textit{subspec})}$ may not apply – that is, contexts should be used linearly. This follows indirectly from Lemma 4 where we show that our translation adheres to Minamide’s linear-type discipline. A more direct approach would be to show that Perceus never derives a ${\mathsf{dup}}$ operation for a context ${\textit{k}}$ in our translation. However, we refrain from doing so here, as it turns out that with general algebraic effect handlers, the linearity of a context may no longer be guaranteed!

7.1 Nonlinear control

A long-standing issue in a TRMc transformation is that it is unsound in the presence of non-local control operations like ${\textit{call}}$ / ${\textit{cc}}$ , ${\textit{shift}}$ / ${\textit{reset}}$ (Danvy & Filinski, Reference Danvy and Filinski1990; Sitaram & Felleisen, Reference Sitaram and Felleisen1990; Shan, Reference Shan2007), or in general with algebraic effect handlers (Plotkin & Power, Reference Plotkin and Power2003; Plotkin & Pretnar, Reference Plotkin and Pretnar2009), whenever a continuation or handler resumption can be invoked more than once. Note that if only single-shot continuations or resumptions are allowed (as in OCaml Dolan et al., Reference Dolan, White, Sivaramakrishnan, Yallop and Madhavapeddy2015) for example), the control flow is still always linear and the TRMc transformation still sound. Since the Koka language relies foundationally on general effect handlers (Leijen, Reference Leijen2017, Reference Leijen2021; Xie & Leijen, Reference Xie and Leijen2021), we need to tackle this problem. Algebraic effect handlers extend the syntax with a handle expression, ${\mathsf{handle}~\textit{h}~\textit{e}}$ , and operations, ${\mathsf{op}}$ , that are handled by a handler ${\textit{h}}$ . There are two more reduction rules (Leijen, Reference Leijen2014):

That is, when an operation is invoked it yields all the way up to the innermost handler for that operation and continues from there with the operation clause. Besides the operation argument, it also receives a resumption ${\textit{resume}}$ that allows the operation to return to the original call site with a result ${\textit{y}}$ . The culprit here is that the resumption captures the delimited evaluation context ${\mathsf{E}}$ in a lambda expression, and this can violate linearity assumptions. In particular, if we regard a TRMC context ${\textit{k}}$ as a linear value (as in Minamide), then such ${\textit{k}}$ may be in the context ${\mathsf{E}}$ of the ${(\textit{handle})}$ rule and captured in a nonlinear lambda. Whenever the operation clause calls the resumption more than once, any captured linear values may be used more than once!

A nice example in practice of this occurs in the well-known Knapsack problem as described by Wu et al. (Reference Wu, Schrijvers and Hinze2014) where they use multiple resumptions to implement a non-determinism handler:

An effectful function in Koka has three arguments where the type denotes a function from type with a potential (side) effect . The select function picks an element from a list using the operations of the effect. The knapsack function picks items from a list of item weights vs that together do not exceed the capacity w (of the knapsack). Since it calls select it has the effect and additionally it has a divergence effect. We can now provide an effect handler that systematically explores all solutions using multiple resumptions:

That is, the solutions handler implements the flip function by resuming twice and appending the results. Even though knapsack returns a single solution as a list, the test function returns a list of all possible solution lists . The knapsack function is in the modulo cons fragment and gets translated to a tail-recursive version by our translation into:

Instead of having a runtime that captures evaluation contexts ${\mathsf{E}}$ directly, Koka usually uses an explicit monadic transformation to translate effectful computations into pure lambda calculus. The effect handling is then implemented explicitly using a generic multi-prompt control monad (Xie & Leijen, Reference Xie and Leijen2020, Reference Xie and Leijen2021). This transforms our knapsack function into:

Every computation in the effect monad either returns with a result or is yielding up to a handler . As described by Xie & Leijen (Reference Xie and Leijen2021), the Koka compiler backend implements this monad as a primitive and can generate efficient C code without needing to allocate closures in the fast non-yielding path.

In our example, we inlined the monadic bind operation where the result select(vs) is explicitly matched. We see that in the case, the continuation expression (namely ) is now explicitly captured under a lambda expression – including the supposedly linear context k! This is how we can end up at runtime with a context that is shared (with a reference count > 1) and where the rule ${(\textit{ucomp})}$ should not be applied.

7.2 Dynamic copying via reference counting

Our context composition is defined in terms of context application, which in turn relies on the in-place substitution (Section 6.2.5):

\begin{align*}(\textit{subspec})~\textit{H},[\textit{H}',\textit{y} \mapsto^{1} \textit{C}~{\dots}~{{\square}}_\textit{i}~{\dots}]^1_\textit{x}~{\mid}{}\mathsf{subst}~\langle\mkern1mu{}\textit{x},\textit{y}{@}\textit{i}\mkern2mu\rangle{}~\textit{z}~~\cong{}~~\textit{H},[\textit{H}',\textit{y} \mapsto^{1} \textit{C}~{\dots}~\textit{z}~{\dots}]^1_\textit{x}~{\mid}{}\textit{x}\end{align*}

This is the operation that eventually fails if the runtime context ${\textit{x}}$ is not unique. In Section 6.2.5, the substitution operation was calculated to recursively visit the full linear chain of the context. This suggests a solution for any non-unique context: we can actually traverse the context at runtime and create a fresh copy instead.

It is not immediately clear though how to implement such operation at runtime: the linear chains up to now are just a proof technique and we cannot actually visit the elements of the chain at runtime as we do not know which field in a chain element points to the next element. What we need to do is to explicitly annotate each constructor ${\textit{C}^\textit{k}}$ (of arity ${\textit{k}}$ ) in a context also with an index ${\textit{i}}$ corresponding to the field that points to the next element, as ${\textit{C}^\textit{k}_\textit{i}}$ . It turns out, we can actually do this efficiently while constructing the context – and we can do it systematically just by modifying our fold function to keep track of this context path at construction:

With such indices present at runtime, we can define non-unique substitution as:

\begin{align*}(\textit{subapp})~\quad \textit{H},[\textit{H}']^{\textit{n}+1}_\textit{x}~{\mid}{}\mathsf{subst}~\langle\mkern1mu{}\textit{x},\textit{y}{@}\textit{i}\mkern2mu\rangle{}~\textit{z}~~\quad \cong{}~\quad \textit{H},[\textit{H}']^{\textit{n}+1}_\textit{x}~{\mid}{}\mathsf{append}~\textit{x}~\textit{z}\end{align*}

where ${\mathsf{append}}$ follows the context path at runtime copying each element as we go and eventually appending ${\textit{z}}$ at the hole:

We can show the context laws still hold for these definitions (see Appendix B.11 in the supplement). The append operation in particular can be implemented efficiently at runtime using a fast loop that updates the previous element at each iteration (essentially using manual TRMC!). In the Koka runtime system, it happens to be the case that there is already an 8-bit field index in the header of each object which is used for stackless freeing. We can thus use that field for context paths since if a context is freed it is fine to discard the context path anyways. The runtime cost of the hybrid technique is mostly due to an extra uniqueness check needed when doing context composition to see if we can safely substitute in-place (see Section 7.3). As we see in the benchmark section, this turns out to be quite fast in practice. Moreover, the Koka compiler uses static-type information when possible to avoid this check if a function is guaranteed to be used only with a linear effect type.

7.3 Efficient code generation

As an example of the code generation of our TRMC scheme, we consider the map function from our benchmarks in Section 9. The map function is specialized by the compiler for the increment function, and after the TRMC transformation we have:

Here the empty context is the Minamide tuple as a value type containing the final result and hole address, something like (invalid, null). For efficiency, we represent the empty tuple with a null address for the hole. The single-cell context is represented by the minamide tuple . Eventually, the value type is passed in registers (x19 and x21), and the generated code for arm64 becomes:

Note in particular how the header for the node in the context is set as where, from left-to-right, we initialize the tag , the context path field ( ), and the total number of fields (also ). As such, maintaining context paths comes for free since it is done as part of header initialization. Also we see the reuse of Perceus reference counting (Xie et al., Reference Xie and Leijen2021; Lorenzen & Leijen, Reference Lorenzen and Leijen2022) in action, where the node that is matched (in x0) is reused for the context node (also in x0). Since the effect inferred for the specialized map function is total, the check for uniqueness of the context is removed as it the context is guaranteed to be used lineraly.

7.4 Dynamic copying without reference counting

Lorenzen et al. (Reference Lorenzen, Leijen, Swierstra and Lindley2024) show that it is possible to support first-class constructor contexts even in languages without precise reference counts. Their proposed implementation (also suggested by Gabriel Scherer) uses a special distinguished value for a runtime hole ${{{\square}}}$ that is never used by any other object. A substitution now first checks the value at the hole: if it is a ${{{\square}}}$ value, the hole is substituted for the first time and we just overwrite the hole in-place (in constant time). However, any subsequent substitution on the same context will find some object instead of ${{{\square}}}$ . At this point, we first dynamically copy the context path (in linear time) and then update the copy in-place.

The illustration above (due to Lorenzen et al., Reference Lorenzen, Leijen, Swierstra and Lindley2024) shows a more complex example of a shared tree context that is applied to two separate nodes. The runtime context path is denoted here by bold edges. The intermediate state is interesting as it is both a valid tree, but also a part of the tree is shared with the remaining context, where the hole points to a regular node now. When that context is applied, only the context path (node 5 and 2) is copied first where all other nodes stay shared (in this case, only node 1).

However, it turns out that this simple approach is not sound without further restrictions. For general first-class contexts, the second context can be arbitrary (instead of always a constant in the TRMC case), the context composition operation c1 ++ c2 needs an extra check in order to avoid creating cycles: we check if c2 has an already overwritten hole or if the hole in c2 is at the same address as in c1. In either case, c2 is copied along the context path.

Figure 3 shows a partial implemention in C code of how one can implement constructor contexts in a runtime for languages without precise reference counting. We assume that HOLE is the distinguished value for unfilled holes ( ${{{\square}}}$ ). When we compose two contexts, we need to ensure we can handle shared contexts as well where we copy a context along the context path if needed (using ctx_copy). In the application and composition functions, the check sees if the hole in c1 is already overwritten (where *c1.hole != HOLE). In that case, we copy c1 along the context path as shown in Section 7.2 to maintain referential transparency.

Fig. 3. Implementing constructor composition and application in the runtime system (for languages without precise reference counts).

However, in the composition operation we also need to do a similar check for c2 as well in order to avoid cycles: the second check checks if c2 has an already overwritten hole, but also if the hole in c2 is the same as in c1. In either case, c2 is copied along the context path. Effectively, both checks ensure that the new context that is returned always ends with a single fresh HOLE. Let’s consider some examples of shared contexts. A basic example is a simple shared context, as in:

which evaluates to . Here, during the second application, check ensures the shared context c is copied such that the list stays unaffected.

A more tricky example is composing a context with itself:

which evaluates to . The check here copies the appended c (since c1.hole == c2.hole). In this example, the potential for a cycle is immediate, but generally it can be obscured with a shared context inside another. Consider:

which evaluates to . The check again copies the appended c2 in c ++ c2 (since *c2.hole != HOLE).

Note that the (B) check in composition is sufficient to avoid cycles. In order to create a cycle in the context path, either c1 must be in the context path of c2 (I), or the c2 in the context path of c1 (II). For case (I), if c1 is at the end of c2, then their holes are at the same address where c1.hole == c2.hole. Otherwise, if c1 is not at the end, then *c1.hole != HOLE and we have copied c1 already due to check (A). For case (II) the argument is similar: if c2 is at the end of c1 we again have c1.hole == c2.hole, and otherwise *c2.hole != HOLE.

The implementation using precise reference counting is not very different from the one without reference counting. The main difference is in the checks (A) and (B), which become:

This is the implementation that is used in the Koka runtime system. The (B) check here is required to maintain the invariant that context paths always form unique chains (Section 7.2). From this property, it follows directly that no cycles can occur in the context path.

7.5 Runtime behavior

Interestingly, the two implementations, with or without precise reference counting, do differ in their runtime performance characteristics, which are dual to each other in terms of space and time.

7.5.1 Time

The implementation without reference counting only copies on demand when the hole is already filled, whereas our earlier implementation with reference counts copies whenever the context is found to be not unique upon filling the hole. The latter can be a problem if the context is later discarded without being used. Consider the knapsack program, which in its last iteration may call itself on a one-element list [x] with . For this special case, the code reduces to:

This computation is run twice, where the first run successfully returns k ++. but the second run fails. The reference counting-based implementation has to copy k in the first run, since its reference count is not one (due to k being captured for the second run). In contrast, assuming that the hole in k is not yet filled, the new implementation can simply fill the hole of k with in the first run without copying. Since k is discarded in the second run, no copying is needed at all. We will come back to this point in Section 9, where we see that the reference counting implementation in Koka does not perform well in a backtracking search, presumably due to this issue.

7.5.2 Space

The implementation without precise reference counts can use more space though than the one based on reference counting. This can occur when a context accidentally holds on to values that have been written into its hole. Consider an earlier state of the knapsack program, where it may process a list . Then we can simplify the code to:

Following the flip(), we first try to use v as our element. But since v > w, this computation fails and we backtrack. However, our new algorithm may have written into the hole of k. This value is now garbage, but this may not be obvious to a garbage collector or reference counting scheme, since k is still live. Only when backtracking to the second run do we copy k and discard the old value.

In contrast, the implementation based on reference counting would have copied (and discarded) k in the first run already. Unlike the new implementation, it is garbage-free (Xie et al., Reference Xie and Leijen2021) and guarantees that no space is used for values that are no longer needed. For this reason, we prefer the implementation via reference counting in Koka, using the other implementation for GC-based languages.

8.1 Modulo cons products

The partition function calls a predicate on each element of a list and appends it to one of two piles depending on the result:

The recursive call to partition is followed by a pattern match on the resulting tuple, an if-statement and finally the constructor application. This does not fit the TRMc transformation directly, but it also might not seem too different – and indeed this function was suggested as fruitful target for an expanded TRMC translation both by Bour et al. (Reference Bour, Clément and Scherer2021) and the conference version of this paper.

However, in order to make this function tail-recursive, the p(x) call would have to be moved before the recursive call. That can be done by a compiler if p is pure, but what if p may perform side effects? Thus, even an extended TRMc transformation could only apply if the user first rewrote their code to:

The conference version of this paper describes a transformation that recognizes that the pattern match on the returned tuple is mirrored in the creation of a new tuple and looks for constructor contexts inside the created tuple.

However, it may not be worth implementing such specific transformation as we can easily rewrite it manually using two explicit first-class constructor contexts for yes and no:

The resulting code is clearer than the version with an explicit ok variable, and not just more efficient but arguably even clearer than the original version. For this reason, we now recommend that programmers use first-class constructor contexts directly for examples like this.

8.2 Difference lists

Another example of future work described by Bour et al. (Reference Bour, Clément and Scherer2021) is the flatten function. This function calls itself recursively and passes the result to the append function on lists:

While append is tail-recursive modulo cons, flatten is not. However, append is just a sequence of constructor applications ending in the second argument, and we can easily rewrite it using a first-class constructor context returned from append (i.e., a difference list):

8.3 Composing constructor contexts

Another example which illustrates the usefulness of first-class conntexts that can be stored in data structures is the composition of constructor contexts with defunctionalized evaluation contexts. While constructor contexts naturally apply to the map over a list, they do not apply directly to a map over trees:

Here, the first recursive call to tmap is not in a constructor context and thus the TRMc transformation alone is not enough to make this tail-recursive. However, instead of resorting to full defunctionalized evaluation contexts, we can use them only for descending into the left child and keep using constructor contexts to descend into the right branch:

This function immediately follows from the technique described in Section 5.3. It extends the acc accumulator whenever it goes into the left subtree and extends the top accumulator whenever it goes into the right subtree. While a version using only defunctionalized evaluation contexts corresponds to pointer reversal (Schorr & Waite, Reference Schorr and Waite1967), this version reverses only the pointers going to the right child, but leaves the pointers to the left child intact.

8.4 Polymorphic recursion

In this paper, we have limited ourselves to recursive functions where each recursive call has the same return type. However, there are some functions where the recursive call might have a different return type due to polymorphic recursion. For example, Okasaki (Reference Okasaki1999) presents the following random access list:

Here the recursive call instantiates with , and the hole in has type . It turns out that for polymorphically recursive code, performing the translation can lead to code that is not typeable is System F. This issue is well known for defunctionalized evaluation contexts, where GADTs are required to regain typability (Pottier & Gauthier, Reference Pottier and Gauthier2004). Analogously, we give two type parameters to first-class constructor contexts where a corresponds to the type of the root and b to the type of the hole. Our primitive operations have the general types:

It turns out that this encapsulates the necessary type information to type the result of the translation for polymorphic recursion. Even though Koka has an intermediate core representation based on System F, the application and composition functions are primitives and Koka transforms the above function without problems. Our cons function is translated to:

8.5 Multiple holes

A limitation of our current approach is that we do not support multiple holes in a constructor context. For example, consider the following function which builds a perfectly balanced binary tree of height n:

This function cannot directly be made tail-recursive with our current approach. The issue is that the value t occurs twice in the constructor. This means that we would need our context to have two holes instead of one. But the compact representation of our context paths makes it impossible to fork the path, which means that we can only support copying for single-hole contexts. When constructor contexts are only used linearly and never copied, it is possible to support multiple holes directly (Bagrel, Reference Bagrel2024).

8.6 TRMC as a source-to-source transformation

Since the introduction of first-class constructor contexts to the language, the TRMc transformation has become source-to-source. This means that there is no longer a direct reason for compiler writers to support TRMc directly as long as first-class contexts are supported, since the latter allow programmers to recreate the effects of the TRMc transformation manually.

Naturally, this raises the question of which parts of the transformation a compiler should handle automatically. In Koka, we currently support the TRMc transformation to ensure that the naive version of map is automatically optimized. However, we do not implement all extensions that are possible. For example, we have not implemented the extension proposed in Section 7.1 of the conference version of this paper since first-class constructor contexts make it easily possible to derive it manually. Furthermore, we do not implement an automatic translation for other kinds of contexts like the ones proposed in Section 4.

One choice for future compiler writers would be to automatically apply exactly those contexts for which benchmarks indicate that they always improve performance. This seems to be the case for constructor contexts and semiring contexts (which are also supported by GCC, see Section 4.4). However, traditional CPS and defunctionalized contexts tend to decrease performance. It can be valuable to use contexts that decrease performance since they still protect against stack overflows, but this should only be done for those functions that actually present a risk of causing a stack overflow.

Another option would be to let users make the choice on which functions should be transformed and with which context. Possible contexts might either be baked into the language or even declared directly by users. In Section 5, we describe how several contexts can be composed so that the compiler can achieve tail-recursive functions where some of the calls are eliminated using more performant contexts than other calls.

Finally, another sensible option would be to perform no TRMC pass in the compiler at all and instead leave the transformation completely to programmers. We believe that the implementations using an explicit accumulator presented in this section are often similar in clarity to direct-style implementations and it would not be infeasible to simply perform the TRMC transformation by hand where required. In return, the language enjoys simpler semantics and there is a smaller implementation burden in the compiler.