3.1 Programming with streams and events

To illustrate how

\begin{equation*}\mathsf{Rattus}\end{equation*}

facilitates working with streams and events, we have implemented a small set of combinators, as shown in Figure 1. The $\textit{map}$ function should be familiar by now. The $\textit{zip}$ function combines two streams similarly to Haskell’s $\textit{zip}$ function defined on lists. Note however that instead of the normal pair type, we use a strict pair type:

\begin{equation*} \mathbf{data}\;a\otimes b= ! a\otimes\mathbin{!} b \end{equation*}

Fig. 1. Small library for streams and events.

It is like the normal pair type (a,b), but when constructing a strict pair ${s\otimes t}$ , the two components s and t are evaluated to weak head normal form.

The $\textit{scan}$ function is similar to Haskell’s $\textit{scanl}$ function on lists: given a stream of values $\textit{v}_{{\rm 0}},v_{1},v_{2},\ldots$ , the expression $\textit{scan}\;(\mathsf{box}\;f)\;{v}$ computes the stream

\begin{equation*} f\;\textit{v}\;\textit{v}_{\mathrm{0}},\quad {f\;(f\;\textit{v}\;\textit{v}_{\mathrm{0}})\;\textit{v}_{1},}\quad {f\;(f\;(f\;\textit{v}\;\textit{v}_{\mathrm{0}})\;\textit{v}_{1})\;\textit{v}_{\mathrm{2}},}\quad\ldots \end{equation*}

If one would want a variant of $\textit{scan}$ that is closer to Haskell’s $\textit{scanl}$ , that is, the result starts with the value v instead of ${f\;v\;v_{0}}$ , one can simply replace the first occurrence of $\textit{acc}'$ in the definition of $\textit{scan}$ with $\textit{acc}$ . Note that the type b has to be stable in the definition of $\textit{scan}$ so that $\textit{acc}'::b$ is still in scope under $\mathsf{delay}$ .

A central component of FRP is that it must provide a way to react to events. In particular, it must support the ability to switch behaviour in response to the occurrence of an event. There are different ways to represent events. The simplest representation defines events of type a as streams of type $\textit{Maybe}\;a$ . However, we will use the strict variant of the ${\textit{Maybe}}$ type:

\begin{equation*} \mathbf{data}\;\textit{Maybe}'\;a=\textit{Just}'{!}\! a\mid \textit{Nothing}' \end{equation*}

We can then devise a simple ${\textit{switch}}$ combinator that reacts to events. Given an initial stream xs and an event e that may produce a stream, swith xs e initially behaves as xs but changes to the new stream provided by the occurrence of an event. In this implementation, the behaviour changes every time an event occurs, not only the first time. For a one-shot variant of ${\textit{switch}}$ , we would just have to change the second equation to

In the definition of ${\textit{switch}}$ , we use the applicative operator

${\mathop{\circledast}}$ defined as follows:

\begin{align*} (\mathop{\circledast})::\bigcirc(a\to b)\to \bigcirc a\to \bigcirc b\\ f\mathop{\circledast}x=\mathsf{delay}\;((\mathsf{adv}\;f)\;(\mathsf{adv}\;x)) \end{align*}

Instead of using ${\mathop{\circledast}}$ , we could have also written ${\mathsf{delay}\;(\textit{switch}\;(\mathsf{adv}\;xs)\;(\mathsf{adv}\;\textit{fas}))}$ instead.

Finally, ${\textit{switchTrans}}$ is a variant of ${\textit{switch}}$ that switches to a new stream function rather than just a stream. It is implemented using the variant $\textit{switchTrans}'$ , which takes just a stream as its first argument instead of a stream function.

3.2 A simple reactive program

To put our bare-bones FRP library to use, let’s implement a simple single-player variant of the classic game Pong: the player has to move a paddle at the bottom of the screen to bounce a ball and prevent it from falling. ^{Footnote 2} The core behaviour is described by the following stream function:

It receives a stream of inputs (button presses and how much time has passed since the last input) and produces a stream of pairs consisting of the 2D position of the ball and the x coordinate of the paddle. Its implementation uses two helper functions to compute these two components. The position of the paddle only depends on the input, whereas the position of the ball also depends on the position of the paddle (since it may bounce off it):

Both auxiliary functions follow the same structure. They use a $\textit{scan}$ to compute the position and the velocity of the object, while consuming the input stream. The velocity is only needed to compute the position and is therefore projected away afterward using $\textit{map}$ . Here, ${\textit{fst}'}$ is the first projection for the strict pair type. We can see that the ball starts at the centre of the screen (at coordinates (0,0)) and moves toward the upper right corner (with velocity (20,50)).

This simple game only requires a static dataflow network. To demonstrate the ability to express dynamically changing dataflow networks in $\mathsf{Rattus}$ , we briefly discuss three refinements of the pong game, each of which introduces different kinds of dynamic behaviours. In each case, we reuse the existing stream functions that describe the basic behaviour of the ball and the paddle, but we combine them using different combinators. Thus, these examples also demonstrate the modularity that $\mathsf{Rattus}$ affords.

First refinement.

We change the implementation of $\textit{pong}$ so that it allows the player to reset the game, for example, after the ball has fallen off the screen:

To achieve this behaviour, we use the ${\textit{switchTrans}}$ combinator, which we initialise with the original behaviour of the ball. The event that will trigger the switch is constructed by mapping ${\textit{ballTrig}}$ over the input stream, which will create an event of type ${\textit{Event}\;(\textit{Str}\;(\textit{Float}\otimes\textit{Input})\to \textit{Str}\;\textit{Pos})}$ , which will be triggered every time the player hits the reset button.

Second refinement.

^{Footnote 3} We can further refine this behaviour of the game so that it automatically resets once the ball has fallen off the screen. This requires a feedback loop since the behaviour of the ball depends on the current position of the ball. Such a feedback loop can be constructed using a variant of the ${\textit{switchTrans}}$ combinator that takes a delayed event as argument:

\begin{equation*} \textit{dswitchTrans}::(\textit{Str}\;a\to \textit{Str}\;b)\to \bigcirc (\textit{Event}\;(\textit{Str}\;a\to \textit{Str}\;b))\to (\textit{Str}\;a\to \textit{Str}\;b) \end{equation*}

Thus, the event we pass on to ${\textit{dswitchTrans}}$ can be constructed from the output of ${\textit{dswitchTrans}}$ by using guarded recursion, which closes the feedback loop:

Final refinement.

^{Footnote 4} Finally, we change the game a bit so as to allow the player to spawn new balls at any time and remove balls that are currently in play. To this end, we introduce a type ${\textit{ObjAction}\;a\;b}$ that represents events that may remove or add objects defined by a stream function of type ${\textit{Str}\;a\to \textit{Str}\;b}$ :

\begin{equation*} \mathbf{data}\;\textit{ObjAction}\;a\;b=\textit{Remove}\mid \textit{Add}!\!(\textit{Str}\;a\to \textit{Str}\;b) \end{equation*}

To keep it simple, we only have two operations: we may add an object by giving its stream function, or we may remove the oldest object. Given the strict list type

\begin{equation*} \mathbf{data}\;\textit{List}\;a=\textit{Nil}\mid \textit{Cons}!\!a!\!(\textit{List}\;a) \end{equation*}

we can implement a combinator that can react to such events:

\begin{equation*} \textit{objTrans}::\textit{Event}\;(\textit{ObjAction}\;a\;b)\to \textit{List}\;(\textit{Str}\;b)\to \textit{Str}\;a\to \textit{Str}\;(\textit{List}\;b) \end{equation*}

This combinator takes three arguments: an event that may trigger operations to manipulate the list of active objects, the initial list of active objects, and the input stream. The result is a stream that at each step contains a list with the current value of each active object.

To use this combinator, we revise the ${\textit{ballTrig}}$ function so that it produces events to add or remove balls in response to input by the player, and we initialise the list of objects as the empty list:

Instead of a stream of type ${\textit{Str}\;\textit{Pos}}$ to describe a single ball, we now have a stream of type ${\textit{Str}\;(\textit{List}\;\textit{Pos})}$ to describe multiple balls.

The ${\textit{objTrans}}$ combinator demonstrates that $\mathsf{Rattus}$ can accommodate dataflow networks that dynamically grow and shrink. But more realistic variants of this combinator can be implemented as well. For example, by replacing ${\textit{List}}$ with a ${\textit{Map}}$ data structure, objects may have identifiers and can be removed or manipulated based on that identifier. Orthogonal to that, we may also allow objects to destroy themselves and spawn new objects. This can be achieved by describing objects using trees instead of streams:

\begin{equation*} \mathbf{data}\;\textit{Tree}\;a=\textit{End}\mid \textit{Next}!\!a!\!(\bigcirc (\textit{Tree}\;a))\mid \textit{Branch}!\!a!\!(\bigcirc (\textit{Tree}\;a))!\!(\bigcirc (\textit{Tree}\;a)) \end{equation*}

A variant of ${\textit{objTrans}}$ can then be implemented where the type ${\textit{Str}\;b}$ in ${\textit{objTrans}}$ and ${\textit{ObjAction}\;a\;b}$ is replaced by ${\textit{Tree}\;b}$ . For example, this can be used in the pong game to make balls destroy themselves once they disappear from screen or make a ball split into two balls when it hits a certain surface.

3.3 Arrowised FRP

The benefit of a modal FRP language is that we can directly interact with signals and events in a way that guarantees causality. A popular alternative to ensure causality is arrowised FRP (Nilsson et al., Reference Nilsson, Courtney and Peterson2002), which takes signal functions as primitive and uses Haskell’s arrow notation (Paterson, Reference Paterson2001) to construct them. By implementing an arrowised FRP library in $\mathsf{Rattus}$ instead of plain Haskell, we can not only guarantee causality but also productivity and the absence of implicit space leaks. As we will see, this forces us to slightly restrict the API of arrowised FRP compared to Yampa. Furthermore, this exercise demonstrates that $\mathsf{Rattus}$ can also be used to implement a continuous-time FRP library, in contrast to the discrete-time FRP library from Section 3.1.

At the centre of arrowised FRP is the ${\textit{Arrow}}$ type class shown in Figure 2. If we can implement a signal function type ${\textit{SF}\;a\;b}$ that implements the ${\textit{Arrow}}$ class, we can benefit from the convenient notation Haskell provides for it. For example, assuming we have signal functions ${\textit{ballPos}::\textit{SF}\;(\textit{Float}\otimes\textit{Input})\;\textit{Pos}}$ and padPos::SF Input Float describing the positions of the ball and the paddle from our game in Section 3.2, we can combine these as follows:

Fig. 2. Arrow type class.

The $\mathsf{Rattus}$ definition of ${\textit{SF}}$ is almost identical to the original Haskell definition from Nilsson et al. (Reference Nilsson, Courtney and Peterson2002). The only difference is the use of strict types and the insertion of the $\bigcirc$ modality to make it a guarded recursive type:

\begin{equation*} \mathbf{data}\;\textit{SF}\;a\;b=\textit{SF}!(\textit{Float}\to a\to (\bigcirc (\textit{SF}\;a\;b)\otimes b)) \end{equation*}

This implements a continuous-time signal function using sampling, where the additional argument of type ${\textit{Float}}$ indicates the time passed since the previous sample.

Implementing the methods of the ${\textit{Arrow}}$ type class is straightforward with the exception of the ${\textit{arr}}$ method. In fact, we cannot implement ${\textit{arr}}$ in $\mathsf{Rattus}$ at all. Because the first argument is not stable, it falls out of scope in the recursive call:

The situation is similar to the $\textit{map}$ function, and we must box the function argument so that it remains available at all times in the future:

That is, the ${\textit{arr}}$ method could be a potential source for space leaks. However, in practice, ${\textit{arr}}$ does not seem to cause space leaks and thus its use in conventional arrowised FRP libraries should be safe. Nonetheless, in $\mathsf{Rattus}$ , we have to replace ${\textit{arr}}$ with the more restrictive variant ${\textit{arrBox}}$ . But fortunately, this does not prevent us from using the arrow notation: $\mathsf{Rattus}$ treats ${\textit{arr}\;f}$ as a short hand for ${\textit{arrBox}\;(\mathsf{box}\;f)}$ , which allows us to use the arrow notation while making sure that ${\mathsf{box}\;f}$ is well-typed, that is, f only refers to variables of stable type.

The ${\textit{Arrow}}$ type class only provides a basic interface for constructing static signal functions. To permit dynamic behaviour, we need to provide additional combinators, for example, for switching signals and for recursive definitions. The ${\textit{rSwitch}}$ combinator corresponds to the ${\textit{switchTrans}}$ combinator from Figure 1:

\begin{equation*} \textit{rSwitch}::\textit{SF}\;a\;b\to \textit{SF}\;(a\otimes\textit{Maybe'}\;(\textit{SF}\;a\;b))\;b \end{equation*}

This combinator allows us to implement our game so that it resets to its start position if we hit the reset button: ^{Footnote 5}

Arrows can be endowed with a very general recursion principle by instantiating the $\textit{loop}$ method in the ${\textit{ArrowLoop}}$ type class shown in Figure 2. However, $\textit{loop}$ cannot be implemented in $\mathsf{Rattus}$ as it would break the productivity property. Moreover, $\textit{loop}$ depends crucially on lazy evaluation and is thus a source for space leaks.

Instead of $\textit{loop}$ , we implement a different recursion principle that corresponds to guarded recursion:

\begin{equation*} \textit{loopPre}::\textit{d}\to \textit{SF}\;(b\otimes\textit{d})\;(\textit{c}\otimes\bigcirc \textit{d})\to \textit{SF}\;b\;\textit{c} \end{equation*}

Intuitively speaking, this combinator constructs a signal function from b to c with the help of an internal state of type d. The first argument initialises the state, and the second argument is a signal function that turns input of type b into output of type c while also updating the internal state. Apart from the addition of the $\bigcirc$ modality and strict pair types, this definition has the same type as Yampa’s ${\textit{loopPre}}$ . Alternatively, we could drop the $\bigcirc$ modality and constrain d to be stable. The use of ${\textit{loopPre}}$ instead of $\textit{loop}$ introduce a delay by one sampling step (as indicated by the $\bigcirc$ modality) and thus ensures productivity. However, in practice, such a delay can be avoided by refactoring the underlying signal function.

Using the ${\textit{loopPre}}$ combinator, we can implement the signal function of the ball:

Here, we also use the ${\textit{integral}}$ combinator that computes the integral of a signal using a simple approximation that sums up rectangles under the curve:

\begin{equation*} \textit{integral}::(\textit{Stable}\;a,\textit{VectorSpace}\;a\;\textit{s})\Rightarrow a\to \textit{SF}\;a\;a \end{equation*}

The signal function for the paddle can be implemented in a similar fashion. The complete code of the case studies presented in this section can be found in the supplementary material.

4.1 Type system

Figure 3 defines the syntax of $\lambda_{\checkmark\!\!\checkmark}$ . Besides guarded recursive types, guarded fixed points, and the two type modalities, we include standard sum and product types along with unit and integer types. The type ${\textit{Str}\;\textit{A}}$ of streams of type A is represented as the guarded recursive type $\mathsf{Fix}\,\alpha. A \times \alpha$ . Note the absence of $\bigcirc $ in this type. When unfolding guarded recursive types such as $\mathsf{Fix}\,\alpha. A \times \alpha$ , the $\bigcirc$ modality is inserted implicitly: $\mathsf{Fix}\,\alpha . A \times \alpha \cong A \times \bigcirc (\mathsf{Fix}\,\alpha. A \times \alpha)$ . This ensures that guarded recursive types are by construction always guarded by the $\bigcirc$ modality.

Fig. 3. Syntax of (stable) types, terms, and values. In typing rules, only closed types are considered (i.e., each occurrence of a type variable $\alpha$ is in the scope of a $\mathsf{Fix}\,\alpha$ ).

For the sake of the operational semantics, the syntax also includes heap locations 1. However, as we shall see, heap locations cannot be used by the programmer directly, because there is no typing rule for them. Instead, heap locations are allocated and returned by $\mathsf{delay}$ in the operational semantics. This is a standard approach for languages with references (see e.g., Abramsky et al. (Reference Abramsky, Honda and McCusker1998); Krishnaswami (Reference Krishnaswami2013)).

Typing contexts, defined in Figure 4, consist of variable typings $x:A$ and $\checkmark$ tokens. If a typing context contains no $\checkmark$ , we call it tick-free. The complete set of typing rules for $\lambda_{\checkmark\!\!\checkmark}$ is given in Figure 5. The typing rules for $\mathsf{Rattus}$ presented in Section 2 appear in the same form also here, except for replacing Haskell’s :: operator with the more standard notation. The remaining typing rules are entirely standard, except for the typing rule for the guarded fixed point combinator $\mathsf{fix}$ .

Fig. 4. Well-formed contexts.

Fig. 5. Typing rules.

The typing rule for $\mathsf{fix}$ follows Nakano’s fixed point combinator and ensures that the calculus is productive. In addition, following Krishnaswami (Reference Krishnaswami2013), the rule enforces the body t of the fixed point to be stable by strengthening the typing context to $\Gamma^{\square}$ . Moreover, we follow Bahr et al. (Reference Bahr, Graulund and Møgelberg2021) and assume x to be of type ${\square(\bigcirc \textit{A})}$ instead of ${\bigcirc \textit{A}}$ . As a consequence, recursive calls may occur at any time in the future, that is, not necessarily in the very next time step. In conjunction with the more general typing rule for $\mathsf{delay}$ , this allows us to write recursive function definitions that, like $\textit{stutter}$ in Section 2.2, look several steps into the future.

To see how the recursion syntax of $\mathsf{Rattus}$ translates into the fixed point combinator of $\lambda_{\checkmark\!\!\checkmark}$ , let us reconsider the $\textit{constInt}$ function:

For readability of the corresponding $\lambda_{\checkmark\!\!\checkmark}$ term, we use the shorthand $s ::: t$ for the $\lambda_{\checkmark\!\!\checkmark}$ term $\mathsf{into} \langle{s}{t}\rangle$ . Recall that ${\textit{Str}\;\textit{A}}$ is represented as $\mathsf{Fix}\,\alpha. A \times \alpha$ in $\lambda_{\checkmark\!\!\checkmark}$ . That is, given $s : A$ and $t : \bigcirc ({\textit{Str}\;\textit{A}})$ , we have that $s ::: t$ is of type ${\textit{Str}\;\textit{A}}$ . Using this notation, the above definition translates into the following $\lambda_{\checkmark\!\!\checkmark}$ term:

\begin{equation*} \mathit{constInt} = \mathsf{fix}\, r. \lambda x . x ::: \mathsf{delay} (\mathsf{adv}\, (\mathsf{unbox}\, r)\,x) \end{equation*}

The recursive notation is simply translated into a fixed point $\mathsf{Fix}\,r. t$ where the recursive occurrence of $\textit{constInt}$ is replaced by ${\mathsf{adv}\;(\mathsf{unbox}\;\textit{r})}$ . The variable r is of type ${\square(\bigcirc (\textit{Int}\to \textit{Str}\;\textit{Int}))}$ and applying $\mathsf{unbox}$ followed by $\mathsf{adv}$ turns it into type ${\textit{Int}\to \textit{Str}\;\textit{Int}}$ . Moreover, the restriction that recursive calls must occur in a context with $\checkmark$ makes sure that this transformation from recursion notation to fixed point combinator results in a well-typed $\lambda_{\checkmark\!\!\checkmark}$ term.

The typing rule for $\mathsf{fix}\,x. t$ also explains the treatment of recursive definitions that are nested inside a top-level definition. The typing context $\Gamma$ is turned into $\Gamma^{\square}$ when type-checking the body t of the fixed point.

For example, reconsider the following ill-typed definition of ${\textit{leakyMap}}:$

Translated into $\lambda_{\checkmark\!\!\checkmark}$ , the definition looks like this:

\begin{align*} \mathit{leakyMap} = \lambda f. \mathsf{fix}\, r. \lambda s. &\mathsf{let}\, x = \mathsf{head}\,s\;\mathsf{in}\,\mathsf{let}\,xs = \mathsf{tail}\, s\\ &\mathsf{in}\;{\color{red}f}\, x ::: \mathsf{delay} ((\mathsf{adv}\, (\mathsf{unbox}\,r))\,(\mathsf{adv}\,xs)) \end{align*}

The pattern matching syntax is translated into projection functions $\mathsf{head}$ and $\mathsf{tail}$ that decompose a stream into its head and tail, respectively, that is,

\begin{equation*} \mathsf{head} = \lambda x . \pi_1\,(\mathsf{out}\,x) \qquad \mathsf{tail} = \lambda x . \pi_2\,(\mathsf{out}\,x) \end{equation*}

More importantly, the variable f bound by the outer lambda abstraction is of a function type and thus not stable. Therefore, it is not in scope in the body of the fixed point.

4.2 Operational semantics

The operational semantics is given in two steps: to execute a $\lambda_{\checkmark\!\!\checkmark}$ program, it is first translated into a more restrictive variant of $\lambda_{\checkmark\!\!\checkmark}$ , which we call $\lambda_{\checkmark}$ . The resulting $\lambda_{\checkmark}$ program is then executed using an abstract machine that ensures the absence of implicit space leaks by construction. By presenting the operational semantics in two stages, we avoid the more complicated set-up of an abstract machine that is capable of directly executing $\lambda_{\checkmark\!\!\checkmark}$ programs. As we show in the example in Section 4.3.3, such a machine would need to perform some restricted form of partial evaluation under $\mathsf{delay}$ and under lambda abstractions.

4.2.1 Translation to $\lambda_{\checkmark}$

The $\lambda_{\checkmark}$ calculus has the same syntax as $\lambda_{\checkmark\!\!\checkmark}$ , but the former has a more restrictive type system. It restricts typing contexts to contain at most one $\checkmark$ and restricts the typing rules for lambda abstraction and $\mathsf{delay}$ as follows:

The construction $\vert{\Gamma}\vert$ turns $\Gamma$ into a tick-free context, which ensures that we have at most one $\checkmark$ – even for nested occurrences of $\mathsf{delay}$ – and that the body of a lambda abstraction is not in the scope of a $\checkmark$ . All other typing rules are the same as for $\lambda_{\checkmark\!\!\checkmark}$ . The $\lambda_{\checkmark}$ calculus is a fragment of the $\lambda_{\checkmark\!\!\checkmark}$ calculus in the sense that $\Gamma\vdash_{\!\checkmark}{t}{A}$ implies $\Gamma\vdash_{\!\checkmark}{t}{A}$ .

Any closed $\lambda_{\checkmark\!\!\checkmark}$ term can be translated into a corresponding $\lambda_{\checkmark}$ term by exhaustively applying the following rewrite rules:

where K is a term with a single hole that does not occur in the scope of $\mathsf{delay}$ , $\mathsf{adv}$ , $\mathsf{box}$ , $\mathsf{fix}$ , or lambda abstraction; and K[t] is the term obtained from K by replacing its hole with the term t.

For example, consider the closed $\lambda_{\checkmark\!\!\checkmark}$ term $\lambda f.\mathsf{delay}(\lambda x. \mathsf{adv}\,(\mathsf{unbox}\,f)\, (x+1))$ of type $\square\bigcirc ({\rm Int} \to {\rm Int}) \to \bigcirc ({\rm Int} \to {\rm Int})$ . Applying the second rewrite rule followed by the first rewrite rule, this term rewrites to a $\lambda_{\checkmark}$ term of the same type as follows:

\begin{align*} &\lambda f.\mathsf{delay}(\lambda x. \mathsf{adv} \,(\mathsf{unbox}\,f)\, (x+1))\\ \to\ & \lambda f.\mathsf{delay}({\rm let}\, y {\mathsf{adv}\, (\mathsf{unbox}\,f)} {\lambda x. y\, (x+1)})\\ \to\ & \lambda f.{\rm let}\, z {\mathsf{unbox}\,f}{\mathsf{delay}({\rm let}\, y {\mathsf{adv}\, z} {\lambda x. y\, (x+1)})} \end{align*}

In a well-typed $\lambda_{\checkmark\!\!\checkmark}$ term, each subterm $\mathsf{adv}\,t$ must occur in the scope of a corresponding $\mathsf{delay}$ . The above rewrite rules make sure that the subterm t is evaluated before the $\mathsf{delay}$ . This corresponds to the intuition that $\mathsf{delay}$ moves ahead in time and $\mathsf{adv}$ moves back in time – thus the two cancel out one another.

One can show that the rewrite rules are strongly normalising and type-preserving (in $\lambda_{\checkmark\!\!\checkmark}$ ). Moreover, any closed term in $\lambda_{\checkmark\!\!\checkmark}$ that cannot be further rewritten is also well-typed in $\lambda_{\checkmark}$ . As a consequence, we can exhaustively apply the rewrite rules to a closed term of $\lambda_{\checkmark\!\!\checkmark}$ to transform it into a closed term of $\lambda_{\checkmark}$ :

Theorem 4.1 For each $\vdash_{\checkmark\!\!\checkmark}\,{t}:{A}$ , we can effectively construct a term t’ with $t \to^* t'$ and $\vdash_{\!\checkmark}{t'}:{A}$ .

Below we give a brief overview of the three components of the proof of Theorem 4.1. For the full proof, we refer the reader to Appendix A.

Strong normalisation.

To show that $\to$ is strongly normalising, we define for each term t a natural number d(t) such that, whenever $t \to t'$ , then $d(t) > d(t')$ . We define d(t) to be the sum of the depth of all redex occurrences in t (i.e., subterms that match the left-hand side of a rewrite rule). Since each rewrite step $t \to t'$ removes a redex or replaces a redex with a new redex at a strictly smaller depth, we have that $d(t) > d(t')$ .

Subject reduction.

We want to prove that $\Gamma\vdash_{\!\!\checkmark\!\!\checkmark}\,s:A$ and $s \to t$ implies $\Gamma\vdash_{\!\!\checkmark\!\!\checkmark}\,t:A$ . To this end, we proceed by induction on $s \to t$ . In case the reduction $s \longrightarrow t$ is due to congruence closure, $\Gamma\vdash_{\!\!\checkmark\!\!\checkmark}\,t:A$ follows immediately by the induction hypothesis. Otherwise, s matches the left-hand side of one of the rewrite rules. Each of these two cases follows from the induction hypothesis and one of the following two properties:

1. (1) If $\Gamma,\checkmark,\Gamma'\vdash_{\!\!\checkmark\!\!\checkmark}{K[\mathsf{adv}\,t]}{A}$ and $\Gamma'$ tick-free, then $\Gamma\vdash_{\!\!\checkmark\!\!\checkmark}\,t{\bigcirc B}$ and $\Gamma,x:\bigcirc B, \checkmark,\Gamma'\vdash_{\!\!\checkmark\!\!\checkmark}{K[\mathsf{adv}\,x]}{A}$ for some B.

2. (2) If $\Gamma, \Gamma'\vdash_{\!\!\checkmark\!\!\checkmark}{K[\mathsf{adv}\,t]}:{A}$ and $\Gamma'$ tick-free, then $\Gamma\vdash_{\!\!\checkmark\!\!\checkmark}\mathsf{adv}\,t:B$ and $\Gamma,x : B,\Gamma'\vdash_{\!\!\checkmark\!\!\checkmark}{K[x]}:{A}$ for some B.

Both properties can be proved by a straightforward induction on K. The proofs rely on the fact that due to the typing rule for $\mathsf{adv}$ , we know that if $\Gamma, \Gamma'\vdash_{\!\!\checkmark\!\!\checkmark}{K[\mathsf{adv}\,t]}:{A}$ for a tick-free $\Gamma'$ , then all of t’s free variables must be in $\Gamma$ .

Exhaustiveness.

Finally, we need to show that $\vdash_{\!\!\checkmark\!\!\checkmark}t:A$ with implies $\vdash_{\!\checkmark}{t}:{A}$ , that is, if we cannot rewrite t any further it must be typable in $\lambda_{\checkmark}$ as well. In order to prove this property by induction, we must generalise it to open terms: if $\Gamma\vdash_{\!\!\checkmark\!\!\checkmark}{t}:{A}$ for a context $\Gamma$ with at most one tick and , then ${\Gamma}\vdash_{\!\checkmark}{t}:{A}$ . We prove this implication by induction on t and a case distinction on the last typing rule in the derivation of ${\Gamma}\vdash_{\!\checkmark}{t}:{A}$ . For almost all cases, ${\Gamma}\vdash_{\!\checkmark}{t}:{A}$ follows from the induction hypothesis since we find a corresponding typing rule in $\lambda_{\checkmark}$ that is either the same as in $\lambda_{\checkmark\!\!\checkmark}$ or has a side condition is satisfied by our assumption that $\Gamma$ have at most one tick. We are thus left with two interesting cases: the typing rules for $\mathsf{delay}$ and lambda abstraction, given that $\Gamma$ contains exactly one tick (the zero-tick cases are trivial). Each of these two cases follows from the induction hypothesis and one of the following two properties:

1. (1) If ${\Gamma_1,\checkmark,\Gamma_2}\vdash_{\checkmark\!\!\checkmark}{t}:{A}$ , $\Gamma_2$ contains a tick, and , then $\Gamma_1^\square,\Gamma_2\vdash_{\checkmark\!\!\checkmark}{t}:{A}$ .

2. (2) If $\Gamma_1,\checkmark,\Gamma_2\vdash{t}:{A}$ and , then $\Gamma_1^\square,\Gamma_2\vdash_{\checkmark}{t}:{A}$ .

Both properties can be proved by a straightforward induction on the typing derivation. The proof of (1) uses the fact that t cannot have nested occurrences of $\mathsf{adv}$ and thus any occurrence of $\mathsf{adv}$ only needs the tick that is already present in $\Gamma_2$ . In turn, (2) holds due to the fact that all occurrences of $\mathsf{adv}$ in t must be guarded by an occurrence of $\mathsf{delay}$ in t itself, and thus the tick between $\Gamma_1$ and $\Gamma_2$ is not needed. Note that (2) is about $\lambda_{\checkmark}$ as we first apply the induction hypothesis and then apply (2).

4.2.2 Abstract machine for $\lambda_{\checkmark}$

To prove the absence of implicit space leaks, we devise an abstract machine that after each time step deletes all data from the previous time step. That means, the operational semantics is by construction free of implicit space leaks. This approach, pioneered by Krishnaswami (Reference Krishnaswami2013), allows us to reduce the proof of no implicit space leaks to a proof of type soundness.

At the centre of this approach is the idea to execute programs in a machine that has access to a store consisting of up to two separate heaps: a ‘now’ heap from which we can retrieve delayed computations, and a ‘later’ heap where we must store computations that should be performed in the next time step. Once the machine advances to the next time step, it will delete the ‘now’ heap and the ‘later’ heap will become the new ‘now’ heap.

The machine consists of two components: the evaluation semantics, presented in Figure 6, which describes the operational behaviour of $\lambda_{\checkmark}$ within a single time step; and the step semantics, presented in Figure 7, which describes the behaviour of a program over time, for example, how it consumes and constructs streams.

Fig. 6. Evaluation semantics.

Fig. 7. Step semantics for streams.

The evaluation semantics is given as a deterministic big-step operational semantics, where we write $\left\langle t; \sigma \right\rangle \Downarrow \langle v; \sigma'\rangle$ to indicate that starting with the store $\sigma$ , the term t evaluates to the value v and the new store $\sigma'$ . A store $\sigma$ can be of one of two forms: either it consists of a single heap $\eta_L$ , that is, $\sigma = \eta_L$ , or it consists of two heaps $\eta_N$ and $\eta_L$ , written $\sigma = \eta_N\checkmark\eta_L$ . The ‘later’ heap $\eta_L$ contains delayed computations that may be retrieved and executed in the next time step, whereas the ‘now’ heap $\eta_N$ contains delayed computations from the previous time step that can be retrieved and executed now. We can only write to $\eta_L$ and only read from $\eta_N$ . However, when one time step passes, the ‘now’ heap $\eta_N$ is deleted and the ‘later’ heap $\eta_L$ becomes the new ‘now’ heap. This shifting of time is part of the step semantics in Figure 7, which we turn to shortly.

Heaps are simply finite mappings from heap locations to terms. To allocate fresh heap locations, we assume a function $\mathsf{alloc}\cdot$ that takes a store $\sigma$ of the form $\eta_L$ or $\eta_N\checkmark\eta_L$ and returns a heap location l that is not in the domain of $\eta_L$ . Given such a fresh heap location l and a term t, we write $\sigma,l\mapsto t$ to denote the store $\eta'_L$ or $\eta_N\checkmark\eta'_L$ , respectively, where $\eta'_L = \eta_L,l \mapsto t$ , that is, $\eta'_L$ is obtained from $\eta_L$ by extending it with a new mapping $l \mapsto t$ .

Applying $\mathsf{delay}$ to a term t stores t in a fresh location l on the ‘later’ heap and then returns l. Conversely, if we apply to such a delayed computation, we retrieve the term from the ‘now’ heap and evaluate it.

4.3 Main results

In this section, we present the main metatheoretical results. Namely, that the core calculus $\lambda_{\checkmark}$ enjoys the desired productivity, causality, and memory properties (see Theorem 4.2 and Theorem 4.3 below). The proof of these results is sketched in Section 5 and is fully mechanised in the accompanying Coq proofs. In order to formulate and prove these metatheoretical results, we devise a step semantics that describes the behaviour of reactive programs. Here, we consider two kinds of reactive programs: terms of type ${\textit{Str}\;\textit{A}}$ and terms of type ${\textit{Str}\;\textit{A}\to \textit{Str}\;\textit{B}}$ . The former just produce infinite streams of values of type A, whereas the latter are reactive processes that produce a value of type ${\textit{B}}$ for each input value of type A. The purpose of the step semantics is to formulate clear metatheoretical properties and to subsequently prove them using the fundamental property of our logical relation (Theorem 5.1). In principle, we could formulate similar step semantics for the Yampa-style signal functions from Section 3.3 or other basic FRP types such as resumptions (Krishnaswami, Reference Krishnaswami2013) and then derive similar metatheoretical results.

4.3.1 Productivity of streams

The step semantics $\overset v\Longrightarrow$ from Figure 7 describes the unfolding of streams of type ${\textit{Str}\;\textit{A}}$ . Given a closed term $\vdash_{\!\checkmark}{t}\textit{Str}\, A$ , it produces an infinite reduction sequence

\begin{equation*} \langle{t};{\emptyset}\rangle {\overset{v_0}\Longrightarrow} \langle{t_1};{\eta_1}{\overset{v_1}\Longrightarrow} \langle{t_2};{\eta_2}\rangle {\overset{v_2}\Longrightarrow} \ldots \end{equation*}

where $\emptyset$ denotes the empty heap and each $v_i$ has type A. In each step, we have a term $t_i$ and the corresponding heap $\eta_i$ of delayed computations. According to the definition of the step semantics, we evaluate $\langle{t_i}{\eta_i\checkmark\rangle}\Downarrow\langle{v_i ::: l}{\eta'_i\checkmark\eta_{i+1}\rangle}$ , where $\eta'_i$ is $\eta_i$ but possibly extended with some additional delayed computations and $\eta_{i+1}$ is the new heap with delayed computations for the next time step. Crucially, the old heap $\eta'_i$ is thrown away. That is, by construction, old data is not implicitly retained but garbage collected immediately after we completed the current time step.

To see this garbage collection strategy in action, consider the following definition of the stream of consecutive numbers starting from some given number:

This definition translates to the $\lambda_{\checkmark\!\!\checkmark}$ term $\mathsf{fix}\, r. \lambda n. n ::: \mathsf{delay} (\mathsf{adv}\, (\mathsf{unbox}\, r)\, (n+\bar{1}))$ , which, in turn, rewrites into the following $\lambda_{\checkmark}$ term:

\begin{equation*} \mathit{from} = \mathsf{fix}\, r. \lambda n. n ::: {\rm let}{r'}{\mathsf{unbox}\, r}{\mathsf{delay} (\mathsf{adv}\, r'\, (n+\bar{1}))} \end{equation*}

Let’s see how the term $\mathit{from}\,\bar{0}$ of type ${\textit{Str}\;\textit{Int}}$ is executed on the machine:

\begin{equation*} \begin{array}{rcl} \langle{\mathit{from}\,\bar{0}}{\emptyset}\rangle &\overset{\bar{0}}{\Longrightarrow}& {\langle\mathsf{adv}\,l'_1}{l_1} \mapsto \textit{from},\,l'_1\mapsto \mathsf{adv}\,l_1\,(\bar{0} + \bar{1})\rangle\\ &\overset{\bar{1}}{\Longrightarrow}& \langle\mathsf{adv}\,l'_2{l_2} \mapsto \textit{from},\,l'_2\mapsto \mathsf{adv}\,l_2\, (\bar{1} + \bar{1})\rangle\\ &\overset{\bar{2}}{\Longrightarrow}& \langle\mathsf{adv}\,l'_3{l_3} \mapsto \textit{from},\,l'_3\mapsto \mathsf{adv}\,l_3\,(\bar{2} + \bar{1})\rangle\\ &\vdots& \end{array} \end{equation*}

In each step, the heap contains at location $l_i$ the fixed point $\mathit{from}$ and at location $l'_i$ the delayed computation produced by the occurrence of $\mathsf{delay}$ in the body of the fixed point. The old versions of the delayed computations are garbage collected after each step and only the most recent version survives.

Our main result is that the execution of $\lambda_{\checkmark}$ terms by the machine described in Figure 6 and 7 is safe. To describe the type of the produced values precisely, we need to restrict ourselves to streams over types whose evaluation is not suspended, which excludes function and modal types. This idea is expressed in the notion of value types, defined by the following grammar:

\begin{equation*} \text{Value types} \quad V, W::= 1\mid{\rm Int} \mid U \times W \mid U + W \end{equation*}

We can then prove the following theorem, which both expresses the fact that the aggressive garbage collection strategy of $\mathsf{Rattus}$ is safe, and that stream programs are productive:

Theorem 4.2 (productivity of streams) Given a term $\vdash_{\checkmark}{t}:{\mathsf{Str}\, A}$ with A a value type, there is an infinite reduction sequence

\begin{equation*} \langle{t};{\emptyset}\rangle {\overset {v_0}\Longrightarrow} \langle{t_1};{\eta_1} {\overset{v_1}\Longrightarrow} \langle{t_2}:{\eta_2}\rangle {\overset{v_2}\Longrightarrow} \ldots \qquad \text{such that} \vdash_{\checkmark}{v_i}:{A} for all i \ge 0. \end{equation*}

The restriction to value types is only necessary for showing that each output value $v_i$ has the correct type.

4.3.2 Productivity and causality of stream transducers

The step semantics ${\overset {vv'}\Longrightarrow}$ from Figure 7 describes how a term of type ${\textit{Str}\;\textit{A}\to \textit{Str}\;\textit{B}}$ transforms a stream of inputs into a stream of outputs in a step-by-step fashion. Given a closed term $\vdash_{\!\checkmark}{t}:\mathsf{Str}\,A\to \mathsf{Str}\,B$ and an infinite stream of input values $\vdash_{\!\checkmark}{v}_{i}:A$ , it produces an infinite reduction sequence

\begin{equation*} \langle{t\,(\mathsf{adv}\,l^\ast)};{\emptyset}\rangle {\overset ({v_0}/{v'_0}\Longrightarrow} \langle{t_1};{\eta_1}\rangle {\overset ({v_1}/{v'_1}\Longrightarrow}\langle{t_2};{\eta_2}\rangle {\overset ({v_2}/{v'_1}\Longrightarrow} \ldots \end{equation*}

where each output value $v'_i$ has type B.

The definition of ${\overset {vv'}\Longrightarrow}$ assumes that we have some fixed heap location $l^\ast$ , which acts both as interface to the currently available input value and as a stand-in for future inputs that are not yet available. As we can see above, this stand-in value $l^\ast$ is passed on to the stream function in the form of the argument $\mathsf{adv}\,l^\ast$ . Then, in each step, we evaluate the current term $t_i$ in the current heap $\eta_i$ :

\begin{equation*} {t_i}{\eta_i,l^\ast \mapsto v_i ::: l^\ast \checkmark l^\ast \mapsto \langle\rangle}{v'_i ::: l}{\eta'_i\checkmark\eta_{i+1},l^\ast \mapsto \langle\rangle} \end{equation*}

which produces the output $v'_i$ and the new heap $\eta_{i+1}$ . Again the old heap $\eta'_i$ is simply dropped. In the ‘later’ heap, the operational semantics maps $l^\ast$ to the placeholder value $\langle\rangle$ , which is safe since the machine never reads from the ‘later’ heap. Then in the next reduction step, we replace that placeholder value with $v_{i+1} ::: l^\ast$ which contains the newly received input value $v_{i+1}$ .

For an example, consider the following function that takes a stream of integers and produces the stream of prefix sums:

This function definition translates to the following term $\mathit{sum}$ in the $\lambda_{\checkmark}$ calculus:

\begin{align*} \mathit{run} &= \mathsf{fix}\,r.\lambda acc. \lambda s. \begin{aligned}[t] &\mathsf{let}\, x = \mathsf{head}\,s \;\mathsf{in}\; \mathsf{let}\, xs = \mathsf{tail}\,s \;\mathsf{in}\;\mathsf{let}\, acc' = acc + x\; \mathsf{in}\\ &\mathsf{let}\, r' = \,r\; \mathsf{in}\; acc' ::: \mathsf{delay} (\mathsf{adv}\, r'\, acc' (\mathsf{adv}\, xs)) \end{aligned} \\ \mathit{sum} &= \mathit{run}\, \bar{0} \end{align*}

Let’s look at the first three steps of executing the $\mathit{sum}$ function with 2, 11 and 5 as its first three input values:

In each step of the computation, $l_i$ stores the fixed point $\textit{run}$ and $l'_i$ stores the computation that calls that fixed point with the new accumulator value (2, 13 and 18, respectively) and the tail of the current input stream.

We can prove the following theorem, which again expresses the fact that the garbage collection strategy of $\mathsf{Rattus}$ is safe, and that stream processing functions are both productive and causal:

Theorem 4.3 (causality and productivity of stream transducers) Given a term $\vdash_{\!\!\checkmark}t:{\mathsf{Str}\, A \to \mathsf{Str}\, B}$ with B a value type, and an infinite sequence of values $\vdash_{\!\!\checkmark}v_i:A$ , there is an infinite reduction sequence

Since the operational semantics is deterministic, in each step $\langle{t_i};{\eta_i}\rangle \overset{v_{i}/v'_{i}}\Longrightarrow \langle{t_{i+1}};{\eta_{i+1}}\rangle$ , the resulting output $v'_{i+1}$ and new state of the computation $\langle{t_{i+1}};{\eta_{i+1}}\rangle$ are uniquely determined by the previous state $\langle{t_i};{\eta_i}\rangle$ and the input $v_{i}$ . Thus, $v'_{i}$ and $\langle{t_{i+1}};{\eta_{i+1}}\rangle$ are independent of future inputs $v_j$ with $j > i$ .

4.3.3 Space leak in the naive operational semantics

Theorems 4.2 and 4.3 show that $\lambda_{\checkmark\!\!\checkmark}$ terms can be executed without implicit space leaks after they have been translated into $\lambda_{\checkmark}$ terms. To demonstrate the need of the translation step, we give an example that illustrates what would happen if we would skip it.

Since both $\lambda_{\checkmark}$ and $\lambda_{\checkmark\!\!\checkmark}$ share the same syntax, the abstract machine from Section 4.2.2 could in principle be used for $\lambda_{\checkmark\!\!\checkmark}$ terms directly, without transforming them to $\lambda_{\checkmark}$ first. However, we can construct a well-typed $\lambda_{\checkmark\!\!\checkmark}$ term for which the machine will try to dereference a heap location that has previously been garbage collected. We might conjecture that we could accommodate direct execution of $\lambda_{\checkmark\!\!\checkmark}$ by increasing the number of available heaps in the abstract machine so that it matches the number of ticks that were necessary to type-check the term we wish to execute. But this is not the case: we can construct a $\lambda_{\checkmark\!\!\checkmark}$ term that can be type-checked with only two ticks but requires an unbounded number of heaps to safely execute directly. In other words, programs in $\lambda_{\checkmark\!\!\checkmark}$ may exhibit implicit space leaks, if we just run them using the evaluation strategy of the abstract machine from Section 4.2.2.

Such implicit space leaks can occur in $\lambda_{\checkmark\!\!\checkmark}$ for two reasons: (1) a lambda abstraction that appears in the scope of a $\checkmark$ , and (2) a term that requires more than one $\checkmark$ to type-check. Bahr et al. (Reference Bahr, Graulund and Møgelberg2019) give an example of (1), which translates to $\lambda_{\checkmark\!\!\checkmark}$ . The following term of type $\bigcirc (\mathsf{Str}\, Int) \to \bigcirc (\mathsf{Str}\, Int)$ is an example of (2):

\begin{equation*} t = \mathsf{fix}\,r.\lambda x. \mathsf{delay} (head (\mathsf{adv}\, x) ::: \mathsf{adv}(\mathsf{unbox}\, r) (\mathsf{delay} (\mathsf{adv} (tail (\mathsf{adv}\, x))))) \end{equation*}

The abstract machine would get stuck trying to dereference a heap location that was previously garbage collected. The problem is that the second occurrence of x is nested below two occurrences of $\mathsf{delay}$ . As a consequence, when $\mathsf{adv}\,x$ is evaluated, the heap location bound to x is two time steps old and has been garbage collected already.

To see this behaviour on a concrete example, recall the $\lambda_{\checkmark}$ term $\mathit{from} : Int \to \mathsf{Str}\, Int$ from Section 4.3.1, which produces a stream of consecutive integers. Using t and $\mathit{from}$ , we can construct the $\lambda_{\checkmark\!\!\checkmark}$ term $\bar{0} ::: t\, (\mathsf{delay}\,(\mathit{from}\,\bar{1}))$ of type $\mathsf{Str}\, Int$ , which we can run on the abstract machine: ^{Footnote 6}

In the last step, the machine would get stuck trying to evaluate $\mathsf{adv}\,l_4$ , since this in turn requires evaluating $\mathsf{head} (\mathsf{adv}\, l_3)$ and $\mathsf{adv}\,(\mathsf{tail}(\mathsf{adv}\,l_1))$ , which would require looking up $l_1$ in $\eta_1$ , which has already been garbage collected. Assuming we modified the machine so that it does not perform garbage collection, but instead holds on to the previous heaps $\eta_1,\eta_2$ , it would continue as follows:

The next execution step would require the machine to look up $l_6$ , which in turn requires $l_5$ , $l_3$ , and eventually $l_1$ . We could continue this arbitrarily far into the future, and in each step the machine would need to look up $l_1$ in the very first heap $\eta_1$ .

This examples suggests that the cause of this space leak is the fact that the machine leaves the nested terms $\mathsf{adv}\, l_1$ , $\mathsf{adv}\, l_3$ , etc. unevaluated on the heap. As our metatheoretical results in this section show, the translation into $\lambda_{\checkmark}$ avoids this problem. Indeed, if we apply the rewrite rules from Section 4.2.1 to t, we obtain the $\lambda_{\checkmark}$ term $\overline 0 ::: t' \, (\mathsf{delay}\,(\mathit{from}\,\overline 1))$ , where

This term can then be safely executed on the abstract machine:

4.4 Limitations

Now that we have formally precise statements about the operational properties of $\mathsf{Rattus}$ ’ core calculus, we should make sure that we understand what they mean in practice and what their limitations are. In simple terms, the productivity and causality properties established by Theorems 4.2 and 4.3 state that reactive programs in $\mathsf{Rattus}$ can be executed effectively – they always make progress and never depend on data that is not yet available. However, $\mathsf{Rattus}$ allows calling general Haskell functions, for which we can make no such operational guarantees. This trade-off is intentional as we wish to make Haskell’s rich library ecosystem available to $\mathsf{Rattus}$ . Similar trade-offs are common in foreign function interfaces that allow function calls into another language. For instance, Haskell code may call C functions.

In addition, by virtue of the operational semantics, Theorems 4.2 and 4.3 also imply that programs can be executed without implicitly retaining memory – thus avoiding implicit space leaks. This follows from the fact that in each step, the step semantics (cf. Figure 7) discards the ‘now’ heap and only retains the ‘later’ heap for the next step. However, similarly to the calculi of Krishnaswami (Reference Krishnaswami2013) and Bahr et al. (Reference Bahr, Graulund and Møgelberg2021, Reference Bahr, Graulund and Møgelberg2019), $\mathsf{Rattus}$ still allows explicit space leaks (we may still construct data structures to hold on to an increasing amount of memory) as well as time leaks (computations may take an increasing amount of time). Below we give some examples of these behaviours.

Given a strict list type List (cf. Section 3.2), we can construct a function that buffers the entire history of its input stream:

Given that we have a function sum :: List Int → Int that computes the sum of a list of numbers, we can write the following alternative implementation of the sums function using buffer:

At each time step, this function adds the current input integer to the buffer of type List Int and then computes the sum of the current value of that buffer. This function exhibits both a space leak (buffering a steadily growing list of numbers) and a time leak (the time to compute each element of the resulting stream increases at each step). However, these leaks are explicit in the program.

An example of a time leak is found in the following alternative implementation of the sums function:

In each step, we add the current input value x to each future output. The closure ${(+x)}$ , which is Haskell shorthand notation for $\lambda y \to y + x$ , stores each input value x.

None of the above space and time leaks are prevented by $\mathsf{Rattus}$ . The space leaks in ${\textit{buffer}}$ and ${\textit{leakySums1}}$ are explicit, since the desire to buffer the input is explicitly stated in the program. That is, while $\mathsf{Rattus}$ prevents implicit space leaks, it still allows programmers to allocate memory as they see fit. The other example is more subtle as the leaky behaviour is rooted in a time leak as the program constructs an increasing computation in each step. This shows that the programmer still has to be careful about time leaks. Note that these leaky functions can also be implemented in the calculi of Krishnaswami (Reference Krishnaswami2013) and Bahr et al. (Reference Bahr, Graulund and Møgelberg2019, Reference Bahr, Graulund and Møgelberg2021), although some reformulation is necessary for the Simply RaTT calculus of Bahr et al. (Reference Bahr, Graulund and Møgelberg2019).

4.5 Language design considerations

The design of $\mathsf{Rattus}$ and its core calculus is derived from the calculi of Krishnaswami (Reference Krishnaswami2013) and Bahr et al. (Reference Bahr, Graulund and Møgelberg2019, Reference Bahr, Graulund and Møgelberg2021), which are the only other modal FRP calculi with a garbage collection result similar to ours. In the following, we review the differences of $\mathsf{Rattus}$ compared to these calculi with the aim of illustrating how the design of $\mathsf{Rattus}$ follows from our goal to simplify previous calculi while still maintaining their strong operational properties.

Like the present work, the Simply RaTT calculus of Bahr et al. (Reference Bahr, Graulund and Møgelberg2019) uses a Fitch-style type system, which provides lighter syntax to interact with the $\square$ and $\bigcirc$ modality compared to Krishnaswami’s use of qualifiers in his calculus. In addition, Simply RaTT also dispenses with the allocation tokens of Krishnaswami’s calculus by making the $\mathsf{box}$ primitive call-by-name. By contrast, Krishnaswami’s calculus is closely related to dual-context systems and requires the use of pattern matching as elimination forms of the modalities. The Lively RaTT calculus of Bahr et al. (Reference Bahr, Graulund and Møgelberg2021) extends Simply RaTT with temporal inductive types to express liveness properties. But otherwise, Lively RaTT is similar to Simply RaTT and the discussion below equally applies to Lively RaTT as well.

As discussed in Section 2.2, Simply RaTT restricts where ticks may occur, which disallows terms like $\mathsf{delay}(\mathsf{delay}\, 0)$ and $\mathsf{delay}(\lambda x. x)$ . In addition, Simply RaTT has a more complicated typing rule for guarded fixed points (cf. Figure 8). In addition to $\checkmark$ , Simply RaTT uses the token to serve the role that stabilisation of a context $\Gamma$ to $\Gamma^\square$ serves in $\mathsf{Rattus}$ . But Simply RaTT only allows one such token, and $\checkmark$ may only appear to the right of . Moreover, fixed points in Simply RaTT produce terms of type $\square A$ rather than just A. Taken together, this makes the syntax and typing for guarded recursive function definitions more complicated and less intuitive. For example, the $\textit{map}$ function would be defined as follows in Simply RaTT:

Fig. 8. Selected typing rules from Bahr et al. (Reference Bahr, Graulund and Møgelberg2019).

Here, # is used to indicate that the argument f is to the left of the token and only because of the presence of this token can we use the $\mathsf{unbox}$ combinator on f (cf. Figure 8). Additionally, the typing of recursive definitions is somewhat confusing: $\textit{map}$ has return type (str a → str b) but when used in a recursive call as seen above, map f is of type ○(str a → str b) instead. Moreover, we cannot call $\textit{map}$ recursively on its own. All recursive calls must be of the form map f, the exact pattern that appears to the left of the #. This last restriction rules out the following variant of $\textit{map}$ that is meant to take two functions and alternately apply them to a stream:

Only alter Map f g is allowed as recursive call, but not alter Map g f. By contrast, alter Map can be implemented in $\mathsf{Rattus}$ without problems:

In addition, because guarded recursive functions always have a boxed return type, definitions in Simply RaTT are often littered with calls to $\mathsf{unbox}$ . For example, the function pong ₁ from Section 3.2 would be implemented as follows in Simply RaTT:

By making the type of guarded fixed points A rather than $\square A$ , we avoid all of the above issues related to guarded recursive definitions. Moreover, the unrestricted $\mathsf{unbox}$ combinator found in $\mathsf{Rattus}$ follows directly from this change in the guarded fixed point typing. If we were to change the typing rule for $\mathsf{fix}$ in Simply RaTT so that $\mathsf{fix}$ has type A instead of $\square A$ , we would be able to define an unrestricted $\mathsf{unbox}$ combinator $\lambda x. \mathsf{fix}\, y.\mathsf{unbox}\, x$ of type $\square A \to A$ .

Conversely, if we keep the $\mathsf{unbox}$ combinator of Simply RaTT but lift some of the restrictions regarding the token such as allowing $\checkmark$ not only to the right of a or allowing more than one token, then we would break the garbage collection property and thus permit leaky programs. In such a modified version of Simply RaTT, we would be able to type-check the following term:

where $\Gamma = \sharp$ if we were to allow two tokens or $\Gamma$ empty, if we were to allow the $\checkmark$ to occur left of the . The above term stores the value $\mathsf{box}\,0$ on the heap and then constructs a stream, which at each step tries to read this value from the heap location. Hence, in order to maintain the garbage collection property in $\mathsf{Rattus}$ , we had to change the typing rule for $\mathsf{unbox}$ .

In addition, $\mathsf{Rattus}$ permits recursive functions that look more than one time step into the future (e.g., $\textit{stutter}$ from Section 2.2), which is not possible in Krishnaswami (Reference Krishnaswami2013) and Bahr et al. (Reference Bahr, Graulund and Møgelberg2019, Reference Bahr, Graulund and Møgelberg2021). However, we conjecture that Krishnaswami’s calculus can be adapted to allow this by changing the typing rule for $\mathsf{fix}$ in a similar way as we did for $\mathsf{Rattus}$ .

We should note that that the # token found in Simply RaTT has some benefit over the $\Gamma^\square$ construction. It allows the calculus to reject some programs with time leaks, for example, from Section 4.4, because of the condition in the rule for $\mathsf{unbox}$ requiring that $\Gamma'$ be token-free. However, we can easily write a program that is equivalent to , that is well-typed in Simply RaTT using tupling, which corresponds to defining mutually recursively with $\textit{map}$ . Moreover, this side condition for $\mathsf{unbox}$ was dropped in Lively RaTT as it is incompatible with the extension by temporal inductive types.

Finally, there is an interesting trade-off in all four calculi in terms of their syntactic properties such as eta-expansion and local soundness/completeness. The potential lack of these syntactic properties has no bearing on the semantic soundness results for these calculi, but it may be counterintuitive to a programmer using the language.

For example, typing in Simply RaTT is closed under certain eta-expansions involving $\square$ , which are no longer well-typed in $\lambda_{\checkmark\!\!\checkmark}$ because of the typing rule for $\mathsf{unbox}$ . For example, we have

\begin{equation*} f : A \to \square B \vdash \lambda\, x. \mathsf{box} (\mathsf{unbox} (f\,x)):A \to \square B \end{equation*}

in Simply RaTT but not in $\lambda_{\checkmark\!\!\checkmark}$ . However, $\lambda_{\checkmark\!\!\checkmark}$ has a slightly different eta-expansion for this type instead:

which matches the eta-expansion in Krishnaswami’s calculus:

On the other hand, because $\lambda_{\checkmark\!\!\checkmark}$ lifts Simply RaTT’s restrictions on tokens, $\lambda_{\checkmark\!\!\checkmark}$ is closed under several types of eta-expansions that are not well-typed in Simply RaTT. For example,

In return, both Krishnaswami’s calculus and $\lambda_{\checkmark\!\!\checkmark}$ lack local soundness and completeness for the $\square$ type. For instance, from ${\Gamma}\vdash_{\checkmark\!\!\checkmark}{t}:{\square A}$ we can obtain ${\Gamma}\vdash_{\checkmark\!\!\checkmark}\mathsf{unbox}\, t:A$ in $\lambda_{\checkmark\!\!\checkmark}$ , but from ${\Gamma}\vdash_{\checkmark\!\!\checkmark}{t}:{A}$ , we cannot construct a term ${\Gamma}\vdash_{\checkmark\!\!\checkmark}{t'}:{\square A}$ . By contrast, the use of the token ensures that Simply RaTT enjoys these local soundness and completeness properties. However, Simply RaTT can only allow one such token and must thus trade off eta-expansion as show above in order to avoid space leaks (cf. the example term above).

In summary, we argue that our typing system and syntax are simpler than both the work of Krishnaswami (Reference Krishnaswami2013) and Bahr et al. (Reference Bahr, Graulund and Møgelberg2019, Reference Bahr, Graulund and Møgelberg2021). These simplifications are meant to make the language easier to use and integrate more easily with mainstream languages like Haskell, while still maintaining the strong memory guarantees of the earlier calculi.

6.1 Implementation of Rattus

At its core, our implementation consists of a very simple library that implements the primitives of $\mathsf{Rattus}$ ( $\mathsf{delay}$ , $\mathsf{adv}$ , $\mathsf{box}$ and $\mathsf{unbox}$ ) so that they can be readily used in Haskell code. The library is given in its entirety in Figure 10. Both $\bigcirc$ and $\square$ are simple wrapper types, each with their own wrap and unwrap function. The constructors Delay and Box are not exported by the library, that is, $\bigcirc$ and $\square$ are treated as abstract types.

Fig. 10. Implementation of $\mathsf{Rattus}$ primitives.

If we were to use these primitives as provided by the library, we would end up with the problems illustrated in Section 2. Such an implementation of $\mathsf{Rattus}$ would enjoy none of the operational properties we have proved. To make sure that programs use these primitives according to the typing rules of $\mathsf{Rattus}$ , our implementation has a second component: a plugin for the GHC Haskell compiler that enforces the typing rules of $\mathsf{Rattus}$ .

The design of this plugin follows the simple observation that any $\mathsf{Rattus}$ program is also a Haskell program but with more restrictive rules for variable scope and for where $\mathsf{Rattus}$ ’s primitives may be used. So type-checking a $\mathsf{Rattus}$ program boils down to first type-checking it as a Haskell program and then checking that it follows the stricter variable scope rules. That means, we must keep track of when variables fall out of scope due to the use of $\mathsf{delay}$ , and $\mathsf{box}$ , but also due to guarded recursion. Additionally, we must make sure that both guarded recursive calls and only appear in a context where $\checkmark$ is present.

To enforce these additional simple scope rules, we make use of GHC’s plugin API which allows us to customise part of GHC’s compilation pipeline. The different phases of GHC are illustrated in Figure 11 with the additional passes performed by the $\mathsf{Rattus}$ plugin highlighted in bold.

Fig. 11. Compiler phases of GHC (simplified) extended with $\mathsf{Rattus}$ plugin (highlighted in bold).

After type-checking the Haskell abstract syntax tree (AST), GHC passes the resulting typed AST on to the scope-checking component of the $\mathsf{Rattus}$ plugin, which checks the above-mentioned stricter scoping rules. GHC then desugars the typed AST into the intermediate language Core. GHC then performs a number of transformation passes on this intermediate representation, and the first two of these are provided by the $\mathsf{Rattus}$ plugin: first, we exhaustively apply the two rewrite rules from Section 4.2.1 to transform the program into a single-tick form according to the typing rules of $\lambda_{\checkmark}$ . Then we transform the resulting code so that $\mathsf{Rattus}$ programs adhere to the call-by-value semantics. To this end, the plugin’s strictness pass transforms all lambda abstractions so that they evaluate their arguments to weak head normal form, and all let bindings so that they evaluate the bound expression into weak head normal form. This is achieved by transforming lambda abstractions and let bindings as follows:

In Haskell Core, case expressions always evaluate the scrutinee to weak head normal form even if there is only a default clause. Hence, this transformation will force the evaluation of x in the lambda abstraction $\lambda x . t$ , and the evaluation of s in the let binding . In addition, this strictness pass also checks that $\mathsf{Rattus}$ code only uses strict data types and issues a warning if lazy data types are used, for example, Haskell’s standard list and pair types. Taken together, the transformations and checks performed by the strictness pass ensure that lambda abstractions, let bindings and data constructors follow the operational semantics of $\lambda_{\checkmark}$ . The remaining components of the language are either implemented directly as Haskell functions ( $\mathsf{delay}$ , , $\mathsf{box}$ and $\mathsf{unbox}$ ) and thus require no transformation or use Haskell’s recursion syntax that matches the semantics of the corresponding fixed point combinator in $\lambda_{\checkmark}$ .

However, the Haskell implementation of $\mathsf{delay}$ and do not match the operational semantics of $\lambda_{\checkmark}$ exactly. Instead of explicit allocation of delayed computations on a heap that then enables the eager garbage collection strategy of the $\lambda_{\checkmark}$ operational semantics, we rely on Haskell’s lazy evaluation for $\mathsf{delay}$ and GHC’s standard garbage collection implementation. Since our metatheoretical results show that old temporal data is no longer referenced after each time step, such data will indeed be garbage collected by the GHC runtime system.

Not pictured in Figure 11 is a second scope-checking pass that is performed after the strictness pass. After the single tick pass and thus also after the strictness pass, we expect that the code is typable according to the more restrictive typing rules of $\lambda_{\checkmark}$ . This second scope-checking pass checks this invariant for the purpose of catching implementation bugs in the $\mathsf{Rattus}$ plugin. The Core intermediate language is much simpler than the full Haskell language, so this second scope-checking pass is much easier to implement and much less likely to contain bugs. In principle, we could have saved ourselves the trouble of implementing the much more complicated scope-checking at the level of the typed Haskell AST. However, by checking at this earlier stage of the compilation pipeline, we can provide much more helpful type error messages.

One important component of checking variable scope is checking whether types are stable. This is a simple syntactic check: a type is stable if all occurrences of $\bigcirc$ or function types in are nested under a $\square$ . However, $\mathsf{Rattus}$ also supports polymorphic types with type constraints such as in the $\textit{const}$ function:

The $\textit{Stable}$ type class is defined as a primitive in the $\mathsf{Rattus}$ library (see Figure 10). The library does not export the underlying type class so that the user cannot declare any instances for $\textit{Stable}$ . Our library does not declare instances of the $\textit{Stable}$ class either. Instead, such instances are derived by the $\mathsf{Rattus}$ plugin that uses GHC’s type checker plugin API, which allows us to provide limited customisation to GHC’s type-checking phase (see Figure 11). Using this API, one can give GHC a custom procedure for resolving type constraints. Whenever GHC’s type checker finds a constraint of the form , it will send it to the $\mathsf{Rattus}$ plugin, which will resolve it by performing the above-mentioned syntactic check on .

6.2 Using Rattus

To write $\mathsf{Rattus}$ code inside Haskell, one must use GHC with the flag -fplugin= $\mathsf{Rattus}$ .Plugin, which enables the $\mathsf{Rattus}$ plugin described above. Figure 12 shows a complete program that illustrates the interaction between Haskell and $\mathsf{Rattus}$ . The language is imported via the module, with the module providing a stream library (of which we have seen an excerpt in Figure 1). The program contains only one $\mathsf{Rattus}$ function, , which is indicated by an annotation. This function uses the $\textit{scan}$ combinator to define a stream transducer that sums up its input stream. Finally, we use the function that is provided by the module. It turns a stream function of type into a Haskell value of type defined as follows:

Fig. 12. Complete $\mathsf{Rattus}$ program.

This allows us to run the stream function step by step as illustrated in the main function: It reads an integer from the console passes it on to the stream function, prints out the response and then repeats the process.

Alternatively, if a module contains only $\mathsf{Rattus}$ definitions, we can use the annotation

to declare that all definitions in a module are to be interpreted as $\mathsf{Rattus}$ code.