Graph-rewriting derivations
Definition 6.15 (Semantics of Graph Programs [ 49 ]) Given a program
GP over a label alphabetC, the semantics of GP is a binary relation→GPon
AC, which is inductively defined as follows:
(1) →GP = ⇒GP if GP = {p1, . . . , pn}is an elementary program (i.e., a rule name set).
(2) →GP1;GP2 = →GP2 ◦ →GP1.
(3) →GP↓ = {hG, Hi | G→∗GP H and 6 ∃H0 : H →GP H0}.
As for their respective semantic domains, RePro and GP do not directly correspond as RePro has an SOS semantics, whereas the semantics of GP is given by a relation on input-output graphs.
We proceed by defining such an input-output (IO) semantic relation for RePro.
Definition 6.16(IO Semantics of RePro). The IO semantics of a control process P is given by the binary relation ⇒IO
P over graphs in |GraphT| defined as follows: G ⇒IO
P H iff there exists a successful trace(ρ1, δ1, N1)
(ρ2, δ2, N2). . .(ρn, δn, Nn)Xfrom(P, G)s.t. G
δ1
=
⇒. . .=⇒δn H.
Note that for technical convenience, the IO semantics of a graph process is defined over concrete graphs in|GraphT|, while in Defini- ton 6.15, we considered abstract graphs (as in [49]). However, the IO
semantics can be easily shown to be invariant w.r.t. isomorphisms: if G⇒IO
Now, we are ready to present the encoding of graph programs as RePro control processes. An encoding [[_]] : GP → P from graph programs to RePro control processes is a function; we provide a function definition which constructively synthesizes a RePro control process term from a given graph program. Afterwards, to verify the soundness of the encoding, we show that it preserves IO semantics (in the GP sense).
The encoding follows the inductive schema of GP and is based on the following ideas:
(1) For an elementary program, the corresponding control process is simply a choice over those rules. As an elementary program terminates after one rule application, each choice branch consists of a rule name followed by a 0.
(2) For encoding sequences like GP1; GP2, we have to ensure that in exactly those states where GP1 terminates successfully, the execution continues with GP2. To that end, in the corresponding encoded RePro control processes, the closing 0’s of the first process are replaced by a unique process identifier mapped to the second one by a defining equation.
(3) As for maximal iteration GP↓over a graph program GP, we again take a unique process identifier to capture iteration by recursion. In addition, we have to define a special control process (put as an alternative choice beside the recursive process) which acts as a stopping criterion for the iteration: this additional process should reach a 0 (i.e., terminate successfully) for exactly those graphs on which the program in the loop body does not succeed.
For providing those stopping processes as needed in the last case above, we follow the same inductive definition schema:
(1) If the loop body is an elementary program, then the stopping process consists of a single action with the empty rule ε as positive component and the set of all rules in the elementary program as non-applicability condition, followed by 0. This 0 is reached exactly if the input graph is such that none of the rules is applicable on it.
(2) If the loop body contains a sequence like GP1; GP2, its failure means that either GP1 fails or GP1 is successful but GP2 fails on the input GP1 provides. This latter case is problematic as demonstrated by the following simple example:
Consider the simple program GP= ({p1}; {p2})↓. An encoding
[[GP↓]]applied to a graph G should have a successful derivation leading to G itself not only in the case p1 cannot be applied to
G (encodable as (e,{p1}).0), but also when there is a “middle graph”, e.g., H, such that G=⇒p1 H and p2is not applicable to H. As indicated by the example, there is a class of (iterated sequential) graph programs for which there is no general schema to define stopping processes, given the above IO semantics of RePro, well- aligned with GP semantics. To overcome this discrepancy between the encoding domain and the IO semantics, we identify a sub- language of so-called backtracking-free programs (Definition6.18),
which are still sufficient to obtain computational completeness of RePro, while avoiding the above issue.
(3) Although iterations cannot be iterated again directly, due to the above case, it is necessary to also provide a definition of a stopping process for maximal iterations. However, this should be an artificial process which cannot be executed successfully on any graph (as a maximal iteration is successful for any graph per definition); for this purpose, it is sufficient to specify a single-action process using any rule p, where p is used both as a positive component (rule to apply) and a non-applicability condition.
As a consequence of the requirements identified above, the formal definition of the encoding makes use of the following definitions: sequentialization of control processes (Definition6.17) and the notion
of backtracking-free programs (Definition6.18) for delineating the domain
of the encoding.
The sequentialization of two control processes P and Q is another process, written as P# Q, essentially consists in correctly “plugging in” the definition of Q at those points of the execution of P where it would terminate, i.e., reach a 0 and fire aX.
Definition 6.17(Sequentialization of Control Processes). Let P, Q∈ P
be two sequential processes (i.e., not containing ||). Their sequentializa- tion is the process P# Q := P[AQ/0]where AQ ∈ K is a fresh identifier with defining equation AQ :=Q and P[X/0]denotes the substitution of X for 0 in P, defined by induction on the structure of P as follows:
• 0[X/0] =X,
• (γ.P)[X/0] =γ.(P[X/0]),
• (P+Q)[X/0] = P[X/0] +Q[X/0], and • A[X/0] = AX,
where AX is a fresh process identifier with defining equation AX := P[X/0]if A :=P.
The notion of backtracking-free programs identifies that subset of graph programs which is handled (i.e., is within the domain) of our
encoding. Intuitively, a program is backtracking-free if the applica- bility of the whole program to a given input graph can be “statically” decided by looking at the rules in the program term and the graph itself, without the need to consider any other concrete graph. Here, applica- bility of a program GP to a graph G means that there exists a graph H s.t. G →GP H. Formally, the backtracking-free property is captured by an inference system as presented in the following definition, where the single rules reflect the following intuitions:
• Every elementary graph program is backtracking-free, as we are able to check the applicability of each rule to G (cf. the axiom rule BFEL).
• A graph program is backtracking-free if it is a maximal iteration, as such a program cannot fail (cf. the axiom rule BFALAP).
• A sequential graph program GP1; GP2is backtracking-free if (1) GP1 is backtracking-free and (2) GP1 and GP2 have a special relation such that GP2 always succeeds after (ASA in short) GP1 has been executed (cf. rule BFSEQ).
Although the ASA relation is defined over intermediate graphs arising after the execution of GP1, there are cases where the ASA rela- tion of two programs might be shown through reasoning solely over program syntax and the constituting rules. As an example from our WSN scenario, consider the following simple programs (cf. Sect.4.1):
GP1 := {pCr};{pCr} GP2 := {pActUS};{pActUS}
Here, GP2will always succeed after GP1: whenever we are success- ful in creating two (short unclassified) links (GP1), we can be sure that afterwards, a program of activating two short unclassified links (GP2) will also be successful, regardless of the concrete topology.
The following definition formalizes the foregoing considerations on backtracking-free programs.
Definition 6.18(Backtracking-Free Programs). A graph program GP is backtracking-free (BF), denoted as BF(GP), if this can be inferred by the following inference system:
BFEL
BF({p1, . . . , pn}) BFALAP BF(GP↓)
BFSEQ
BF(GP1) ASA(GP1, GP2) BF(GP1; GP2)
where the ASA predicate (for Always Succeeds After) is defined as:
ASA(GP1, GP2) iff for all G →GP1 X there is an H such that X→GP2 H.
The set of backtracking-free graph programs is denoted by BF(GP ).
A failure process cGP for a graph program GP is a control process which terminates successfully exactly on those input graphs where GP fails; moreover, the output of cGP is the unmodified input graph. Thus, failure processes can be used to test the applicability of GP on a given graph. Although failure processes cannot be specified constructively in general, this is possible for backtracking-free graph programs as shown in the following definition.
Definition 6.19(Failure Processes). The failure process cGP of a backtracking- free graph program GP ∈ BF(GP ) is a RePro control process, defined inductively as follows:
1. {p1\, . . . , pn} = (ε,{p1, . . . , pn}).0, where ε : (∅ ← ∅ → ∅)(see Definition2.3);
2. dGP↓ = (p,{p}).0, where p is any rule;
3. if BF(GP1)and ASA(GP1, GP2), thenGP\1; GP2=GPd1.
The following proposition ensures that failure processes indeed fulfill their purpose: (1) they do not modify the input graph (i.e., their IO semantics is an identity relation) and (2) they terminate successfully on every graph, and only on those, to which the original graph program is not applicable.
Proposition 6.7. Let GP ∈BF(GP )be a backtracking-free program and let