Difference between pages "Maplet Overriding in Goal" and "The Use of Theories in Code Generation"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Billaude
(Rules implemented in MapOvrGoal have been changed. Modifications have been reported their.)
 
imported>Andy
 
Line 1: Line 1:
This page describes the design of a tactic requested here : [https://sourceforge.net/tracker/index.php?func=detail&aid=3306228&group_id=108850&atid=651672 Feature Request #3306228]
+
= Defining Translations Using The Theory Plug-in =
 +
The theory plug-in is used to add mathematical extensions to Rodin. The theories are created, and deployed, and can then be used in any models in the workspace. When dealing with implementation level models, such as in Tasking Event-B, we need to consider how to translate newly added types and operators into code. We have augmented the theory interface with a Translation Rules section. This enables a user to define translation rules that map Event-B formulas to code.
 +
== Translation Rules==
 +
<div id="fig:Translation Rules">
 +
<br/>
 +
[[Image:TheoryCGRules.png|center||caption text]]
 +
<center>'''Figure 1''': Translation Rules</center>
 +
<br/>
 +
</div>
  
= Objective =
+
Figure 1 shows the interface, and some translations rules of the mapping to Ada.
  
Split every goal in the form : <math>f\ovl{\{x\mapsto y\}}\in A\;op_1\;B </math> into two sub-goals if and only if the sequent contains a hypothesis such as <math>f\in A\;op_2\;B</math> :
+
The theory is given a name, and may import some other theories. Type parameters can be added, and we use them here to type the meta-variables. The meta-variable ''a'' is restricted to be an integer type, but meta-variable ''c'' can be any type. Meta-variables are used in the translator rules for pattern matching.
:*<math>x\in A</math>
 
:*<math>y\in B</math>
 
Where <math>op_1</math> denote either a Relation <math>\left(\rel\right)</math>, or a Total Relation <math>\left(\trel\right)</math>, or a Partial Function <math>\left(\pfun\right)</math>, or a Total Function <math>\left(\tfun\right)</math>, and <math>op_2</math> is such as <math>f\in A\;op_2\;B\limp f\in A\;op_1\;B</math>.
 
  
= Design Decision =
+
Translator rules are templates, which are used in pattern matching. Event-B formulas are defined on the left hand side of the rule, and the code to be output (as text) appears on the right hand side of the matching rule. During translation an abstract syntax tree (AST) representation of the formula is used. The theory plug-in attempts to match the formulas in the rules with each syntactic element of the AST. As it does so it builds the textual output as a string, until the whole AST has been successfully matched. When a complete tree is matched, the target code is returned. If the AST is not matched, a warning is issued, and a string representation of the original formula is returned.
  
Those two subgoals and the predicate are not equivalent to the goal. Indeed, in the case <math>op_1</math> is a Relation, the goal is equivalent to <math>\{x\}\domsub f\in A\setminus\{x\}\rel B\land x\in A\land y\in B</math>. But this has the drawback of writing three times the expression ''x''. If this expression is big, then it can make the proof rule hard to read.
+
== Type Rules for Code Generation ==
  
But, we know that <math>\left(f\in A\;op_1\;B\right)\limp \left(\{x\}\domsub f\in A\setminus\{x\}\;op_1\;B\right)</math> for all the relation given in Objective. By ensuring that <math>f\in A\;op_2\;B</math> is among the hypotheses of the sequent, we ensure that the first predicate of the conjunction is provable. Indeed, if this check was not done, the proof obligation may be unprovable since there are a loss of informations by writing <math>f\in A\;op_2\;B</math> instead of <math>\{x\}\domsub f\in A\setminus\{x\}\;op_1\;B</math>.
+
The type rules section, shown in Figure 1, is where the relationship is defined, between Event-B types and the type system of the implementation.
  
= Table =
+
= Adding New (implementation-level) Types =
 +
When we are working at abstraction levels close to the implementation level, we may make an implementation decision which requires the introduction of a new type to the development. We give an example of our approach, where we add a new array type, shown in Figure 2, and then define its translation to code.
  
{| class="wikitable alternance" style="text-align:center; width:80%;"
+
== An Array Type Definition ==
|+ <math>f\in A\;op_2\;B\limp f\in A\;op_1 B</math>
+
<div id="fig:Extension with an Array Type">
|-
+
<br/>
|<math>op_1\;\backslash\;op_2</math>
+
[[Image:ArrayDef.png|center||caption text]]
! scope=col | <math>\rel</math>
+
<center>'''Figure 2''': Array Definition</center>
! scope=col | <math>\trel</math>
+
<br/>
! scope=col | <math>\srel</math>
+
</div>
! scope=col | <math>\strel</math>
 
! scope=col | <math>\pfun</math>
 
! scope=col | <math>\tfun</math>
 
! scope=col | <math>\pinj</math>
 
! scope=col | <math>\tinj</math>
 
! scope=col | <math>\psur</math>
 
! scope=col | <math>\tsur</math>
 
! scope=col | <math>\tbij</math>
 
|-
 
! scope=row | <math>\rel</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|-
 
! scope=row | <math>\trel</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|<math></math>
 
|<math>\checkmark</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|-
 
! scope=row | <math>\srel</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|-
 
! scope=row | <math>\strel</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|-
 
! scope=row | <math>\pfun</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|-
 
! scope=row | <math>\tfun</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|-
 
! scope=row | <math>\pinj</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|-
 
! scope=row | <math>\tinj</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|-
 
! scope=row | <math>\psur</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|-
 
! scope=row | <math>\tsur</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|<math>\checkmark</math>
 
|-
 
! scope=row | <math>\tbij</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>-</math>
 
|<math>\checkmark</math>
 
|-
 
|}
 
  
 +
The array operator notation is defined in the expression array(s: P(T)); and the semantics is defined in the direct definition. arrayN constrains the arrays to be of fixed length. Array lookup, update, and constructor operators are subsequently defined. In the next step we need to define any translations required to implement the array in code.
  
[[Category:Design proposal]]
+
== Translation Rules ==
 +
 
 +
<div id="Translation Rules for the Array Type">
 +
<br/>
 +
[[Image:ArrayTrans.png|center||caption text]]
 +
<center>'''Figure 3''': Translation Rules for the Array Type</center>
 +
<br/>
 +
</div>
 +
 
 +
Figure 3 shows the Ada translation; beginning with the meta-variable definitions that are used for pattern matching in the translation rules. Each of the operators; ''newArray'', and ''update'', and an expression using the ''lookup'' operator, are mapped to their implementations on the right hand side of the rule. The ''Type Rules'' section describes the implementation's description of the ''arrayN'' type.

Revision as of 15:51, 15 May 2012

Defining Translations Using The Theory Plug-in

The theory plug-in is used to add mathematical extensions to Rodin. The theories are created, and deployed, and can then be used in any models in the workspace. When dealing with implementation level models, such as in Tasking Event-B, we need to consider how to translate newly added types and operators into code. We have augmented the theory interface with a Translation Rules section. This enables a user to define translation rules that map Event-B formulas to code.

Translation Rules


caption text
Figure 1: Translation Rules


Figure 1 shows the interface, and some translations rules of the mapping to Ada.

The theory is given a name, and may import some other theories. Type parameters can be added, and we use them here to type the meta-variables. The meta-variable a is restricted to be an integer type, but meta-variable c can be any type. Meta-variables are used in the translator rules for pattern matching.

Translator rules are templates, which are used in pattern matching. Event-B formulas are defined on the left hand side of the rule, and the code to be output (as text) appears on the right hand side of the matching rule. During translation an abstract syntax tree (AST) representation of the formula is used. The theory plug-in attempts to match the formulas in the rules with each syntactic element of the AST. As it does so it builds the textual output as a string, until the whole AST has been successfully matched. When a complete tree is matched, the target code is returned. If the AST is not matched, a warning is issued, and a string representation of the original formula is returned.

Type Rules for Code Generation

The type rules section, shown in Figure 1, is where the relationship is defined, between Event-B types and the type system of the implementation.

Adding New (implementation-level) Types

When we are working at abstraction levels close to the implementation level, we may make an implementation decision which requires the introduction of a new type to the development. We give an example of our approach, where we add a new array type, shown in Figure 2, and then define its translation to code.

An Array Type Definition


caption text
Figure 2: Array Definition


The array operator notation is defined in the expression array(s: P(T)); and the semantics is defined in the direct definition. arrayN constrains the arrays to be of fixed length. Array lookup, update, and constructor operators are subsequently defined. In the next step we need to define any translations required to implement the array in code.

Translation Rules


caption text
Figure 3: Translation Rules for the Array Type


Figure 3 shows the Ada translation; beginning with the meta-variable definitions that are used for pattern matching in the translation rules. Each of the operators; newArray, and update, and an expression using the lookup operator, are mapped to their implementations on the right hand side of the rule. The Type Rules section describes the implementation's description of the arrayN type.