imported>Nicolas |
imported>Andy |
| Line 1: |
Line 1: |
| − | {{TOCright}}
| + | == 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=== |
| | + | Figure 1 shows the interface, and some translations rules of the mapping to Ada. |
| | | | |
| − | == Purpose == | + | <div id="fig:Translation Rules"> |
| | + | <br/> |
| | + | [[Image:TheoryCGRules.png|center||caption text]] |
| | + | <center>'''Figure 1''': Translation Rules</center> |
| | + | <br/> |
| | + | </div> |
| | | | |
| − | Rodin 2.0 with theory feature provides support for developing theories. But sharing theories can be somewhat difficult if care is not taken for exporting and importing them. This is related to the fact that theories are always in a particular project called "MathExtensions".
| + | The translation rules are templates used for pattern matching. The meta-variables are defined and typed, and used in the rules. 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. |
| − | To understand the problem, let's say we have developed an Event-B project P and a theory T and want to make an archive in order to share them. The workspace looks like this:
| |
| − | | |
| − | + MathExtensions
| |
| − | - T.tuf
| |
| − | - T.dtf
| |
| − | + P
| |
| − | - C0.buc
| |
| − | - m0.bum
| |
| − | ...
| |
| − | | |
| − | If we make a standard archive export of these projects (File > Export > Archive File), we will get a zip file containing the project P and the project MathExtensions.
| |
| − | | |
| − | But then, the person who will import the archive into his workspace with the theory feature installed (File > Import > Existing Projects into Workspace > Select archive file), will already have a project named "MathExtensions" in the workspace. Thus, the import wizard will warn that "Some projects cannot be imported because they already exist in the workspace", and theories of "MathExtensions" in the archive will not be imported. This page is dedicated to proposing workarounds for this problem.
| |
| − | | |
| − | == Solution 1: theories at archive root ==
| |
| − | | |
| − | When exporting, select option "Create only selected directories", then select project P, but not project MathExtensions, only the T.* files in it, as shown below:
| |
| − | | |
| − | [[Image:Export_P_Troot.png]]
| |
| − | | |
| − | Then clean P and MathExtensions (Project > Clean).
| |
| − | | |
| − | Then, import is done in two steps:
| |
| − | # import T: File > Import > Archive File select the archive, untick the P project, only select T.* files at the root, select to import into the MathExtensions as shown on the image below
| |
| − | # import P the standard way: File > Import > Existing Projects into Workspace > Select archive file
| |
| − | | |
| − | [[Image:Import_P_Troot.png]]
| |
| − | | |
| − | Note: in this case we chose to only put the .tuf (theory unchecked file) and .bpr (proof file) into the archive, because other files (.tcf, .bpo, .bps) are generated upon build, and .dtf (deployed theory file) is generated when deploying T. It is also possible to put every T.* files in the archive, or only T.dtf. In any case, it is generally preferable to clean imported projects and the MathExtensions project.
| |
| − | | |
| − | This solution is the most conservative one, as other theories that might exist in the importing workspace are conserved.
| |
| − | | |
| − | == Solution 2: remove MathExtensions at import ==
| |
| − | | |
| − | This second solution is the most simple but can be used only when the importer has not developed any theories.
| |
| − | It consists in exporting P and T the standard way, so that the archive contains P and MathExtensions projects. Then the importer simply deletes his empty MathExtensions project from the workspace before importing the standard way (File > Import > Existing Projects into Workspace > Select archive file).
| |
| − | | |
| − | == Solution 3: temporary project ==
| |
| − | | |
| − | This solution consists in creating a temporary project, for instance TempMathExtensions, then copying theory files to export in it. The exporter then makes a standard project archive with P and TempMathExtensions (and NOT MathExtensions).
| |
| − | | |
| − | The importer can then import this archive the standard way (File > Import > Existing Projects into Workspace > Select archive file), then copy theory files from TempMathExtensions to MathExtensions, and finally delete TempMathExtensions. A clean of P and MathExtensions is then highly recommended.
| |
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
Figure 1 shows the interface, and some translations rules of the mapping to Ada.
Figure 1: Translation Rules
The translation rules are templates used for pattern matching. The meta-variables are defined and typed, and used in the rules. 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.
