The Use of Theories in Code Generation - Revision history

Guillaume: Add to Theory Plug-in category

2021-06-14T15:00:27Z

Add to Theory Plug-in category

← Older revision		Revision as of 15:00, 14 June 2021
Line 40:		Line 40:

	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.		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.

			[[Category:Theory Plug-in]]

imported>Andy: /* Adding New (implementation-level) Types */

2012-05-17T10:55:10Z

Adding New (implementation-level) Types

← Older revision		Revision as of 10:55, 17 May 2012
Line 17:		Line 17:
	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.		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 =		= 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.		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.

imported>Andy: /* Translation Rules */

2012-05-17T10:54:38Z

Translation Rules

← Older revision		Revision as of 10:54, 17 May 2012
Line 2:		Line 2:
	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.		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==		== Translation Rules==
	Code generation rules are specified in a theory file, which is created using the Theory plug-in.		Code generation rules are specified in a theory file, which is created using the Theory plug-in. Figure 1 shows a pretty print of some of the translations rules that have been specified for the Ada code generator. In the figure we can see that 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. For instance, the meta-variable ''a'' is restricted to be an integer type, but meta-variable ''c'' can be any unspecified type, ''Q''. Meta-variables are used in the translator rules for pattern matching.

	<div id="fig:Translation Rules">		<div id="fig:Translation Rules">
Line 11:		Line 11:
	</div>		</div>

	~~Figure 1 shows a pretty print of some of the translations~~ rules that have been specified to generate Ada code. In the figure we can see that 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 unspecified type, ''Q''. Meta-variables are ~~used in the translator rules for pattern matching~~.		Translator rules are templates. They are used in a pattern matching algorithm, in the Theory plug-in, invoked by the code generator. 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.

	~~Translator rules~~ are ~~templates,~~ used in a pattern matching algorithm in the code generator. 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 ==		== Type Rules for Code Generation ==

imported>Andy: /* Translation Rules */

2012-05-17T10:51:00Z

Translation Rules

← Older revision		Revision as of 10:51, 17 May 2012
Line 2:		Line 2:
	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.		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==		== Translation Rules==
			Code generation rules are specified in a theory file, which is created using the Theory plug-in.

	<div id="fig:Translation Rules">		<div id="fig:Translation Rules">
	<br/>		<br/>
Line 9:		Line 11:
	</div>		</div>

	Figure 1 shows the ~~interface, and some~~ translations rules ~~of the mapping~~ to Ada.		Figure 1 shows a pretty print of some of the translations rules that have been specified to generate Ada code. In the figure we can see that 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 unspecified type, ''Q''. Meta-variables are used in the translator rules for pattern matching.

	~~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.		Translator rules are templates, used in a pattern matching algorithm in the code generator. 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 ==		== Type Rules for Code Generation ==

imported>Andy: /* Translation Rules */

2012-05-15T15:51:43Z

Translation Rules

← Older revision		Revision as of 15:51, 15 May 2012
Line 13:		Line 13:
	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.		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 ~~expressions and predicates~~ 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) of the ~~source string~~ is ~~constructed~~. The theory plug-in ~~then~~ attempts to match the rules with each syntactic element of the AST. As it does so it builds the ~~code to~~ output, 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 the original ~~string~~ is returned.		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 ==		== Type Rules for Code Generation ==

imported>Andy: /* Translation Rules */

2012-05-15T14:52:01Z

Translation Rules

← Older revision		Revision as of 14:52, 15 May 2012
Line 11:		Line 11:
	Figure 1 shows the interface, and some translations rules of the mapping to Ada.		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.		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 used ~~for~~ pattern matching. Event-B expressions and predicates 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.		Translator rules are templates, which are used in pattern matching. Event-B expressions and predicates 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) of the source string is constructed. The theory plug-in then attempts to match the rules with each syntactic element of the AST. As it does so it builds the code to output, 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 the original string is returned.

	== Type Rules for Code Generation ==		== Type Rules for Code Generation ==

imported>Andy: /* Translation Rules */

2012-05-15T14:35:09Z

Translation Rules

← Older revision		Revision as of 14:35, 15 May 2012
Line 41:		Line 41:
	</div>		</div>

	Figure 3 shows		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.

imported>Andy: /* Adding New (implementation-level) Types */

2012-05-15T14:27:35Z

Adding New (implementation-level) Types

← Older revision		Revision as of 14:27, 15 May 2012
Line 22:		Line 22:
	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.		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 ==
	<div id="fig:Extension with an Array Type">		<div id="fig:Extension with an Array Type">
	<br/>		<br/>
Line 30:		Line 31:

	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.		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 ==

	<div id="Translation Rules for the Array Type">		<div id="Translation Rules for the Array Type">

imported>Andy: /* Adding New (implementation-level) Types */

2012-05-15T14:11:07Z

Adding New (implementation-level) Types

← Older revision		Revision as of 14:11, 15 May 2012
Line 37:		Line 37:
	<br/>		<br/>
	</div>		</div>

			Figure 3 shows

imported>Andy: /* Adding New (implementation-level) Types */

2012-05-15T13:44:27Z

Adding New (implementation-level) Types

← Older revision		Revision as of 13:44, 15 May 2012
Line 33:		Line 33:
	<div id="Translation Rules for the Array Type">		<div id="Translation Rules for the Array Type">
	<br/>		<br/>
	[[Image:~~Arraytrans~~.png\|center\|\|caption text]]		[[Image:ArrayTrans.png\|center\|\|caption text]]
	<center>'''Figure 3''': Translation Rules for the Array Type</center>		<center>'''Figure 3''': Translation Rules for the Array Type</center>
	<br/>		<br/>
	</div>		</div>