Beauger, Nicolas

Butler, Michael

Hoang, Son

Salehi Fathabadi, Asieh

Voisin, Laurent

Wilkinson, Toby

Southampton (e-Prints Soton)

Theory Plug-in for Rodin 3.xT.S. Hoang1, L. Voisin2, A. Salehi1, M. Butler1, T. Wilkinson1, andN. Beauger21 ECS, University of Southamtpon, U.K.2 Systerel, FranceAbstract. The Theory plug-in enables modellers to extend the mathe-matical modelling notation for Event-B, with accompanying support forreasoning about the extended language. Previous version of the Theoryplug-in has been implemented based on Rodin 2.x. This presentation out-line the main improvements to the Theory plug-in, to be compatible withRodin 3.x, in terms of both reliability and usability. We will also presentthe changes that were needed in the Rodin core to accommodate theTheory plug-in. Finally, we identify future enhancements and researchdirections for the Theory plug-in.1 IntroductionThe Theory plug-in v3.0 has been implemented based on Rodin 2.x. The Theoryplug-in enables modellers to extend the mathematical modelling notation forEvent-B, with accompanying support for reasoning about the extended language.As a result for this extension, different formulae within an Event-B model canbe built from different formula factories. As an example, when dealing with aproof obligation, in particular, checking if an existing proof is reusable, we haveto deal with two formula factories: (1) the factory associated with the proofobligation (coming from the model), and (2) the factory associated with theexisting proof. In the case where the model is altered, these formula factoriesmight be incompatible, rendering the existing proof unusable. In Rodin 3.0,there are major changes (compared to Rodin 2.8) within the Rodin Core (http://wiki.event-b.org/index.php/Rodin_Platform_3.0_Release_Notes).– Stronger AST Library: The API of the AST library has been strengthenedto mitigate risks of unsoundness when mixing several formula factories. Now,every AST node carries the formula factory with which it was built, and theAST operations that combine several formulas check that formula factoriesare compatible.– Stronger sequent prover: In order to improve the reliability of the proofstatus when working with mathematical extensions, the reasoners can bedeclared as context-dependent. The proofs that use a context dependentreasoner will not be trusted merely based on their dependencies, but insteadthey will be replayed in order to update their status. This applies in particu-lar to Theory Plug-in reasoners, that depend on the mathematical languageand proof rules defined in theories, which change over time.arXiv:1701.08625v1  [cs.SE]  4 Jan 2017The above changes directly effect the Theory plug-in, in particular to avoidbuilding formulae from sub-formulae with different formula factories.2 Mathematical Extensions via the Theory Plug-inThe Theory plug-in [1] enables developers to define new (polymorphic) datatypes and operators upon those data types. These additional modelling conceptsmight be defined axiomatically or directly (including inductive definitions). Wehave made use of the Theory plug-in capability to define domain-specific conceptsand provide proof rules for reasoning about them. We focus on the followingfeatures of the Theory plug-in that are relevant for our report.2.1 Modelling extensionsThe following modelling extensions are offered by the Theory plug-in: Polymor-phic Inductive Datatypes, Axiomatic Datatypes, Operators (using Direct Defini-tion, Inductive Definition or Axiomatic definition)Polymorphic Inductive Datatypes A datatype with type parameters (poly-morphic) is defined using several constructors. Each constructor can have zero ormore destructors. As an example, the common List inductive datatype is definedas in Fig. 1. A List is either an empty list (nil) or a concatenation of an element(head) and a list (tail).Fig. 1: List DatatypeAxiomatic Datatypes A datatype without any definition is axiomaticallydefined. By convention, an axiomatic datatype satisfies the non-emptiness andmaximality properties, i.e., for an axiomatic type S,S 6= ∅ (non-emptiness)∀x·x ∈ S . (maximality)An example of a axiomatic type for Real number (without any additional axioms)is in Fig. 2.Fig. 2: Real DatatypeOperators Operator can be defined directly, inductively or axiomatically. Fig. 3shows the definitions of two operators list isEmpty (defined directly) andlist length (defined inductively). An operator defined without any definitionFig. 3: Some operators for List Datatypewill be defined axiomatically. Operator notation can be either PREFIX (default)or INFIX (for operator with two or more arguments). Further properties can bedeclared for operators include associativity and commutativity. Fig. 4 shows thedeclaration for three operators: sum, zero, and (unary) minus. In particular, sumis declared to be an infix operator which is associative and commutative. Theaxioms are the assumption about these operators that can be used to definedproof-rules.Reasoning extensions To support reasoning about the user-defined datatypesand operators, the Theory plug-in offers 5 different proof tactics:– Manual inferencing– Manual rewriting (including expanding definitions)– Automatic inferencing– Automatic rewriting– Automatic definition expandingThese proof tactics are configured using the proof rules as a part of the user-defined theories. The manual tactics corresponding to application of a singleproof rule or expanding a single definition. For rewriting tactics, they oftenFig. 4: Some operators for Real Datatypework at a particular location of the formula. Automatic applications of proofrules mean to repeatedly apply one or more rules until no progress can be made.There are two type of proof rules supported by the Theory plug-in, namely,rewrite rules and inference rules.Rewrite rules A simple (unconditional) rewrite rule contains information onhow to rewrite a formula (often to a simpler form). A rewrite rule can also beconditional where the results of the rewriting depends on the circumstances.In Fig. 5, Rules isEmpty nil rewrite and isEmpty cons rewrite are uncon-ditional where Rule isEmpty rewrite is conditional.Inference rules An inference rule contains a list of given conditions (possiblyempty) and the inferred clause. In Fig. 5, Rule isEmpty nil inference is anexample of inference rules. An inference rule can be applied backward or forward(by default, it is applicable in both direction).3 Changes to the Rodin Core3.1 Compatibility of Formula FactoriesThe first main part of the work is to ensure that the Theory plug-in verifies theconstruction of the AST formula to guarantee the compatibility of the formulafactories. Since the formula factories are basically constructed from the core(standard) factory with mathematical extensions (datatypes, operators), com-patibility between different formula factories is reduced to equalities betweendatatypes and operators.– (Inductive) Datatype: Two inductive datatypes are the same if they havethe same signature, i.e., name, type parameters, constructors, destructors.Fig. 5: Example of proof rules for List Datatype– Axiomatic Datatype: Two axiomatic datatypes are the same if they havethe same signature, i.e., name.– Operators (axiomatically defined or with direct/inductive defini-tions): Two operators are the same if they have the same signature, i.e.,name, and arguments (including argument types). Note that this compar-ison does NOT take into account the actual definitions/properties of theoperators.With the above definition, the Theory plug-in correctly compares the formulafactory in constructing proofs and checking reusability of existing proofs.3.2 Supporting Infix Predicate OperatorThis particular additional functionality is mainly for improving the usability ofthe Theory plug-in. We have implemented support for introducing Infix predicateoperator. For example, consider the operator smr (smaller than) for a datatypeReal numbers. With prefix operator, for expressing x smaller than y, we writesmr(x, y)which is unnatural. With the support for infix operator, we can write the formulaasx smr ywhich improves the readability of the formal text. This support requires modi-fication of both the Rodin platform core and the Theory plug-in core.3.3 Supporting Type SpecialisationThe Theory plug-in has to instantiate several generic datatypes and operators.Such an instantiation means that both types and variables have to be replacedat the same time. For instance, the classical list operator is defined as List(T ),but can be used as List(1 .. 3).The same issue also needs to be addressed by other plug-ins, such as genericinstantiation plug-ins that allow to make a generic development and later in-stantiate it into another development.Therefore, all the machinery for instantiating at the same time types andvariables has been developed withing the Rodin core in Rodin 3.x under the nameof specialisation (the instantiation name being already used for another purpose).This specialisation mechanism can be applied to any type, type environment orformula and guarantees type safety (if the input is well-typed, then the outputis guaranteed to also be well-typed).4 Changes to the Theory Plug-in4.1 Improvement on Pattern MatchingThe pattern matching facility of the Theory plug-in has been upgraded to usedirectly the support from the Event-B core for specialising (instantiating) formu-lae. This ensures that the information for specialising formulae is type-consistent.The following examples illustrate some consistent specialisations (which are un-supported in the previous version).Patterns FormulaeS −→ P(S)S −→ S × TAnother important improvement on pattern matching is the implementationfor matching associative operators (which is only implemented for some specialcases before). The matching for associative formulae is done based on a simplegreedy algorithm. The following examples illustrate the result of pattern match-ing for an associative operator, namely forward composition ;.Patterns Formulae Resultf ; {x 7→ c} g;h; {y 7→ c} f ← g;hx← yc← ce; f g;h; {y 7→ c} e← gf ← h; {y 7→ c}Note that in the second example, another possible result for pattern matchingwould be [e← g;h, f ← {y 7→ c}]. Our algorithm only returns a single matchingresult that it found first in the case where there more than one possible matching.4.2 Supporting Unicode Typesetting for Real Number OperatorsAnother usability improvement that we have implemented is the support fortypesetting Real number operators in Unicode. Instead of ASCII text, we usethe following Unicode symbols for the common operators that we used in themodelling.4.3 Usability Improvement/Reimplementation Rule-based ProverAs mentioned before, the rule-based prover of the Theory plug-in offers 5 differenttactics:1. Manual inferencing2. Manual rewriting3. Automatic inferencing4. Automatic rewriting5. Automatic definition expandingEach tactic is a wrapper around one or more reasoners. Roughly speaking,each reasoner manages an application of a single inference/rewrite rule. Table 1shows the relationship between the tactics and the corresponding reasoner (forthe pervious, i.e., v3.0, and the current implementation, i.e., v4.0 ). The decisionTactic v3.0 v4.0Manual inferencing Single reasoner Single reasonerManual rewriting Single reasoner Single reasonerAutomatic inferencing Single reasoner Multiple reasonersAutomatic rewriting Single reasoner Multiple reasonersAutomatic definition expanding Single reasoner Multiple reasonersTable 1: Tactics and Reasonersto implement the automatic tactics combining multiple reasoners is for usability.Instead bundling the effect of apply several rules into a single proof node, weseparately apply the rules one-by-one. The result is as follows– The proofs are easy to understand.– The proofs are less prone to changes (e.g., changes in the model).– The proofs are easy to adapt, e.g., one can keep a part of the proofs producedautomatically (by pruning) and proceed further manually.Reasoner Input In the previous version, the context of the proof obligation ispassed as an input to the reasoner. In this version, the context is retrieved fromthe origin of the proof obligation. This ensure that the same context, e.g., theformula factory, is used for the obligation and the proof. Further more, due tothe changes to the automatic reasoners described previously, the reasoner inputsfor these reasoners are adapted accordingly. Table 2 summarises the differencesbetween v3.0 and v4.0 of the tool.Reasoner v3.0 v4.0Manual Inferencing– PO Context– Rule Meta-data– Application hypothe-sis (if forward infer-ence) or null (if back-ward inference)– Rule Meta-data– Application hypothe-sis (if forward infer-ence) or null (if back-ward inference)Manual Rewrite– PO Context– Rule Meta-data– Application hypothe-sis (if rewriting a hy-pothesis) or null (ifrewriting the goal)– Rewrite position– Rule Meta-data– Application hypothe-sis (if rewriting a hy-pothesis) or null (ifrewriting the goal)– Rewrite positionAutomatic Inferencing– PO Context – Rule Meta-data– Forward or backwardAutomatic Rewriting– PO Context – Rule Meta-dataTable 2: Reasoner InputWell-definedness When instantiating a proof rule, each instantiation expres-sion required to be well-defined, to ensure that the resulting sequents are well-defined. In v3.0, the well-definedness sub-goals are generated one for each instan-tiation expression and are mixed with the other sub-goals, and in some cases arenot generated at all. We have consolidate the generation of the WD sub-goals (inv4.0 ) by combing all these sub-goals into a single sub-goal (using conjunction)and add this new WD sub-goal as (always) the first sub-goal when applying aproof rule. As a result, the proof are much less prone to changes.5 Future WorkIn this paper, we have highlighted the major changes to the Theory plug-in andthe Rodin Core, focusing on bringing the Theory plug-in to the latest versionof the Rodin platform. In particular, the update requires some update to thecore of the Rodin Platform itself, hence will be publicly available after the nextrelease (v3.3 ) of the Rodin Platform. At the same time, we also improved theusability of Theory plug-in, especially focusing on features that required changesfrom the Rodin plug-in core.In the next release, we will focus our attention to the usability of the plug-in,by gathering feedbacks from its users. Some of the ideas for improvement are:– Matching facility for associative and commutative operators (currently ig-noring commutativity).– Support for user-defined tactics– Support for predicate variables in theories– Theory instantiation (different abstraction-level of theories).AcknowledgementsLaurent Voisin and Nicolas Beauger have been partially funded by the FrenchResearch Agency under grant ANR-13-INSE-0001 (IMPEX project). Thai SonHoang, Michael Butler and Toby Wilkinson are supported by the ASUR Pro-gramme project 1014 C6 PH1 104.Disclaimer. This document is an overview of MOD sponsored research and isreleased to inform projects that include safety- critical or safety-related soft-ware. The information contained in this document should not be interpreted asrepresenting the views of the MOD, nor should it be assumed that it reflectsany current or future MOD policy. The information cannot supersede any statu-tory or contractual requirements or liabilities and is offered without prejudice orcommitment.References1. Michael J. Butler and Issam Maamria. Practical theory extension in Event-B. InZhiming Liu, Jim Woodcock, and Huibiao Zhu, editors, Theories of Programmingand Formal Methods - Essays Dedicated to Jifeng He on the Occasion of His 70thBirthday, volume 8051 of Lecture Notes in Computer Science, pages 67–81. Springer,2013.

Theory plug-in for Rodin 3.x

Abstract

Similar works

Full text

Available Versions

Southampton (e-Prints Soton)