Translation approach

Our goal in this chapter is to help the user of our approach to implement the seman-tics of a language using one of the approaches presented in previous paragraphs. To accomplish this goal we need to devise a translation, i.e., an operation that takes an instance of our problem and expresses its semantics.

Abstract Semantics

Model Simple SOS rules Set rewrite system

Compiles to Instance of

Data

Formalism

Figure6.2 – Translation approach

For the translation we take the approach depicted in Fig. 6.2. We start from a formalism. In the formalism one can create models. Each model is an instance of the formalism. The formalism has an abstract semantics. The abstract semantics might be very general and applicable to all models of the formalism. In our approach, we give a concrete semantics to each model. This concrete semantics is given using what we

6.3. General Principle 65 call SimpleSOSrules (cf. Section6.3.2). Thus, as shown in the diagram, a model is translated to SimpleSOSrules, which are in turn an instance of the abstract semantics of the formalism. Finally, theSOSrules are translated to a set rewrite system like the one presented in Chapter5. We call each transformation acompilation.

We introduce our translation through two case studies. In each case study we introduce a formalism. Then we produce a translation, i.e., a compilation function, from the models of this formalism to simple SOS rules. Finally, we translate these SOSrules to anSRsystem.

This translation approach is designed to make it easy to translate a formalism for new users of our approach. In practice,i.e.,in our tool (cf. Chapter8), the translation is done directly from the formalism toSRin an automatic way.

6.3 General Principle

The translation of the semantics of a system follows certain general principles. Given a system and its semantics we follow some standard guidelines to translate its diff er-ent parts. First, the semantics of data types is always given using set rewriting style semantics. We consider data types such as integers, maps, etc. Thus, a data type is an algebra with a well defined set of operations. In particular, these operations are explicit in the terms. For example, given a data type for integers, we have a term

+(1, 2). Second, we draw a distinction between simpleSOSrules and complex ones.

We considerSOSrules complex if their precondition requires to perform a sub transi-tion. For example, the following rule is a complex rule:

e→i e⁰ →i⁰

e+e⁰ →i+i⁰ (6.1)

Indeed, Rule (6.1) requires to perform two subtransitions. A more detailed discussion of complex rules is presented in Section6.3.3. For simple rules we give formal syntax in Section6.3.2.

Usually we want to describe a transition systemhΓ,→i, whereΓis the set of states and→⊆Γ×Γ. In our framework, the set of states is denoted by termst ∈ T_Σ. Thus we haveΓ = T_Σ. Sometimes, we also have finite transitions systems,e.g.,data types.

A finite transition system ishΓ,→,Ti, where Γand→are as before, andT is the set of terminal states. In our case, we have that T is the set of terms that only contain generators.

6.3.1 Data types

The semantics of data types is always given as rewrite rules. Of course, rewrite rules are not enough in our framework. We also need to give how the strategies are applied to the set of terms. Also, applying the rewriting approach requires some considerations in our approach, we take a look at the subtleties in this section.

The rules that work for single terms cannot always be used directly for sets of terms. In fact, the set semantics of our strategies for list of rules implies that we keep

66 Chapter 6. Semantics Using Set Rewriting only the rewritten terms (cf. Example5.3.7). This is very practical to model transition systems but not final transition systems like the rewriting of basic types. Indeed, when we rewrite final transition systems like this one we are interested in rewriting (and keeping) the whole set at each step. This is because we might have a set were some elements are already completely rewritten while others are still being rewritten. Ap-plying the rule in those cases would remove some elements of the resulting set. Thus, we introduce a strategy that can rewrite the whole set without removing elements that were already rewritten (or that are to be rewritten by other rules). The strategy is the following:

RewriteSetWith(S)=Choice(

Choice(

Union(S,Not(S)), S),

Not(S))

TheRewriteSetWithrule applies the union of strategyS andNot(S). This succeeds if theS strategy partially rewrites the set. If the S strategy completely rewrites the set, then theNotstrategy fails and theUnionwith it. If theUnionfails, then the strategy tries to apply either S orNot(S). Since they are complementary, we have that there is always one that succeeds. By wrapping rewrite rules in theRewriteSetWithstrategy we can easily give semantics to terminal transition systems.

The next step in our approach is to make sure that the rewrite rules are applied to all terms and subterms. For this purpose we use the classical innermost strategy. We can define it as follows:

bottomUp(S)= Choice(One(bottomUp(S),0),S)

ThebottomUpstrategy applies strategySto the innermost subterm but only once. To apply a set of rewrite rules in an innermost fashion we can define the innermost as follows:

Innermost(S)=Fixpoint(bottomUp(RewriteSetWith(S)))

Given a set of expressions, one can compute the result of all the expressions by apply-ing theInnermost(S) strategy with the list of rules for the data type passed as parame-ters.

6.3.2 Simple SOS Rules

SimpleSOSrules are rules that consist have the form given by the syntax in Table6.1.

Basically, the preconditions are only Boolean expressions formed by predicates and the actions are functions that modify the state. To translate this kind of rule we propose a generic compile function that takes a simple rule as strategy and returns a strategy.

6.3. General Principle 67 State: s∈States

Actions: ifa:State→State, thena∈Act ifa,a⁰ ∈Act, thena◦a∈Act

Predicates: Predicates= {pred|pred :State→ {true,false}}

ifa∈Act a◦ p∈Pred Conditions: true,false∈Cond

ifpred∈Predicates, thenpred ∈Cond ifc,c⁰ ∈Cond, thenc∧c⁰ ∈Cond Simple rule: ifc∈Condanda∈Action, then

c

s→a(s) ∈SimpleSOS

Table6.1 – Abstract syntax for simpleSOSrules

The compile rule is generic and the user only needs to provide a manual transla-tion for each predicate and actransla-tion. We refer to these functransla-tions asuserPredCompile : Predicates → Strat anduserActCompile : Actions → Strat. For our framework to work the action strategy needs to behave as a function if the predicate is true. Also, the predicate strategy must return the set of terms where the predicate is true, and fail if no term satisfies the predicate. The compile function is presented below:

genComp:Cond∪Act∪SimpleSOS →Strat

: c

s→a(s) 7→Sequence(comp(c),comp(s)) :c∧c⁰ 7→Sequence(comp(c),comp(c⁰)) :a◦a⁰ 7→Sequence(comp(a),comp(a⁰)) :a◦p 7→Sequence(comp(a),comp(p))

:pred 7→userPredCompile(pred)

:a 7→userActCompile(a), ifa:State→State

Our compile function is very simple. Indeed, it only translates the compositions and logical ands to theSequencestrategy. This works for the preconditions because if one condition fails, then the whole Sequence fails. It also works for the actions because when with non failing strategies, the Sequencebehaves as simple function composition.

In our case studies we give examples of the two user defined functions and how to define them.

6.3.3 Complex SOS Rules

We consider complex rules the rules of the form transition = subaction

action

68 Chapter 6. Semantics Using Set Rewriting This rules are very practical to give the semantics of a system because they decompose a transition in several sub transitions. Each sub transition itself can be decomposed and so on. Their expressivity is a consequence of their high levelness.

Intuitively, we would like to apply the same framework that we use for simple SOS rules. However this framework does not work for this setting. Let us consider the following rule defining the evaluation of an assignment:

he, σi → hi, σi hx:=e, σi → hσ[x= i]i

This rule tells us to compute the value of the expression in the context of the σ, and then create a new context where the returned value is assigned to xin the context.

The problem with this rule (for our framework) is that the context of the evaluation of the subactionis implicit. An evaluator evaluating the rule would: start evaluating action, realize it has to evaluate the subaction, put the actionon hold (and its state), evaluate the subaction, go back to the context of the action, and evaluate the action with the result of theaction.

However, in our framework there is no notion of context. Strategies are pure partial functions, hence, they are only aware of their input. Thus, we need to encode the context of each strategy in its input and output. We present how this could work in our approach in Fig. 6.3. The idea is that a complex language expression, whose

Normal Expression

Rewrite Rules Transformation

Strategy

Combination Strategy Expression Normal

Expression

Normal Expression Normal

Expression Normal Expression

Sub expression Complex Language Expression

Complex Strategy Data flow

Derived from

Data Processing

Invisible actions

Engine

Temporary Expression Temporary Expression