ADVANCE D3.3 Language extension: Difference between revisions
imported>Asiehsalehi |
imported>Asiehsalehi |
||
(8 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
= Overview = | == Overview == | ||
Mathematical extensions have been co-developed by Systerel (for the Core Rodin Platform) and Southampton (for the Theory plug-in). The main purpose of this new feature was to provide the Rodin user with a way to extend the standard Event-B mathematical language by supporting user-defined operators, basic predicates and algebraic types. Along with these additional notations, the user can also define new proof rules (proof extensions). | Mathematical extensions have been co-developed by Systerel (for the Core Rodin Platform) and Southampton (for the Theory plug-in). The main purpose of this new feature was to provide the Rodin user with a way to extend the standard Event-B mathematical language by supporting user-defined operators, basic predicates and algebraic types. Along with these additional notations, the user can also define new proof rules (proof extensions). | ||
Line 5: | Line 5: | ||
The Theory plug-in provides, among other things, a user-friendly mechanism to extend the Event-B mathematical language as well as the prover. A theory is the dedicated component used to hold mathematical extensions (datatypes, operators with direct definitions, operators with recursive definitions and operators with axiomatic definitions), and proof extensions (polymorphic theorems, rewrite and inference rules). Theories are developed in the workspace (akin to models), and are subject to static checking and proof obligation generation. Proof obligations generated from theories ensure any contributed extensions do not compromise the soundness of the existing infrastructure for modelling and proof. In essence, the Theory plug-in provides a systematic platform for defining, validating and using extensions while exploiting the benefits brought by proof obligations. | The Theory plug-in provides, among other things, a user-friendly mechanism to extend the Event-B mathematical language as well as the prover. A theory is the dedicated component used to hold mathematical extensions (datatypes, operators with direct definitions, operators with recursive definitions and operators with axiomatic definitions), and proof extensions (polymorphic theorems, rewrite and inference rules). Theories are developed in the workspace (akin to models), and are subject to static checking and proof obligation generation. Proof obligations generated from theories ensure any contributed extensions do not compromise the soundness of the existing infrastructure for modelling and proof. In essence, the Theory plug-in provides a systematic platform for defining, validating and using extensions while exploiting the benefits brought by proof obligations. | ||
= Motivations / Decisions = | == Motivations / Decisions == | ||
= Available Documentation = | Supporting mathematical and proof extensions has been a longing for the Event-B community for considerable time. Serious considerations have been made to ensure any support ensures: 1) ease of use, and 2) soundness preservation. The Theory plug-in became a natural candidate to provide support for mathematical and proof extensions. The use of proof obligations goes a long way in preserving the soundness of the underlying Event-B formalism. | ||
In the past 12 months, the capability of defining axiomatic definitions has been provided. Axiomatic definitions are defined by supplying the types, a set of operators, and a set of axioms. This feature has allowed us to create a few significant theories (language extensions), including the generalized sum/product and real numbers. Also it aids to model the hybrid systems. These extensions are being evaluated in the WP1 and WP2 case studies. | |||
In the past 5 months, the procedure of accessibility scope definition is enhanced as below: | |||
* A theory can access other global theories directly. | |||
* A theory (wither local/global) will be introduced to a context/machine scope by means of a "theorypath" file. | |||
Also the below additions are added to the plug-in: | |||
* Conflict checking during process of importing a theory or introducing a theory. | |||
* Several bugs are fixed, including the colour coding. | |||
== Available Documentation == | |||
Pre-studies (states of the art, proposals, discussions): | Pre-studies (states of the art, proposals, discussions): | ||
Line 24: | Line 37: | ||
* Theory Plug-in User Manual.<ref>http://wiki.event-b.org/images/Theory_Plugin.pdf</ref> | * Theory Plug-in User Manual.<ref>http://wiki.event-b.org/images/Theory_Plugin.pdf</ref> | ||
= Planning = | == Planning == | ||
The implementation of the Theory plug-in is now reaching a stable state. A lot of enhancement were introduced during June-August 2013, which makes the Theory plug-in ready to be integrated as a part of the core distribution of Rodin v2.8. | |||
Also the following works are planned for the third period: | |||
* Enhancement of the deploy process: providing a read-only view of a deployed theory | |||
* Improvements of the plugin structure in order to be supported by ProB | |||
* Optimization of the HTML editor of a theory | |||
** colour coding to be compatible with the Event-B editor | |||
** enhancing the view of the conditional rewrite rules | |||
* Providing a facility to automatic generation of rewrite/inference rules (from axiom/theorem) | |||
= References = | == References == | ||
<references/> | <references/> | ||
[[Category:ADVANCE D3.3 Deliverable]] | [[Category:ADVANCE D3.3 Deliverable]] |
Latest revision as of 14:52, 7 October 2013
Overview
Mathematical extensions have been co-developed by Systerel (for the Core Rodin Platform) and Southampton (for the Theory plug-in). The main purpose of this new feature was to provide the Rodin user with a way to extend the standard Event-B mathematical language by supporting user-defined operators, basic predicates and algebraic types. Along with these additional notations, the user can also define new proof rules (proof extensions).
The Theory plug-in provides, among other things, a user-friendly mechanism to extend the Event-B mathematical language as well as the prover. A theory is the dedicated component used to hold mathematical extensions (datatypes, operators with direct definitions, operators with recursive definitions and operators with axiomatic definitions), and proof extensions (polymorphic theorems, rewrite and inference rules). Theories are developed in the workspace (akin to models), and are subject to static checking and proof obligation generation. Proof obligations generated from theories ensure any contributed extensions do not compromise the soundness of the existing infrastructure for modelling and proof. In essence, the Theory plug-in provides a systematic platform for defining, validating and using extensions while exploiting the benefits brought by proof obligations.
Motivations / Decisions
Supporting mathematical and proof extensions has been a longing for the Event-B community for considerable time. Serious considerations have been made to ensure any support ensures: 1) ease of use, and 2) soundness preservation. The Theory plug-in became a natural candidate to provide support for mathematical and proof extensions. The use of proof obligations goes a long way in preserving the soundness of the underlying Event-B formalism.
In the past 12 months, the capability of defining axiomatic definitions has been provided. Axiomatic definitions are defined by supplying the types, a set of operators, and a set of axioms. This feature has allowed us to create a few significant theories (language extensions), including the generalized sum/product and real numbers. Also it aids to model the hybrid systems. These extensions are being evaluated in the WP1 and WP2 case studies.
In the past 5 months, the procedure of accessibility scope definition is enhanced as below:
- A theory can access other global theories directly.
- A theory (wither local/global) will be introduced to a context/machine scope by means of a "theorypath" file.
Also the below additions are added to the plug-in:
- Conflict checking during process of importing a theory or introducing a theory.
- Several bugs are fixed, including the colour coding.
Available Documentation
Pre-studies (states of the art, proposals, discussions):
- Proposals for Mathematical Extensions for Event-B.[1]
- Mathematical Extension in Event-B through the Rodin Theory Component.[2]
- Generic Parser's Design Alternatives.[3]
Technical details (specifications):
- Mathematical_Extensions wiki page.[4]
- Constrained Dynamic Lexer wiki page.[5]
- Constrained Dynamic Parser wiki page.[6]
- Theory plug-in wiki page.[7]
User's guides:
- Theory Plug-in User Manual.[8]
Planning
The implementation of the Theory plug-in is now reaching a stable state. A lot of enhancement were introduced during June-August 2013, which makes the Theory plug-in ready to be integrated as a part of the core distribution of Rodin v2.8. Also the following works are planned for the third period:
- Enhancement of the deploy process: providing a read-only view of a deployed theory
- Improvements of the plugin structure in order to be supported by ProB
- Optimization of the HTML editor of a theory
- colour coding to be compatible with the Event-B editor
- enhancing the view of the conditional rewrite rules
- Providing a facility to automatic generation of rewrite/inference rules (from axiom/theorem)
References
- ↑ http://deploy-eprints.ecs.soton.ac.uk/216/
- ↑ http://deploy-eprints.ecs.soton.ac.uk/251/
- ↑ http://wiki.event-b.org/index.php/Constrained_Dynamic_Parser#Design_Alternatives
- ↑ http://wiki.event-b.org/index.php/Mathematical_Extensions
- ↑ http://wiki.event-b.org/index.php/Constrained_Dynamic_Lexer
- ↑ http://wiki.event-b.org/index.php/Constrained_Dynamic_Parser
- ↑ http://wiki.event-b.org/index.php/Theory_Plug-in
- ↑ http://wiki.event-b.org/images/Theory_Plugin.pdf