3.1 Derived forms

Figure 7 displays derived forms for common patterns. One exceedingly common pattern is for a facet to be constructed in response to the appearance of an assertion and torn down in response to its disappearance. The Light and Hub actors both fall into this category. We abstract this pattern into the during form. Each time the asserted event fires, any pattern variables bound in pattern are instantiated to yield a concrete assertion, $\textit{pattern}'$ . The (on (retracted …)) endpoint monitors this assertion in the new facet.

Fig. 7. Derived forms.

Figure 7 also shows a related derived form, during/spawn. In contrast to during, this form does not create a facet within the actor but spawns an actor in the dataspace. The critical difference concerns failure. While a failure in during tears down the current actor, a failure in during/spawn terminates the separate actor but leaves the spawning one alone.

Both during and during/spawn allow the programmer to directly express matching of supply to demand. Assertions matched by the pattern are interpreted as demand; the during-body constitutes the supply. As demand increases via new matching assertions in the dataspace, the supply expressions are executed to match. As demand decreases again due to the withdrawal of assertions, (on (retracted …)) endpoints automatically terminate the facet or actor in response. Resources are allocated via (on start …) clauses and released in (on stop …) clauses in response to changing needs.

Figure 7 defines a second family of derived forms concerning the integration of newly arrived assertions into local fields. While actors often just deal with singleton assertions, other scenarios call for a set, a hash table, or even an aggregate summary of several assertions. To support this idiom, the facet language provides derived constructs called queries. Queries define and subsequently update fields, making their results available for use in neighboring facet endpoints.

One such form, define/query-value, is useful for local tracking of an assertion kind in which there may be zero or one instance in the dataspace. For example, we could extend the smart home program with persistence, so that the user’s assignments of devices to rooms are saved between runs of the program. A separate actor would handle persisting such configurations to the file system or other location and loading them when the program starts. Then, when the Hub actor boots, it needs to operate based on a reloaded configuration or start with a default fresh one. It may use

$$ \begin{array}{l} \mathtt{(\mathtt{define/query-value} config \mathtt{DC} (configuration \mathtt{\$}lights \ldots)} \\ \qquad \mathtt{(configuration lights \dots))} \end{array}$$

to create a field that defaults to DC (short for default configuration) value unless there is a configuration assertion, in which case it uses the value of that assertion.

The second such form, define/query-set, collects information from relevant assertions in a set.Footnote ⁴ A user-interface component for the smart home may use it to show the user all of the lights currently installed in the system:

$$ \mathtt{({define/query-set} lights (light {\$}id {\_}) id)}$$

The query scheme directly generalizes to structures such as hash tables, etc., and also allows aggregations analogous to SQL’s COUNT(*) and GROUP BY.

3.2 The case for facets

Returning to the dining concurrency researchers example, facets support a conversational style in several ways:

• • Engaging in a new conversation is as simple as starting a facet. Likewise, stopping a facet disengages from a conversation.

• • The during form directly connects context to behavior.

• • The tree of facets mirrors the way (sub)conversations branch from existing conversations.

Defining actors using facets provides additional advantages over basic functions and objects, as well. Appendix A provides an implementation of the light actor using a procedural notation as a concrete basis of comparison, demonstrating and explaining these benefits.

Generally put, the facet notation combines and extends a number of concepts from other languages and empowers programmers to use them in a synergistic manner. For example, end-point programming may remind the reader of the event-handling and reactive programming style of Esterel (Berry & Gonthier, Reference Berry and Gonthier1992) and Crime (Mostinckx et al., Reference Mostinckx, Lombide Carreton and De Meuter2008). Dataflow exists in many forms (Demetrescu et al., Reference Demetrescu, Finocchi and Ribichini2011). Updates to behavior have been around as long as the Actor model (Hewitt et al., Reference Hewitt, Bishop and Steiger1973). The during behavior is the clearest example of the synergistic use of these features. It precisely describes a temporal engagement with the dataspace; sets up and tears down local behavior as needed; and simultaneously takes into account the accumulated conversational context.

4.1 Basic types

The starting point is a structural type system. Base types describe data such as Int, Bool, etc. A struct-type definition such as (struct light ([on? : Bool])) introduces the type constructor LightT.Footnote ⁵ . Thus, (light #true) has type (LightT Bool).

Our previous work on structural types (Caldwell et al., Reference Caldwell, Garnock-Jones and Felleisen2020) for purely functional dataspace actors validates that it prevents mistakes involving the shape of assertions. That is, type checking incorporates knowledge of how a dataspace routes assertions among actors and uses the types to confirm that assertions cannot upset routing. It is straightforward to adapt this system and its proof of soundness to facet-oriented dataspace actors.

4.2 Specification

Like for structural properties of routing assertions, programmers need a language for behavioral—that is, temporal—properties, too. Like structural types give a syntax and semantics to claims about properties of assertions, behavioral types should allow the programmer to make claims concerning the behavior of actors in a dataspace. We employ a form of linear temporal logic (LTL) for this purpose, though of course, its basic propositions must somehow involve the assertions that actors deposit into and withdraw from dataspaces. In addition to introducing this language, this section also informally explains what it means for a facet-based actor program to live up to such a specification.

LTL has a long history as a specification language for concurrent programs and the basis for mechanized checks (Manna & Pnueli, Reference Manna and Pnueli1991; Holzmann, Reference Holzmann1997; Pnueli, Reference Pnueli1977). When compared to other temporal logics, such as the branching-time computation tree logic (CTL), LTL is typically considered more intuitive and at least as amenable to efficient model checking (Vardi, Reference Vardi2001; Rozier, Reference Rozier2011). Moreover, compared to typical protocol description languages such as choreographies (Carbone & Montesi, Reference Carbone and Montesi2013) or session types (Honda et al., Reference Honda, Yoshida and Carbone2008), LTL allows the focus to be on what is communicated rather than who does the communicating, suiting the anonymous style of dataspace programming.

The base LTL predicates are types that describe assertions in the dataspace. For example, the formula (LightT Bool) holds at any moment iff some actor has deposited an assertion (light #true) or (light #false) in the dataspace. Specifications may also use negation (Not), and (Not (LightT Bool)) means no assertion of this structure type is in the dataspace.

Other connectives are conjunction (And), disjunction (Or), and logical implication (Implies). With temporal connectives, a programmer can specify the evolution of dataspace programs. The proposition (Always (LightT Bool)) holds if the dataspace contains a light assertion at every moment during execution, regardless of which actor has deposited it there. Meanwhile,

$$(\mathtt{Until} (\mathrm {LightT} \,\,\mathtt{Bool}) (\mathtt{Not} \,\,\mathrm{Wall Switch On}))$$

says that eventually there will not be a (wall-switch-on) assertion in the dataspace, but until then there is a light assertion. The formula

describes an execution state with an assertion matching in the dataspace or the execution arrives at such a state within a finite number of steps.

A dataspace program satisfies a specification if its dataspace evolves according to the interpretation of the LTL formula. Thus, a program lives up to the just-mentioned formula if, at some point during execution, an actor makes a matching light assertion. In particular, any dataspace program that includes the light-facet actor from the preceding section satisfies this formula, because it makes a light assertion as it boots.

Consider another proposition:

It is the strong version of Until, requiring that (Not wallSwitchOn) eventually be true.

Take the dataspace program that runs the two actors on the left:

The evolution of the dataspace is on the right. It shows which assertions are in the dataspace for the first four time steps, starting with the boot state.

After booting, actor 1 makes a light assertion and actor 2 adds a (wall-switch-on) to the dataspace. Hence, the dataspace configuration at that point matches the antecedent of the implication. Consequently, the Until property must also describe that state so that the latter models the complete formula. Due to actor 1’s assertion, actor 2 stops its only facet, leading to the withdrawal of the assertion. Since the light assertion remains active until that point, the implication still holds. Furthermore, actor 1 notices the disappearance of the (wall-switch-on), and in response, replaces its own assertion the dataspace. As a result, the next configurations also match the antecedent of the implication as does the until property.

While the notion of satisfaction is intuitive, the eventual goal is to mechanize this type-checking of specifications. In this regard, the sample explanations are also suggestive. What is needed is an abstract description of the behavior of the actors and their interaction with dataspaces via assertions. And again, just like for structural type checking, it is the shape of exchanges that can serve in this role, not the precise assertions.

4.3 Effect types for facets

The end of the preceding section almost dictates the third step. Historically, type systems research uses effect-type systems for descriptions of program behavior (Lucassen & Gifford, Reference Lucassen and Gifford1988). In the setting of facet-oriented actors, the to-be-observed effects are caused by actors overall, facets, and endpoints. Hence, each corresponding term-level construct comes with a type-level construct for describing the type of its effects. See Figure 8 for the actual notation.

Fig. 8. Effect types.

Let us illustrate the synthesis of effect types with the code for spawning the simplistic Light actor from Section 3 (without rooms and power switches). Ignoring fields and expressions, the code describes a single actor and a single facet nested within this actor. The facet itself comes with three end points: a plain assertion endpoint, an on-asserted one and an on-retracted one. The behavioral type mirrors this description, including the ordering of the endpoints within the facet:

Here is how to read the type in terms of the actor’s communication behavior:

• • it makes an assertion of type (LightT Bool);

• • it expresses interest to assertions of type (InRoomT Int);

• • it reacts to their appearance and disappearance; and

• • its reactions do not change its communication behavior.

For this last point, note that the bodies of the On types are empty.

From this perspective, a behavioral type is a simplified actor. This simplified actor communicates via types of assertions rather than value assertions. By taking the behavior type of each actor in a program—say, the smart home program—we get a communication-only program, that is, a collection of simplified actors and their types of assertion exchanges with dataspaces. Accordingly, the number of possible behaviors is much lower—and that is precisely what enables a mechanical checking of (some) specifications.

4.4 Checking specifications mechanically

The transition of possible interactions from concrete value assertions to types of assertions enable specification checking. At a rather high level, the checker infers effect types from a program and compiles them to the language of a model checker. The compilation encodes effect types as simplified actors. This model-checking program is combined with the programmer’s LTL formula. If the model-checking attempt fails, the error is reported in terms of a trace of these simplified actor programs.

The theory behind this idea is presented in Sections 5 and 7. Section 8 verifies why this approach works. The implementation is sketched in Section 9. Section 10 evaluates its ability to check behavioral properties of realistic programs. The following subsection illustrates the working of the model checker with an example.

4.5 Revisiting the smart-home example

To demonstrate the power of the specification language, let us revisit the smart home example from Section 3. The code presented in Figure 4 is buggy, and attempting to check it against a natural specification exposes the bug, Here is the specification of the expected behavior of the lights:

This specification describes the expected outcomes of interactions between the presence sensor, light, and light-switch actors. It states that the light turns on and off in response to the sensor actor’s InRoomT assertions, as long as it is powered (WallSwitchOn).

When analyzed with respect to this specification, our implementation of LTL checking reports the error and provides a counterexample in terms of the involved actors and their assertions:

If a presence sensor is installed and configured after the light in the same room is turned on even though it is empty, the light stays on due to the sensor’s initial reading.

Based on this trace, we can identify the active assertions and thus the active facets of the Light actor. This assessment provides a starting point for determining where to locate the bug. A close look reveals that the light-facet facet in Figure 4 reacts only to the retraction of (in-room room 0) to determine that the room is occupied. If the room is occupied when the light regains power, no such retraction will take place. To fix this problem, we can amend the facet to query the state of in-room assertions on startup. The boxed code in Figure 9 is all that is needed to make the actor satisfy its LTL specification.

Fig. 9. Implementation of the Light actor, fixed (see Figure 4).

5.1 Formal syntax

Figure 10 defines the abstract syntax of facet-oriented actors. Statements $\mathrm{Pr}$ imperatively update the actor’s state in one of several ways:

• • $\mathtt{start}\,\,\,{\mathrm{fn}}\,\,\,{\overrightarrow{\mathrm{e}}}\,\,\,{(\overrightarrow{\mathrm{D} \,\,\mathrm{Pr}})}$ —starting a facet with name $\mathrm{fn}$ , assertions $\overrightarrow{\mathrm{e}}$ , and event handlers $(\overrightarrow{\mathrm{D} \ \mathrm{Pr}})$ ;

• • $\mathtt{stop}\,\,{\mathrm{fn}}\,\,{\mathrm{Pr}}$ —terminating a facet, along with all of its children, and engaging in some continuation behavior ${\mathrm{Pr}}$ ;

• • —creating a mutable field for $\mathrm{Pr}$ ;

• • ${\mathrm{x}}:={\mathrm{e}}$ —assigning a new value to a field; and

• • —spawning an additional actor.

Fig. 10. Program syntax.

Statements may introduce local, lexically scoped variables with . Otherwise, they are just like statements in other programming languages that compose sequentially ( ${\mathrm{Pr}};{\mathrm{Pr}}$ ). For technical reasons, the grammar includes no-op (skip).

The set of expressions comprises

• • b—basic values;

• • ${p}({\overrightarrow{\mathrm{e}}})$ —invocations of potentially partial primitive operations;

• • $\mathrm{x}$ —references to variable names;

• • $!{\mathrm{x}}$ —field access;

• • $?{\mathrm{e}}$ —assertion of interest in $\mathrm{e}$ ;

• • $({\overrightarrow{\mathrm{e}}})$ —tuple with tag m;

• • $\star$ —wildcard assertion patterns/templates; and

• • ${\mathrm{x}}:{\tau}$ —binding patterns.

A vector of assertion templates ( $\overrightarrow{\mathrm{e}}$ ) defines the assertions made by a facet. Templates describe families of assertions built with labels (m), interests ( ${?}$ ), wildcards ( $\star$ ), and expressions ( $\mathrm{e}$ ).

Event handlers consist of an event description ( $\mathrm{D}$ ) and a body ( $\mathrm{Pr}$ ). Events describe occurrences that are either internal to the actor ( $\mathtt{start}$ , $\mathtt{stop}$ ) or particular assertions in the dataspace ( $\mathtt{asserted}\,\,{\mathrm{e}}$ , $\mathtt{retracted}\,\,{\mathrm{e}}$ ). In the latter case, the description includes a pattern expression $\mathrm{e}$ defining the relevant assertions. In order to construct patterns, expressions additionally include match-anything wildcards ( $\star$ ) and binding variables ( ${\mathrm{x}}:{\tau}$ ).

In comparison to the implemented syntax, the model uses some obvious short-hands and some less obvious simplifications:

• • The assertion endpoints of a facet are all declared together.

• • The event handlers come as a sequence of description/handler body pairs.

• • The fields shared by a facet’s endpoints are declared outside the facet.

• • The assertion labels replace struct names.

• • Binding variables in patterns require a type annotation.

Here is the basic Light actor from Figure 2 in the model’s syntax:

5.2 Semantics

Since individual actors consume events and produce assertions, we choose to specify the semantics of facet-oriented actors via a labeled transition system. Each transition acts on a machine state and constructs the next one. The transition labels $\mathit{l}$ describe either inputs in the form of event patches ( $\Delta$ ) or outputs in the form of spawned actors ( $\overline{{\mathrm{Pr}}}$ ). An unlabeled transition relation ( $\bullet$ ), represents actor-internal work. Patches $\Delta$ comprise two disjoint assertions sets $\pi$ , representing added and removed assertions. Assertions $\mathrm{u}$ range over basic values, labeled tuples, and assertions of interest.

The formulation of machines requires syntax for describing the states in addition to the syntax of programs. Figure 11 defines this syntax and the machine states. The error state represents an actor that has crashed due to an unhandled error.

Fig. 11. Evaluation syntax.

An actor machine state consists of five components: . The components track different kinds of state and knowledge:

• • the activity state of facets

The machine must express which facets are currently active as well as the parent-child relationship among them. This aspect takes the form of a tree: $\mathrm{FT}$ . A node $\mathrm{fn}\,\,[{\overrightarrow{\mathrm{e}}}(\overrightarrow{\mathrm{D}\,\,\mathrm{Pr}})].\overrightarrow{\mathrm{FT}}$ in this tree describes an active facet in terms of its name, its assertion and event handler endpoints, and its children, while the empty tree takes the form $\epsilon$ .

• • the instruction stream within the active facets

A machine state identifies a sequence of ready-to-perform instructions $\mathrm{I}$ , and it also maintains a queue of pending scripts $\mathrm{PS}$ . A pending script ( ${\mathrm{fid}},\,\,{\mathrm{Pr}}$ ) is a sequence of statements to be performed and pertinent context information. The context is a facet ID $\langle{\overrightarrow{\mathrm{fn}}}\rangle$ identifying the facet from which the script originated. A facet ID is a sequence of facet names forming the path from the root of the tree to that particular facet. Instructions $\mathrm{I}$ can $\mathtt{start}$ a new facet at a designated location in the tree; $\mathtt{stop}$ a running one; and $\mathtt{spawn}$ an actor.

• • the information known to the actor

Specifically, the store $\sigma$ holds the contents of the fields, while the set of assertions $\pi$ keeps track of the actor’s current knowledge of assertions in the dataspace. Newly booted facets receive these assertions as an event.Footnote ⁶

Finally, we need some miscellaneous pieces of syntax. An $\mathrm{Evt}$ is either a patch or facet $\mathtt{start}$ / $\mathtt{stop}$ . Evaluation reduces expressions to values $\mathrm{v}$ .

Figure 12—above the horizontal line—shows the initial machine state $\mathrm{M}$ for the light-facet facet from above. The rest of the figure displays the first two transitions of the machine.

Fig. 12. The light-facet facet as an initial machine state and its transitions.

Transition Relations. Figure 13 defines the transition relation on machine states that describes the behavior of a single facet-based actor in response to incoming events. For the moment we ignore how such events arrive; Section 7 covers that aspect of the semantics. We use $\mathrm{M} \longrightarrow \mathrm{M}'$ as shorthand for .

Fig. 13. Transition relation.

Generally speaking, the machine works in the following fashion. Initially, the machine state describes an inert actor, meaning there are no instructions to perform nor pending scripts to execute. When the machine receives an event patch, it is matched against the event handlers of the actor’s facets. For each successful match, the body of the event handler is enqueued as a pending script.

Once the matching process is completed, the machine executes the scripts. It dequeues the first one and interprets the instructions, one at a time. Some instructions generate internal events (facet start and stop). For those the machine matches them again against the facet tree, and this process may enqueue additional scripts. The machine continues in this manner until it reaches inertness again. At that time, another external event may be injected.

Here are descriptions of the machine’s five transition rules:

• inject —The rule’s purpose is to dispatch an event to an inert actor. Due to dataspace routing, the event is guaranteed to conform to the actor’s interests. Incorporating the incoming patch via $\oplus$ yields a new set $\pi'$ of assertions known by the actor. The dispatch metafunction matches the event against each handler in the tree of facets, yielding a pending script for each match.

• transfer —The machine transfers the next pending script to the current register and partially evaluates ( ${p-e}$ -s) its internal statements. In doing so, it updates and creates fields in the store. The process eliminates expressions and yields a sequence of instructions that alter the active facet tree ( $\mathtt{start}$ / $\mathtt{stop}$ ) or correspond to an output by the actor ( $\mathtt{spawn}$ ). Partially evaluating the script means eval-ing expressions, which may include applications of partial primitives. In the event that such a primitive fails, the actor crashes. The error state represents a crashed actor without any behavior.

• start—The next instruction demands the start of a facet. The new facet is given a fresh name; the bodies of each of its event handlers refer to the new name. The dispatch function is used to create two scripts: one to signal a $\mathtt{start}$ event and one to boot the event handlers that correspond to the known assertions of the actor. These scripts are enqueued and the new facet is inserted in the tree. The instruction specifies the location for the new facet in the tree as a path ( $\mathrm{fid}$ ) to the new facet’s parent. The locate metafunction constructs the appropriate context. It is possible that no such context exists, which happens when the desired parent, or one of its anscestors, is terminated via a $\mathtt{stop}$ instruction in the time between the script containing this $\mathtt{start}$ statement being enqueued and the instruction executing. In that case, the new facet is immediately terminated. The dispatch function informs it of the $\mathtt{stop}$ event. The resulting scripts are enqueued, and the facet is never inserted into the tree.

• stop—The machine terminates an active facet and its children, dispatch-ing a $\mathtt{stop}$ event to allow these facets to shut down in an orderly manner. The instruction may designate a facet that is already eliminated. In this case, there is no more.

• spawn—The facet wishes to create an actor, which the machine treats as an output instruction. Formally, the transition comes with a $\overline{{\mathrm{Pr}}}$ label.

The top-most machine state in Figure 12 transitions to an inert state in two steps. The first one injects the script, consuming the patch $\,\,{\mathtt{{in-room}(0)}}{\emptyset}$ as the label indicates. The second enqueues the script’s instruction and performs it.

5.2.1 Metafunctions

The transition system of Figure 13 refers to several metafunctions. This section provides their formal definitions. The definitions make use of secondary metafunctions, which are defined in Appendix B.

The ${boot}_{\mathrm{Pr}}$ function initializes the machine from an actor description. It recognizes only scripts that create some number of fields and then $\mathtt{start}$ a single facet. It creates each field and then boots the facet as a child of a synthetic root facet with no behavior. The synthetic root facet allows the initial facet to be replaced by any number of facets via $\mathtt{stop}$ :

The dispatch function matches an event against each handler in a tree of facets, accumulating the successes as a list of pending scripts:

It utilizes a helper function, dispatch1, to instantiate the body of a single event handler with the substitution(s) arising from matching against a single event. Substitutions $\gamma$ map variables to values and matching a pattern against a set of assertions yields a set of substitutions $\mathcal{S}$ :

Finally, unroll sequentializes a set of statements using an arbitrary yet fixed ordering:

The ${p-e}$ function partially evaluates a script, yielding a sequence of instructions and an updated store:

The ${facet-context}$ function produces the path of facet names (a $\mathrm{fid}$ ) leading to the hole in a context:

Meanwhile, locate performs the reverse direction, producing the context for a particular $\mathrm{fid}$ in a tree of facets:

6.1 Type syntax and judgment

Figure 14 defines the syntax of types. Effect types T directly reflect the core facet syntax (Figure 10), including facet $\mathtt{start}$ / $\mathtt{stop}$ and $\mathtt{spawn}$ operations of $\mathrm{Pr}$ . Event descriptor types $\mathrm{D}_{\mathrm{T}}$ correspond directly to the term level descriptors $\mathrm{D}$ . Types $\tau$ summarize the result of expressions, with base types B describing primitive values. Type environments $\Gamma$ associate variable names from patterns and fields with their types and facet names with the marker FacetName.

Fig. 14. Type syntax.

Figure 15 specifies the core type judgment on facets: It ensures that facet and field names are used appropriately while collecting certain facet operations as an effect type T. As mentioned, this effect type is used for behavioral analysis. Auxiliary judgments apply to the different categories of syntax; Appendix D provides their definitions.

Fig. 15. Facet typing.

Here are explanations of the key typing rules:

T-Start assigns types to a facet-creation instruction. It appeals to an auxiliary judgment for checking the assertion expressions $\mathrm{e}$ , which also produces a description of the assertion types $\tau$ . The condition $\mathtt{assertable}({\tau})$ , defined in Appendix D, ensures that assertion types do not contain binding patterns or field names. The event descriptors $\mathrm{D}$ for each event handler are checked in the same manner, yielding a type $\mathrm{D}_{\mathrm{T}}$ for each. The final aspect to check is the body $\mathrm{Pr}$ of each event handler. For each such body, the environment is extended with the name of the facet being started as well as the binding variables from the pattern in the event descriptor (via the ${bindings}_{\mathrm{D}}$ metafunction). Checking each body produces a type level description of its behavior, T. The product of the rule is a Start effect, combining the types of the assertions plus each event handler description and its body.

T-Stop is the analogue of for facet termination. It consults the environment to ensure that the named facet is in context. The ${prune-up-to}$ function removes the target facet’s name from the environment, as well as the names of any of its descendants, when checking the continuation $\mathrm{Pr}$ . The resulting effect type is to $\mathtt{Stop}$ the same facet with a continuation behavior.

T-Field, T-Assign check field creation and assignment, respectively. The judgment for field creation checks the type of the initial expression and associates the name with an appropriate type in the environment for the remaining statements. The judgment for field assignment looks up that type in the environment, making sure that the type of the assigned expression matches. Field updates and references are not included in effect types. Thus, field creation yields the effect type from its enclosed statements while field assignment yields a Skip effect.

T-Spawn concerns the creation of actors. The rule utilizes the prune function (Appendix D) to remove identifiers associated with fields and facet names from the running actor, because these names are local. The spawned actor’s behavior $\mathrm{Pr}$ is checked within this restricted context, and it has the (sole) effect of Start-ing a facet. The effect type of the $\mathtt{spawn}$ statement is a $\mathtt{Spawn}$ with a type description of the actor’s initial facet.

6.2 Machine types and type-level machines

The judgment $\vdash_{\mathrm{M}}:\mathrm{M_{\mathrm{T}}}$ relates a machine $\mathrm{M}$ to a machine type $\mathrm{M_{\mathrm{T}}}$ . A machine type $\langle\mathrm{FT}_\mathrm{T};{\overrightarrow{\mathrm{I}}}_\mathrm{T};\overrightarrow{\mathrm{PS}_{\mathrm{T}}};{\pi_{\tau}};{\sigma_{\tau}}\rangle$ includes a facet tree type ( $\mathrm{FT}_{\mathrm{T}}$ ), sequence of instruction types ( $\overrightarrow{\mathrm{I_{\mathrm{T}}}}$ ), sequence of pending script types ( $\overrightarrow{\mathrm{PS_{\mathrm{T}}}}$ ), set of assertion types ( $\pi_{\tau}$ ), and store type ( $\sigma_{\tau}$ ). Appendix F defines the full judgment and syntax. In brief, the syntax of machine types reflects the syntax of machines (Figure 11) in the same manner that effect types T (Figure 14) reflect the syntax of statements $\mathrm{Pr}$ (Figure 10).

The statement of soundness for facet-based actors relies on two auxiliary notions. First, we say $\mathrm{M}$ is an inert machine state, $\texttt{inert}({\mathrm{M}})$ , iff . That is, it has neither instructions to perform nor pending scripts to execute. Second, we designate a set of internal transition labels, $\mathit{l_{\bullet}}$ . Internal labels correspond to the machine processing instructions and scripts. Thus, they consist of each $\bullet$ and $\overline{{\mathrm{Pr}}}$ label, but not $\Delta$ .

If a well-typed single-actor machine configuration can take an inject step, it eventually transitions to an inert machine state or a state that represents an exceptional state (due to a misapplication of a partial primitive).

The transition system for machine states operates on machine types with only minor syntactic adjustments. Appendix F defines the full type-level transition system. Section 8 makes use of this notion for behavioral analysis of actors. Here, we note that transitions on type machines are well-defined.

7.1 Facet dataspace programs

Caldwell et al., (Reference Caldwell, Garnock-Jones and Felleisen2020) show how to link a semantics for individual actors with the dataspace semantics and prove the soundness of the composite system. Their semantics coincides with ours, so that the soundness of the system follows from Theorem 5, because each actor implements the functional interface of a $\textbf{BehFun}$ . The ${interp_{\mathrm{M}}}$ function is the key component connecting the semantics of dataspaces with the semantics of facet actors. It implements the dataspace behavior interface $\textbf{BehFun}$ for facet machine states, and it applies a pending patch to a machine state via an -step, then allows the machine to continue via internal transitions until reaching either inertness or an error state. The result of the function is the new machine state together with a patch describing the difference(s) in assertions between the initial and final states. Furthermore, any $\overline{{\mathrm{Pr}}}$ transitions are translated to dataspace specifications P:

The ${boot}_{\mathrm{P}}$ metafunction translates a facet-level $\mathtt{spawn}$ to a dataspace process description:

7.2 Type-level dataspace programs

Section 6.2 sketches how to lift the transition system on a facet machine to operate on a facet machine type. Similarly, the dataspace transition system above naturally lifts to the type level with only minor adjustments. A type-level dataspace consists of actors communicating in terms of assertion types $\tau$ . Facet machine types provide behavior to actors in a type-level dataspace the same way that facet machines give behavior to term-level dataspace actors. We write $\mathrm{DS}_{\mathrm{T}}$ to refer to a dataspace configuration with type assertions.

7.3 Example

Figure 17 shows a dataspace configuration based on the smart home example and its evolution. For readability, the example employs a notation different from that of Figure 16, giving each actor a name rather than an address and aggregating various other parts of the syntax. Each actor is displayed as a triple, as in for an actor with name nm. The leftmost element is the current pending event for the actor, while on the right are its current set of assertions. The example treats the behavior and private state of each actor as a black box, displaying them as a box containing the actor’s name. For brevity, we use two additional notational shorthands. As a pending event, $\cdot$ represents the empty , while a single assertion $\mathrm{u}$ stands for the patch .

Fig. 17. Example Dataspace Transitions

The configuration contains three actors, representing the control hub, a light with the ID “l1”, and a presence sensor with the ID “ps1”. Each transition of the relation from Figure 16 is broken into two steps. The first routes assertions among the actors and updates pending events when there is relevant information. The second dispatches each actor on its pending event and updates its current assertions.

The system proceeds in the following manner:

1. 1. Initially, the light actor announces its presence and on/off state, as well as a subscription to a room assignment.

2. 2. The hub actor’s interest in light assertions yields a corresponding event.

3. 3. In response, the hub actor introduces a room assignment to the “bed” room.

4. 4. Routing results in an event informing the light actor of the assignment.

5. 5. The light actor’s reaction is to introduce a subscription for assertions that the “bed” room is empty.

6. 6. The subscription matches the existing empty assertion, immediately yielding an event for the light actor.

7. 7. The light actor updates its light assertion to the off state in response to the room being empty.

8. 8. The hub actor receives a patch describing the change to the light assertion.

9. 9. Finally, the hub actor processes the latest patch without changing its assertions, yielding an inert system.

Figure 18 shows the corresponding type-level system. The primary difference is that the assertions in the dataspace are types rather than values; the names of the actors have also been capitalized to emphasize the difference between the two examples. The transitions follow the same logic as those of Figure 17, with one exception. The example encodes the on/off state of the light as a Bool. Consequently, the types of assertions in the dataspace do not change when the light switches from on to off in response to an empty assertion (type). Thus, the type-level system reaches inertness in fewer transitions than the term-level one.

Fig. 18. Example type dataspace transitions.

9.1 Implementing the behavior of facet-oriented actors

The basic language implementation of facet-oriented actors consists of three layers:

• • a syntax layer, which provides the facet notation of the first half of this paper;

• • a runtime system, which provides data structures and functions that implement the behavior of facets and endpoints; and

• • an imperative dataflow network for tracking changes to fields and scheduling the re-evaluation of dependent computations.

These pieces are built atop the existing implementation of the dataspace model. The dataspace implementation does not require any modifications in order to support these elements, just as the dataspace model predicts (Garnock-Jones & Felleisen, Reference Garnock-Jones and Felleisen2016).

The syntax layer essentially turns the surface forms into calls to functions provided by the runtime system. It makes use of syntax/parse, Racket’s high-level syntax extension system (Culpepper & Felleisen, Reference Culpepper and Felleisen2010, Reference Culpepper and Felleisen2012). Implementing the surface language with syntax/parse greatly simplifies the addition of actor syntax. Moreover, the resulting interface can be extended and grown as the language develops, and the implementation can benefit from any improvements to the underlying dataspace library. It also facilitates the addition of a type checker.

The run-time system is the most sophisticated of the three layers. The key elements strongly mirror the data structures of the machine and the meta-functions of the formal model of Section 5. Technically speaking, the run-time system maintains data structures corresponding to the different parts of machine states $\mathrm{M}$ and defines functions for dealing with facets, enqueuing scripts, etc. The implementation differs from the model primarily in its support for efficient re-evaluation of the assertions of an actor as fields are updated.

Finally, the runtime maintains a bipartite, directed dataflow graph for each facet-oriented actor. A source node represents a field, a target node an endpoint, and edges the dependencies of the endpoints on the fields. Each endpoint representation contains a procedure that is used to compute the set of assertions to be associated with the endpoint. By recording field dependencies during the execution of such procedures, the implementation learns which endpoints must have their assertion sets recomputed in response to a field change.

9.2 Implementing the type checker

The type checker is implemented with the Turnstile meta-DSL (Chang et al., Reference Chang, Knauth and Greenman2017). Roughly speaking, Turnstile macros supplement syntax/parse with a mechanism to check types first and elaborate the given source syntax into target terms later. That is, each syntactic form is defined as a macro that performs some type checking before elaborating to syntax that implements the run-time behavior. Type information is propagated via metadata on syntax objects.

For example, the define-typed-syntax macro for start-facet looks like this:

Line by line, this definition reads the following way:

• • The macro applies to syntax that matches the (start-facet id expr …+) pattern.Footnote ⁷ The pattern expects an identifier and a nonempty sequence of endpoint expressions.

• • The code between pronounced “elaborates to”—and the dashed line analyzes and checks these endpoint forms:

  • 1. The first clause elaborates each endpoint expression, ep, individually in an environment extension that records name as the name of a facet. This allows Turnstile to resolve each identifier reference within each ep to the proper type.

  • 2. The result of a successfulFootnote ⁸ elaboration is bound to the name ep-, while the types of effects performed by ep are bound to the name effs.

  • 3. The trailing ellipse dictates that each ep form is analyzed in this manner.

• • The #:fail-unless clause enforces the side-condition on the corresponding type-checking rule. It makes sure that the body has only endpoint installation effects, such as from the use of on, assert, and field; it disallows the following effect types: start-facet, stop, and spawn. The actual work is left to a helper function: all-endpoint-effects?. If the check fails, the checker signals a type error.

• • The clause below the dashed line consists of the macro’s two outputs:

  • 1. The first output is the target expression that implements the behavior of start-facet. The produced expression calls the install-facet! procedure, which is provided by the run-time support system for facets. The procedure consumes the name and a thunk that runs the results of elaborating the endpoint forms—in the specified order. These endpoint forms then elaborate to calls to other procedures from the run-time system, and so on.

  • 2. The second output attaches a type to the elaboration. Here it describes the effect type of the form: StartFacet, with endpoint types described by effs ….

Generally speaking, the define-typed-syntax macros are almost verbatim transliterations of the typing rules presented in Figure 15.

9.3 Implementing the model checker

A programmer initiates a system verification with respect to some specification by adding the following formula to the program:

In terms of Theorem 12, this formula requests a check of where the LTL formula $\psi$ corresponds to spec, and T is the series of actor-types, one per actor in the dataspace program. If the check succeeds, then the actors of these types jointly realize the specification.

The implementation of verify-actors utilizes the model checker SPIN (Holzmann, Reference Holzmann1997) to check such uses. That is, it translates each use of verify-actors into a Promela program, that is, SPIN’s input forms.

More precisely, the translation turns each actor-type into a Promela process with a state-machine driven behavior. Each state corresponds to a set of active facets within the actor. An encoding of the dataspace routing algorithm allows processes to react to the appearance and disappearance of assertions, while an additionally generated process performs message dispatching.

SPIN is invoked on this Promela program, plus a translation of the LTL $\psi$ . If verification fails, the trace provided by SPIN is back-translated into the actions of the type-level actors.

Figure 20 displays a sample Promela program. It is the result of translating the Light actor’s type. The figure annotates the Promela code with in-line explanations. We italicize the annotations to distinguish them from the actual code and comments, which are enclosed within /*…*/. The rest of the Promela process follows the same form.

Fig. 20. Annotated excerpt of a Promela program for the SPIN model checker

Blocks of code within the actor (lines 15, 23) execute atomically to avoid any unnecessary interleaving with other actor’s initialization in the SPIN search space. Additionally, comments within the code, such as those on lines 16 and 30, embed information from the Racket source program; this information is used to back-translate counterexamples of the SPIN model to the source level.

10.1 Corpus

This section describes the programs in the corpus, as well as several behavioral properties for each program that comprise the subject of the evaluation. One property—deadlock-freedom—is relevant to several examples and thus factored into its own Section (10.2), which discusses the topic in the context of dataspace programs and our behavioral checks. Each program consists of about 500 lines of code, comprising the concurrent core of a larger system.

Smarthome. This program is an extended version of the earlier examples, including a text-based user interface and temperature sensors and controls.

• • Light Presence. This property describes the desired interaction between presence sensors and lights in the smarthome program. The specification essentially states that once a presence sensor and light have been installed in a room, the light turns on or off as the user moves in or out of the room, respectively.Footnote ⁹ Note that while on the surface this property only talks about light and presence sensor actors, the behavior of those actors depends on additional interactions from the user interface, the actor representation of the user, and the hub actor.

• • Steady State Temperature. This property specifies the desired behavior of the thermostat in the smarthome: when the user sets a desired temperature, the system gradually heats or cools the home until the target is reached, before turning off.

Data Processing. This program implements the core of a streaming data processing framework, inspired by Flink.Footnote ¹⁰ Clients submit jobs consisting of some number of inter-dependent tasks. Several actors collaborate to manage the underlying computational resources for executing tasks, tracking intermediate progress, and delivering the end result.

• • Task Delegation. This property checks the working of three actors that collaborate to perform tasks by treating them as a black box: each assigned task is eventually performed. Performing a task involves delegating it from the job manager to a task manager, and then from a task manager to a task runner, and finally propagating the results back in the opposite direction.

• • Job Completion. This is another black-box correctness property: when a client submits a job, the job’s results eventually become available. When a client submits a job, a job manager actor analyzes the request and computes a directed, acyclic graph of tasks. It then processes the task graph by assigning tasks as they become ready to other actors, before finally announcing the results of the job. A weak variant of this property states that each job either completes or processes tasks in an infinite loop.

• • Load Balancing. Task-runner actors are capable of performing one task at a time. A task manager actor monitors the status of task performers and assigns them tasks when they are idle. Likewise, each task manager has a capacity based on the number of task runners it manages. The job manager assigns tasks to task managers based on their current free capacity. This property states that the task manager never assigns a task to a busy runner and the job runner never assigns a task to a task manager that is at capacity. A weak variant of the property pertains to the scenario where each task manager oversees exactly one task runner actor.

Caucus. This program represents a geographically distributed, iterative election in the style of a caucus, inspired by the “two-buyer problem” from the behavioral types literature (Honda et al., Reference Honda, Yoshida and Carbone2008). A distinct actor represents each voter and candidate. After a registration period, voting commences across a collection of regions. Within each region, voting proceeds in rounds until a single candidate receives a majority share of the vote. Once every region has reached a decision, the winner of the most regions is pronounced the winner of the election. In each region, an actor guards against various forms of misbehavior from voters and candidates, such as voting twice.

• • Resolution. The election completes. A weak variant of the property states that either the election completes or holds infinitely many rounds of voting.

• • Candidate (Mis)Behavior. This property is the specification for a well-behaved candidate actor in the election. A well-behaved candidate actor announces its candidacy as an assertion and maintains it until either the election is over or an election agent informs it that it is no longer in the running.

• • Voter (Mis)Behavior. This property is the specification for a well-behaved voter actor. A well-behaved voter actor registers in exactly one region and then participates in each round of voting in that region by casting exactly one vote for one of the eligible candidates. A weak variant of the property states that the voter registers and always votes at least once in each round.

Windowing System. This program implements a basic graphical windowing system. A collection of driver actors collaborate to provide the primary interface. A layout-solving actor powers graphical output by combining requested sizes and layout styles (such as vertical or tabular) with the actual dimensions of the system window to compute the actual size and location of each item. Another interface actor provides descriptions of mouse events, including when the mouse is touching a window, mouse presses, and releases. The mouse interface allows for an actor mix-in (a function that starts facets or endpoints) to implement drag-and-drop behavior, which can then be instantiated and reused freely. The rest of the program consists of actors implementing rudimentary windowed applications and menus.

• • Layout. This property describes the behavior of the layout engine, which spawns solvers for horizontal, vertical, and tabular layouts on demand. The specification is based on a comment in the original, untyped program, describing the desired behavior; it essentially demands that requests for layouts are answered with solutions:

  

This comment closely corresponds to the specification language of assertion types and LTL connectives provided by the implementation.

• • Menu Duration. This property checks the lifetime of menu items: that they appear in response to selecting a menu and that they remain until either a selection is made or a mouse click occurs, either selecting a menu item or closing the menu.

Web Chat. This program implements the server for a chat service loosely based on Slack.Footnote ¹¹ It allows a user to connect, sign up for an account, and then create and join conversations. Connected users may request to follow one another. Accepted follow requests lead to each user being added to the contact list of the other. Users may join the conversations of their contacts. The system implements an option for permission delegation, so that if user A chooses to invite user B to a conversation, user B may then invite user C, and so on.

• • Conversation Release. This property is based on a comment in the original, untyped program, essentially calling for the release of resources in the event that a request is canceled before the response has materialized:

  

A weak version of the property relaxes the need for the resources to all be removed “at once.”

• • Contact Release. This property is also based on a similar comment in the code to the conversation release property, but in the module for managing the contacts list for users:

  

A weak version of the property relaxes the need for the resources to all be removed “at once.”

10.2 Deadlock freedom

Dataspaces implement a form of asynchronous message-passing, so in a technical sense every dataspace program is free from deadlocks. However, dataspace programs may reach a stuck state where each actor waits for further communication before continuing. Such a situation is sometimes referred to as a soft deadlock. The corpus includes several programs that feature numerous kinds of actors participating in interwoven conversations, making freedom from such soft deadlocks a desirable property to check.

Figure 21 demonstrates a simple program simulating two friends attempting to make plans. One friend actor, once it knows the time of the meeting, is ready to suggest a location. Meanwhile, the other friend actor, is ready to suggest a time depending on the location. The result is no communication at all. Such situations can arise from poorly designed protocols and buggy implementations. Figure 21 is a case of the former.

Fig. 21. Soft deadlocked actors.

One way of describing soft deadlocks is that an actor states an interest, that interest is never withdrawn (that is, the interest remains relevant to the actor), and no matching assertion ever arises. The following LTL formula states this property with respect to the friend1 actor’s interest in Time assertions:

Checking this LTL property against the implementations of the friend1 and friend2 actors fails, as should be expected for Figure 21. The resulting trace illustrates the two actors waiting for one another with active subscriptions but no matching assertions.

A similar property describes the deadlock from the perspective of the friend2 actor’s interest in Place assertions, which fails a similar check:

Generalizing, a program may be checked for deadlocks by taking each assertion of interest ? $\tau$ and checking the following LTL formula:

Such a check succeeds if the model checker can show that the program never deadlocks. This property may be too strong for the level of type precision. An alternative approach is to state in LTL that the program definitely deadlocks, and see if model checking produces a counterexample, implying that the program has some non-deadlocking executions:

This section refers to the former property as strong (soft) deadlock freedom and the latter as weak (soft) deadlock freedom.

10.3 Results

Table 1 summarizes the results. Each row of the table describes a property from the corresponding program. A ✓ in the “Expressible” column indicates that the implementation can express the property and a corresponding ✓ in the “Checkable” column indicates that the implementation successfully checked the property. Otherwise, the process of stating and checking could not be completed. Section 10.4 discusses these cases.

Table 1: Evaluation results

10.3.1 Performance

One possibility is that, even if the implementation can express and check a desired property, the result may not return within a reasonable amount of time. The potential for a program’s state space to grow exponentially is unavoidable. Eventually, even the most optimized checkers will require enormous amounts of memory and face slowdowns. Determining a threshold for a “reasonable” amount of time is tricky, as different developers have different conceptions. This evaluation sets the upper bound for a check that could still be useful at eight hours. That is a long time, but short enough to be a part of continuous integration (CI) tests that run on a nightly basis, with the results ready for review the next morning. Table 2 details the running time and peak memory usage for each successfully checked property.

Table 2. Running time (seconds) and memory usage (megabytes) of each completed check. The checks ran on a laptop with an Apple M1 Pro CPU, 32GB of memory, and MacOS Ventura 13.5 installed

The performance clears the “integration test” threshold by a wide margin. All of the properties take seconds or a few minutes rather than hours to check. The property that takes the longest to check, deadlock freedom for the smarthome program, consists of 22 individual properties, one for each type of subscription in the program. Each sub-property leads to a separate invocation of the model checker, one for each type of interest in the program. These results put the performance in the realm of “unit test” acceptability, where the checks can be run along with a unit test suite before committing each change to a project.

10.4 Interpretation and discussion

This section discusses each of the properties that the implementation failed to support and the primary reason(s). In a few cases, interesting details for successfully checked properties are provided as well.

Data Processing.

• • Job Completion. The implementation is not able to check this property. The checker is not able to reason about the termination of the task-processing loop in the protocol. Even though the loop follows an inductive structure—processing a DAG—this information is not propagated to the type level. Moreover, since an LTL formula always talks about all possible executions of a system, the specification language cannot express that it is at least possible to reach the desired end state.

• • Load Balancing. The implementation is unable to state and check the property. For a task manager with an arbitrary number of associated task runners, stating the specification requires stating relations between numbers. Checking the property would similarly require reasoning about arithmetic operations. Moreover, the property inherently deals with the multiplicity of assertions of a certain types, namely task-assignment assertions. Violating the property means having more than the expected number of such assertions.

Checking the weak variant of the specification makes use of a coincidence in the program for working around the inability to reason about the multiplicity of assertions. Because there happen to exist two distinct types of tasks, a limited form of multiplicity can be checked—namely, if there are some of one type of task assigned to a manager, there are none of the other, and vice versa.

Caucus.

• • Resolution. Checking this property also encounters difficulty due to the potential non-termination of a loop in the protocol. The implementation is unable to reason about the termination of the loop, even though the loop matches a simple inductive structure (one candidate is removed each round).

• • Voter (Mis)Behavior. The implementation lacks the precision to state the full specification. The primary impediments are the inability to correlate information from one assertion to another, such as the name of the candidate the voter chooses with the names of the candidates on the ballot, as well as reason about the multiplicity of assertions. However, the weak specification is still able to distinguish a correct implementation of a voter from several malicious ones.

• • Deadlock Freedom. While Section 10.2 discusses deadlock freedom, one interesting point to note is that this check uncovered a bug in the program: at the end of each round of voting, a region manager actor announces intermediary results that inform the candidates of their status in the race, except for the final round of voting, the manager actor simply announces the winner. Due to an oversight, the original implementation of the candidate actors only listened for the intermediate results, not the winner announcement. As a result, they were soft deadlocked waiting for an intermediate update that never materializes. The fix to the bug is to have the candidate actor listen and react to the final election result.

Web Chat.

• • Conversation Release. This property is checkable with the implementation, with one caveat: the phrase “at once” entails a level of precision that is beyond the implementation. That is, it can check that the required assertions disappear, but it does not have a way of expressing that the concerned parties, “all eligible answerers,” all react within a set timeframe. However, that part of the specification is of dubious importance when scrutinized: dataspace routing will always dispatch an event to all interested actors when the question is withdrawn. Each such actor will have the opportunity to react to the event in due time. Since dataspace scheduling is fair, there is little reason to worry about such timing details. Thus, the full specification is beyond the implementation, but the weak version, without the timing constraint, is checkable.

• • Contact Release. Just as with the conversation release property, the “at once” phrasing creates difficulty but is of questionable importance. So again, the full specification is not checkable but a weak variant without the timing constraint is.

Threats to Validity. There are several threats to validity of this evaluation. The corpus comprises a small number of programs, authored by only three individuals. The programs for the corpus were not selected randomly. Rather, we sought programs whose implementations involved a high degree of concurrency and communication, as opposed to business logic or other concerns. Moreover, the identification of properties and subsequent verification efforts were conducted by the authors of the tools. We are highly familiar with both the capabilities and limitations, potentially biasing the search for properties that are a good match for the current capabilities.

11.1 Facets and the design of concurrent languages

Programming languages provide limited support for organizing conversations among groups of actors and their internals. Garnock-Jones et al. (Reference Garnock-Jones, Tobin-Hochstadt and Felleisen2014, 2016) compare dataspace communication with related coordination mechanisms such as the Conversation Calculus (Vieira et al., Reference Vieira, Caires and Seco2008), the Mobile Ambient Calculus (Cardelli & Gordon, Reference Cardelli and Gordon2000), the join calculus (Fournet & Gonthier, Reference Fournet and Gonthier2000), and tuplespaces (Carriero et al. Reference Carriero, Gelernter, Mattson and Sherman1994; Murphy et al., Reference Murphy, Picco and Roman2006), as well as various actor systems and process calculi. Here, we focus on linguistic features for organizing the code of individual actors.

State-Machine Actors. Actor systems such as Akka (Akka Project, Reference Project2022) and Erlang/OTP (Armstrong, Reference Armstrong2003) provide means of organizing actors as state machines. Erlang’s gen_statem interface exemplifies these mechanisms. The programmer describes each state in the machine as a procedure mapping an incoming message to the next state and some actions to carry out. These state transition functions also operate on the actor’s private store, handled separately from the state of the machine.

Actors organized as event-driven state machines lose access to contextual information. Instead, such notations force programmers to encode context into each state and save related information explicitly in the private store. Such encodings, however, make it cumbersome to create actors that simultaneously participate in multiple conversations or alternatively engage and disengage in multiple intertwined behaviors, such as the Hub and Light actors from Section 3.

The gen_statem interface and its sibling gen_server address only one of the concerns of facets in a limited fashion: abstracting control state. Language support ends at instantiating the interface with callbacks. An actor that deals with multiple types of messages in a single state must often manually demultiplex the message to match it with the proper response. Callbacks use the familiar state-passing style, operating on a monolithic store. Though callbacks may coordinate startup and shutdown of the actor, initiating and closing a conversation comes without linguistic support.

Fact Spaces and Crime. The inspirational fact spaces model (Mostinckx et al., Reference Mostinckx, Scholliers, Philips, Herzeel and De Meuter2007) shares many similarities with the dataspace model. Fact spaces build on TOTAM (Scholliers et al., Reference Scholliers, González Boix and De Meuter2009, Reference Scholliers, González Boix, De Meuter and D’Hondt2010; González Boix et al., Reference González Boix, Scholliers, De Meuter and D’Hondt2014), a form of tuplespace, to equip actors with a means of moving and sharing state. In fact spaces, programs react to both the appearance and disappearance of facts from a shared repository. Reactions are described in a logic coordination language, allowing the computation of new facts based on current facts via forward-chaining. The language implementation (implicitly) records the dependencies between facts and invokes application actions specified by logic rules.

The implementation of the fact space model, dubbed Crime (Mostinckx et al., Reference Mostinckx, Lombide Carreton and De Meuter2008), integrates the fact spaces model with the AmbientTalk language (Van Cutsem et al., Reference Van Cutsem, Mostinckx, González Boix, Dedecker and De Meuter2007; Van Cutsem et al., Reference Van Cutsem, Gonzalez Boix, Scholliers, Lombide Carreton, Harnie, Pinte and De Meuter2014). AmbientTalk is an instance of the Actor model (Agha Reference Agha1986; De Koster, et al., Reference De Koster, Van Cutsem and De Meuter2016) in the mold of E (Miller et al., Reference Miller, Tribble and Shapiro2005). In E and AmbientTalk, objects are organized into vats; each vat runs its own event loop, dispatching incoming messages to the contained objects. Combining AmbientTalk and Crime requires bridging the gap between the events corresponding to assertion and retraction of facts and the message exchange of AmbientTalk. The solution incorporates reactive programming, in the mold of FrTime (Cooper & Krishnamurthi, Reference Cooper and Krishnamurthi2006). The result is that actors may define time-varying behaviors, with values shifting based on the available facts.

The differences between Crime and facet-oriented dataspace actors stem from the absence of a unifying notion of a conversational frame. Crime comes without any representation of a conversation, hence programs lack the conversational structure of (nested) facets. Time-varying collections do not offer a way of propagating changes to the tuples in the shared space, unlike the fields and query forms that connect to an actor’s endpoints. Because Crime does not group the components of conversational behavior, no automatic support exists for the release of associated resources. Programmers must carefully reason about the relationships between components to ensure that the state of the actor and associated tuples remain consistent. The underlying E language offers object references to denote specific conversations within the heap of a given actor and employs method dispatch as a limited pattern matcher over received messages.

Concurrency Within Active Objects. Some Active Objects languages allow for concurrency within an Actor or Actor-like entity (de Boer et al., Reference de Boer, Clarke and Johnsen2007; Schäfer & Poetzsch-Heffter Reference Schäfer and Poetzsch-Heffter2008, Reference Schäfer and Poetzsch-Heffter2010). Typically, this concurrency is achieved by allowing multiple message dispatches to be active within a single active object. This allows for splitting control and state among numerous objects, resembling the way our facets and fields individually contribute to the actor’s overall behavior.

Much like with conventional object-oriented programming, communication between active objects forms a graph structure. Each active object is a node in the graph and has an edge to each object it communicates with via asynchronous method invocation. Indeed, many active object languages support both the communication-level graph and the traditional object-oriented “refers to” relationship with support for passive objects (Boer et al., Reference Boer, Serbanescu, Hähnle, Henrio, Rochas, Din, Johnsen, Sirjani, Khamespanah, Fernandez-Reyes and Yang2017). Each active object (node in the communication graph) may implement its behavior using any number of such passive objects following traditional object-oriented design (Gamma et al., Reference Gamma, Helm, Johnson and Vlissides1994).

Dataspaces and faceted actors possess the same graph-like communication structure. Each actor (node) is connected to each other actor that it communicates with via assertions (edge). Thinking in terms of the graph abstracts away the differences between the message-passing paradigms employed by active objects (point-to-point) and dataspaces (publish/subscribe). Just as how an active object may implement its behavior using any number of passive objects with their own fields and method definitions, a facet-based actor defines its behavior across a collection of facets, fields, and endpoints. The primary difference is that passive objects form a graph, while facets form a (dynamically changing) tree. The tree structure of facets enables the ability to program directly to the concerns of startup and, especially, shutdown (via the stop statement and on stop event handlers).

One interpretation of this analysis is that it may be fruitful to adapt the facet notation to the domain of active objects. Combining facets for defining behavior with passive objects for defining state has the potential to synthesize the best of both worlds.

ConGoLog. While communication-by-assertion in dataspaces is inspired by Prolog fact databases, ConGoLog (De Giacomo et al., Reference De Giacomo, Lespérance and Levesque2000) is a more direct adaptation of logic programming to concurrency. In ConGoLog, a programmer first models a particular domain—typical applications include robotic control systems—with a collection of axioms describing relevant properties and the effects of performing particular actions. The main program then specifies some number of concurrent agents—as logic programs—emitting effects, each of which may update the stated properties, and reacting to the truthiness of such properties.

ConGoLog and dataspaces share a deep connection but also differ in significant ways with respect to their conceptions of state and agent. As a variant of the actor model, dataspaces provide each actor with its own isolated memory, while the dataspace itself contains information shared with the rest of the program. Information shared in the dataspace is tied to the identity of some particular actor, imposing a rigid structure on updates and a connection to component failure. Meanwhile, ConGoLog lacks the distinction between local state of an agent and globally visible state information of the situation. Concurrent ConGoLog agents come without the structure provided by facets for grouping related behavior and state, as well as orchestrating startup, shutdown, and component evolution—partly because these concerns are not a goal of the design.

Sparrow. The Sparrow DSL (Avila et al., Reference Avila, De Koster and De Meuter2020) extends Erlang with the ability to react to complex event patterns. That is, rather than just handling one message at a time from its mailbox, a programmer may utilize Sparrow to specify an actor’s behavior dependent on particular combinations of messages, timing constraints, and so on. Reactions to a given pattern may be dynamically added to and removed from an actor’s behavior. A reaction is like a facet with a single event-handler endpoint. They lack the other features of our language, like the hierarchical structure, start-up and shut-down behavior, and grouping of facets, as well as localized state of fields.

Dataflow. The simple dataflow system described here is most similar to the simple dependency tracking approach to object-oriented reactive programming described by Salvaneschi & Mezini (Reference Salvaneschi and Mezini2014, section 2.3) and was in fact directly inspired by the dependency tracking of JavaScript frameworks such as KnockoutFootnote ¹² (Sanderson, Reference Sanderson2010) and Meteor.Footnote ¹³

11.2 Behavioral type systems

In general, the design and theory of a type system is intimately tied to the underlying language. This is doubly true of behavioral type systems, which express control-flow aspects of the program, not just the static relationships found in purely structural type systems. Consequently, applying ideas around the actor model to dataspaces and facet-oriented actors poses a serious challenge. Dataspaces provide a form of publish/subscribe communication (Eugster et al., Reference Eugster, Felber, Guerraoui and Kermarrec2003) that has received little attention in the context of behavioral type systems. While encoding dataspaces in a traditional message-passing (or channel-based) setting is possible, the encoding would obscure a program’s communication patterns too much for the targeted behavioral type system to be of use. Application-specific information could potentially be recovered by utilizing more powerful type-level reasoning, such as dependent session types (Toninho et al., Reference Toninho, Caires and Pfenning2011), but presently bringing such machinery to bear in a usable programming language remains unsolved.

Our work specifically draws inspiration from studying the approach to type checking more so than the specifics of the systems. In that sense, our design follows that of Igarashi & Kobayashi (Reference Igarashi and Kobayashi2001) and Chaki et al. (Reference Chaki, Rajamani and Rehof2002), in which the type checker constructs type-level processes as abstractions for term-level behavior. The type-level processes serve as the basis for behavioral analysis. In the case of Igarashi & Kobayashi (Reference Igarashi and Kobayashi2001), the checks are generic. Subtyping and other parts of the type checker may be instantiated to yield checks for races, deadlocks, etc. Chaki et al. (Reference Chaki, Rajamani and Rehof2002) use the SPIN model checker for simulation-based subtyping and analyzing conformance to LTL specifications. In their case, LTL formulae state properties of channels in the system.

Effpi. The Effpi message-passing framework (Scalas et al., Reference Scalas, Yoshida and Benussi2019) reflects core process and communication operations to the type level and uses dependent function types to precisely track which channels are used. By model checking these type-level descriptions, it becomes possible to verify certain properties stated in a temporal logic, including deadlock-freedom and some communication patterns. By contrast, we seek to verify any LTL formula, allowing application-specific correctness properties. The biggest difference to our work is the communication paradigm. While Effpi uses message-passing along channels in a process calculus, our actors share knowledge via a dataspace.

Conversation Types. Conversation types (Caires & Vieira, Reference Caires and Vieira2009) add behavioral checking to the Conversation Calculus (Vieira et al., Reference Vieira, Caires and Seco2008). A conversation type describes a sequence of message exchanges within a particular context, i.e., conversation. Like the global types of Honda et al. (Reference Honda, Yoshida and Carbone2008), a conversation type may be decomposed to type(s) describing the actions of the individual processes participating in the conversation. Crucially, the decomposition is flexible. A given conversation type may be realized as the composition of numerous different combinations of participant types. This flexibility meshes well with the anonymous communication in the conversation calculus, allowing a degree of agnosticism with regard to the number of participants in a conversation and their individual roles when looking from the global perspective. At first glance, this approach may work for dataspace actors, but because every communication is between a single sender and a single receiver, the model remains similar to channel-based models rather than publish/subscribe communication. In addition to structural message safety, their types ensure a degree of deadlock-freedom.

Active Object Languages. There are several notable behavioral type systems and efforts to perform static verification on active object languages. Behavioral type systems for active objects tend to focus on the problem of detecting deadlocks (Henrio et al., Reference Henrio, Laneve and Mastandrea2017). They employ a similar types-as-processes technique, capturing key information, such as dependencies between futures, as effect types. Proof rules (i.e., type checking) can then determine whether the program may deadlock. Our behavioral checks of facet programs instead treat effect types as abstracted, but still executable, processes, with the goal of both (model)checking properties of programs and validating the design of the DSL.

The Rebeca modeling language (Sirjani et al., Reference Sirjani, Movaghar, Shali and de Boer2004) is the closest to our own behavioral checking. With Rebeca, a programmer may use communication and abstraction facilities of active objects to define a modes of their program or system. The Rebeca model checker, Modere (Jaghoori et al., Reference Jaghoori, Movaghar and Sirjani2006), can then verify properties of the model specified as temporal logic formulae. Rebeca has numerous extensions, notably broadcasting (Yousefi et al., Reference Yousefi, Ghassemi and Khosravi2015). The goal of our work is to check properties of programs versus models of programs and to thus validate the design of the facet DSL. It might be possible to target Rebeca as a backend for the implementation, rather than SPIN, and benefit from its message-passing-specific optimizations.

ConGoLog. In bounded contexts, it is possible to decide some temporal properties of ConGoLog programs (De Giacomo et al., Reference De Giacomo, Lespérance, Patrizi and Sardina2016). Thus, it ought to be possible to develop a model checker based on these decision procedures that could express and check temporal properties similar to the ones that we explore for dataspace programs. No such model-checker implementation appears in the literature.

Types for the Join Calculus. The join calculus (Fournet & Gonthier, Reference Fournet and Gonthier2000) shares some similarities with dataspace actors. It has a soup of messages versus the table of assertions in a dataspace. The event handler endpoints of facets resemble join patterns, especially in the objective join calculus (Fournet et al., Reference Fournet, Laneve, Maranget and Rémy2000). Recent work (Crafa & Padovani, Reference Crafa and Padovani2017) has developed behavioral types for the join calculus around the notion of type state (Strom & Yemini, Reference Strom and Yemini1986). They describe the types of messages understood by an object and use connectives such as conjunction, disjunction, and repetition to determine how a reference to an object can and must be used. The resulting design is able to elegantly track the dynamic interface of, e.g., a lock object. Unfortunately, they note the challenge of implementing such connectives, as well as the necessary substructural support.

Mailbox Types. Similarly to the behavioral type systems for the Join Calculus, mailbox types (de’Liguoro & Padovani, Reference de’Liguoro and Padovani2018) use a commutative regular expression of messages to describe the inputs to an actor. Though the description of messages is unordered, sequencing is still expressible using mailbox-passing. Following a familiar technique in behavioral systems, type analysis collects information from the program as the basis for analysis. In this case, it is a dependency graph among mailboxes. The dependency graphs are vital for detecting and preventing programs that may deadlock.

Session Types. Type systems for the $\pi$ -calculus and related process calculi have been widely studied. Session type systems (Honda et al., Reference Honda, Vasconcelos and Kubo1998) in particular have been utilized to describe and verify the communication properties of many kinds of systems. Our methods are closely related to the generic $\pi$ -calculus type system of Igarashi & Kobayashi (Reference Igarashi and Kobayashi2001). They relate processes with abstract process types, including the primary process constructors: channel send and receive, parallel composition, and so on. Their system is parametric over constraints on process types, allowing different instantiations targeted for different properties, such as deadlock prevention.

Multiparty session types (Honda et al., Reference Honda, Yoshida and Carbone2008; Scalas & Yoshida, Reference Scalas and Yoshida2019) come closer to describing the group oriented communications between dataspace actors. Global types provide a perspective for describing the protocol among a group of participants. Though efforts toward adapting session type theories to actor systems have found some success (Mostrous & Vasconcelos, Reference Mostrous and Vasconcelos2011; Crafa Reference Crafa2012; Neykova & Yoshida, Reference Neykova and Yoshida2014), much work remains to be done to handle the full spectrum of actor programming and its relatives, such as the dataspace model.