2.1 Functors and monads

Functors. In Haskell, a functor ${{f}\mathbin{::}\mathbin{\ast}\to \mathbin{\ast}}$ instantiates the functor type class, which has a single functor mapping operation.

Furthermore, a functor should satisfy the following two functor laws:

(2.1)

(2.2)

We sometimes use the operator ${\mathbin{\langle{{{\$}}}\rangle}}$ as an alias for fmap.

Monads. Monadic side effects (Moggi, Reference Moggi1991), the main focus of this paper, are those that can dynamically determine what happens next. A monad ${{m}\mathbin{::}\mathbin{\ast}\to \mathbin{\ast}}$ is a functor which instantiates the monad type class, which has two operations return (η) and bind $({>\!\!>\!\!=})$ .

Furthermore, a monad should satisfy the following three monad laws:

(2.3)

(2.4)

(2.5)

Haskell supports ${\mathbf{do}}$ blocks as syntactic sugar for monadic computations. For example, ${\mathbf{do}\;{x}\leftarrow {m};{f}\;{x}}$ is translated to ${{m}>\!\!>\!\!={f}}$ . Two convenient derived operators are ${>\!\!>}$ and ${\mathbin{\langle{{{\ast}}}\rangle}}$ .Footnote ¹

2.2 Nondeterminism and state

Following both the approaches of Hutton and Fulger (Reference Hutton and Fulger2008) and of Gibbons and Hinze (Reference Gibbons and Hinze2011), we introduce effects as subclasses of the Monad type class.

Nondeterminism. The first monadic effect we introduce is nondeterminism. We define a subclass MNondet of Monad to capture the nondeterministic interfaces as follows:

Here, ∅ denotes failures and $(\left[\!\right])$ denotes nondeterministic choices. Instances of the MNondet interface should satisfy the following four laws:Footnote ²

(2.6)

(2.7)

(2.8)

(2.9)

The first two laws state that ${(\left[\!\right])}$ and should form a monoid, i.e., ${(\left[\!\right])}$ should be associative with as its neutral element. The last two laws show that ${(>\!\!>\!\!=)}$ is right-distributive over ${(\left[\!\right])}$ and that ${{\varnothing}}$ cancels bind on the left.

The approach of Gibbons and Hinze (Reference Gibbons and Hinze2011) is to reason about effectful programs using an axiomatic characterization given by these laws. It does not rely on the specific implementation of any particular instance of MNondet. In contrast, Hutton and Fulger (Reference Hutton and Fulger2008) reason directly in terms of a particular instance. In the case of MNondet, the quintessential instance is the list monad, which extends the conventional Monad instance for lists.

State. The signature for the state effect has two operations: a get operation that reads and returns the state and a put operation that modifies the state, overwriting it with the given value, and returns nothing. Again, we define a subclass MState of Monad to capture its interfaces.

These operations are regulated by the following four laws:

(2.10)

(2.11)

(2.12)

(2.13)

The standard instance of MState is the state monad State s.

2.3 The N-queens puzzle

The n-queens problem used here is an adapted and simplified version from that of Gibbons and Hinze (Reference Gibbons and Hinze2011). The aim of the puzzle is to place n queens on a $n \times n$ chess board such that no two queens can attack each other. This means that no two queens should be placed on the same row, the same column or the same diagonal of the chess board.

Given n, we number the rows and columns by ${[\mathrm{1}\mathinner{\ldotp\ldotp}{n}]}$ . Since all queens should be placed on distinct rows and distinct columns, a potential solution can be represented by a permutation xs of the list ${[\mathrm{1}\mathinner{\ldotp\ldotp}{n}]}$ , such that ${{xs}\mathbin{!!}{i}\mathrel{=}{j}}$ denotes that the queen on the ith column is placed on the jth row. Using this representation, queens cannot be put on the same row or column.

A naive algorithm. We have the following naive nondeterministic algorithm for n-queens.

The program ${{queens}_{{naive}}\;\mathrm{4}\mathbin{::}[ [ {Int}]]}$ gives as result ${[ [ \mathrm{2},\mathrm{4},\mathrm{1},\mathrm{3}],[ \mathrm{3},\mathrm{1},\mathrm{4},\mathrm{2}]]}$ . The program uses a generate-and-test strategy: it generates all permutations of queens as candidate solutions, and then tests which ones are valid.

The function ${{permutations}\mathbin{::}[ {a}]\to [ [ {a}]]}$ from Data.List computes all the permutations of its input. The function choose implemented as follows nondeterministically picks an element from a list.

The function filtr p x returns x if p x holds and fails otherwise.

The pure function ${{valid}\mathbin{::}[ {Int}]\to {Bool}}$ determines whether the input is a valid solution.

A solution is valid when each queen is safe with respect to the subsequent queens:

The call safe q n qs checks whether the current queen q is on a different ascending and descending diagonal than the other queens qs, where n is the number of columns that q is apart from the first queen ${{q}}_{{1}}$ in qs.

Although this generate-and-test approach works and is quite intuitive, it is not very efficient. For example, all solutions of the form ${(\mathrm{1}\mathbin{:}\mathrm{2}\mathbin{:}{qs})}$ are invalid because the first two queens are on the same diagonal. However, the algorithm still needs to generate and test all $(n-2)!$ candidate solutions of this form.

A backtracking algorithm. We can fuse the two phases of the naive algorithm to obtain a more efficient algorithm, where both generating candidates and checking for validity happens in a single pass. The idea is to move to a state-based backtracking implementation that allows early pruning of branches that are invalid. In particular, when placing the new queen in the next column, we make sure that it is only placed in positions that are valid with respect to the previously placed queens.

We use a state (Int, [ Int]) to contain the current column and the previously placed queens. The backtracking algorithm of n-queens is implemented as follows.

The function guard fails when the input is false.

The function ${{s}\mathbin{\oplus}{r}}$ updates the state with a new queen placed on row r in the next column.

The above monadic version of queens essentially assume that each searching branch has its own state; we do not need to explicitly restore the state when backtracking. Though it is a convenient high-level programming assumption for programmers, it causes obstacles to low-level implementations and optimizations. In the following sections, we investigate how low-level implementation and optimization techniques, such as those found in Prolog’s Warren Abstract Machine and Constraint Programming systems, can be incorporated and proved correct.

3.1 Free monads and their folds

We implement algebraic effects and handlers as free monads and their folds.

Free monads. Free monads are gaining popularity for their use in algebraic effects (Plotkin and Power, Reference Plotkin and Power2002, Reference Plotkin and Power2003) and handlers (Plotkin and Pretnar, Reference Plotkin and Pretnar2009, Reference Plotkin and Pretnar2013), which elegantly separate syntax and semantics of effectful operations. A free monad, the syntax of an effectful program, can be captured generically in Haskell.

This data type is a form of abstract syntax tree (AST) consisting of leaves (Var a) and internal nodes ( ${{Op}\;({f}\;({Free}\;{f}\;{a}))}$ ), whose branching structure is determined by the functor f. This functor is also known as the signature of operations.

A fold recursion scheme. Free monads come equipped with a fold recursion scheme.

This fold interprets an AST structure of type ${{Free}\;{f}\;{a}}$ into some semantic domain b. It does so compositionally using a generator ${{gen}\mathbin{::}{a}\to {b}}$ for the leaves and an algebra ${{alg}\mathbin{::}{f}\;{b}\to {b}}$ for the internal nodes; together these are also known as a handler.

The monad instance of Free is straightforwardly implemented with fold.

Under certain conditions folds can be fused with functions that are composed with them (Wu and Schrijvers, Reference Wu and Schrijvers2015; Gibbons, Reference Gibbons2000). This gives rise to the following laws:

(3.1)

(3.2)

(3.3)

These three fusion laws turn out to be essential in the further proofs of this paper.

Nondeterminism. Instead of using a concrete monad like List, we use the free monad Free Nondet _F over the signature Nondet _F following algebraic effects.

This signatures gives rise to a trivial MNondet instance:

With this representation the right-distributivity law and the left-identity law follow trivially from the definition of ${(>\!\!>\!\!=)}$ for the free monad.

In contrast, the identity and associativity laws are not satisfied on the nose. Indeed, ${{Op}\;({Or}\;{Fail}\;{p})}$ is for instance a different abstract syntax tree than p. Yet, these syntactic differences do not matter as long as their interpretation is the same. This is where the handlers come in; the meaning they assign to effectful programs should respect the laws. We have the following ${{h}}_{{ND}}$ handler which interprets the free monad in terms of lists.

With this handler, the identity and associativity laws are satisfied up to handling as follows:

\begin{equation*}\begin{array}{r@{}c@{}l} {h}_{ND}\;({\varnothing}\mathbin{\left[\!\right]}{m}) & ~=~ & {h}_{ND}\;{m} ~=~ {h}_{ND}\;({m}\mathbin{\left[\!\right]}{\varnothing}) \\ {{h}}_{{ND}\;(({m}\mathbin{\left[\!\right]}{n})\mathbin{\left[\!\right]}{o})} & ~=~ & {{h}}_{{ND}}\;({m}\mathbin{\left[\!\right]}({n}\mathbin{\left[\!\right]}{o}))\end{array}\end{equation*}

In fact, two stronger contextual equalities hold:

\begin{equation*}\begin{array}{r@{}c@{}l} {{h}}_{{ND}\;(({\varnothing}\mathbin{\left[\!\right]}{m})>\!\!>\!\!={k})} & ~=~ & {{h}}_{{ND}\;({m}>\!\!>\!\!={k})} ~=~ {{h}}_{{ND}\;(({m}\mathbin{\left[\!\right]}{\varnothing})>\!\!>\!\!={k})} \\ {{h}}_{{ND}\;((({m}\mathbin{\left[\!\right]}{n})\mathbin{\left[\!\right]}{o})>\!\!>\!\!={k})} & ~=~ & {{h}}_{{ND}\;(({m}\mathbin{\left[\!\right]}({n}\mathbin{\left[\!\right]}{o}))>\!\!>\!\!={k})}\end{array}\end{equation*}

These equations state that the interpretations of the left- and right-hand sides are indistinguishable even when put in a larger program context ${>\!\!>\!\!={k}}$ . They follow from the definitions of ${{h}}_{{ND}}$ and ${(>\!\!>\!\!=)}$ , as well as the associativity and identity properties of ${(+\!\!+)}$ .

We obtain the two non-contextual equations as a corollary by choosing ${{k}\mathrel{=}{\eta}}$ .

State. Again, instead of using the concrete State monad in Section 2.2, we model states via the free monad ${{Free}\;({State}}_{{F}\;{s})}$ over the state signature.

This state signature gives the following MState s instance:

The following handler ${{h}^\prime_{{State}}}$ maps this free monad to the ${{State}\;{s}}$ monad.

It is easy to verify that the four state laws hold contextually up to interpretation with ${{h}^\prime_{{State}}}$ .

3.2 Modularly combining effects

Combining multiple effects is relatively easy in the axiomatic approach based on type classes. By imposing multiple constraints on the monad m, e.g. ${({MState}\;{s}\;{m},{MNondet}\;{m})}$ , we can express that m should support both state and nondeterminism and respect their associated laws. In practice, this is often insufficient: we usually require additional laws that govern the interactions between the combined effects. We discuss possible interaction laws between state and nondeterminism in details in Section 4.

The coproduct operator for combining effects. To combine the syntax of effects given by free monads, we need to define a right-associative coproduct operator ${\mathrel{{:}{+}{:}}}$ for signatures.

Note that given two functors f and g, it is obvious that ${{f}\mathrel{{:}{+}{:}}{g}}$ is again a functor. This coproduct operator allows a modular definition of the signatures of combined effects. For instance, we can encode programs with both state and nondeterminism as effects using the data type ${Free}\;({State}_{F}\mathrel{:}{+}{:}{Nondet}_{F})\;{a}$ . The coproduct also has a neutral element ${{Nil}_{{F}}}$ , representing the empty effect set.

We define the following two instances, which allow us to compose state effects with any other effect functor f, and nondeterminism effects with any other effect functors f and g, respectively. As a result, it is easy to see that ${Free}\;({State}_{F}\;{s}\mathrel{{:}{+}{:}}{Nondet}_{F}\mathrel{{:}{+}{:}}{f})$ supports both state and nondeterminism for any functor f.

Modularly combining effect handlers. In order to interpret composite signatures, we use the forwarding approach of Schrijvers et al. (Reference Schrijvers, Piróg, Wu and Jaskelioff2019). This way the handlers can be modularly composed: they only need to know about the part of the syntax their effect is handling and forward the rest of the syntax to other handlers.

A mediator ${(\mathbin{\#})}$ is used to separate the algebra alg for the handled effects and the forwarding algebra fwd for the unhandled effects.

The handlers for state and nondeterminism we have given earlier require a bit of adjustment to be used in the composite setting since they only consider the signature of their own effects. We need to interpret the free monads into composite domains, ${{StateT}\;({Free}\;{f})\;{a}}$ and ${{Free}\;{f}\;[ {a}}$ , respectively. Here, StateT is the state transformer from the Monad Transformer Library (Jones, Reference Jones1995).

The new handlers, into these composite domains, are defined as follows:

Also, the empty signature ${{Nil}}_{{{F}}}$ has a trivial associated handler.

3.3 Proof device

The algebraic effects and handlers implementation we introduce in this paper is, much like the core calculus of a programming language, a proof device and not an ergonomic library. The results we obtain for this representation can be transferred to other representations.

Explicit isomorphisms. For instance, notice for instance that ${{h}}_{{{State}}}$ and ${{h}}_{{{ND+f}}}$ both require the signature they handle to be on the left in the co-product. It is possible to relax this requirement by means of advanced type-level programming, e.g., using type class overloading (Swierstra, Reference Swierstra2008). That makes using handlers more ergonomic at the cost of obscuring formal reasoning about them. Because the latter is the focus of this paper, we do not introduce the additional flexibility. Instead, we appeal to explicit isomorphisms, to reorder the signatures in a co-product. For example, the ${{(\Leftrightarrow)}}$ isomorphism that we will use in Section 4.2 swaps the order of two functors in the co-product signature of the free monad.

Transfer to other representations. Our use of type class constraints allows us to reduce other monadic representations to the core algebraic effects and handlers representation by an appeal to parametricity (Voigtländer, Reference Voigtländer2009). For instance, for a program ${{p}\mathbin{::}\forall {m}\forall {\circ }{MNondet}\;{m}\Rightarrow {m}\;{Int}}$ we have that:

$ \begin{equation*}{p}\mathbin{::}[ {Int}] = {h}_{ND}\;({p}\mathbin{::}{Free}\;{Nondet}_{F}\;{Int})\end{equation*}$

This is true because ${h}_{ND}$ is the structure-preserving map from the ${{Free}\;{Nondet}}_{{{F}}}$ instance of ${{MNondet}}$ to the [] instance. That is to say, ${h}_{ND}$ satisfies the following four equations:

$\begin{eqnarray*}{{h}}_{{{ND}}\;({\eta}\;{x})} & = & {{\eta}\;{x}} \\{{h}}_{{{ND}}\;({m}>\!\!>\!\!={k})} & = & {{h}_{{ND}}\;{m}>\!\!>\!\!={h}_{{ND}}{\circ }{k}} \\{{h}_{{ND}}\;{\varnothing}} & = & {{\varnothing}} \\{{h}_{{ND}}\;({m}\mathbin{\left[\!\right]}{n})} & = & {{h}_{{ND}}\;{m}\mathbin{\left[\!\right]}{h}_{{ND}}\;{n}}\end{eqnarray*}$

Since the free-monad representation is initial, the structure-preserving map ${{h}}_{{ND}}$ is guaranteed to exist and be unique. Now, if we want to prove a property about ${{p}\mathbin{::}[ {Int}]}$ , the parametricity equation allows us to prove it instead about ${{h}_{{ND}}\;({p}\mathbin{::}{Free}\;{Nondet}_{{F}}\;{Int})}$ . A similar observation can be made for other constraints, like MState or the combination of MState and MNondet.

In the rest of this paper, we focus on results for the core representation of algebraic effects and handlers. By means of the above approach, these results can be generalized to other representations.

4.1 Local-state semantics

When a branch of a nondeterministic computation runs into a dead end and the continuation is picked up at the most recent branching point, any alterations made to the state by the terminated branch are invisible to the continuation. We refer to this semantics as local-state semantics. Gibbons and Hinze (Reference Gibbons and Hinze2011) also call it backtrackable state.

The local-state laws. The following two laws characterize the local-state semantics for a monad with state and nondeterminism:

(4.1)

(4.2)

The equation (4.1) expresses that is the right identity of put; it annihilates state updates. The other law expresses that put distributes from the left in ${(\left[\!\right])}$ .

These two laws only focus on the interaction between put and nondeterminism. The following laws for get can be derived from other laws. The proof can be found in Appendix 1.

(4.3)

(4.4)

If we take these four equations together with the left-identity and right-distributivity laws of nondeterminism, we can say that nondeterminism and state “commute”; if a get or put precedes a or ${\mathbin{\left[\!\right]}}$ , we can exchange their order (and vice versa).

Implementation. Implementation-wise, the laws imply that each nondeterministic branch has its own copy of the state. For instance, Equation (4.2) gives us

The state we get in the second branch is still 42, despite the ${{put}\;\mathrm{21}}$ in the first branch.

One implementation satisfying the laws is

where m is a nondeterministic monad, the simplest structure of which is a list. This implementation is exactly that of StateT s m a in the Monad Transformer Library (Jones, Reference Jones1995) which we have introduced in Section 3.2.

With effect handling (Kiselyov and Ishii, Reference Kiselyov and Ishii2015; Wu et al., Reference Wu, Schrijvers and Hinze2014), we get the local state semantics when we run the state handler before the nondeterminism handler:

In the case where the remaining signature is empty ( ${{f}\mathrel{=}{Nil}_{{F}}}$ ), we get:

Here, the result type ${({s}\to [ {a}])}$ differs from ${{s}\to [ ({a},{s})]}$ in that it produces only a list of results ( ${[ {a}]}$ ) and not pairs of results and their final state $({[ ({a},{s})]})$ . The latter is needed for ${{Local}\;{s}\;{m}}$ to have the structure of a monad, in particular to support the modular composition of computations with ${(>\!\!>\!\!=)}$ . Such is not needed for the carriers of handlers because the composition of computations is taken care of by the ${(>\!\!>\!\!=)}$ operator of the free monad.

4.2 Global-state semantics

Alternatively, one can choose a semantics where state reigns over nondeterminism. In this case of non-backtrackable state, alterations to the state persist over backtracks. Because only a single state is shared over all branches of nondeterministic computation, we call this state the global-state semantics.

The global-state law. The global-state semantics sets apart non-backtrackable state from backtrackable state. In addition to the general laws for nondeterminism ((2.6) – (2.9)) and state ((2.10) – (2.13)), we provide a global-state law to govern the interaction between nondeterminism and state.

(4.5) $\begin{alignat}{2} &\mathbf{put-or}:\quad & {({put}\;{s}>\!\!>{m})\mathbin{\left[\!\right]}{n}} &= {{put}\;{s}>\!\!>({m}\mathbin{\left[\!\right]}{n})}\mbox{.} \end{alignat}$

This law allows lifting a put operation from the left branch of a nondeterministic choice. For instance, if ${{m}\mathrel{=}{\varnothing}}$ in the left-hand side of the equation, then under local-state semantics (laws (2.6) and (4.1)) the left-hand side becomes equal to n, whereas under global-state semantics (laws (2.6) and (4.5)) the equation simplifies to ${{put}\;{s}>\!\!>{n}}$ .

Implementation. Figuring out a correct implementation for the global-state monad is tricky. One might believe that ${{Global}\;{s}\;{m}\;{a}\mathrel{=}{s}\to ({m}\;{a},{s})}$ is a natural implementation of such a monad. However, the usual naive implementation of ${(>\!\!>\!\!=)}$ for it does not satisfy right-distributivity (2.8) and is therefore not even a monad. The type ${{ListT}\;({State}\;{s})}$ from the Monad Transformer Library (Jones, Reference Jones1995) expands to essentially the same implementation with monad m instantiated by the list monad. This implementation has the same flaws. More careful implementations of ListT (often referred to as “ListT done right”) satisfying right-distributivity (2.8) and other monad laws have been proposed by Volkov (Reference Volkov2014); Gale (Reference Gale2007). The following implementation is essentially that of Gale.

The Maybe in this type indicates that a computation may fail to produce a result. However, since the s is outside of the Maybe, a modified state is returned even if the computation fails. This ${{Global}\;{s}\;{a}}$ type is an instance of the MState and MNondet type classes.

Failure, of course, returns an empty continuation and an unmodified state. Branching first exhausts the left branch before switching to the right branch.

Effect handlers (Kiselyov and Ishii, Reference Kiselyov and Ishii2015; Wu et al., Reference Wu, Schrijvers and Hinze2014) also provide implementations that match our intuition of non-backtrackable computations. The global-state semantics can be implemented by simply switching the order of the two effect handlers compared to the local state handler ${{h}_{{Local}}}$ .

This also runs a single state through a nondeterministic computation. Here, the ${{(\Leftrightarrow)}}$ isomorphism from Section 3.2 allows ${{h}_{{Local}}}$ and ${{h}_{{Global}}}$ have the same type signature.

In the case where the remaining signature is empty ( ${{f}\mathrel{=}{Nil}_{{F}}}$ ), we get:

Like in Section 4.1, the carrier type here is again simpler than that of the corresponding monad because it does not have to support the ${(>\!\!>\!\!=)}$ operator.

4.3 Simulating local state with global state

Both local state and global state have their own laws and semantics. Also, both interpretations of nondeterminism with state have their own advantages and disadvantages.

Local-state semantics imply that each nondeterministic branch has its own state. This may be expensive if the state is represented by data structures, e.g. arrays, that are costly to duplicate. For example, when each new state is only slightly different from the previous, we have a wasteful duplication of information.

Global-state semantics, however, threads a single state through the entire computation without making any implicit copies. Consequently, it is easier to control resource usage and apply optimization strategies in this setting. However, doing this to a program that has a backtracking structure, and would be more naturally expressed in a local-state style, comes at a great loss of clarity. Furthermore, it is significantly more challenging for programmers to reason about global-state semantics than local-state semantics.

To resolve this dilemma, we can write our programs in a local-state style and then translate them to the global-state style to enable low-level optimizations. In this subsection, we show one systematic program translation that alters a program written for local-state semantics to a program that, when interpreted under global-state semantics, behaves exactly the same as the original program interpreted under local-state semantics. This translation explicitly copies the whole state and relies on the nondeterminism mechanism to insert state-restoring branches. We will show other translations from local-state semantics to global-state semantics which avoid the copying and do not rely on nondeterminism in Sections 7 and 8.

State-restoring put. Central to the implementation of backtracking in the global state setting is the backtracking variant ${{put}_{{R}}}$ of ${{put}}$ . The idea is that ${{put}_{{R}}}$ , when run with a global state, satisfies laws (2.10) to (4.2) — the state laws and the local-state laws. Going forward, ${{put}_{{R}}}$ modifies the state as usual, but, when backtracked over, it restores the old state.

We implement ${{put}_{{R}}}$ using both state and nondeterminism as follows:

Here the side branch is executed for its side effect only; it fails before yielding a result.

Intuitively, the second branch generated by ${{put}_{{R}}}$ can be understood as a backtracking or state-restoring branch. The put_R s operation changes the state to s in the first branch put s, and then restores it to the original state s’ in the second branch after we finish all computations in the first branch. Then, the second branch immediately fails so that we can keep going to other branches with the original state s’. For example, assuming an arbitrary computation comp is placed after a state-restoring put, we have the following calculation.

This program saves the current state s’, computes comp using state s, and then restores the saved state s’. Figure 1 shows how the state-passing works and the flow of execution for a computation after a state-restoring put.

Fig. 1:

State-restoring put-operation.

Another example of ${{put}_{{R}}}$ is shown in Table 2, where three programs are run with initial state ${{s}}_{{0}}$ . Note the difference between the final state and the program result for the state-restoring put.

Table 2:

Comparing put and ${put}_{R}$

Translation with state-restoring put. We do not expect the programmer to program against the global-state semantics directly and use the state-restoring ${{put}_{{R}}}$ as they see fit, as this can be quite confusing and error-prone. Instead, we provide an automatic translation: The programmer writes their program against the local-state semantics and uses the regular put. We then translate the local-state semantics program to a corresponding global-state semantics program using the effect handler local2global:

This handler maps the put with local-state semantics onto the state-restoring ${{put}_{{R}}}$ with global-state semantics. All other local-state operations are mapped onto their global-state counterpart.

For example, recall the backtracking algorithm queens for the n-queens example in Section 2.3. It is initially designed to run in the local-state semantics because every branch maintains its own copy of the state and has no influence on other branches. We can handle it with ${{h}_{{Local}}}$ as follows.

With the simulation local2global, we can also translate queens to an equivalent program in global-state semantics and handle it with ${{h}_{{Global}}}$ .

The following theorem guarantees that the translation local2global preserves the meaning when switching from local-state to global-state semantics:

Proof Both the left-hand side and the right-hand side of the equation consist of function compositions involving one or more folds. We apply fold fusion separately on both sides to contract each into a single fold:

$\begin{eqnarray*}{h}_{Global}{\circ}{local2global} & = & {fold}\;{gen}_{LHS}\;({alg}_{LHS}^{S}\mathbin{\#}{alg}_{RHS}^{ND}\mathbin{\#}{fwd}_{LHS}) \\{h}_{Local}& = & {fold}\;{gen}_{RHS}\;({alg}_{RHS}^{S}\mathbin{\#}{alg}_{RHS}^{ND}\mathbin{\#}{fwd}_{RHS})\end{eqnarray*}$

We approach this calculationally. That is to say, we do not first postulate definitions of the unknowns above ( ${{alg}}_{{{LHS}}^{{S}}}$ and so on) and then verify whether the fusion conditions are satisfied. Instead, we discover the definitions of the unknowns. We start from the known side of each fusion condition and perform case analysis on the possible shapes of input. By simplifying the resulting case-specific expression, and pushing the handler applications inwards, we end up at a point where we can read off the definition of the unknown that makes the fusion condition hold for that case.

Finally, we show that both folds are equal by showing that their corresponding parameters are equal:

$\begin{eqnarray*}{{gen}}_{{{LHS}}} & = & {{gen}}_{{{RHS}}} \\{{alg}}_{{{LHS}}^{{S}}} & = & {{alg}}_{{{RHS}}^{{S}}} \\{{alg}}_{{{LHS}}^{{ND}}} & = & {{alg}}_{{{RHS}}^{{ND}}} \\{{fwd}}_{{{LHS}}} & = & {{fwd}}_{{{RHS}}}\end{eqnarray*}$

A noteworthy observation is that, for fusing the left-hand side of the equation, we do not use the standard fusion rule fusion-post (3.2):

$\begin{eqnarray*} {{h}_{{Global}}{\circ }{fold}\;{Var}\;{alg}} & = & {{fold}\;({h}_{{Global}}{\circ }{Var})\;{alg'}} \\ \Leftarrow \qquad {{h}_{{Global}}{\circ }{alg}} & = & {{alg'}{\circ }{fmap}\;{h}_{{Global}}}\end{eqnarray*}$

where ${{local2global}\mathrel{=}{fold}\;{Var}\;{alg}}$ . The problem is that we will not find an appropriate ${{alg'}}$ such that ${{alg'}\;({fmap}\;{h}_{{Global}}\;{t})}$ restores the state for any t of type $({State}_{F}\;{s}\mathrel{:}{+}{:}{Nondet}_{F}\mathrel{:}{+}{:}{f})\;({Free}\;({State}_{F}\;{s}\mathrel{:}{+}{:}{Nondet}_{F}\mathrel{:}{+}{:}{f})\;{a})$ .

Fortunately, we do not need such an ${{alg'}}$ . We can assume that the subterms of t have already been transformed by local2global, and thus all occurrences of Put appear in the ${{put}_{{R}}}$ constellation.

We can incorporate this assumption by using the alternative fusion rule fusion-post’ (3.3):

$\begin{eqnarray*} {{h}_{{Global}}{\circ }{fold}\;{Var}\;{alg}} & = & {{fold}\;({h}_{{Global}}{\circ }{Var})\;{alg'}} \\ \Leftarrow \qquad {{h}_{{Global}}{\circ }{alg}{\circ }{fmap}\;{local2global}} & = & {{alg'}{\circ }{fmap}\;{h}_{{Global}}{\circ }{fmap}\;{local2global}}\end{eqnarray*}$

The additional ${{fmap}\;{local2global}}$ in the condition captures the property that all the subterms have been transformed by local2global.

In order to not clutter the proofs, we abstract everywhere over this additional ${{fmap}\;{local2global}}$ application, except for the key lemma which expresses that the syntactic transformation local2global makes sure that, despite any temporary changes, the computation t restores the state back to its initial value.

We elaborate each of these steps in Appendix 2.

Note on global replacement. To preserve the behaviour when going from local-state to global-state semantics, care should be taken to replace all occurrences of put. Particularly, placing a program in a larger context, where put has not been replaced, can change the meaning of its subprograms. An example of such a problematic context is ${(>\!\!>{put}\;{t})}$ , where the ${{get}}-{{put}}$ law (2.12) breaks and programs ${{get}>\!\!>{put}_{{R}}}$ and ${{\eta}\;()}$ can be differentiated:

Those two programs do not behave in the same way when ${{s}\not\equiv {t}}$ . Hence, only provided that all occurrences of put in a program are replaced by ${{put}_{{R}}}$ can we simulate local-state semantics with global-state semantics. This has been articulated in the proof by the composition ${{h}_{{Global}}{\circ }{local2global}}$ : there is no room between the replacement by local2global and the interpretation with ${{h}_{{Global}}}$ to add plain put operations. The global replacement requirement also manifests itself in the proof, in the form of the fusion-post’ rule rather than the more widely used fusion-post rule.

5.1 Simulating nondeterminism with state

The main idea of simulating nondeterminism with state is to explicitly manage

1. 1. a list of the results found so far, and

2. 2. a list of yet to be explored branches, which we call a stack.

This stack corresponds to the choicepoint stack in Prolog. When entering one branch, we can push other branches to the stack. When leaving the branch, we collect its result and pop a new branch from the stack to continue.

We define a new type S a consisting of the results and stack.

The branches in the stack are represented by computations in the form of free monads over the ${{State}}_{{F}}$ signature. We do not allow branches to use other effects here to show the idea more clearly. In Section 5.2, we will consider the more general case where branches can have any effects abstracted by a functor f.

For brevity, instead of defining a new stack effect capturing the stack operations like pop and push, we implement stack operations with the state effect. We define three auxiliary functions in Figure 2 to interact with the stack in ${{S}\;{a}}$ :

• • The function ${{pop_S}}$ removes and executes the top element of the stack.

• • The function ${{push_S}}$ pushes a branch into the stack.

• • The function ${{append_S}}$ adds a result to the current results.

Fig. 2:

Auxiliary functions ${{pop_S}}$ , ${{push_S,}}$ and ${{append_S}}$ .

Now, everything is in place to define a simulation function ${{nondet2state_S}}$ that interprets nondeterministic programs represented by the free monad ${{Free}\;{Nondet}_{{F}}\;{a}}$ as state-wrapped programs represented by the free monad ${{Free}\;({State}}_{{F}\;({S}\;{a}))\;()}$ .

The generator of this handler records a new result and then pops the next branch from the stack and proceeds with it. Likewise, for failure the handler simply pops and proceeds with the next branch. For nondeterministic choices, the handler pushes the second branch on the stack and proceeds with the first branch. The ${{nondet2state_S}}$ implements the depth-first search strategy which is consistent with the implementation of ${{h}}_{{ND}}$ Footnote ³ .

To extract the final result from the S wrapper, we define the ${{extract_S}}$ function.

Finally, we define the function ${{run}_{{ND}}}$ which wraps everything up to handle a nondeterministic computation to a list of results. The state handler ${{h}^\prime_{{State}}}$ is defined in Section 3.1.

We have the following theorem showing the correctness of the simulation via the equivalence of the ${{run}_{{ND}}}$ function and the nondeterminism handler ${{h}}_{{ND}}$ defined in Section 3.1.

Theorem 2.

The proof can be found in Appendix 3.1. The main idea is again to use fold fusion. Consider the expanded form

Both ${{nondet2state_S}}$ and ${{h}}_{{ND}}$ are written as folds. We use the law fusion-post’ (3.3) to fuse the left-hand side into a single fold. Since the right-hand side is already a fold, to prove the equation we just need to check the components of the fold ${{h}}_{{ND}}$ satisfy the conditions of the fold fusion, i.e., the following two equations: For the latter, we only need to prove the following two equations:

$\begin{align*}\begin{array}{rl} &(extract_{S}{\circ}{h}_{State}^{\prime}){\circ}{gen}\mathrel{=}{gen}_{ND} \\ &(extract_{S}{\circ}{h}_{State}^{\prime}){\circ}{alg}{\circ}{fmap}\;nondet2state_{S}\\ \mathrel{=}& {alg}_{ND}{\circ}{fmap}\;(extract_{S}{\circ}{h}_{State}^{\prime}){\circ}{fmap}\;nondet2state_{S}\end{array}\end{align*}$

where gen and alg are from the definition of ${{nondet2state_S}}$ , and ${{gen}_{{ND}}}$ and ${{alg}_{{ND}}}$ are from the definition of ${{h}}_{{ND}}$ .

5.2 Combining the simulation with other effects

The ${{nondet2state_S}}$ function only considers nondeterminism as the only effect. In this section, we generalize it to work in combination with other effects. One immediate benefit is that we can use it in together with our previous simulation ${{local2global}}$ in.Section 4.3.

Firstly, we need to augment the signature in the computation type for branches with an additional functor f for other effects. The computation type is essentially changed from ${Free}\;({State}_{F}\;{s})\;{a}$ to ${{Free}\;({State}}_{{F}\;{s}\mathrel{{:}{+}{:}}{f})\;{a}}$ . We define the state type ${{SS}\;{f}\;{a}}$ as follows:

We also modify the three auxiliary functions in Figure 2 to ${{pop}_{{SS}}}$ , ${{push}_{{SS}}}$ and ${{append}_{{SS}}}$ in Figure 3. They are almost the same as the previous versions apart from being adapted to use the new state-wrapper type ${{SS}\;{f}\;{a}}$ .

Fig. 3:

Auxiliary functions ${{pop}_{{SS}}}$ , ${{push}_{{SS}}}$ and ${{append}_{{SS}}}$ .

The simulation function nondet2state is also very similar to ${{nondet2state_S}}$ except for requiring a forwarding algebra fwd to deal with the additional effects in f.

The function ${{run}_{{ND+f}}}$ puts everything together: it translates the nondeterminism effect into the state effect and forwards other effects using ${{nondet2state}}$ , then handles the state effect using ${{h}_{{State}}}$ , and finally extracts the results from the final state using ${{extract}_{{SS}}}$ .

We have the following theorem showing that the simulation ${{run}_{{ND+f}}}$ is equivalent to the modular nondeterminism handler ${{h}_{{ND+f}}}$ in Section 3.2.

Theorem 3.

The proof proceeds essentially in the same way as in the non-modular setting. The main difference, due to the modularity, is an additional proof case for the forwarding algebra.

$\begin{array}{rl} &({extract}_{SS}{\circ}{h}_{State}){\circ}{fwd}{\circ}{fmap}\;nondet2state_{S}\\ {\mathrel{=}}& {fwd}_{ND+f}{\circ}{fmap}\;({extract}_{SS}{\circ}{h}_{State}){\circ}{fmap}\;nondet2state_{S}\end{array}$

The full proof can be found in Appendix 3.2.

6.1 Modelling two states with one state

When we combine the two simulation steps from the two previous sections, we end up with a computation that features two state effects. The first state effect is the one present originally, and the second state effect keeps track of the results and the stack of remaining branches to simulate the nondeterminism.

For a computation of type ${Free}\;({State}_{F}\;{s}_{1}\mathrel{{:}{+}{:}}{State}_{F}\;{s}_{2}\mathrel{{:}{+}{:}}{f})\;{a}$ that features two state effects, we can go to a slightly more primitive representation ${Free}\;({State}_{F}\;({s}_{1},{s}_{2})\mathrel{{:}{+}{:}}{f})\;{a}$ featuring only a single state effect that is a pair of the previous two states.

The handler states2state implements the simulation by projecting different get and put operations to different components of the pair of states.

We have the following theorem showing the correctness of states2state:

On the left-hand side, we write ${{h}_{{States}}}$ for the composition of two consecutive state handlers:

On the right-hand side, we use the isomorphism nest to mediate between the two different carrier types. The definition of nest and its inverse flatten are defined as follows:

where the isomorphism ${\alpha^{-1}}$ and its inverse ${\alpha}$ rearrange a nested tuple

The proof of Theorem 4 can be found in Appendix 4. Theorem 4 has two function compositions on the right-hand side, which would require using fusion twice, resulting in a complicated handler. To avoid this complexity, we show the correctness of the isomorphism of nest and flatten, and prove the following equation:

The following commuting diagram summarizes the simulation.

6.2 Putting everything together

We have defined three translations for encoding high-level effects as low-level effects.

• • The function local2global simulates the high-level local-state semantics with global-state semantics for the nondeterminism and state effects (Section 4).

• • The function nondet2state simulates the high-level nondeterminism effect with the state effect (Section 5).

• • The function states2state simulates multiple state effects with a single state effect (Section 6.1).

Combining them, we can encode the local-state semantics for nondeterminism and state with just one state effect. The ultimate simulation function simulate is defined as follows:

Similar to the ${{extract}_{{SS}}}$ function in Section 5.2, we use the extract function to get the final results from the final state.

Figure 4 illustrates each step of this simulation.

Fig. 4:

An overview of the simulate function.

In the simulate function, we first use our three simulations local2global, nondet2state and states2state to interpret the local-state semantics for state and nondeterminism in terms of only one state effect. Then, we use the handler ${{h}_{{State}}}$ to interpret the state effect into a state monad transformer. Finally, we use the function extract to get the final results.

We have the following theorem showing that the simulate function exactly behaves the same as the local-state semantics given by ${{h}_{{Local}}}$ .

The proof can be found in Appendix 5.

We provide a more compact and direct definition of simulate by fusing all the consecutive steps into a single handler:

The common carrier of the above algebras ${alg}_{1}\mathbin{\#}{alg}_{2}\mathbin{\#}{fwd}$ is ${{Comp}\;{s}\;{f}\;{a}}$ . This is a computation that takes the current results, choicepoint stack and application state, and returns the list of all results. The first two inputs are bundled in the CP type.

N-queens with only one state. With simulate, we can implement the backtracking algorithm of the n-queens problem in Section 2.3 with only one state effect as follows.

7.1 Reversible state updates

Our goal is to undo a state change without holding on to the old state. Instead, we should be able to recover the old state from the new state. However, knowing only the new state is usually not enough to accomplish this. We must also know “what update was applied to the old state that led to the new state”.

We reify the information about the update in a type u, which depends on the particular application at hand. For example, in the queens program of Section 2.3 we repeatedly update the state to place an additional queen on the board. Recall that a state s of type ${({Int},[ {Int}])}$ consists of the current column c and the partial solution sol, i.e., the rows of the already placed queens. Hence, the information we need to characterize an update is the row r of the queen to place in the current column, i.e., ${{u}\mathrel{=}{Int}}$ . The update itself is performed as ${{s}\mathbin{\oplus}{r}}$ , where

Now we can clearly recover the old state from the new state and the modification as follows:

Indeed, we clearly have ${({s}\mathbin{\oplus}{r})\mathbin{\ominus}{r}\mathrel{=}{s}}$ .

In general, we define a typeclass ${{Undo}\;{s}\;{u}}$ with two operations ${(\mathbin{\oplus})}$ and ${(\mathbin{\ominus})}$ to characterize reversible state updates. Here, s is the type of states and u is the type of updates.

Instances of Undo should satisfy the following law which says that ${\mathbin{\ominus}{x}}$ is a left inverse of ${\mathbin{\oplus}{x}}$ :

(7.1) $\begin{alignat}{2} &\mathbf{plus-minus}:\quad & {(\mathbin{\ominus}{x}){\circ }(\mathbin{\oplus}{x})} ~=~ & {{id}} \mbox{.}\end{alignat}$

7.2 Reversible state update effect

For our optimized approach to work, we have to restrict the way the state is changed in local-state programs. We no longer allow arbitrary ${{put}\;{s'}}$ calls to change the implicit state. The only supported changes are of the form ${{put}\;({s}\mathbin{\oplus}{u})}$ where ${{s}}$ is the current state.

To enforce this requirement, we replace the general ${{get}}/{{put}}$ interface provided by MState with the more restricted interface of a new type class:

This MModify class has three operations: a mget operation that reads and returns the state (similar to the get operation of MState), an update u operation that updates the state with the reversible state change u, and a ${{restore}\;{u}}$ operations that reverses the update u. Note that only the mget and update operations are expected to be used by programmers; restore operations are automatically generated by the translation to the global-state semantics.

The three operations satisfy the following laws:

(7.2)

(7.3)

(7.4)

(7.5)

The first law for ${{mget}}$ corresponds to that for get. The second and third law, respectively, capture the impact of update and restore on mget. Finally, the fourth law expresses that restore undoes the effect of update.

We can rewrite the queens program to make use of this MModify type class. Compared to the MState-based version in Section 2.3, we only need to replace get with mget and ${{put}\;({s}\mathbin{\oplus}{r})}$ with update r.

Like we did for the state effects in Section 3.1, we define a new signature Modify _F representing the syntax of modification-based state effects and implement the free monad ${{Free}\;({Modify}_{{F}}\;{s}\;{r}\mathrel{{:}{+}{:}}{f})}$ as an instance of ${{MModify}\;{s}\;{r}}$ .

Like the ${{h}_{{State}}}$ handler, the following ${{h}_{{Modify}}}$ handler maps this free monad to the StateT monad transformer, but now using the operations ${(\mathbin{\oplus})}$ and ${(\mathbin{\ominus})}$ provided by ${{Undo}\;{s}\;{r}}$ .

It is easy to check that the four laws hold contextually up to interpretation with ${{h}_{{Modify}}}$ .

Note that here we still use the StateT monad transformer and immutable states for the clarity of presentation and simplicity of proofs. The ${(\mathbin{\oplus})}$ and ${(\mathbin{\ominus})}$ operations also take immutable arguments. To be more efficient, we can use mutable states to implement in-place updates or use the technique of functional but in-place update (Lorenzen et al., Reference Lorenzen, Leijen and Swierstra2023). We leave them as future work.

Similar to Sections 4.1 and 4.2, the local-state and global-state semantics of ${{Modify}_{{F}}}$ and ${{Nondet}_{{F}}}$ are given by the following functions ${{h}_{{LocalM}}}$ and ${{h}_{{GlobalM}}}$ , respectively.

For example, the locate-state interpretation of ${{queens}_{{M}}}$ is obtained through:

7.3 Simulating local state with global state and undo

We can implement the translation from local-state semantics to global-state semantics for the modification-based state effects in a similar style to the translation local2global in Section 4.3. The translation ${{local2global_M}}$ still uses the mechanism of nondeterminism to restore previous state updates for backtracking. In Section 8, we will show a lower-level simulation of local-state semantics without relying on nondeterminism.

Compared to local2global, the main difference is that we do not need to copy and store the whole state. Instead, we store the update u and reverse the state update using ${{restore}\;{u}}$ in the second branch. The following theorem shows the correctness of local2global _M .

Theorem 6. Given ${{Functor}\;{f}}$ and ${{Undo}\;{s}\;{u}}$ , the equation

holds for all programs ${{p}\mathbin{::}{Free}\;({Modify}_{{F}}\;{s}\;{u}\mathrel{{:}{+}{:}}{Nondet}_{{F}}\mathrel{{:}{+}{:}}{f})\;{a}}$ that do not use the operation ${{Op}\;({Inl}\;{MRestore}\;\_\,\_ )}$ . The proof of this theorem can be found in Appendix 6.

As a consequence of the theorem, we can get the desired local-state behaviour for ${{queens}_{{M}}}$ by simulating it with global-state semantics as follows:

8.1 Simulating local state with global trail stack

Let us work out the trail stack idea in more detail. For that, we will need a second instance of the state effect. The primary one keeps track of the state featured in the local-state semantics. The new, secondary one keeps track of the trail stack. We can easily model this stack datastructure as a Haskell lists.

We store this stack in the secondary instance of the state effect, and we add and remove elements through the pushStack and popStack functions.

We store two types of entries in the trail stack. The first types are the reversible updates u (see Section 7) that we apply to the primary state. The second types are markers that mark the end of a batch on the trail stack; we represent these with the unit type (). Hence, we use the sum type ${{Either}\;{u}\;()}$ to use both as elements of the trail stack.

When we enter a left branch, we push a ${{Right}\;()}$ marker on the trail stack. For every state update u we perform in that branch, we push the corresponding ${{Left}\;{u}}$ entry on top of the marker. When we backtrack to the right branch, we unwind the trail stack down to the marker and reverse all updates along the way. This process is known as “untrailing”.

With the above trail stack functionality in place, the following translation function local2trail simulates the local-state semantics with global-state semantics by means of the trail stack.

As already informally explained above, this translation function 1) pushes updates to the trail tack, 2) pushes a marker to the trail stack in the left branch of a choice, and 3) untrails in the right branch. All other operations remain as is.

To ensure that pushStack and popStack access the secondary, trail-stack state in the above translation, we also need to define the following instance of MState.

Now, we can combine the simulation local2trail with the global-state semantics provided by ${{h}_{{GlobalM}}}$ , and handle the trail stack at the end.

The following theorem establishes the correctness of ${{h}_{{GlobalT}}}$ with respect to the local-state semantics given by ${{h}_{{Local}}}$ defined in Section 4.1.

Theorem 7. Given ${{Functor}\;{f}}$ and ${{Undo}\;{s}\;{u}}$ , the equation

holds for all programs ${{p}\mathbin{::}{Free}\;({Modify}_{{F}}\;{s}\;{u}\mathrel{{:}{+}{:}}{Nondet}_{{F}}\mathrel{{:}{+}{:}}{f})\;{a}}$ that do not use the operation ${{Op}\;({Inl}\;({MRestore}\;\_\,\_ ))}$ .

The proof can be found in Appendix 7; it uses the same fold fusion strategy as in the proofs of other theorems.

8.2 Putting everything together, again

We can further combine the local2trail simulation with the nondet2state simulation of nondeterminism from Section 5 and the state2state simulation of multiple states from Section 6.1. The resulting simulation encodes the local-state semantics with one modification-based state and two stacks, a choicepoint stack generated by nondet2state and a trail stack generated by local2trail. This has a close relationship to the WAM of Prolog. The modification-based state models the state of the program. The choicepoint stack stores the remaining branches to implement the nondeterministic searching. The trail stack stores the previous state updates to implement the backtracking.

The combined simulation function ${{simulate_T}}$ is defined as follows:

It uses the auxiliary function extractT to get the final results and to reorder the signatures. Note that the initial state used by extractT is ${({SS}\;[ ]\;[ ],{Stack}\;[ ])}$ , which contains an empty results list, an empty choicepoint stack, and an empty trail stack.

Figure 5 illustrates each step of this simulation. The state type ${{St}\;{s}\;{u}\;{f}\;{a}}$ is defined as ${{SS}\;({Modify}_{{F}}\;{s}\;{u}\mathrel{{:}{+}{:}}{State}}_{{F}\;({Stack}\;({Either}\;{u}\;()))\mathrel{{:}{+}{:}}{f})\;{a}}$ .

Fig. 5:

An overview of the ${{simulate_T}}$ function.

In the ${{simulate_T}}$ function, we first use our three simulations local2trail, nondet2state and states2state (together with some reordering of signatures) to interpret the local-state semantics for state and nondeterminism in terms of a modification-based state and a general state containing two stacks. Then, we use the handler ${{h}_{{Modify}}}$ to interpret the modification-based state effect, and use the handler ${{h}_{{State}}}$ to interpret the two stacks. Finally, we use the function extractT to get the final results.

As in Section 6.2, we can also fuse ${{simulate_T}}$ into a single handler.

Here, the carrier type of the algebras is ${{Comp}\;{f}\;{a}\;{s}\;{u}}$ . It differs from that of ${{simulate_F}}$ in that it also takes a trail stack as an input.

N-queens with two stacks. With ${{simulate_T}}$ , we can implement the backtracking algorithm of the n-queens problem with one modification-based state and two stacks.

9.1 Prolog

Prolog is a prominent example of a system that exposes nondeterminism with local state to the user, but is itself implemented in terms of a single, global state.

Warren abstract machine. The folklore idea of undoing modifications upon backtracking is a key feature of many Prolog implementations, in particular those based on the Warren Abstract Machine (WAM) Warren (Reference Warren1983); Aït-Kaci (1991). The WAM’s global state is the program heap and Prolog programs modify this heap during unification only in a very specific manner: following the union-find algorithm, they overwrite cells that contain self-references with pointers to other cells. Undoing these modifications only requires knowledge of the modified cell’s address, which can be written back in that cell during backtracking. The WAM has a special stack, called the trail stack, for storing these addresses, and the process of restoring those cells is called untrailing.

WAM derivation and correctness. Several authors have studied the derivation of the WAM from a specification of Prolog, and its correctness.

Börger and Rosenzweig (Reference Börger, Rosenzweig, Beierle and Plümer1995) start from an operational semantics of Prolog based on derivation trees and refine this in successive steps to the WAM. Their approach was later mechanized in Isabelle/HOL by Pusch (Reference Pusch1996). Pirog and Gibbons (Reference Pirog and Gibbons2011) sketch how the WAM can be derived from a Prolog interpreter following the functional correspondence between evaluator and abstract machine Ager et al. (Reference Ager, Danvy and Midtgaard2005).

Neither of these approaches is based on an abstraction of effects that separates them from other aspects of Prolog.

The 4-port box model. While trailing happens under the hood, there is a folklore Prolog programming pattern for observing and intervening at different point in the control flow of a procedure call, known as the 4-port box model. In this model, upon the first entrance of a Prolog procedure it is called; it may yield a result and exits; when the subsequent procedure fails and backtracks, it is asked to redo its computation, possibly yielding the next result; finally it may fail. Given a Prolog procedure p implemented in Haskell, the following program prints debugging messages when each of the four ports are used:

This technique was applied in the monadic setting by Hinze (Reference Hinze1996), and it has been our inspiration for expressing the state restoration with global state.

Functional models of prolog. Various authors have modelled (aspects of) Prolog in functional programming languages, often using monads to capture nondeterminism and state effects. Notably, Spivey and Seres (Reference Spivey and Seres1999) develop an embedding of Prolog in Haskell.

Most attention has gone towards modelling the nondeterminism or search aspect of Prolog, with various monads and monad transformers being proposed (Hinze, Reference Hinze2000; Kiselyov et al., Reference Kiselyov, Shan, Friedman and Sabry2005). Notably, Schrijvers et al. (Reference Schrijvers, Wu, Desouter and Demoen2014) shows how Prolog’s search can be exposed with a free monad and manipulated using handlers.

None of these works consider mapping high-level to low-level representations of the effects.

9.2 Reasoning about side effects

There are many works on reasoning and modelling side effects. Here, we cover those that have most directly inspired this paper.

Axiomatic reasoning. Gibbons and Hinze (Reference Gibbons and Hinze2011) proposed to reason axiomatically about programs with effects and provided an axiomatic characterization of local state semantics. Our earlier work in Pauwels et al. (Reference Pauwels, Schrijvers and Mu2019) was directly inspired by their work: we introduced an axiomatic characterization of global state and used axiomatic reasoning to prove handling local state with global state correct. We also provided models that satisfy the axioms, whereas their paper mistakenly claims that one model satisfies the local state axioms and that another model is monadic. This paper is an extension of Pauwels et al. (Reference Pauwels, Schrijvers and Mu2019), but notably, we depart from the axiomatic reasoning approach; instead we use proof techniques based on algebraic effects and handlers.

Algebraic effects. Our formulation of implementing local state with global state is directly inspired by the effect handlers approach of Plotkin and Pretnar (Reference Plotkin and Pretnar2009). By making the free monad explicit our proofs benefit directly from the induction principle that Bauer and Pretnar established for effect handler programs. While Lawvere theories were originally Plotkin’s inspiration for studying algebraic effects, the effect handlers community has for a long time paid little attention to them. Yet, Lukšič and Pretnar (Reference Lukšič and Pretnar2020) have investigated a framework for encoding axioms or effect theories in the type system: the type of an effectful function declares the operators used in the function, as well as the equalities that handlers for these operators should comply with. The type of a handler indicates which operators it handles and which equations it complies with. This allows expressing at the type level that a handler reduces a higher-level effect to a lower-level one.

Wu and Schrijvers (Reference Wu and Schrijvers2015) first presented fusion as a technique for optimizing compositions of effect handlers. They use a specific form of fusion known as fold–build fusion or short-cut fusion (Gill et al., Reference Gill, Launchbury and Peyton Jones1993). To enable this kind of fusion they transform the handler algebras to use the codensity monad as their carrier. Their approach is not directly usable because it does not fuse non-handler functions, and we derive simpler algebras (not obfuscated by the codensity monad) than those they do.

More recently, Yang and Wu (Reference Yang and Wu2021) have used the fusion approach of Wu and Schrijvers (Reference Wu and Schrijvers2015) (but with the continuation monad rather than the codensity monad) for reasoning; they remark that, although handlers are composable, the semantics of these composed handlers are not always obvious and that determining the correct order of composition to arrive at a desired semantics is nontrivial. They propose a technique based on modular handlers (Schrijvers et al., Reference Schrijvers, Piróg, Wu and Jaskelioff2019), which considers conditions under which the fusion of these modular handlers respect not only the laws of each of the handler’s algebraic theories but also additional interaction laws. Using this technique they provide succinct proofs of the correctness of local state handlers, constructed from a fusion of state and nondeterminism handlers.

Earlier versions. This paper refines and much expands on two earlier works of the last author.

Pauwels et al. (Reference Pauwels, Schrijvers and Mu2019) have the same goal as Section 4: it uses the state-restoring version of put to simulate local state with global state. It differs from this work in that it relies on an axiomatic (i.e., law-based), as opposed to handler-based, semantics for local and global state. This means that handler fusion cannot be used as a reasoning technique. Moreover, it uses a rather heavy-handed syntactic approach to contextual equivalence, and it assumes that no other effects are invoked.

Another precursor is the work of Seynaeve et al. (Reference Seynaeve, Pauwels and Schrijvers2020), which establishes similar results as those in Section 5.1. However, instead of generic definitions for the free monad and its fold, they use a specialized free monad for nondeterminism and ordinary recursive functions for handling. As a consequence, their proofs use structural induction rather than fold fusion. Furthermore, they did not consider other effects either.