Program Equivalence in the Erlang Actor Model

Abstract

This paper presents the formal semantics of concurrency in Core Erlang, an intermediate language for Erlang, along with a notion of program equivalence (based on barbed bisimulation) that is able to model equivalence between programs that have different communication structures but the same observable behaviour. The novelty in our formalisation is its extent: it includes semantics for messages and exit and link signals, in addition to most of Core Erlang’s sequential features. Furthermore, unlike previous studies, this work formalises message receipt using primitive operations, consistent with the standard as of Erlang/OTP 23. In this novel formalisation, we show some generally applicable program equivalences (such as process identifier renaming and silent evaluation) and present a practical case study featuring the equivalence of sequential and concurrent list processing.

1. Introduction

The main motivation of this work is to provide formal basis for reasoning about refactoring transformations of Erlang programs. Code refactoring is the process of improving the internal structure of a program without affecting its observable behaviour [1]. Admittedly, one of the main challenges of refactoring is correctness [2,3] as “refactoring might not always be behaviour-preserving in practice” [4]. Most refactoring tools lack a precise specification of how they affect the code, are only verified via testing, and in peculiar circumstances they can introduce bugs. Therefore, the majority of developers do not even use automated tools specifically designed for refactoring [2,3].

We aim to break the status quo and develop trustworthy refactoring tools with formal guarantees of behaviour-preservation, fostering tool-assisted refactoring. By using mathematical definitions of program behaviour and program equivalence, we can achieve high levels of assurance by carrying out machine-checked, formal proofs about behaviour-preservation of program transformations.

1.1. Our Target Language

This paper extends our previous work on the formalisation of (Core) Erlang [5,6], an impure, concurrent functional programming language featuring strict evaluation, uncurried function abstraction and application. In particular, our work here targets the concurrent subset of Core Erlang, by defining a modular formal semantics and program equivalence definitions for it, as a milestone towards reasoning about the correctness of refactoring concurrent programs. The language features we cover in this paper allow us to express and prove the behavioural equivalence of sequential and parallel algorithmic skeletons (such as map and pmap), a formal result strongly motivated and encouraged in [7].

(Core) Erlang implements and extends the actor model [8] to express concurrency. An Erlang node consists of processes (actors) which execute in their own memory. Communication between processes is achieved via asynchronous message passing; the messages sent from a process are placed at the end of the receiver’s mailbox and the receiver can select messages to handle (i.e., messages do not need to be processed in the order of their arrival).

In addition to messages, Erlang processes communicate via signals such as link, unlink, or exit [9]. These signals potentially modify the state of the process upon their arrival, without being placed into the mailbox. Links can be established and removed between processes with link and unlink signals. These links are bidirectional and serve as a way to notify a process with an exit signal when a linked process has terminated. Exit signals express termination, and, upon their arrival, a process can terminate, drop the signal, or convert it into a message and place it at the end of its mailbox. Processes also have different process flags. In this formalisation, we address the trap_exit flag; whenever this flag is set, exit signals will be converted into messages (except in very particular circumstances). Links and trapping exit signals are the main ingredients of building fault-tolerant Erlang systems.

1.2. Contributions

In this paper, we investigate the actor model of Core Erlang with the extensions mentioned above. Namely, we make the following contributions:

• An upgrade to the modular, frame stack style semantics for concurrent Core Erlang [10,11] (including a more refined semantics of message reception and exceptions);
• A notion of program equivalence for concurrent Core Erlang, based on bisimulation, that is able to model equivalence between programs that have different communication structures but the same observable behaviour;
• Concurrent program equivalence examples: We show that silent evaluation and process identifier renaming produce equivalent programs, and that transforming lists sequentially is equivalent to doing it concurrently;
• A machine-checked formalisation of the semantics and results concerning it in the Coq proof management system (we establish the link between the code and this paper in Appendix C).

The paper is structured as follows. In Section 2, we briefly summarise related and previous work, then Section 3 presents the formal semantics of concurrent Core Erlang. Section 4 defines bisimulations to argue about program equivalence, and shows some examples. Section 5 highlights theoretical and technical challenges, discusses the Coq implementation, and compares our work to tightly related research. Finally, Section 6 concludes the paper.

2. Related Work

In this section, we briefly summarise the related and our previous work on formal semantics for (Core) Erlang and program equivalence in the concurrent setup.

2.1. Erlang Semantics

Fredlund’s influential work [12] set the state of the art in the formal definition of the Erlang programming language. It follows the documentation [5] faithfully, including signals (such as exit and link), similar to our approach. However, unlike our definition, Fredlund’s semantics handles signal-passing as an atomic operation, while according to the “signal ordering guarantee” [9], this is not necessarily the case.

The work of Lanese et al. [13,14,15,16] defines the semantics of Core Erlang for a small subset of sequential Core Erlang expressions, messages, primitives for message-passing, and process creation. They express message-passing as non-atomic; however, the order of messages between a source and destination is not preserved in the ether, potentially violating Erlang’s semantics on signal ordering [9]. They also impose a restriction on their semantics: process identifiers can only appear as computation results (i.e., when evaluating self or spawn actions); however, the main limitation of their work is the language coverage of the semantics, for both the sequential and concurrent features.

Harrison’s [17] formalisation of Core Erlang is minimal, but it is implemented in Isabelle, which aided our Coq development. There is also related research on Core Erlang with the goal of causal debugging of concurrent programs [18], which defines a semantics of similar coverage to ours.

All the related work mentioned above models receive expressions as language primitives, while (as of OTP 23 [19]) message receipts are expressed with primitive operations. In this work, we address this change, but this comes with a number of drawbacks which we discuss in Section 5.

2.2. Bisimulation Approaches

The original notion of bisimulation has a long history [20,21,22]. Since then, multiple variants of bisimulations have been proposed. We rely on the notion of barbed bisimulation [23]. Barbed bisimulation explicitly defines what should be observed, and its weak variants do not compare how many and what steps the bisimilar systems take.

This notion of observational equivalence was successfully applied to Erlang-like languages: by Lanese et al. [16] to prove that PID renaming and evaluation without message arrives provide bisimilar Core Erlang nodes, and by Bocchi et al. [24] in an actor model variant with failures. There are also a number of proof techniques based on bisimulation (e.g., bisimulation up-to) [21], some of which were also discussed in [16]. In the future, we plan to adopt these ideas to aid in bisimulation proofs for Erlang refactorings.

2.3. Previous Work

In our previous work [11], we defined a frame stack semantics for the sequential sublanguage of Core Erlang, and investigated several program equivalence concepts in the sequential setup. Moreover, we also investigated the concurrency model of Core Erlang with a minimal sublanguage [10], also based on a frame stack semantics.

A frame stack semantics is essentially a small-step [25], reduction-style [26] semantics where the reduction context is split into a stack of basic evaluation frames [27]. In this semantics style, there are explicit rules to decompose the reduction context around a redex into a stack which represents the continuation of the evaluation. This semantics style is simpler to use in proof assistants because the reduction context does not need to be inferred; the aforementioned rules construct it explicitly.

This paper unites our two previous results [10,11], extends the formalisation for better language coverage (based on Fredlund’s work [12]), and adapts the techniques used by Lanese et al. [16] to argue about program equivalence. Although the theorems we discuss here were also proved by Lanese et al. [16], their proofs are mathematical, high-level proofs (for a restricted sublanguage of Core Erlang), whilst our results are also implemented in Coq as formal, machine-checked proofs.

Compared to our previous work, our semantics is extended with the formalisation of exceptions in the concurrent setup, spawn_link (spawning a process while creating a link) and expresses message receipt with primitive operations (as introduced in Erlang/OTP 23 [19]). We also define a more faithful representation of mailboxes and links which was necessary to handle the above-mentioned primitive operations correctly. In fact, to best of our knowledge, our formalisation is the first one to address this major change in message receipts.

3. Concurrent Formal Semantics

In this section, we describe the syntax and semantics of Core Erlang. The semantics presented here is modular and consists of three layers (see

Table 1. The layers of the semantics.

Layer Name	Notation	Description
Inter-process (Section 3.5)	${\stackrel{\iota :a}{\to }}_O$	System-level reductions
Process-local (Section 3.4)	$\stackrel{a}{\to }$	Process-level reductions
Sequential (Section 3.3)	⟶	Computational reductions

).

Reductions denoted with ⟶ are computational steps performed by the sequential frame stack semantics defined in our previous work [11]. Informally, $\langle K,r\rangle ⟶\langle K^{\prime },r^{\prime }\rangle$ means that in the frame stack (continuation) K, a redex r is rewritten to $r^{\prime }$ while the stack changes to $K^{\prime }$. Reductions denoted with $p\stackrel{a}{\to }{p}^{\prime }$ are the process-local steps, which involve one single process and communicate with the inter-process semantics by the actions. The inter-process semantics (denoted with $N{\stackrel{\iota :a}{\to }}_O{N}^{\prime }$) describes how communication is carried out between processes.

This section is structured as follows. In Section 3.1 we describe the formal syntax of Core Erlang, then in Section 3.3, Section 3.4 and Section 3.5 we define the semantics following the structure in Table 1. Section 3.6 discusses an example evaluation (on which we build a program equivalence proof in Example 2), and Section 3.7 presents substantial properties of the semantics.

3.1. Language Syntax

First, we recall the syntax of Core Erlang from our previous work [11] in Figure 1. We reuse the same notations and shorthands: lists from the metatheory are denoted with $e_1,\dots ,e_n$, and non-empty lists with $e_1,e_2,\dots ,e_n$. Appending an element to the front of a list is denoted with $x::l$, and for concatenation we use $l_1++l_2$.

We use i to range over integers, $a,f$ over atoms, and k over natural numbers. We use superscripts to denote the roles of expressions. Furthermore, x ranges over variables and $\iota$ over process identifiers. Integers (denoted with numbers), atoms (enclosed in single quotation marks), variables, empty and non-empty lists, tuples, and maps (tilde-enclosed tuples of key-value pairs, denoted with superscripts) form the patterns of the language. The set of values essentially consists of the same elements with the addition of function identifiers ($f/k$ atom-arity pairs), process identifiers (PIDs), and function closures (which include a list of functions $\mathit{fdefs}$ that can be applied recursively in the closure’s body).

In Core Erlang, the result of the evaluation is either a value sequence (denoted with $<v_1,\dots ,v_n>$ or $\mathit{vs}$) or an exception. While most expressions of the language evaluate to singleton value sequences, one can use value list expressions ($<e_1,\dots ,e_n>$) in binding expressions (such as case, let, letrec, or try) to bind multiple names simultaneously. Pattern-matching is expressed with case expressions; each case clause consists of a list of patterns to be matched, a guard, and a body expression (denoted with superscripts).

The set of expressions of Core Erlang also contains the values, lists, tuples, and maps containing expressions, sequencing (do), uncurried function abstraction (fun) and application (apply), inter-module function calls (call), and primitive operations (primop). Currently, the module system is not formalised; thus, inter-module calls only express standard and built-in functions (BIFs) [28] and their semantics is simulated in the metatheory.

Exceptions in Erlang implementations are represented by a triple: an exception class (which is an atom), and two values describing the reason of the exception and additional details about the exception (these are denoted with superscripts). These three values are bound in a catch clause of a try expression. For further details, see the language specification [6].

Compared to our previous work [11], the only syntactical addition is the syntax for PIDs; our previous results on the sequential sublanguage [11] still hold for this extension. The other concurrent features of the language (e.g., message sending and receiving) are expressed with BIF calls and primitive operations. As of Erlang/OTP 23 [19], receive expressions are defined as syntactic sugar on top of primitive operations (Figure 2), which are described in Section 3.4.

3.2. Running Example

As an example, we show that sequential and concurrent maps over lists behave in the same way: the expression in Figure 3 computes this mapping sequentially, while the code in Figure 4 splits the list into two parts, computes the transformation concurrently, then appends the two sub-lists. Hence, the reason both expressions send the transformed list to a particular PID $\iota$ as the final step of their evaluation: in Example 2 we reason about the equivalence of these expressions based on their observable behaviour, i.e., the outward communication they carry out.

Note that we use $c_{\mathit{map}}$ to denote the closure of the sequential list transforming function (inside letrec) in Figure 3. Also note that the labelled code segments are intended to ease understanding of Example 1 later, and they are not relevant at this point.

3.3. Sequential Semantics

For the sequential semantics, we reuse the frame stack semantics from our previous work [11] (also described in Appendix A) and we build the process-local and inter-process semantics on top of it, based on the prototype described in [10]. A sequential configuration consists of a frame stack and a redex. The syntax of redexes, frame stacks, and frames is described in Figure 5. Essentially, a frame is a compound expression with a hole in place of one of its subexpressions.

The frames for language elements, that include a list of subexpressions (i.e., tuples, value lists, maps, inter-module calls, primitive operations, and function applications) are expressed with parameter list frames $id(v_1,\dots ,v_{i-1},\square ,e_{i+1},\dots ,e_n)$. The frame identifier $\mathit{id}$ determines which language element the frame corresponds to. This way, the evaluation of a list of parameter expressions is expressed uniformly, without repeating the rules for each expression type.

The sequential reductions are denoted with $\langle K,r\rangle ⟶\langle K^{\prime },r^{\prime }\rangle$. In Figure 6, we only recall the evaluation rules for inter-module calls and primitive operations from our previous work. The complete definition can be found in [11] and Appendix A.

3.4. Process-Local Semantics

The process-local semantics describes the behaviour of a single process in response to an action. First, we define Core Erlang processes.

Definition 1 

(Core Erlang processes). A process (denoted with $p\in \mathit{Process}$) is either dead or alive.

• A live process is a quintuple $(K,r,q,L,b)$, where K denotes its frame stack, r is the redex currently evaluated, and q is the mailbox. L is the set of linked process identifiers, and b is a metatheoretical boolean value denoting the status of the trap_exit flag.
• A terminated (or dead) process (denoted with T) is a finite map of (linked) process identifiers to values.

Compared to related studies [10,12,16], we do not formalise the mailbox of a process as a single list of values but, rather, split it into seen and unseen messages (denoted with $[v_1,\dots ,v_m▸v_{m+1},\dots ,v_n]$ where $v_{m+1}$ is the first unseen message). This change was needed to correctly express the meaning of the primitive operations of message receipts [19], while it also narrows gap between the formalisation and the standard Erlang/OTP compiler. We formally define the mailbox operations on Figure 7. Incoming messages are placed at the end of the unseen message list. We can check the first unseen message (and its existence) in a mailbox. The first unseen message can be placed into the seen section of the mailbox. When a message is received, it is removed from the mailbox, and the remaining elements should all be scanned again for the next message receipt (i.e., they all become unseen). With this formalism, the entire mailbox can be pictured as follows:

$$[v_1,\dots ,v_m]++[v_{m+1},\dots ,v_n]$$

As mentioned before, the concurrent sublanguage of (Core) Erlang is based on the actor model [8]. Processes of (Core) Erlang communicate with asynchronous message-passing and signals; in fact, messages are just one particular kind of signal. In this paper, we consider four signal types, while there are several others [9].

Definition 2 

(Signals).

$$\begin{array}{cc}\hfill s\in \mathit{Signal}& ::=\mathit{msg}\left(v\right)\mid \mathit{exit}(v,b)\mid \mathit{link}\mid \mathit{unlink}\hfill \end{array}$$

• Messages are values that are sent from one process and placed into the mailbox of another process.
• Link signals communicate that two processes should be linked. Links are bidirectional; when one of the processes terminates, it will notify the other process with an exit signal.
• Unlink signals indicate that the link between two processes should be removed.
• Exit signals are used to indicate runtime errors. Terminated processes send them to their links, but they can be created and sent manually (with the ‘exit’/2 BIF) too. Exit signals include a value describing the reason of termination and a boolean flag of whether they have been triggered by a link.

Actions represent the effects that characterise concurrency; they unambiguously define the next reduction a process should take, while they also include the necessary data from the context to make this step (e.g., in the case of message sending, these data consist of PID of the sender, PID of the receiver, and the message value). The syntax of signals and actions are shown below.

Definition 3 

(Actions).

$$\begin{array}{cc}\hfill a\in \mathit{Action}& ::=\mathit{send}({\iota }^s,{\iota }^d,s)\mid \mathit{arr}({\iota }^s,{\iota }^d,s)\mid \mathit{self}\left(\iota \right)\mid \mathit{spawn}(\iota ,v_1,v_2,b)\mid \tau \mid \epsilon \hfill \end{array}$$

We call τ and $\mathit{self}\left(\iota \right)$ silent actions. We use ${\iota }^s$ to emphasise that this PID is a source of a signal, while ${\iota }^d$ denotes target (destination) PIDs.

• Signals can be sent, and they can arrive at processes. These actions include the sender’s (${\iota }^s$) and receiver’s (${\iota }^d$) PIDs. Note that signal-passing is not instantaneous; signals reside in “the ether” before their arrival. This behaviour is expressed with the inter-process semantics (we refer to Section 3.5).
• A process can obtain its PID with $\mathit{self}\left(\iota \right)$ from the inter-process semantics.
• A process can spawn another process to evaluate a function with $\mathit{spawn}(\iota ,v_1,v_2,b)$. $\iota$ is the PID of the spawned process given by the inter-process semantics, $v_1$ should be a closure value, and $v_2$ should be a (Core) Erlang list of parameters. The flag b denotes whether the spawned process should be linked to its parent (when evaluating spawn_link).
• We use $\tau$ actions to denote reductions of the computational (sequential) layer and some process-local steps for which the system is strongly confluent (formally defined in Theorem 4).
• The local reduction steps are denoted with $\epsilon$ actions. These steps affect either the mailbox, the set of links, or the process flag (besides the frame stack and the redex) of a process, and they are not confluent with the other actions.

Before delving into discussing the rules of the process-local semantics, we introduce the following notations for readability.

• $\lambda x\Rightarrow b$ is used to denote functions of the metatheory.
• $\mathit{ff}$ denotes metatheoretical false, and $\mathit{tt}$ denotes metatheoretical true.
• $\mathit{map}(f,l)$ is a higher-order function of the metatheory, transforming all elements of the (metatheoretical) container l (list or set) by applying the (metatheoretical) function f to them.
• $\mathit{to}\_\mathit{obj}\left(y\right)$ is used to transform the metatheoretical (list or boolean) value y to a Core Erlang value (a list or ‘true’ or ‘false’ atoms).
• $\mathit{to}\_\mathit{meta}\left(v\right)$ is used to transform the Core Erlang value v to its metatheoretical counterpart. The result of this function is of option type; it is $\mathit{None}$ for unsuccessful conversion, or the metatheoretical counterpart enclosed in $\mathit{Some}$.
• $M\left[k\right]$ denotes the value enclosed in $\mathit{Some}$ associated with the key k in a finite map M, if it exists. Otherwise, the result is $\mathit{None}$.
• $M\setminus k$ denotes removing the value associated with the key k from the finite map M.

Next, we briefly discuss the rules of the process-local semantics, categorised into 4 groups:

• Semantics of signal arrival (Figure 8);
• Semantics of signal sending (Figure 9);
• Semantics of spawn and self (Figure 10);
• Semantics of local actions (Figure 11).

We start the explanation with the rules about signal arrival. We note that the Erlang reference manual [9] does not express the behaviour of signal arrival precisely (although, there are no inconsistencies). Thus we determined the sufficient premises of the following rules by testing the reference implementation (also reported in [10]).

• Rule Msg shows that incoming messages are appended to the list of unseen messages in the mailbox.
• Rules ExitDrop, ExitTerm, and ExitTrap describe the arrival of an exit signal. Based on the set of links L, the state of the trap_exit flag b, the reason value v, and the link flag $b_e$ of the exit signal, and the source ${\iota }^s$ and destination ${\iota }^d$ PIDs, there are three different behaviours.

  -

  Rule ExitDrop drops the exit signal if its reason was ‘normal’ or it came from an unlinked process and was triggered by a link.

  -

  Rule ExitTerm terminates the process, by transforming it into a dead process which will notify its links with the reason of the termination (each linked PID is associated with this reason value). This rule can be applied in three scenarios: (a) the exit’s reason is ‘kill’ and it was sent manually (in this case, the reason is changed to ‘killed’); (b) exits are not trapped, and a non-‘normal’ exit either came from a linked process or was sent manually with a non-‘kill’ reason; (c) exits are not trapped, and the process terminated itself with an exit signal with ‘normal’ reason.

  -

  Rule ExitTrap “traps” the exit signal by converting it into a message that is appended to the mailbox. This rule can be used if the process traps exits, the incoming signal is either triggered by a link, or its reason is not ‘kill’.

• Rule LinkArr and UnlinkArr describe the arrival of $\mathit{link}$ and $\mathit{unlink}$ signals, which modify the set of the linked PIDs.

Next, we discuss rules about signal sending (Figure 9). Note that all the first frames in the following rules use frame identifiers from Figure 5 inside a parameter list frame $\mathit{id}(v_1,\dots ,v_{i-1},\square )$ which includes the normal forms of its subexpressions.

• Rule Send describes message sending. This BIF reduces to the message value which is also communicated to the inter-process semantics inside the send action.
• Rule Exit describes manual exit signal sending. In this case, the result is ‘true’ while the exit signal is communicated to the inter-process semantics. The link flag of the signal is ff, since it is sent manually.
• Rules Link and Unlink describe sending link and unlink signals. Both evaluate to ‘ok’ while adding or removing a PID from the set of links, and communicating the corresponding action to the inter-process level.
• Rule Dead describes the communication of a dead process. Dead processes send an exit signal to all the linked processes with the given reason value. The flag of the signal is tt, since it is triggered by a link.

Thereafter, we describe how $\mathit{self}$ and $\mathit{spawn}$ BIFs evaluate.

• Rule Self reduces to the PID of the current process which is obtained from the inter-process level in the action $\mathit{self}$.
• Rules Spawn and SpawnLink describe process spawning. The spawned process will evaluate the given function applied to the given parameters, which are communicated to it within the $\mathit{spawn}$ action. To be able to evaluate this function application, the parameters of spawn are required to be a closure and a proper Core Erlang list. The result is the PID of the spawned process which is obtained from the inter-process semantics in the $\mathit{spawn}$ action. In the case of rule SpawnLink, the flag in the spawn action is also set, and a link is established to the spawned PID.

Finally, we describe rules about process-local steps (Figure 11). Unlike in previous work [10,12,16], we express rules about message receipts with primitive operations; since receive expressions have been removed from the primitives of Core Erlang in OTP 23 [19], they are automatically expanded to the primitive operations.

• Rule Seq lifts the sequential steps to the process-local level.
• Rule Flag changes the state of the trap_exit flag of the process to the provided boolean value, and its result is the original value of the flag. Rule FlagExc raises an exception, if a non-boolean value was provided.
• Rule Term describes the normal termination. The links are notified with exit signals with ‘normal’ reason.
• Rule TermExc describes the behaviour when an exception terminates the process. Each linked process is notified with an exit signal which includes the exception’s reason.
• Rule Peek checks the first unseen message (if it exists). The result is a value sequence consisting of ‘true’ and the said message.
• Rule PeekFail is used if there are no unseen messages in the mailbox. The result is a value sequence consisting of ‘false’ and an error value (which can be neither observed in the implementations, nor in the generated BEAM code).
• Rule RecvNext moves the first unseen message into the list of seen messages (if it exists).
• Rule RemoveMsg removes the first unseen message from the mailbox and sets all messages as unseen hereafter.
• Rule WaitInf describes the semantics of unblocking. This rule is used if there is an unseen message, otherwise the process is blocked until one arrives. The result ‘false’ indicates that the timeout (‘infinity’) was not reached.
• Rule Wait0 always evaluates to ‘true’, indicating that a timeout was reached. Currently, we have not formalised the timing; thus, only 0 and ‘infinity’ timeouts are modelled; however, we plan to change this in the future.
• Rule WaitExc evaluates to an exception when an invalid timeout value (i.e., non-integer and non-infinity) was used.

3.5. Inter-Process Semantics

After having the process-local semantics defined, we turn our attention to the inter-process (node-level) semantics, which defines how actions should be propagated among processes. The main advantage of this semantics is its simplicity—it is described with only four rules. First, we define the notion of process pools.

Definition 4 

(Process pool). A (process) pool Π is a finite map (associative list) which assigns PIDs to processes.

In (Core) Erlang, signal passing is not atomic. According to the reference manual [9] “The amount of time that passes between the time a signal is sent and the arrival of the signal at the destination is unspecified but positive”; thus, we need to store these signals in an ether until they arrive. Moreover, this ether should respect the signal-ordering, i.e., “if an entity sends multiple signals to the same destination entity, the order is preserved” [9].

Definition 5 

(Ether). An ether is a finite map (associative list) which assigns a pair of PIDs (representing the source and destination of signals) to a list of signals. We denote ethers with Δ.

Definition 6 

(Node). A Core Erlang node N is a pair of a process pool and an ether. We use $N^{\Pi }$ and $N^{\Delta }$ for the pool and ether of N.

Before discussing the four rules of the inter-process semantics, we introduce a number of notations for ethers and process pools.

• $\iota :p\Vert \Pi$ denotes the pool consisting of process p (associated with PID $\iota$) and pool $\Pi$.
• $\Delta [({\iota }^s,{\iota }^d)\mapsto l]$ updates the ether $\Delta$ by binding the pair of PIDs $({\iota }^s,{\iota }^d)$ to the list of signals l.
• $\Delta \left[({\iota }^s,{\iota }^d){\mapsto }^{+}s\right]$ appends a signal s to the end of the list associated with $({\iota }^s,{\iota }^d)$ in the ether $\Delta$. If there is nothing associated with the given source and destination, this function creates a singleton list associated with the given PIDs.
• $\mathit{remFirst}(\Delta ,{\iota }^s,{\iota }^d)$ removes the first signal from the list associated with $({\iota }^s,{\iota }^d)$ from $\Delta$. Its result is of option type, if there is a signal to remove, the result is this signal and the modified ether enclosed in $\mathit{Some}$, otherwise $\mathit{None}$.
• $\mathit{PIDsOf}(\Delta )$ and $\mathit{PIDsOf}(\Pi )$ denote the PIDs that appear in $\Delta$ or $\Pi$, respectively. A PID appears in an ether if it is used as a source or destination of a signal, or if it appears syntactically in one of the signals stored in the ether. Respectively, a PID appears in a pool if there is a process associated with it, or it appears inside a process syntactically.
• $\mathit{eval}(v^f,v_1,\dots ,v_k)$ notation is taken from [11]; here, we only use it to express beta-reduction of $v_f$ with the parameters $v_1,\dots ,v_k$. For more details, refer to Appendix A and [11].

Next, we discuss the semantics rules (shown in Figure 12). In general, all rules propagate an action to one of the processes inside the process pool, potentially changing the ether or creating new processes.

Remark 1. 

The rules of the inter-process semantics are decorated with a set of PIDs O; these PIDs are considered as observed, and no processes can be spawned on them. The communication to the PIDs in O is used to express the observable behaviour in bisimulation definitions in Section 4.

• Rule NSend describes signal sending. When a process (associated with ${\iota }^s$) sends a signal to ${\iota }^d$, this signal is placed into the ether with the source ${\iota }^s$ and destination ${\iota }^d$.
• Rule NArrive removes the first signal from the ether (with some source ${\iota }^s$) to deliver to the process with PID ${\iota }^d$.
• Rule NSpawn describes process creation. When a process reduces with a $\mathit{spawn}$ action, the inter-process semantics assigns a fresh and unobserved PID ${\iota }_2$ to the new process which will evaluate the given closure applied to the given parameters of the $\mathit{spawn}$ action. If the flag in the $\mathit{spawn}$ action is set (i.e., spawn_link has been evaluated in the process), a link to the parent process is also established. Whether $v^f$ is a closure and the third parameter of spawn is a proper Core Erlang list of values are checked in the process-local semantics (in rules Spawn and SpawnLink).
• Rule NLocal defines that every other action should be only propagated to the process-local level without modifying the ether, or creating new processes.

We use $N\stackrel{l}{{\to }_O^{*}}{N}^{\prime }$ to denote the reflexive transitive closure of the semantics, where l is the evaluation trace of PID-action pairs. We write $N\stackrel{a}{{\to }_O^{*}}{N}^{\prime }$ if the trace only consists of actions a (and its length is irrelevant), and omit the trace entirely if it is not relevant.

3.6. Example Evaluation

In this section, we show example evaluations for our running example presented in Figure 4, where we instantiate the metavariables in the following way (we keep $\iota$ as arbitrary):

$$\begin{array}{cc}\hfill e_l& :=\left[\mathtt{1}\right|\left[\mathtt{2}\right|\left[\mathtt{3}\right|\left[\mathtt{4}\right|\left[\right]\left]\right]\left]\right]i:=2\hfill \\ \hfill e_f& \mathtt{:}\mathtt{=}\mathtt{fun}\mathtt{\left(}\mathtt{X}\mathtt{\right)}\mathtt{\to }\mathtt{call} \mathtt{‘}\mathtt{erlang}\mathtt{’}:\mathtt{‘}\mathtt{+}\mathtt{’}\mathtt{(}\mathtt{X}\mathtt{,}\mathtt{1}\mathtt{)}\hfill \end{array}$$

We remind the reader that the closure of the sequential list processing ($c_{\mathit{map}}$ evaluated as the result closure of the letrec expression in Figure 3) is already substituted correctly.

Example 1 

(Concurrent map evaluation). We use the following shorthands for the evaluation. We note that we also labelled the code presented in Figure 2, Figure 3 and Figure 4 with the following shorthands to ease understanding.

• $e_{\mathit{pmap}}$ denotes the expression presented in Figure 4;
• $c_{\mathit{child}}$ denotes the closure for the spawned process:

  $$\mathit{clos}(\varnothing ,[\mathtt{S},\mathtt{L}],\mathtt{call}\mathtt{‘}\mathtt{erlang}\mathtt{’}\mathtt{:}\mathtt{‘}\mathtt{!}\mathtt{’}(\mathtt{S},\mathtt{apply}{\mathit{c}}_{\mathit{map}}(e_f,\mathtt{L})));$$
• $e_{\mathit{let}}$ denotes the second subexpression of the  do  expression from Figure 4, which processes the list suffix sequentially, and receives the result from the child process;
• $e_{\mathit{case}}$ denotes the outermost  case  expression (checking the result of peeking the mailbox) from Figure 2 substituted with the two cases of the  receive  expression in Figure 4;
• $e_{\mathit{reccase}}$ denotes the innermost  case  expression (substituted with the concrete values in the  receive  expression of Figure 4) from Figure 2 which checks the result of the timeout;
• ${\mathit{cl}}_1,{\mathit{cl}}_2$ denote the clauses of the  case  expression of Figure 3.
• $v^l$ is used for the transformed list [2|[3|[4|[5|[]]]]], and $v_1^l$ for the transformed prefix [2|[3|[]]].

Next, we present multiple ways to evaluate concurrent list transformation. For brevity, we show the sequential configurations, since the set of linked processes and the process flag does not influence this evaluation (i.e., they can be arbitrary for both the parent and the child process), and show the mailbox separately. First, we show the configurations for the parent in which a non-silent reduction can happen or happened, and the initial state:

$$\begin{array}{ccc}\hfill & \langle \epsilon ,e_{\mathit{pmap}}\rangle \hfill & \hfill \left(p_{\mathit{start}}\right)\\ \hfill & \langle \mathit{call}(\mathtt{‘}\mathtt{erlang}\mathtt{’},\mathtt{‘}\mathtt{spawn}\mathtt{’})(c_{\mathit{child}},\square )::\mathtt{do}\square e_{\mathit{let}}::\epsilon ,\left[\mathtt{1}\right|\left[\mathtt{2}\right|\left[\right]]]\rangle \hfill & \hfill \left(p_{\mathit{spawn}}\right)\\ \hfill & \langle \mathtt{do}\square e_{\mathit{let}}::\epsilon ,<{\iota }_{\mathit{c}}>\rangle \hfill & \hfill \left(p_{\mathit{do}}\right)\\ \hfill & \langle \mathit{primop}(\mathtt{‘}\mathtt{recv}\_\mathtt{peek}\_\mathtt{message}\mathtt{’})(\square )::\hfill \\ \hfill & ::\mathtt{let}<\mathtt{Success},\mathtt{Msg}>=\square \mathtt{in}{e}_{\mathit{case}}::\epsilon ,\square \rangle \hfill & \hfill \left(p_{\mathit{peek}}\right)\\ \hfill & \langle \mathtt{let}<\mathtt{Success},\mathtt{Msg}>=\square \mathtt{in}{e}_{\mathit{case}}::\epsilon ,<\mathtt{‘}\mathtt{false}\mathtt{’},\mathtt{‘}\mathtt{error}\mathtt{’}>\rangle \hfill & \hfill \left(p_{\mathit{fail}}\right)\\ \hfill & \langle \mathit{primop}(\mathtt{‘}\mathtt{recv}\_\mathtt{wait}\_\mathtt{timeout}\mathtt{’})(\square )::\hfill \\ \hfill & ::\mathtt{let}=\square \mathtt{in}{e}_{\mathit{reccase}}::\epsilon ,<\mathtt{‘}\mathtt{infinity}\mathtt{’}>\rangle \hfill & \hfill \left(p_{\mathit{wait}}\right)\\ \hfill & \langle \mathit{call}(\mathtt{‘}\mathtt{erlang}\mathtt{’},\mathtt{‘}!\mathtt{’})(\iota ,\square )::\epsilon ,<\left[\mathtt{2}\right|\left[\mathtt{3}\right|\left[\mathtt{4}\right|\left[\mathtt{5}\right|\left[\right]]]]]>\rangle \hfill & \hfill \left(p_{\mathit{send}}\right)\\ \hfill & \langle \epsilon ,<\left[\mathtt{2}\right|\left[\mathtt{3}\right|\left[\mathtt{4}\right|\left[\mathtt{5}\right|\left[\right]\left]\right]\left]\right]>\rangle \hfill & \hfill \left(p_{\mathit{final}}\right)\end{array}$$

The child process can also be in three such states where non-silent actions can happen. We present these and the child’s initial state:

$$\begin{array}{ccc}\hfill & \langle \epsilon ,\mathtt{case}\left[\mathtt{1}\right|\left[\mathtt{2}\right|\left[\right]]]\mathtt{of}{\mathit{cl}}_1;{\mathit{cl}}_2\mathtt{end}\rangle \hfill & \hfill \left(c_{\mathit{start}}\right)\\ \hfill & \langle \mathit{call}(\mathtt{‘}\mathtt{erlang}\mathtt{’},\mathtt{‘}!\mathtt{’})({\iota }_{\mathit{p}},\square )::\epsilon ,<v_1^l>\rangle \hfill & \hfill \left(c_{\mathit{send}}\right)\\ \hfill & \langle \epsilon ,<v_1^l>\rangle \hfill & \hfill \left(c_{\mathit{final}}\right)\\ \hfill & \varnothing \hfill & \hfill \left(c_{\mathit{term}}\right)\end{array}$$

We highlight possible execution paths for the concurrent list transforming function. In Figure 13, we show the decision points where it matters which action to evaluate first. The semantics is strongly confluent for silent actions according to Theorems 3 and 4; thus, the order of silent reductions does not matter. For this reason, we do not discuss these steps (but refer to Appendix B for an example). In Figure 13, we use the notations below for the states of the node and denote silent reduction chains with (*). In the following list of pairs, the first component denotes the ether, the second the process pool consisting of at most the parent and child process, and the parent’s mailbox is explicitly described (the child’s mailbox is empty in all steps). The node’s subscripts highlight the next BIF that the parent has to evaluate, while the superscripts denote the remaining actions that can happen in the given configuration.

• $N_{start}$ = ($\varnothing ,(p_{start},[▸]$))
• $N_{spawn}$$=(\varnothing ,(p_{spawn},[▸]))$
• $N_{spawnafter}$$=(\varnothing ,(p_{do},[▸])\Vert c_{start})$
• $N_{peek}^{send}$$=(\varnothing ,(p_{peek},[▸])\Vert c_{send})$
• $N_{peekfail}^{send}$$=(\varnothing ,(p_{fail},[▸])\Vert c_{send})$
• $N_{peek}^{msg,term}$$=(\varnothing \left[({\iota }_{\mathit{c}},{\iota }_{\mathit{p}}){\mapsto }^{+}{v}_1^l\right],(p_{peek},[▸])\Vert c_{final})$
• $N_{peekfail}^{msg,term}$$=(\varnothing \left[({\iota }_{\mathit{c}},{\iota }_{\mathit{p}}){\mapsto }^{+}{v}_1^l\right],(p_{fail},[▸])\Vert c_{final})$
• $N_{wait}^{send}$$=(\varnothing ,(p_{wait},[▸])\Vert c_{send})$
• $N_{peekfail}^{msg}$$=(\varnothing \left[({\iota }_{\mathit{c}},{\iota }_{\mathit{p}}){\mapsto }^{+}{v}_1^l\right],(p_{fail},[▸])\Vert c_{term})$
• $N_{peek}^{msg}$$=(\varnothing \left[({\iota }_{\mathit{c}},{\iota }_{\mathit{p}}){\mapsto }^{+}{v}_1^l\right],(p_{peek},[▸])\Vert c_{term})$
• $N_{peek}^{term}$$=(\varnothing ,(p_{peek},[▸v_1^l])\Vert c_{final})$
• $N_{wait}^{term}$$=(\varnothing ,(p_{wait},[▸v_1^l])\Vert c_{final})$
• $N_{wait}^{msg,term}$$=(\varnothing \left[({\iota }_{\mathit{c}},{\iota }_{\mathit{p}}){\mapsto }^{+}{v}_1^l\right],(p_{wait},[▸])\Vert c_{final})$
• $N_{peek}$$=(\varnothing ,(p_{peek},[▸v_1^l])\Vert c_{term})$
• $N_{send}^{term}$$=(\varnothing ,(p_{send},[▸])\Vert c_{term})$
• $N_{wait}^{msg}$$=(\varnothing \left[({\iota }_{\mathit{c}},{\iota }_{\mathit{p}}){\mapsto }^{+}{v}_1^l\right],((p_{wait},[▸])\Vert c_{term})$
• $N_{send}$$=(\varnothing ,(p_{send},[▸])\Vert c_{term})$
• $N_{term}$$=(\varnothing \left[({\iota }_{\mathit{p}},\iota ){\mapsto }^{+}{v}^l\right],(p_{final},[▸])\Vert c_{term})$
• $N_{wait}$$=(\varnothing ,(p_{wait},[▸v_1^l])\Vert c_{final})$
• $N_{final}$$=(\varnothing \left[({\iota }_{\mathit{p}},\iota ){\mapsto }^{+}{v}^l\right],p_{final},[▸])\Vert c_{final})$

The evaluation starts with the parent splitting the list in half (since $i=2$), and spawning the child process ($N_{start}$, $N_{spawn}$, $N_{spawned}$). Next, both the parent and child process evaluate the map function sequentially for their list segments reaching $N_{peek}^{send}$ (for this evaluation, we refer to Appendix B, Example A1). At this point, either the child sends its result to the parent, or the parent fails to evaluate‘recv_peek_message’. Actually, the child can even send the message ($N_{peekfail}^{msg,term}$), and terminate ($N_{peekfail}^{msg}$), while the parent still fails on‘recv_peek_message’, because the message has not been delivered yet (with Msg).

If the parent failed in either of the previous steps, it becomes stuck on an infinite timeout, until the message from the child arrives. Next, the parent continues the evaluation of the message receipt recursively (see Figure 2), and retries peeking into the mailbox. This leads to $N_{peek}^{term}$ (if the child is not yet terminated) or $N_{peek}$ (if the child is already terminated). If the parent tried peeking into the mailbox only after the message had arrived (i.e., peeking had never failed), then one of the previous two states was reached, too.

Finally, the parent successfully receives the transformed list from the child (reaching either $N_{send}^{term}$ or $N_{send}$); then it appends the two segments and sends the result to the observed PID ι.

3.7. Semantic Properties

Next, we show a number of properties of the concurrent semantics, and for their proofs, we refer to the formalisation [29], and to Appendix C, which connects the concepts of this paper, to the code. First, we state that our semantics respects the signal ordering guarantee [9].

Theorem 1 

(Signal ordering guarantee). For all nodes $N_1$, $N_2$, $N_3$, PIDs $\iota ,{\iota }^{\prime }$, and unique signals (i.e., they are different from any other signal in the starting configuration). $s_1\ne s_2$, if $N_1{\stackrel{\iota :\mathit{send}(\iota ,{\iota }^{\prime },s_1)}{\to }}_O{N}_2$ and $N_2{\stackrel{\iota :\mathit{send}(\iota ,{\iota }^{\prime },s_2)}{\to }}_O{N}_3$, then for all nodes $N_4$ and action traces l which satisfy $N_3\stackrel{l}{{\to }_O^{*}}{N}_4$ and also $({\iota }^{\prime },\mathit{arr}(\iota ,{\iota }^{\prime },s_1))\notin l$ then $\nexists N_5:N_4{\stackrel{{\iota }^{\prime }:\mathit{arr}(\iota ,{\iota }^{\prime },s_2)}{\to }}_O{N}_5$ (i.e., there is no node at which $s_2$ can arrive).

To reason about process creation in later sections, it is inevitable to reason about PID renaming. We use renaming when arguing about process spawns because in most cases, the freshness criteria imposed by NSpawn is too weak as it depends only on O and the node the spawn is evaluated in. In some cases, there could be other PIDs that should be distinct from the spawned one (e.g., when reasoning about node equivalence).

Definition 7 

(PID renaming). We denote PID renaming with $r[{\iota }_1\mapsto {\iota }_2]$, which syntactically replaces all occurrences of ${\iota }_1$ with ${\iota }_2$ inside a redex r. For simplicity, we use the same notation for frame stacks, mailboxes, lists, and live processes.

We denote PID renaming for finite maps (dead processes, ethers, process pools, and nodes) with $N[{\iota }_1\leftrightarrow {\iota }_2]$. For these syntactical constructs, renaming is the syntactical exchange of the given two PIDs. With this notion, we avoid accidental overwriting of existing bindings in a finite map.

Given a list of PID pairs $[({\iota }_1,{\iota }_1^{\prime }),\dots ,({\iota }_n,{\iota }_n^{\prime })]$, we use $r[{\iota }_1\mapsto {\iota }_1^{\prime },\dots ,{\iota }_n\mapsto {\iota }_n^{\prime }]$ (and $N[{\iota }_1\leftrightarrow {\iota }_1^{\prime },\dots ,{\iota }_n\leftrightarrow {\iota }_n^{\prime }]$) for sequential renaming, i.e., $r[{\iota }_1\mapsto {\iota }_1^{\prime }]\dots [{\iota }_n\mapsto {\iota }_n^{\prime }]$ ($N[{\iota }_1\leftrightarrow {\iota }_1^{\prime }]\dots [{\iota }_n\leftrightarrow {\iota }_n^{\prime }]$, respectively).

PIDs cannot be renamed freely while reasoning about program equivalence; we have to make sure that we do not bind observed or used PIDs while renaming. This property is expressed with the following two compatibility definitions. Node-compatibility ensures that a renaming satisfies the freshness conditions, and action-compatibility ensures that this freshness condition is respected by the reductions with the given actions.

Definition 8 

(Node-compatible renaming). A list of PID pairs $[({\iota }_1,{\iota }_1^{\prime }),\dots ,({\iota }_n,{\iota }_n^{\prime })]$ is compatible with a node N and observable PIDs O, if for all indices i the following points are all satisfied:

• ${\iota }_i,{\iota }_i^{\prime }\notin O$;
• ${\iota }_i^{\prime }\notin \mathit{PIDsOf}(N^{\Delta }[{\iota }_1\leftrightarrow {\iota }_1^{\prime },\dots ,{\iota }_{i-1}\leftrightarrow {\iota }_{i-1}^{\prime }])$;
• ${\iota }_i^{\prime }\notin \mathit{PIDsOf}(N^{\Pi }[{\iota }_1\leftrightarrow {\iota }_1^{\prime },\dots ,{\iota }_{i-1}\leftrightarrow {\iota }_{i-1}^{\prime }])$.

Definition 9 

(Action-compatible renaming). A list of PID pairs $[({\iota }_1,{\iota }_1^{\prime }),\dots ,({\iota }_n,{\iota }_n^{\prime })]$ is compatible with an action a, if for all indices i, ${\iota }_i^{\prime }\notin \mathit{PIDsOf}(a[{\iota }_1\mapsto {\iota }_1^{\prime },\dots ,{\iota }_{i-1}\mapsto {\iota }_{i-1}^{\prime }])$.

We note that we can always define a compatible renaming for a node or action based on fresh PIDs. Next, we show that node and action-compatible renamings preserve the semantics.

Theorem 2 

(Renaming preserves reduction). For all lists of PID pairs $[({\iota }_1,{\iota }_1^{\prime }),\dots ,({\iota }_n,{\iota }_n^{\prime })]$ which are compatible with nodes N with observable PIDs O, and actions a, all reductions $N{\stackrel{\iota :a}{\to }}_O{N}^{\prime }$ are preserved by the compatible renaming, i.e.,

$$N[{\iota }_1\leftrightarrow {\iota }_1^{\prime },\dots ,{\iota }_n\leftrightarrow {\iota }_n^{\prime }]{\stackrel{\iota [{\iota }_1\leftrightarrow {\iota }_1^{\prime },\dots ,{\iota }_n\leftrightarrow {\iota }_n^{\prime }]:a[{\iota }_1\mapsto {\iota }_1^{\prime },\dots ,{\iota }_n\mapsto {\iota }_n^{\prime }]}{\to }}_O{N}^{\prime }[{\iota }_1\leftrightarrow {\iota }_1^{\prime },\dots ,{\iota }_n\leftrightarrow {\iota }_n^{\prime }].$$

In addition to renaming, the other important property of the semantics is confluence, on which some of our equivalence examples depend. We proved two confluence properties: a diamond property for reasoning about different processes, and a strong confluence property for reasoning about silent actions. For the first theorem, we need to define the compatibility of actions.

Definition 10 

(Compatibility between actions). Two actions are compatible, if neither of them is a spawn action, or if one is a $\mathit{spawn}(\iota ,v_1,v_2,b)$ action, the other one is not $\mathit{spawn}(\iota ,v_3,v_4,b^{\prime })$ or $\mathit{send}({\iota }^s,\iota ,v)$ (i.e., in case of spawn or send, the used (and target) PIDs are different).

The previous definition can always be satisfied by using PID renaming for the spawn actions.

Theorem 3 

(Commutativity of reductions (a restricted diamond property)). For all nodes $N_1,N_2,N_2^{\prime }$, compatible actions $a_1,a_2$, and PIDs ${\iota }_1\ne {\iota }_2$, if $N_1{\stackrel{{\iota }_1:a_1}{\to }}_O{N}_2$ and $N_1{\stackrel{{\iota }_2:a_2}{\to }}_O{N}_2^{\prime }$, there exists a node $N_3$, which satisfies both $N_2{\stackrel{{\iota }_2:a_2}{\to }}_O{N}_3$ and $N_2^{\prime }{\stackrel{{\iota }_1:a_1}{\to }}_O{N}_3$.

Theorem 4 

(Strong confluence with silent actions). For all nodes $N_1,N_2,N_2^{\prime }$, silent actions $a_s$, actions a, and PIDs ι, if $N_1{\stackrel{\iota :a_s}{\to }}_O{N}_2$ and $N_1{\stackrel{\iota :a}{\to }}_O{N}_2^{\prime }$, then one of the following cases is satisfied:

• $a_s=a$ and $N_2^{\prime }=N_2$; or
• a is an arrive action, there is a node $N_3$, such that $N_2{\stackrel{\iota :a}{\to }}_O{N}_3$, and either $N_2^{\prime }{\stackrel{\iota :a_s}{\to }}_O{N}_3$ or $N_3=N_2^{\prime }$ (in the latter case, the process with PID ι was terminated).

4. Program Equivalence

In this section, we investigate a number of definitions for program equivalence based on barbed bisimulation [30]. This section is structured as follows. In Section 4.1, we introduce the usual notion of strong and weak (barbed) bisimulations, and argue why they are insufficient to reason about (Core) Erlang nodes. Next, in Section 4.2, we introduce a refined program equivalence concept based on barbed bisimulation, which is suitable to argue about refactoring correctness on concurrent programs. Finally, in Section 4.3, we enumerate a number of bisimulation examples which can be considered as correct concurrent refactorings.

4.1. Restrictive Notions of Program Equivalence

Practically, two concurrent programs are equivalent, if an external observer cannot distinguish their behaviour. For us, the communication (i.e., the signals sent) of a node can be observed from the outside. For barbed bisimulations, we have to characterise this property. First, we define the observable behaviour as the signals in a node’s ether targeting some PID in the set O (i.e., O is the observer, and the signals sent to it define the observed behaviour). Based on this thought, we can define when two nodes agree on the observed signals:

Definition 11 

(Nodes agree on observed signals). Two nodes $N_1$, $N_2$ weakly agree on O, when for all PIDs ${\iota }_s,{\iota }_d$, if ${\iota }_d\in O$ implies that there exists a PID ${\iota }_2^s$ such that $N_1^{\Delta }\left[({\iota }_s,{\iota }_d)\right]\simeq N_2^{\Delta }\left[({\iota }_2^s,{\iota }_d)\right]$, where ≃ denotes syntactical equality up to PIDs.

Two nodes strongly agree on O, if they weakly agree on O; moreover, ${\iota }_2^s={\iota }_s$ in the previous definition.

The first definition we investigate is barbed strong bisimulation, which relates two nodes whenever they can make the same reductions, and they agree on the signals sent to observed PIDs.

Definition 12 

(Barbed strong bisimulation). A relation $\mathcal{R}$ on nodes is a barbed strong bisimulation observing O if given two nodes $N_1,N_2$, $\mathcal{R}(N_1,N_2)$ implies the following:

• For all nodes $N_1^{\prime }$, actions a, and PIDs ι, if $N_1{\stackrel{\iota :a}{\to }}_O{N}_1^{\prime }$ then $\exists N_2^{\prime }:N_2{\stackrel{\iota :a}{\to }}_O{N}_2^{\prime }$ and $\mathcal{R}(N_1^{\prime },N_2^{\prime })$;
• The converse of the previous point for reductions from $N_2$;
• $N_1$ and $N_2$ strongly agree on O (note that this property is symmetric).

We use $N_1{\sim }_O{N}_2$ to denote that $N_1$ and $N_2$ are related by a relation $\mathcal{R}$ which is a barbed strong bisimulation.

Proving strong bisimilarity even between simple nodes is impossible in most practical cases. Consider a node consisting of one process which computes the expression $\mathtt{call}\mathtt{‘}\mathtt{erlang}\mathtt{’}:\mathtt{‘}+\mathtt{’}(\mathtt{1},\mathtt{2})$ and a node with a process computing $\mathtt{3}$. The first node can take some $\tau$ computation steps, which could not be taken by the second one. To loosen this notion of program equivalence, we can introduce weak bisimulations.

Definition 13 

(Barbed weak bisimulation). A relation $\mathcal{R}$ on nodes is a weak barbed bisimulation observing O if given two nodes $N_1,N_2$, $\mathcal{R}(N_1,N_2)$ implies the following:

• For all nodes $N_1^{\prime }$, actions a, and PIDs ι, if $N_1{\stackrel{\iota :a}{\to }}_O{N}_1^{\prime }$ then $\exists N_2^{\prime },N_2^{″},N_2^{‴}:N_2\stackrel{\tau }{{\to }_O^{*}}{N}_2^{\prime }\underset{O}{\overset{\iota :a}{\to }}{N}_2^{″}\stackrel{\tau }{{\to }_O^{*}}{N}_2^{‴}$ and $\mathcal{R}(N_1^{\prime },N_2^{‴})$;
• The converse of the previous point for reductions from $N_2$;
• $N_1$ and $N_2$ strongly agree on O.

We use $N_1{\approx }_O{N}_2$ to denote that $N_1$ and $N_2$ are related by a relation $\mathcal{R}$ which is a weak barbed bisimulation.

Remark 2. 

There is no need to include silent reduction steps from $N_2$ in the third point of Definition 13 as τ actions do not affect the ether.

With this definition, we can prove examples like the previous one, which only differ in computational steps, but cannot prove equivalence between nodes that communicate or spawn processes differently. In particular, with this notion, we cannot prove the equivalence between the two list processing functions from the running example (Figure 3 and Figure 4). This is because the sequential variant only communicates the result of the computation, while the parallel version spawns a child process and also performs communication between the child and parent processes.

4.2. Alternative Notion for Weak Barbed Bisimulation

We borrow another idea of (weak) barbed bisimulation used for related research on Core Erlang [16], and tailor it to our needs. In this definition, we do not compare the actions that induce the reductions made by the nodes, and only focus on the observables. If a reduction is taken by one node, the other one has to simulate it, but there is no restriction on what and how many steps this simulation should take.

Definition 14 

(Barbed bisimulation). A relation $\mathcal{R}$ on nodes is a barbed bisimulation observing O, if given two nodes $N_1,N_2$, $\mathcal{R}(N_1,N_2)$ implies the following:

• For all nodes $N_1^{\prime }$, actions a, and PIDs ι, if $N_1{\stackrel{\iota :a}{\to }}_O{N}_1^{\prime }$ then $\exists N_2^{\prime }:N_2\stackrel{\tau }{{\to }_O^{*}}{N}_2^{\prime }$ and $\mathcal{R}(N_1^{\prime },N_2^{\prime })$;
• $\exists N_2^{\prime }:N_2\stackrel{\tau }{{\to }_O^{*}}{N}_2^{\prime }$ and $N_1$ and $N_2^{\prime }$ weakly agree on O;
• The converse of the previous points for reductions and observables of $N_2$.

We use $N_1{≋}_O{N}_2$ to denote that $N_1$ and $N_2$ are related by a relation $\mathcal{R}$ which is a barbed bisimulation. Hereafter, whenever we write bisimulation, we mean this definition.

After defining the suitable notion of program equivalence, we state the basic properties of this relation: reflexivity, symmetry, and transitivity. We furthermore highlight that this notion is less restrictive than the previous two definitions (for the proofs, refer to the formalisation [29]).

Theorem 5 

(Equivalence relation). For all sets of PIDs O, the relation ${≋}_O$ is reflexive, symmetric, and transitive.

Theorem 6 

(Correspondence between bisimulations). For all sets of PIDs O, ${\sim }_O\subset {\approx }_O\subset {≋}_O$.

4.3. Bisimulation Examples

Next, we show some bisimilar node pairs. For complete proofs, we refer to the formalisation [29], while we also give some insights here. In general, to prove these lemmas, we relied on coinduction, and case distinction based on the four rules of the inter-process semantics (Figure 12). To reason about spawn actions, in most cases, we also had to use renaming (either with Theorem 7 or with the coinductive hypothesis).

Theorem 7 

(PID-renaming is a barbed bisimulation). For all lists $[({\iota }_1,{\iota }_1^{\prime }),\dots ,({\iota }_n,{\iota }_n^{\prime })]$ containing PID pairs which are compatible with the node N and sets of PIDs O, $N{≋}_{O}N[{\iota }_1\leftrightarrow {\iota }_1^{\prime },\dots ,{\iota }_n\leftrightarrow {\iota }_n^{\prime }]$.

Proof. 

We proceed with coinduction. We need to prove the four conditions of the bisimulation (Definition 14). The proof of the third and fourth points is based on the symmetric properties of bisimulations, and equality; thus, we only briefly explain the proof of the first two points. For readability, we use l to denote the list of renamings ${\iota }_1\leftrightarrow {\iota }_1^{\prime },\dots ,{\iota }_n\leftrightarrow {\iota }_n^{\prime }$ (or ${\iota }_1\mapsto {\iota }_1^{\prime },\dots ,{\iota }_n\mapsto {\iota }_n^{\prime }$ depending on the context).

Suppose that $N{\stackrel{\iota :a}{\to }}_O{N}^{\prime }$. We need to show $N\left[l\right]{\stackrel{\iota \left[l\right]:a\left[l\right]}{\to }}_O{N}^{\prime }\left[l\right]$. According to Theorem 2, if the renaming is compatible with action a, we can show that the renaming preserves the reduction, and by the coinductive hypothesis, the reached nodes are bisimilar. Since the renaming is compatible with the initial node, it is also compatible with almost all actions, because the PIDs that appear in the actions originated either from the ether or the process pool. On the other hand, $\mathit{spawn}$ actions involve a fresh PID (${\iota }_{spawn}$), which could collide with the PIDs used for renaming. In this case, we can extend the list of renamings with a new renaming: $({\iota }_{spawn},{\iota }_{fresh})::l$. Since ${\iota }_{fresh}$ is chosen arbitrarily, we can ensure that it does not appear in the node or the action, and this extended list is compatible with action a, thus $N[{\iota }_{spawn}\leftrightarrow {\iota }_{fresh},l]{\stackrel{\iota \left[{\iota }_{spawn}\mapsto {\iota }_{fresh},l\right]:a[{\iota }_{spawn}\mapsto {\iota }_{fresh},l]}{\to }}_O{N}^{\prime }[{\iota }_{spawn}\leftrightarrow {\iota }_{fresh},l]$, and we can use the coinductive hypothesis for this extended list to prove that the reached nodes are bisimilar.

The proof of the second point is mostly technical. If there are signals targeting ${\iota }^d\in O$ in the ether of N (e.g., with the source ${\iota }^s$), we can show that there are signals targeting ${\iota }^d$ in $N\left[l\right]$ too, with the source ${\iota }^s\left[l\right]$. Moreover, these signals are equal up to the PIDs.    □

While PID renaming seems to be an obvious (and often implicitly used) property, in a machine-checked formalisation, we need to be rigorous and explicit both in its proof and in its uses. Without renaming, there is no way to reason about nodes that use different PIDs, and also spawn some new processes, since the spawned PID is potentially not fresh in the other node. We mitigate this problem by renaming the spawned PID to a fresh(er) one.

Next, we state two technical lemmas to reason about elements of the ether and process pool which do not affect the evaluation. With these lemmas, we can remove irrelevant signals and terminated processes from a node during bisimulation proofs. The first lemma states that signals originating from, or targeting, terminated processes do not distinguish nodes.

Lemma 1 

(Ether update for terminated processes). For all nodes N, sets of PIDs O, and PIDs ${\iota }^s$, ${\iota }^d$ which satisfies ${\iota }^d\notin O$, if both $N^{\Pi }\left[{\iota }^s\right]$ and $N^{\Pi }\left[{\iota }^d\right]$ are terminated processes, then for any list of signals l, $N{≋}_O(N^{\Delta }[({\iota }^s,{\iota }^d)\mapsto l],N^{\Pi })$, and $N{≋}_O(N^{\Delta }\setminus ({\iota }^s,{\iota }^d),N^{\Pi })$.

Proof. 

We proceed by coinduction. We need to prove the four conditions of the bisimulation (Definition 14). The points about observables trivially hold since the update in the ether does not affect observed PIDs.

Suppose that $N{\stackrel{\iota :a}{\to }}_O{N}^{\prime }$, then we have to show that we can perform an equivalent step with the updated ether.

• If NLocal or NArrive was used, then the same step can be made in the updated node (since these actions could not have been taken by terminated processes), and we can use the coinductive hypothesis.
• If NSpawn was used (which could not have been performed by a terminated process), we have to rename the PID of the spawned process to a fresh PID (so that it does not appear anywhere in the modified configuration, nor in the set of PIDs used in l), and we can perform the same reduction step with the fresh PID, since it satisfies the side condition of NSpawn. We finish this case by using the transitivity of barbed bisimulation with Theorem 7 and the coinductive hypothesis.
• In the case of NSend, we can make the same reduction in the updated node, regardless of which process sent the message. Supposing that $a=\mathit{send}({\iota }^s,{\iota }^d,s)$, we can use the coinductive hypothesis with the list of signals chosen as $l++\left[s\right]$ (or just $\left[s\right]$, if we prove the second part of the theorem).

For the converse direction, we can use the fact that any ether E can be expressed with two updates:

• If $E\left[({\iota }^s,{\iota }^d)\right]=\mathit{Some}\left(l^{\prime }\right)$, then $E=E[({\iota }^s,{\iota }^d)\mapsto l][({\iota }^s,{\iota }^d)\mapsto l^{\prime }]$.
• If $E\left[({\iota }^s,{\iota }^d)\right]=\mathit{None}$, then $E=E[({\iota }^s,{\iota }^d)\mapsto l]\setminus ({\iota }^s,{\iota }^d)$.

Therefore, we can use the same train of thought as described above to conclude the proof.    □

The following lemma states that adding unlinked terminated processes (we denote empty maps with ∅) to a node creates an equivalent node.

Lemma 2 

(Terminated process). For all nodes N, sets of PIDs O, and PIDs ι, if $\iota \notin O$ and $\iota \notin \mathit{dom}\left(N^{\Pi }\right)$, then $N{≋}_O(N^{\Delta },\iota \mapsto \varnothing \Vert N^{\Pi })$.

Proof. 

This proof is also constructed with coinduction. The main idea is that the terminated process ∅ cannot take any reduction; thus, the same reductions can be made in both nodes, and this way, the ether is not affected either (i.e., observables remain the same).    □

The next theorem states that if a node can be reduced with $\tau$ steps or $\mathit{self}$ actions, the result is equivalent to the original node. It is useful to reason about concrete node equivalences since it reduces the problem of proving bisimulation to proving evaluation. Together with the transitivity of ${≋}_O$, in bisimulation proofs, we can discharge reasoning about silent steps.

Theorem 8 

(Silent evaluation). For all nodes $N,N^{\prime }$, sets of PIDs O, if $N\stackrel{l}{{\to }_O^{*}}{N}^{\prime }$ for some action trace l, which contains only silent (i.e., τ or $\mathit{self}$) actions, $N{≋}_O{N}^{\prime }$ holds.

Proof. 

For this theorem, it is sufficient to prove that one single silent step creates bisimilar nodes, since based on this fact and the transitivity of the barbed bisimulation (Theorem 5), we can prove the original property by induction on the action trace l.

To prove that a single silent step creates bisimilar nodes, we use coinduction, and prove the four requirements for barbed bisimulation. Suppose that $a=\tau \vee \exists \iota ,a=\mathit{self}\left(\iota \right)$, and $N{\stackrel{\iota :a}{\to }}_O{N}^{\prime }$. We prove $N{≋}_O{N}^{\prime }:$.

First, we check what other possible reductions can be made from N based on the first point in Definition 14. Suppose that for some action $a^{\prime }$, PID ${\iota }^{\prime }$ and node $N^{″}$, there is a reduction $N{\stackrel{{\iota }^{\prime }:a^{\prime }}{\to }}_O{N}^{″}$. We have to show that

$$\exists N_{final},N^{\prime }{\to }_O^{*}{N}_{final}\wedge N^{\prime }{≋}_O{N}_{final}.$$

There are the following options:

• If ${\iota }^{\prime }=\iota$, then there are two options:

  -

  If $a^{\prime }=a$, i.e., the same step is taken, then $N^{\prime }=N^{″}$ and we can choose $N_{final}=N^{\prime }$ and use the reflexivity of the bisimulation.

  -

  If $a^{\prime }\ne a$, then $a^{\prime }$ can only be an arrive action (Theorem 4). Supposing that the arrive action does not terminate the process, it can be postponed after making the reduction with a; thus, there is a node $N^{‴}$ to which $N^{\prime }{\stackrel{\iota :a^{\prime }}{\to }}_O{N}^{‴}$ and $N^{″}{\stackrel{\iota :a}{\to }}_O{N}^{‴}$. We choose $N_{final}=N^{‴}$, which is reachable from $N^{\prime }$ based on the first reduction, and prove $N^{\prime }{≋}_O{N}^{\prime \prime \prime }$ based on the coinductive hypothesis and the second reduction.

  -

  If $a^{\prime }\ne a$, $a^{\prime }$ is an arrive action, and it terminates the process, then the process is also if the action arrives in $N^{\prime }$, since silent actions do not modify either of the properties (linked PIDs, source and destination, exit reason, process flag) used in the semantics for arrives (see Figure 8); thus, $N^{\prime }{\stackrel{\iota :a^{\prime }}{\to }}_O{N}^{″}$. We can choose $N_{final}=N^{″}$ and use the reflexivity of the bisimulation.

• If for some action $a^{\prime }$, PID ${\iota }^{\prime }$ and node $N^{″}$, there is a reduction $N{\stackrel{{\iota }^{\prime }:a^{\prime }}{\to }}_O{N}^{″}$, then we can use Theorem 3 to derive the existence of a node $N^{‴}$ to which $N^{\prime }{\stackrel{{\iota }^{\prime }:a^{\prime }}{\to }}_O{N}^{‴}$ and $N^{″}{\stackrel{\iota :a}{\to }}_O{N}^{‴}$. We choose $N_{final}=N^{‴}$, which is reachable from $N^{\prime }$ based on the first reduction, and prove $N^{\prime }{≋}_O{N}^{‴}$ based on the coinductive hypothesis and the second reduction.

To prove that for all reductions $N^{\prime }{\stackrel{{\iota }^{\prime }:a^{\prime }}{\to }}_O{N}^{″}$, the result $N^{″}$ is bisimilar to a node which is reachable from N, we can chain this reduction after the assumption of $N{\stackrel{\iota :a}{\to }}_O{N}^{\prime }$, and use the reflexivity of the bisimulation (Theorem 5).

The observables are not modified in the ether by silent actions; thus, the requirements on them of Definition 14 hold.    □

We highlight that this theorem is more restrictive than the normalisation theorem of [16], which also considers message sending and process spawning in this bisimulation (we refer the reader to Section 5 for a discussion of why this is not the case for us). Finally, we show a concrete program equivalence based on barbed bisimulation.

Example 2 

(Equivalence of sequential and concurrent map).  Consider the expressions from Figure 3 (denoted with $e_{\mathit{map}}$) and Figure 4 (denoted with $e_{\mathit{pmap}}$). For all values $v_l$, $v_f$, natural numbers i, PIDs ι which appear as the metavariables in Figure 3 and Figure 4, and for all PIDs ${\iota }_{base}$, $(\varnothing ,{\iota }_{base}\mapsto (\epsilon ,e_{\mathit{map}},[▸],\varnothing ,\mathit{ff})\Vert \varnothing ){≋}_{\left\{\iota \right\}}(\varnothing ,{\iota }_{base}\mapsto (\epsilon ,e_{\mathit{pmap}},[▸],\varnothing ,\mathit{ff})\Vert \varnothing )$, if the following conditions hold:

• ${\iota }_{base}\ne \iota$.
• The closure value $v_f$ computes a metatheoretical function f, that is, for all values v, we can prove $\langle \epsilon ,\mathtt{apply}{v}_f\left(v\right)\rangle {⟶}^{*}<f\left(v\right)>$ in the sequential layer.
• $v_l$ is a proper Core Erlang list, i.e., it is constructed as $\left[v_1\right|\left[v_2\right|\dots \left[v_n\right|\left[\right]]]\dots ]$, and $i\le n$.
• $v_l$ does not contain any PIDs; moreover, the application of $v_f$ does not introduce any PIDs.

Proof Sketch. 

The proof of this theorem is quite involved; thus, we refer to the formalisation [29] for all details, and only describe the main idea here. We avoided using the definition of the bisimulation manually since it takes many reductions to evaluate both sequential and parallel list transformation, and reasoning about the four conditions of Definition 14 generates unnecessary, tremendous overhead. Instead, we heavily rely on Theorem 8 and the transitivity of bisimulation (Theorem 5) to discharge silent evaluation steps from the reasoning.

There are two main points to prove: there is an evaluation of the parallel list processing that behaves the same way as the sequential one, and vice versa. The former point follows from the fact that the sequential map can be only evaluated deterministically (see Example A1 for more insights) and from Example 1 where (all) paths lead to the same final configuration. The latter point is more challenging, since all evaluation paths in Figure 13 have to be simulated by the sequential list processing. To prove this, we need to manually apply the definition of bisimulation in all states from Figure 13 from where a non-silent reduction happens.    □

5. Discussion

In this section, we describe the novelty of this work with respect to our previous work we build on. We also discuss some major theoretical and technical challenges originating from the formalised signals, the absence of atomic receive expressions, and the fact that our formalisation is mechanized in Coq.

5.1. Novelty

As mentioned before, this paper builds on, and extends, our previous work described in [10,11]. Namely, we reused the sequential semantics of [11] (which we recall in Appendix A), and built the process-local and inter-process semantics on top of it based on [10]. However, note that we do not repeat the definitions presented there; in particular, this current paper not only extends our previous work but defines the communication primitives with a different granularity (i.e., with the new primitives implemented in Erlang/OTP version 23 [19]), which required changes in the underlying representations compared to [10] (such as that of mailboxes, process pools, and the ether), the semantic rules, and the proofs of the fundamental properties. Since the implementation of the new communication primitives does not fully conform with the old language specification, our work is essential, and it sets the state-of-the-art regarding the formal definition of the actor model of Erlang, providing a rigorous and solid basis for future research on the most recent communication model.

5.2. Theoretical Challenges

The first challenge we encountered was the definition of the inter-process semantics, which had to satisfy both the signal-ordering guarantee and the fact that message passing is not atomic (as explained in Section 3.5). These conditions make it necessary to define an ether that includes the sent but not delivered signals in an ordered way. In addition to making the semantics more complex, this decision also makes some reductions impossible, which would have been carried out if the signal-ordering guarantee was not enforced. On the other hand, this simplifies reasoning about signal arrival, since only the first signals need to be considered from the ether (from the ordered list of signals) targeting a process.

Next, the formalisation of exit signals comes with a number of challenges. Since exit signals can potentially terminate a process, they also limit the confluence properties of the semantics. This is also one of the reasons why Theorem 8 is more restricted than “normalisation” (from [16]) which also allows send and $\epsilon$ actions in the reduction chain. Whether an exit signal terminates a process depends on a number of factors: which are the linked PIDs, how the trap_exit flag is set, what is the reason value, and the source of the signal. If the process for which the exit is arriving can also make a step which modifies either of these, the process will behave in a different way if the signal arrives before or after this step, and this breaks the confluence property.

A similar argument can be made about the correlation between primitive operations for message receipts and arrival. For example, if a message arrives before evaluating recv_peek_message, then the first component of its result is the atom $\mathtt{‘}\mathtt{true}\mathtt{’}$, while if the message arrives later, the same component could be ‘false’ (if there are no unseen messages in the mailbox). This means that Lemma 9 of [16]—saying that any reduction that can be made with a process can also be made if a new message is appended at the end of the mailbox—cannot be proved; this lemma only holds for receive expressions that evaluate in an atomic way. To handle the maximum number of reductions with Theorem 8 when reasoning about bisimulations, we decided to label all reductions with $\tau$ (not just steps of the sequential layer) for which the semantics is strongly confluent.

5.3. Formalisation

As mentioned before, all of our results are machine-checked with Coq [29] (around 35,000 lines of code). We briefly explain the main design decisions we made.

• We deeply embedded the syntax of Core Erlang into Coq as an inductive definition, so that we can use induction to reason about substitutions, PID renamings, and variable scoping.
• We encoded variables (and function identifiers) of Core Erlang with the nameless variable representation, i.e., all variables are de Bruijn indices. Using a nameless encoding simplifies reasoning about alpha-equivalence to checking equality, and fresh variable generation is simply expressed with addition of natural numbers. This way, the syntax is less readable for the human eye, but it is much simpler to define parallel capture-avoiding substitutions and use them in proofs [31].
• We did not use a similar, nameless encoding for PIDs. While process pools behave like binders, PIDs generally do not behave as variables: PIDs are dynamically created, and we do not apply substitutions for them. Moreover, in some cases, we might need to depend on the exact value of a PID in the program (e.g., for PID comparison). In addition, alpha-equivalence of PIDs cannot be reduced to equality checking with a nameless encoding. Suppose that we have several process spawns that can be executed in any order. After executing all process spawns in all possible orders, the result systems will be alpha-equivalent, but never equal, since the spawned PIDs (as de Bruijn indices) would depend on the particular execution path.
• We expressed all semantic layers as inductive judgements in order so that we could more easily use Coq’s tactics (inversion and constructor) to handle semantic reductions in proofs.
• We formalised process pools, ethers and dead processes as finite maps so that the used PIDs inside such constructs can be collected by a recursive function. Based on the collection result, we can come up with fresh PIDs for spawned processes. If we used functions instead of finite maps, showing that a concrete PID does not appear inside process of a process pool would have required much more complex proofs (potentially based on induction).
• For an implementation of finite maps and freshness, we relied on the Iris project’s stdpp [32] library, which also includes the set_solver tactic that can be used to automatically discharge statements about sets and finite maps.
• The formalisation depends only on one standard axiom; we use functional extensionality for reasoning about parallel substitutions.

Having a machine-checked formalisation also comes with some drawbacks. Firstly, a proof assistant forces the proof engineer to be more precise compared to writing mathematical proofs on paper. For our project, this creates technical difficulties whenever reasoning about spawn actions is needed, because (in most cases) at these steps, we have to rely on renaming with fresh PIDs. After defining the necessary fresh PIDs, we have to manually simplify these renamings, and in equivalence proofs, based on the transitivity of the bisimulation (Theorem 5), we use Theorem 7 to reach the desired results.

However, relying on the transitivity of the bisimulation (or any other bisimulation-transforming proof) comes with another drawback: in a coinductive proof, the guardedness checker of Coq does not accept proofs that use transitivity on the coinductive hypothesis, since it is often unsound (for now, we turned off the guardedness checker for these proofs and relied on existing approaches [16] to carry out the proofs; we intend to investigate other approaches to this). However, the violations of the guardedness only originate from the following two proof strategies.

• In Theorem 7, we used bisimulation’s symmetry to justify the first clause of Definition 14 for the derivations starting from $N_2$ (i.e., for the node with renamings); however, we are certain that this could be replaced by several analogous helper lemmas, ultimately discharging the potential of invalidity.
• For every other case (including Lemmas 1 and 2), we used bisimulation’s transitivity with Theorem 7 for injective alpha-renaming (based on the soundness results of [33]).

6. Conclusions and Future Work

We have defined formal semantics for the concurrent subset of Core Erlang, building on earlier work [10,11], extending the sequential syntax with process identifiers (PIDs), and defining the concurrent (process-local and inter-process) semantics by defining the meaning of concurrent built-in functions and primitive operations.

We defined three concepts of concurrent program equivalence based on barbed bisimulations. We argued that the usual notions of strong and weak bisimulations are too restrictive to reason about program equivalence. In order to model equivalence between programs that have different communication structure but the same observable behaviour, we introduced a weaker variant of barbed bisimulation (following the footsteps of [16,24]), with which we proved a number of program equivalences (such as PID renaming, executing computation steps, list processing sequentially or concurrently), reaching beyond previous and related work. The results presented here are formalised in the Coq proof assistant.

In the future, we aim to generalize the equivalence proof for sequential and concurrent list processing to include exit signals and message source validation. We then aim to generalize and create new approaches for reasoning about bisimulations to make it simpler to show concrete Core Erlang programs equivalent, to fulfil our goal of verifying Erlang refactorings.