Difference between pages "D45 General Platform Maintenance" and "Mathematical Extensions"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Ladenberger
(added bmotion studio relevant chapter)
 
imported>Nicolas
 
Line 1: Line 1:
= Overview =
+
Currently the operators and basic predicates of the Event-B mathematical language supported by Rodin are fixed.
The Rodin platform versions concerned by this deliverable are:
+
We propose to extend Rodin to define basic predicates, new operators or new algebraic types.
* 2.1(08.02.2011),
 
* 2.2(01.06.2011),
 
* 2.2.2(01.08.2011),
 
* 2.3(04.10.2011),
 
* 2.4(31.01.2011),
 
* 2.5(30.04.2011).
 
This year, the maintenance carried on fixing identified bugs, although an emphasis was put on correcting usability issues. Indeed, during the annual meeting in Nice, the WP9 members agreed to refocus on the needed tasks to address some specific bugs and issues reported by DEPLOY partners, and wished resolved by the end of DEPLOY. Thus, no new features were implemented but those appearing in the description of work. The tasks to be performed by the WP9 members were then scheduled, prioritized and regularly updated during the WP9 bi-weekly meetings. The updates allowed to capture and integrate rapidly some minor changes to enhance the usability of the platform which were required by the DEPLOY partners. The following paragraphs will give an overview of the the work that has been performed concerning maintenance on the existing platform components (i.e. core platform and plug-ins).
 
  
See the Release Notes<ref name="documentation">http://wiki.event-b.org/index.php/D32_General_Platform_Maintenance#Available_Documentation</ref> and the SourceForge<ref name=documentation>http://wiki.event-b.org/index.php/D45_General_Platform_Maintenance#Available_Documentation</ref> databases (bugs and feature requests) for details about the previous and upcoming releases of the Rodin platform.
+
== Requirements ==
  
* General platform maintenance
+
=== User Requirements ===
The maintenance done to overcome Rodin scalability weaknesses and enhance the proving experience will be detailed in a separate chapter. However, some features initially planned and some other which were later added and prioritized are worth to mention:
+
* Binary operators (prefix form, infix form or suffix form).
:*Possibility to highlight patterns in the ProverUI,
+
* Operators on boolean expressions.
:*A better output providing warnings and errors in case of wrong or missing building configurations,
+
* Unary operators, such as absolute values.
:*The switch to Eclipse 3.7,
+
: Note that the pipe, which is already used for set comprehension, cannot be used to enter absolute values (''in fact, as in the new design the pipe used in set comprehension is only a syntaxic sugar, the same symbol may be used for absolute value. To be confirmed with the prototyped parser. It may however be not allowed in a first time until backtracking is implemented, due to use of lookahead making assumptions on how the pipe symbol is used. -Mathieu ).
:*A Handbook to complete and enhance the existing documentation.
+
* Basic predicates (e.g., the symmetry of relations <math>sym(R) \defi R=R^{-1}</math>).
 +
: Having a way to enter such predicates may be considered as syntactic sugar, because it is already possible to use sets (e.g., <math>R \in sym</math>, where <math>sym \defi \{R \mid R=R ^{-1}\}</math>) or functions (e.g., <math>sym(R) = \True</math>, where <math>sym \defi (\lambda R \qdot R \in A \rel B \mid \bool(R = R^{-1}))</math>).
 +
* Quantified expressions (e.g., <math>\sum x \qdot P \mid y</math>, <math>\prod x \qdot P \mid y</math>, <math>~\min(S)</math>, <math>~\max(S)</math>).
 +
* Types.
 +
** Enumerated types.
 +
** Scalar types.
  
* {{TODO}} An overview of the contribution about Mathematical extensions / Theory Plug-in (Issam Maamria)
+
=== User Input ===
 +
The end-user shall provide the following information:
 +
* keyboard input
 +
* Lexicon and Syntax. <br/>More precisely, it includes the symbols, the form (prefix, infix, postfix), the grammar, associativity (left-associative or right associative), commutativity, priority, the mode (flattened or not), ...
 +
* Pretty-print. <br/>Alternatively, the rendering may be determined from the notation parameters passed to the parser.
 +
* Typing rules.
 +
* Well-definedness.
  
* {{TODO}} An overview of the contribution about Plug-in Incompatibilities (All partners)
+
=== Development Requirements ===
 +
* Scalability.
  
* {{TODO}} An overview of the contribution about Modularisation (Alexei Illiasov)
+
== Towards a generic AST ==
  
* {{TODO}} An overview of the contribution about Decomposition (Renato Silva)
+
The following AST parts are to become generic, or at least parameterised:
 +
* [[Constrained_Dynamic_Lexer | Lexer]]
 +
* [[Constrained Dynamic Parser | Parser]]
 +
* Nodes ( Formula class hierarchy ): parameters needed for:
 +
** Type Solve (type rule needed to synthesize the type)
 +
** Type Check (type rule needed to verify constraints on children types)
 +
** WD (WD predicate)
 +
** PrettyPrint (tag image + notation (prefix, infix, postfix) + needs parentheses)
 +
** Visit Formula (getting children + visitor callback mechanism)
 +
** Rewrite Formula (associative formulæ have a specific flattening treatment)
 +
* Types (Type class hierarchy): parameters needed for:
 +
** Building the type expression (type rule needed)
 +
** PrettyPrint (set operator image)
 +
** getting Base / Source / Target type (type rule needed)
 +
* Verification of preconditions (see for example <tt>AssociativeExpression.checkPreconditions</tt>)
  
* {{TODO}} An overview of the contribution about Team-based Development (Colin Snook, Vitaly Savicks)
+
=== Vocabulary ===
  
* {{TODO}} An overview of the contribution about UML-B (Colin Snook, Vitaly Savicks)
+
An '''extension''' is to be understood as a single additional operator definition.
  
== An overview of the contribution about ProR (Michael Jastram) ==
+
=== Tags ===
  
ProR is a replacement of the original requirements plug-in, which got discontinued in 2010. It is based on the OMG ReqIF standard (<ref name="reqif">http://www.omg.org/spec/ReqIF/</ref>), which provides interoperability with industry tools. It evolved into the Eclipse Foundation project "Requirements Modeling Framework" (RMF, <ref name="rmf">http://eclipse.org/rmf</ref>), resulting in significant visibility.  ProR is independent from Rodin.  Integration is achieved with a separate plug-in that provides support for traceability and model integration.
+
Every extension is associated with an integer tag, just like existing operators. Thus, questions arise about how to allocate new tags and how to deal with existing tags.<br />
 +
The solution proposed here consists in keeping existing tags 'as is'. They are already defined and hard coded in the <tt>Formula</tt> class, so this choice is made with backward compatibility in mind.
  
= Motivations =
+
Now concerning extension tags, we will first introduce a few hypotheses:
The tasks to solve the issues faced by the DEPLOY partners have been listed and have been assigned to groups according to their priority. A high priority means a high need in the outcome of a given task. The group 1 has the highest priority, the group 2 has an intermediate priority, and the group 3 has the lowest priority. The group 4 concerns topics that could not be resourced during the lifetime of DEPLOY.The prover integrity item, although not being directly covered, has been partially addressed thanks to Isabelle and SMT integration. Unfortunately, the originally planned export of full proofs and integrity check was too ambitious to be fully achieved in the scope of DEPLOY.
+
* Tags_Hyp1: tags are never persisted across sessions on a given platform
 +
* Tags_Hyp2: tags are never referenced for sharing purposes across various platforms
 +
In other words, cross-platform/session formula references are always made through their ''String'' representation. These assumptions, which were already made and verified for Rodin before extensions, lead us to restrict further considerations to the scope of a single session on a single platform.
  
{{SimpleHeader}}
+
The following definitions hold at a given instant <math>t</math> and for the whole platform.<br />
|-
+
Let <math>\mathit{EXTENSION}_t</math> be the set of extensions supported by the platform at instant <math>t</math>;<br /> let <math>\mathit{tag}_t</math> denote the affectation of tags to an extension at instant <math>t</math> (<math>\mathit{tag}_t \in \mathit{EXTENSION}_t \pfun \intg</math>);<br /> let <math>\mathit{COMMON}</math> be the set of existing tags defined by the <tt>Formula</tt> class (<math>\mathit{COMMON} \sub \intg</math>).<br /> The following requirements emerge:
! scope=col | Group 1 (highest priority) || Responsible
+
* Tags_Req1: <math>\forall t \qdot \mathit{tag}_t \in \mathit{EXTENSION}_t \tinj \intg</math>
|-
+
* Tags_Req2: <math>\forall e, t_1,t_2 \qdot \mathit{tag}_{t_1}(e)=\mathit{tag}_{t_2}(e)</math> where <math>t_1, t_2</math> are two instants during a given session
|Performance <br /> - Core (large models, etc.) <br /> - GUI (incl. prover UI, edition, etc.) || SYSTEREL
+
* Tags_Req3: <math>\forall t \qdot \ran(\mathit{tag}_t) \cap \mathit{COMMON} = \empty</math>
|-
 
|Prover Performances <br /> - New rewriting rules / inference rules <br /> - Automatic tactics (preferences, timeout, etc.) || SYSTEREL
 
|-
 
|ProB Disprover (incl. counter examples to DLF POs) || Düsseldorf
 
|-
 
|Stability (crash, corruption, etc.)  || SYSTEREL
 
|-
 
|Editors || SYSTEREL/Düsseldorf
 
|-
 
|}
 
{{SimpleHeader}}
 
|-
 
! scope=col | Group 2 || Responsible
 
|-
 
| Prover Performances <br /> - SMT provers integration <br /> - connection with Isabelle  <br /> - Mathematical extensions <br /> - ProB || <br />SYSTEREL <br /> ETH Zürich <br /> Southampton/SYSTEREL <br /> Düsseldorf
 
|-
 
|Scalability <br /> - Decomposition <br /> - Modularisation plug-in <br /> - Team-based development || <br /> Southampton <br /> Newcastle <br /> Southampton
 
|-
 
|Plug-in incompatibilities || Newcastle
 
|-
 
|Model-based testing || Pitesti/Düsseldorf
 
|-
 
|ProR || Düsseldorf
 
|}
 
{{SimpleHeader}}
 
|-
 
! scope=col | Group 3 || Responsible
 
|-
 
|Scalability <br /> - Generic instantiation <br /> - UML-B maintenance <br /> || <br /> Southampton <br /> ETH Zürich/Southampton
 
|-
 
|Code Generation || Southampton
 
|}
 
{{SimpleHeader}}
 
|-
 
! scope=col | Group 4
 
|-
 
|Prover Integrity
 
|-
 
|Integrity of Code Generation
 
|}
 
== Platform maintenance ==
 
The platform maintenance, as it can be deduced from the above tables in section [[#Motivations | Motivations]], mainly concerned stability and performance improvement. These topics will be discussed and detailed in a separate chapter about scalability improvements.<br>
 
However, other improvements of utmost importance were made on the platform. These improvements either came from DEPLOY partners specific needs, or were corresponding to previously identified needs (listed in D32 - Model Construction tools & Analysis III Deliverable).
 
Hence we review below the motivations of some noteworthy implemented features:
 
* A Possibility to highlight patterns in the Prover UI.
 
This feature came from a request of DEPLOY partners<ref name="searchInPUI">https://sourceforge.net/tracker/?func=detail&atid=651672&aid=3092835&group_id=108850</ref>, often facing the need to find particular patterns such as expressions in long predicates (e.g. long goals). Since Rodin 2.2, and its new Proving UI interface, a nice feature was added, allowing to search and highlight a string pattern into the whole Proving UI views and editors. This function as also been enabled on direct selection of text in this UI.
 
* A better output providing warnings and errors in case of wrong or missing building configurations.
 
This issue, often seen as a bug or as a plug-in incompatibility, was raised when a user imports and tries to use a model on a platform with some missing required plug-ins. The user often thought his models corrupted whereas Rodin was not able to build them, and hid this information to the user. This is why, since Rodin 2.3, an output has been provided in such case, taking the form of warnings or errors that any user can understand and review. This is a first answer to Rodin plug-in incompatibilities issues.
 
* The switch to Eclipse 3.7.
 
Due to the major improvements made every year in Eclipse releases and the continuously growing number of contributing projects which are for some of them used as basis for Rodin plug-ins, the Rodin platform follows the evolution and is adapted every year quickly to the latest Eclipse version available. This year, Rodin 2.3 originated the switch from Eclipse 3.6 to Eclipse 3.7.
 
* A Handbook to complete and enhance the existing documentation.
 
At the DEPLOY Plenary Meeting in Zürich in 2010, it has been stated that the current documentation, in its state at that time, would not support a engineer starting using the tools without significant help of an expert <ref name="documentationoverhaul>http://wiki.event-b.org/index.php/User_Documentation_Overhaul</ref>. Significant efforts to improve the documentation were performed and coordinated by Düsseldorf, and took form of a handbook<ref name="RodinHandbook">http://handbook.event-b.org/</ref>. The Rodin handbook has the aim to minimize the access to an expert, by providing the necessary assistance to an engineer in the need to be productive using Event-B and the Rodin toolset. The contents of the handbook, user oriented, were originated by some contents of the Event-B wiki.
 
  
== Mathematical extensions / Theory Plug-in ==
+
The above-mentioned scope-restricting hypothesis can be reformulated into: <math>\mathit{tag}</math> needs not be stable across sessions nor across platforms.
{{TODO}} ''To be completed by Issam Maamria''
 
== Plug-in Incompatibilities ==
 
By its extensibility nature, the Rodin platform is susceptible to incompatibilities. Indeed, there are many ways in which incompatibilities could occur, and it occurred in the lifetime of DEPLOY. A good example, is the dependency management. Suppose that a bundle x_v1.0 is needed by a plug-in A (i.e. a dependency from A has been defined to x in at most the version 1.0) and installed in Rodin. Then the plug-in x_v1.1 is needed by a plug-in B. The both versions 1.0 and 1.1 of x could not be installed and used at the same time and create thus some usage incompatibility.
 
  
== Modularisation ==
+
=== Formula Factory ===
{{TODO}} ''To be completed by Alexei Illiasov''
 
== Decomposition ==
 
{{TODO}} ''To be completed by Renato Silva'' 
 
== Team-based Development ==
 
{{TODO}} ''To be completed by Colin Snook, Vitaly Savicks''
 
== UML-B ==
 
{{TODO}} ''To be completed by Colin Snook, Vitaly Savicks''
 
== ProR ==  
 
  
While the original requirements plug-in for Rodin was useful as a prototype, a number of shortcomings lead to a new development.  In particular, the original plug-in was a traceability tool with externally managed requirements.  With ProR, requirements are authored and edited within Eclipse. The original plug-in supported only a limited number of attributes and flat (unstructured) requirements. ProR supports all data structures that the ReqIF standard<ref name="reqif">http://www.omg.org/spec/ReqIF/</ref> supports. Further, ReqIF-support for industry tools like Rational DOORS, MKS or IRqA is expected in the near future, while the original plug-in required a custom adaptor for each data format.
+
The requirements about tags give rise to a need for centralising the <math>\mathit{tag}</math> relation in order to enforce tag uniqueness.
 +
The Formula Factory appears to be a convenient and logical candidate for playing this role. Each time an extension is used to make a formula, the factory is called and it can check whether its associated tag exists, create it if needed, then return the new extended formula while maintaining tag consistency.
  
ProR is developed independently from Rodin.  Dependencies to Rodin exist only in the Rodin integration plug-in.  This significantly decreases the maintenance effort for the integration plugin, while increasing the visibility of ProR in the Open Source community.  The move of ProR from the University of Düsseldorf to the Eclipse Foundation increases visibility even further.  The Rodin integration plug-in is maintained as an independent project at github.
+
The factory can also provide API for requests about tags and extensions: getting the tag from an extension and conversely.
  
== BMotion Studio ==
+
We also need additional methods to create extended formulæ. A first problem to address is: which type should these methods return ?
{{TODO}} ''To be completed by Lukas Ladenberger''
+
We could define as many extended types as the common AST API does, namely <tt>ExtendedUnaryPredicate</tt>, <tt>ExtendedAssociativeExpression</tt>, and so on, but this would lead to a large number of new types to deal with (in visitors, filters, …), together with a constraint about which types extensions would be forced to fit into. It is thus preferable to have as few extended types as possible, but with as much parameterisation as can be. Considering that the two basic types <tt>Expression</tt> and <tt>Predicate</tt> have to be extensible, we come to add two extended types <tt>ExtendedExpression</tt> and <tt>ExtendedPredicate</tt>.
  
= Choices / Decisions =
+
ExtendedExpression makeExtendedExpression( ? )
== Platform maintenance ==
+
ExtendedPredicate makeExtendedPredicate( ? )
* Revisited task priority
 
This year, the process of giving priority to maintenance tasks was revisited according the the refocus mentioned above. The aim was to address all the major scalability issues before the end of DEPLOY. Thus, the requests coming from DEPLOY partners were given high priorities, and they were also prioritized against the already planned tasks coming from both DEPLOY partners and the Description of Work.
 
* Keep 32-bit versions of the Rodin platform on linux and windows systems
 
It was asked by end users to make both 32-bit and 64-bit versions of the Rodin platform available for Linux and Windows platforms. Only a 64-bit version of Rodin is available on Mac platforms as 32-bit Mac (early 2006) platforms are no longer maintained. The request to offer 64-bit was motivated by the possibility to increase for them the available Java heap size for some memory greedy platforms (these before 2.3). However, the drawbacks of assembling and maintaining more platforms (5 platforms instead of 3) and the corrections brought to the database which improved the memory consumption pushed away the limitations of the platform, made this request not relevant for now.
 
  
== Mathematical extensions / Theory Plug-in ==
+
Second problem to address: which arguments should these methods take ?
{{TODO}} ''To be completed by Issam Maamria''
+
Other factory methods take the tag, a collection of children where applicable, and a source location. In order to discuss what can be passed as argument to make extended formulæ, we have to recall that the <tt>make…</tt> factory methods have various kinds of clients, namely:
== Plug-in Incompatibilities ==
+
* parser
It has been decided in cooperation with all the WP9 partners to find better ways to address the plug-in incompatibility issues. First of all, the various partners refined the concept of "plug-in incompatibility". Hence, various aspects could be identified and some specific answers were given to each of them. The user could then defined more clearly the incompatibility faced. Plug-in incompatibilities can be separated in two categories:
+
* POG
:* Rodin platform/plug-in incompatibilities, due to some wrong match between Rodin included packages and the plug-in dependencies (i.e. needed packages). These incompatibilities, when reported, allowed the plug-in developers to contact SYSTEREL in charge of managing the packages shipped with a given version of Rodin. It could also allow traceability of incompatibilities and information to the user through a specific and actualized table on each Rodin release notes page on the Wiki<ref name="incompTableA">http://wiki.event-b.org/index.php/Rodin_Platform_Releases#Current_plug-ins</ref>.
+
* provers
:* Plug-in/plug-in incompatibilities, due to some wrong match between needed/installed packages, or API/resources incompatible usage. A table was created on each release notes wiki page, and a procedure was defined<ref name="incompTableB">http://wiki.event-b.org/index.php/Rodin_Platform_Releases#Known_plug-in_incompatibilities</ref> so that identified incompatibilities are listed and corrected by the concerned developers.
+
(other factory clients use the parsing or identifier utility methods: SC modules, indexers, …)
It appeared that cases of using a model which references some missing plug-ins were formerly often seen as compatibility issues although they were not.<br>
 
After the incompatibilities have been identified, the developing counterparts being concerned assigned special tasks and coordination to solve issues the soonest as possible. Incompatibilities are often due to little glitches or desynchronisation and such direct coordination of counterpart appeared appropriate because quick and effective.
 
  
== Modularisation ==
+
Thus, the arguments should be convenient for clients, depending on which information they have at hand.
{{TODO}} ''To be completed by Alexei Illiasov''
+
The source location does not obviously seem to require any adaptation and can be taken as argument the same way. Concerning the tag, it depends on whether clients have a tag or an extension at hand. Both are intended to be easily retrieved from the factory. As a preliminary choice, we can go for the tag and adjust this decision when we know more about client convenience.
== Decomposition ==
 
{{TODO}} ''To be completed by Renato Silva'' 
 
== Team-based Development ==
 
{{TODO}} ''To be completed by Colin Snook, Vitaly Savicks''
 
== UML-B ==
 
{{TODO}} ''To be completed by Colin Snook, Vitaly Savicks''
 
== ProR ==
 
  
The following key decisions were made when developing ProR:
+
As for children, the problem is more about their types. We want to be able to handle as many children as needed, and of all possible types. Looking to existing formula children configurations, we can find:
 +
* expressions with predicate children: <math>\mathit{bool}(P)</math>
 +
* expressions with expression children: <math>E_1 + E_2</math>
 +
* predicates with predicate children: <math>P_1 \limp P_2</math>
 +
* predicates with expression children: <math>\mathit{partition}(S, E_1, E_2)</math>
 +
* mixed operators: <math>\{x \qdot P(x) \mid E(x)\}</math>, but it is worth noting that the possibility of introducing bound variables in extended formulæ is not established yet.
 +
Thus, for the sake of generality, children of both types should be supported for both extended predicates and extended expressions.
  
* '''New development, rather than continuing the original plug-in''' - the architecture of ProR differs significantly from that of the original plug-in (see [[D45_General_Platform_Maintenance#ProR]].  In addition, new technologies like EMF promised a cleaner, more powerful framework for an implementation.
+
ExtendedExpression makeExtendedExpression(int tag, Expression[] expressions, Predicate[] predicates, SourceLocation location)
 +
ExtendedPredicate makeExtendedPredicate(int tag, Expression[] expressions, Predicate[] predicates, SourceLocation location)
  
* '''ReqIF as the underlying data model''' - the ReqIF standard <ref name="reqif">http://www.omg.org/spec/ReqIF/</ref> is gaining traction and promises interoperability with industry tools.  In addition, a digital version of the data model was available for free and could serve as the foundation for the model code.
+
=== Defining Extensions ===
  
* '''The Eclipse Modeling Framework''' (EMF) was identified as a technology that would allow a quick and clean foundation for an implementation.  Further, the Rodin EMF-plug-in represents a convenient interface for integrating ProR and ProB.  Last, the digital data model from the OMG could be imported directly into EMF and used for generating the model code.
+
An extension is meant to contain every information and behaviour required by:
 +
* Keyboard
 +
* (Extensible Fonts ?)
 +
* Lexer
 +
* Parser
 +
* AST
 +
* Static Checker
 +
* Proof Obligation Generator
 +
* Provers
  
* '''Keeping ProR independent from Rodin''' - There is significant interest in ReqIF right now, but this interest is unrelated to formal methods.  By providing an implementation that is independent from Rodin, we have a much larger target group of potential users and developers.  By carefully designing extension points, we can still provide a powerful Rodin integration.
+
==== Keyboard requirements ====
  
* '''Eclipse Foundation Project''' - we were actively establishing an open source community around ProR.  By recruiting engaged partners early on, development progressed faster than anticipated.  By becoming an Eclipse Foundation project <ref name="rmf">http://eclipse.org/rmf</ref>, we exceeded our goals in this respect.
+
'''Kbd_req1''': an extension must provide an association combo/translation for every uncommon symbol involved in the notation.
  
== BMotion Studio ==
+
==== Lexer requirements ====
{{TODO}} ''To be completed by Lukas Ladenberger''
 
  
= Available Documentation =
+
'''Lex_req1''': an extension must provide an association lexeme/token for every uncommon symbol involved in the notation.
* Core platform:
 
:The following pages give useful information about the Rodin platform releases:
 
:* Release notes<ref>http://wiki.event-b.org/index.php/Rodin_Platform_Releases</ref>.
 
:* Bugs<ref>https://sourceforge.net/tracker/?group_id=108850&atid=651669</ref>.
 
:* Feature requests<ref>https://sourceforge.net/tracker/?group_id=108850&atid=651672</ref>.
 
*The Rodin handbook is proposed as a PDF version and a HTML version and a dedicated plug-in makes it available as help within Rodin<ref name="RodinHandbook">http://handbook.event-b.org/</ref>.
 
  
*{{TODO}}  Links for Mathematical extensions / Theory Plug-in
+
==== Parser requirements ====
*{{TODO}}  Links for Modularisation
 
*{{TODO}}  Links for Decomposition
 
*{{TODO}}  Links for Team-based Development
 
*{{TODO}}  Links for UML-B
 
* Links for ProR
 
** ProR at the Eclipse Foundation <ref name="rmf">http://eclipse.org/rmf</ref>
 
** ProR Documentation for end users and plugin developers <ref>http://pror.org</ref>
 
  
= Status =
+
According to the [[Constrained_Dynamic_Parser| Parser]] page, the following informations are required by the parser in order to be able to parse a formula containing a given extension.
== Platform maintenance ==
 
By the end of the project, there are :
 
* xx bugs reported and open. All with a priority lower or equal to 5.
 
* xx feature requests expressed and still open.
 
  
== Mathematical extensions / Theory Plug-in ==
+
* symbol compatibility
{{TODO}} ''To be completed by Issam Maamria''
+
* group compatibility
== Plug-in Incompatibilities ==
+
* symbol precedence
As the time of writing this deliverable, no plug-in incompatibilities are left or known to exist between the platform and plug-ins or between plug-ins.
+
* group precedence
 +
* notation (see below)
  
== Modularisation ==
+
==== AST requirements ====
{{TODO}} ''To be completed by Alexei Illiasov''
 
== Decomposition ==
 
{{TODO}} ''To be completed by Renato Silva'' 
 
== Team-based Development ==
 
{{TODO}} ''To be completed by Colin Snook, Vitaly Savicks''
 
== UML-B ==
 
{{TODO}} ''To be completed by Colin Snook, Vitaly Savicks''
 
== ProR ==  
 
  
ProR took on a life on its own as part of the Requirements Modeling Framework<ref name="rmf">http://eclipse.org/rmf</ref>.  It is currently in the incubation stage of an Eclipse project.  There are currently five committers in total, with two from the Rodin project, namely Michael Jastram (Project Lead) and Lukas Ladenberger.
+
===== Extended Formulæ =====
  
The Rodin integration supports:
+
[[Image:AST_Formulae.png]]
  
* Creating traces between model elements and requirements
+
===== Extension API =====
* Highlighting of model elements in the requirements text
 
* Marking of invalidated traces, where either the requirement or model element had changed.
 
  
The Rodin integration is hosted at GitHub.
+
Extensions are required to implement the following APIs in order to be supported in the AST. It is the expression of the missing information for a <tt>ExtendedExpression</tt> (resp. <tt>ExtendedPredicate</tt>) to behave as a <tt>Expression</tt> (resp. <tt>Predicate</tt>). It can also be viewed as the parametrization of the AST.
  
== BMotion Studio ==
+
[[Image:AST_Extensions.png]]
{{TODO}} ''To be completed by Lukas Ladenberger''
 
  
= References =
+
===== Mediator API =====
<references/>
 
  
[[Category:D45 Deliverable]]
+
The mediators provided as arguments to these APIs have the following specification:
 +
 
 +
[[Image:AST_Mediators.png]]
 +
 
 +
===== Example: Binary PLUS =====
 +
 
 +
public class BinaryPlus implements IExpressionExtension {
 +
 +
public Type getType(ITypeMediator mediator, ExtendedExpression expression) {
 +
final Type resultType = mediator.getFormulaFactory().makeIntegerType();
 +
for (Expression child : expression.getChildExpressions()) {
 +
final Type childType = child.getType();
 +
if (!childType.equals(resultType)) {
 +
return null;
 +
}
 +
}
 +
return resultType;
 +
}
 +
 +
public Type typeCheck(ITypeCheckMediator mediator,
 +
ExtendedExpression expression) {
 +
final Type resultType = mediator.getFormulaFactory().makeIntegerType();
 +
for (Expression child : expression.getChildExpressions()) {
 +
mediator.sameType(child.getType(), resultType);
 +
}
 +
return resultType;
 +
}
 +
 +
public void checkPreconditions(Expression[] expressions,
 +
Predicate[] predicates) {
 +
Assert.isTrue(expressions.length >= 2);
 +
Assert.isTrue(predicates.length == 0);
 +
}
 +
 +
public String getSyntaxSymbol() {
 +
return "+";
 +
}
 +
 +
public Predicate getWDPredicate(IWDMediator mediator,
 +
IExtendedFormula formula) {
 +
return mediator.makeChildWDConjunction(formula);
 +
}
 +
 +
public void toString(IToStringMediator mediator, IExtendedFormula formula) {
 +
final Expression[] childExpressions = formula.getChildExpressions();
 +
mediator.append(childExpressions[0], false);
 +
mediator.append(getSyntaxSymbol());
 +
mediator.append(childExpressions[1], true);
 +
}
 +
 +
public boolean isFlattenable() {
 +
return false;
 +
}
 +
 +
}
 +
 
 +
==== Static Checker requirements ====
 +
 
 +
The static checker is involved in:
 +
* static checking an extension definition (pre deployment)
 +
: {{TODO}}
 +
* static checking a model that uses extensions (post deployment);
 +
: to that purpose, (deployed) extensions need to be placed in the build dependency graph before models that use them
 +
: it must check that these (deployed) extensions are present in the project
 +
: it needs to get the appropriate FormulaFactory for parsing
 +
: it must be aware of extensions being added/deleted/replaced to reprocess dependent models
 +
 
 +
==== Proof Obligation Generator requirements ====
 +
{{TODO}}
 +
==== Provers requirements ====
 +
{{TODO}}
 +
 
 +
=== Extension compatibility issues ===
 +
{{TODO}}
 +
 
 +
== User Input Summarization ==
 +
 
 +
Identified required data entail the following user input:
 +
 
 +
* '''id''':
 +
:a String id
 +
 
 +
* '''type''':
 +
:either EXPRESSION or PREDICATE
 +
 
 +
* '''keyboard''':
 +
:a list of associations 'symbol <-> ASCII shortcut' for uncommon symbols
 +
 
 +
* '''notation''':
 +
:a choice between
 +
:* fixed-size:
 +
::* prefix: <math>\operatorname{op}(a,b,c)</math>
 +
::* infix: <math>a ~ \lozenge ~ b ~ \lozenge ~ c</math>
 +
:: the number of children (3 here) is given
 +
:: for each child, the type (''Expression'' or ''Predicate'') is given
 +
:: only one operator symbol is provided
 +
:or
 +
:*variable-size notation:
 +
::* prefix: <math>\operatorname{op}(x_1,\ldots,x_n)</math>
 +
::* infix: <math>x_1 ~ \lozenge ~ \ldots ~ \lozenge ~ x_n</math>
 +
:: the minimum number of children is given (for infix operators, the minimum must be 2 or more)
 +
:: all children bear the same type, one of ''Expression'' or ''Predicate''
 +
:: only one operator symbol is provided
 +
 
 +
* '''parsing''':
 +
:compatibility:
 +
:* a compatibility group id (an existing one or a new one)
 +
:* a list of compatibility group ids compatible with this group
 +
:* a list of other extension ids in this compatibility group compatible with this extension
 +
 
 +
:precedence:
 +
:* a precedence group id (an existing one or a new one)
 +
:* a list of precedence group ids with higher priority than this group
 +
:* a list of precedence group ids with lower priority than this group
 +
:* a list of other extension ids in this precedence group with higher priority than this extension
 +
:* a list of other extension ids in this precedence group with lower priority than this extension
 +
 
 +
:As these informations have a global scope, we may think about more convenient ways to input/review them, avoiding a manual scanning of all individual extensions.
 +
 
 +
* '''type rule''':
 +
:* a type predicate
 +
:* (for EXPRESSION) a type expression
 +
 +
* '''well-definedness''':
 +
:a choice between:
 +
:* the pre-defined WD condition: 'children WD conjunction'
 +
:or
 +
:* a custom well-definedness predicate
 +
 
 +
== Impact on other tools ==
 +
 
 +
Impacted plug-ins (use a factory to build formulæ):
 +
* <tt>org.eventb.core</tt>
 +
: In particular, the static checker and proof obligation generator are impacted.
 +
* <tt>org.eventb.core.seqprover</tt>
 +
* <tt>org.eventb.pp</tt>
 +
* <tt>org.eventb.pptrans</tt>
 +
* <tt>org.eventb.ui</tt>
 +
 
 +
== Identified Problems ==
 +
The parser shall enforce verifications to detect the following situations:
 +
* Two mathematical extensions are not compatible (the extensions define symbols with the same name but with a different semantics).
 +
* A mathematical extension is added to a model and there is a conflict between a symbol and an identifier.
 +
* An identifier which conflicts with a symbol of a visible mathematical extension is added to a model.
 +
 
 +
Beyond that, the following situations are problematic:
 +
* A formula has been written with a given parser configuration and is read with another parser configuration.
 +
: As a consequence, it appears as necessary to remember the parser configuration.
 +
: The static checker will then have a way to invalid the sources of conflicts (e.g., priority of operators, etc).
 +
:: ''The static checker will then have a way to invalid the formula upon detecting a conflict (name clash, associativity change, semantic change...) [[User:Mathieu|mathieu]]
 +
 
 +
* A proof may free a quantified expression which is in conflict with a mathematical extension.
 +
: SOLUTION #1: Renaming the conflicting identifiers in proofs?
 +
 
 +
== Open Questions ==
 +
 
 +
=== New types ===
 +
Which option should we prefer for new types?
 +
* OPTION #1: Transparent mode.
 +
:In transparent mode, it is always referred to the base type. As a consequence, the type conversion is implicitly supported (weak typing).
 +
:For example, it is possible to define the <tt>DISTANCE</tt> and <tt>SPEED</tt> types, which are both derived from the <math>\intg</math> base type, and to multiply a value of the former type with a value of the latter type.
 +
 
 +
* OPTION #2: Opaque mode.
 +
:In opaque mode, it is never referred to the base type. As a consequence, values of one type cannot be converted to another type (strong typing).
 +
:Thus, the above multiplication is not allowed.
 +
:This approach has at least two advantages:
 +
:* Stronger type checking.
 +
:* Better prover performances.
 +
:It also has some disadvantages:
 +
:* need of ''extractors'' to convert back to base types.
 +
:* need of extra circuitry to allow things like <math>x:=d*2</math> where <math>x, d</math> are of type <tt>DISTANCE</tt>
 +
 
 +
* OPTION #3: Mixed mode.
 +
:In mixed mode, the transparent mode is applied to scalar types and the opaque mode is applied to other types.
 +
 
 +
=== Scope of the mathematical extensions ===
 +
* OPTION #1: Project scope.
 +
:The mathematical extensions are implicitly visible to all components of the project that has imported them.
 +
* OPTION #2: Component scope.
 +
:The mathematical extensions are only visible to the components that have explicitly imported them. However, note that this visibility is propagated through the hierarchy of contexts and machines (<tt>EXTENDS</tt>, <tt>SEES</tt> and <tt>REFINES</tt> clauses).
 +
:An issue has been identified. Suppose that <tt>ext1</tt> extension is visible to component <tt>C1</tt> and <tt>ext2</tt> is visible to component <tt>C2</tt>, and there is no compatibility issue between <tt>ext1</tt> and <tt>ext2</tt>. It is not excluded that an identifier declared in <tt>C1</tt> conflict with a symbol in <tt>ext2</tt>. As a consequence, a global verification is required when adding a new mathematical extension.
 +
 
 +
== Bibliography ==
 +
* J.R. Abrial, M.Butler, M.Schmalz, S.Hallerstede, L.Voisin, [http://deploy-eprints.ecs.soton.ac.uk/80 ''Proposals for Mathematical Extensions for Event-B''], 2009.
 +
:This proposal consists in considering three kinds of extension:
 +
# Extensions of set-theoretic expressions or predicates: example extensions of this kind consist in adding the transitive closure of relations or various ordered relations.
 +
# Extensions of the library of theorems for predicates and operators.
 +
# Extensions of the Set Theory itself through the definition of algebraic types such as  lists or ordered trees using new set constructors.
 +
 
 +
[[Category:Design proposal]]

Revision as of 13:27, 2 April 2010

Currently the operators and basic predicates of the Event-B mathematical language supported by Rodin are fixed. We propose to extend Rodin to define basic predicates, new operators or new algebraic types.

Requirements

User Requirements

  • Binary operators (prefix form, infix form or suffix form).
  • Operators on boolean expressions.
  • Unary operators, such as absolute values.
Note that the pipe, which is already used for set comprehension, cannot be used to enter absolute values (in fact, as in the new design the pipe used in set comprehension is only a syntaxic sugar, the same symbol may be used for absolute value. To be confirmed with the prototyped parser. It may however be not allowed in a first time until backtracking is implemented, due to use of lookahead making assumptions on how the pipe symbol is used. -Mathieu ).
  • Basic predicates (e.g., the symmetry of relations sym(R) \defi R=R^{-1}).
Having a way to enter such predicates may be considered as syntactic sugar, because it is already possible to use sets (e.g., R \in sym, where sym \defi \{R \mid R=R ^{-1}\}) or functions (e.g., sym(R) = \True, where sym \defi (\lambda R \qdot R \in A \rel B \mid \bool(R = R^{-1}))).
  • Quantified expressions (e.g., \sum x \qdot P \mid y, \prod x \qdot P \mid y, ~\min(S), ~\max(S)).
  • Types.
    • Enumerated types.
    • Scalar types.

User Input

The end-user shall provide the following information:

  • keyboard input
  • Lexicon and Syntax.
    More precisely, it includes the symbols, the form (prefix, infix, postfix), the grammar, associativity (left-associative or right associative), commutativity, priority, the mode (flattened or not), ...
  • Pretty-print.
    Alternatively, the rendering may be determined from the notation parameters passed to the parser.
  • Typing rules.
  • Well-definedness.

Development Requirements

  • Scalability.

Towards a generic AST

The following AST parts are to become generic, or at least parameterised:

  • Lexer
  • Parser
  • Nodes ( Formula class hierarchy ): parameters needed for:
    • Type Solve (type rule needed to synthesize the type)
    • Type Check (type rule needed to verify constraints on children types)
    • WD (WD predicate)
    • PrettyPrint (tag image + notation (prefix, infix, postfix) + needs parentheses)
    • Visit Formula (getting children + visitor callback mechanism)
    • Rewrite Formula (associative formulæ have a specific flattening treatment)
  • Types (Type class hierarchy): parameters needed for:
    • Building the type expression (type rule needed)
    • PrettyPrint (set operator image)
    • getting Base / Source / Target type (type rule needed)
  • Verification of preconditions (see for example AssociativeExpression.checkPreconditions)

Vocabulary

An extension is to be understood as a single additional operator definition.

Tags

Every extension is associated with an integer tag, just like existing operators. Thus, questions arise about how to allocate new tags and how to deal with existing tags.
The solution proposed here consists in keeping existing tags 'as is'. They are already defined and hard coded in the Formula class, so this choice is made with backward compatibility in mind.

Now concerning extension tags, we will first introduce a few hypotheses:

  • Tags_Hyp1: tags are never persisted across sessions on a given platform
  • Tags_Hyp2: tags are never referenced for sharing purposes across various platforms

In other words, cross-platform/session formula references are always made through their String representation. These assumptions, which were already made and verified for Rodin before extensions, lead us to restrict further considerations to the scope of a single session on a single platform.

The following definitions hold at a given instant t and for the whole platform.
Let \mathit{EXTENSION}_t be the set of extensions supported by the platform at instant t;
let \mathit{tag}_t denote the affectation of tags to an extension at instant t (\mathit{tag}_t \in \mathit{EXTENSION}_t \pfun \intg);
let \mathit{COMMON} be the set of existing tags defined by the Formula class (\mathit{COMMON} \sub \intg).
The following requirements emerge:

  • Tags_Req1: \forall t \qdot \mathit{tag}_t \in \mathit{EXTENSION}_t \tinj \intg
  • Tags_Req2: \forall e, t_1,t_2 \qdot \mathit{tag}_{t_1}(e)=\mathit{tag}_{t_2}(e) where t_1, t_2 are two instants during a given session
  • Tags_Req3: \forall t \qdot \ran(\mathit{tag}_t) \cap \mathit{COMMON} = \empty

The above-mentioned scope-restricting hypothesis can be reformulated into: \mathit{tag} needs not be stable across sessions nor across platforms.

Formula Factory

The requirements about tags give rise to a need for centralising the \mathit{tag} relation in order to enforce tag uniqueness. The Formula Factory appears to be a convenient and logical candidate for playing this role. Each time an extension is used to make a formula, the factory is called and it can check whether its associated tag exists, create it if needed, then return the new extended formula while maintaining tag consistency.

The factory can also provide API for requests about tags and extensions: getting the tag from an extension and conversely.

We also need additional methods to create extended formulæ. A first problem to address is: which type should these methods return ? We could define as many extended types as the common AST API does, namely ExtendedUnaryPredicate, ExtendedAssociativeExpression, and so on, but this would lead to a large number of new types to deal with (in visitors, filters, …), together with a constraint about which types extensions would be forced to fit into. It is thus preferable to have as few extended types as possible, but with as much parameterisation as can be. Considering that the two basic types Expression and Predicate have to be extensible, we come to add two extended types ExtendedExpression and ExtendedPredicate.

ExtendedExpression makeExtendedExpression( ? )
ExtendedPredicate makeExtendedPredicate( ? )

Second problem to address: which arguments should these methods take ? Other factory methods take the tag, a collection of children where applicable, and a source location. In order to discuss what can be passed as argument to make extended formulæ, we have to recall that the make… factory methods have various kinds of clients, namely:

  • parser
  • POG
  • provers

(other factory clients use the parsing or identifier utility methods: SC modules, indexers, …)

Thus, the arguments should be convenient for clients, depending on which information they have at hand. The source location does not obviously seem to require any adaptation and can be taken as argument the same way. Concerning the tag, it depends on whether clients have a tag or an extension at hand. Both are intended to be easily retrieved from the factory. As a preliminary choice, we can go for the tag and adjust this decision when we know more about client convenience.

As for children, the problem is more about their types. We want to be able to handle as many children as needed, and of all possible types. Looking to existing formula children configurations, we can find:

  • expressions with predicate children: \mathit{bool}(P)
  • expressions with expression children: E_1 + E_2
  • predicates with predicate children: P_1 \limp P_2
  • predicates with expression children: \mathit{partition}(S, E_1, E_2)
  • mixed operators: \{x \qdot P(x) \mid E(x)\}, but it is worth noting that the possibility of introducing bound variables in extended formulæ is not established yet.

Thus, for the sake of generality, children of both types should be supported for both extended predicates and extended expressions.

ExtendedExpression makeExtendedExpression(int tag, Expression[] expressions, Predicate[] predicates, SourceLocation location)
ExtendedPredicate makeExtendedPredicate(int tag, Expression[] expressions, Predicate[] predicates, SourceLocation location)

Defining Extensions

An extension is meant to contain every information and behaviour required by:

  • Keyboard
  • (Extensible Fonts ?)
  • Lexer
  • Parser
  • AST
  • Static Checker
  • Proof Obligation Generator
  • Provers

Keyboard requirements

Kbd_req1: an extension must provide an association combo/translation for every uncommon symbol involved in the notation.

Lexer requirements

Lex_req1: an extension must provide an association lexeme/token for every uncommon symbol involved in the notation.

Parser requirements

According to the Parser page, the following informations are required by the parser in order to be able to parse a formula containing a given extension.

  • symbol compatibility
  • group compatibility
  • symbol precedence
  • group precedence
  • notation (see below)

AST requirements

Extended Formulæ

AST Formulae.png

Extension API

Extensions are required to implement the following APIs in order to be supported in the AST. It is the expression of the missing information for a ExtendedExpression (resp. ExtendedPredicate) to behave as a Expression (resp. Predicate). It can also be viewed as the parametrization of the AST.

AST Extensions.png

Mediator API

The mediators provided as arguments to these APIs have the following specification:

AST Mediators.png

Example: Binary PLUS
public class BinaryPlus implements IExpressionExtension {

	public Type getType(ITypeMediator mediator, ExtendedExpression expression) {
		final Type resultType = mediator.getFormulaFactory().makeIntegerType();
		for (Expression child : expression.getChildExpressions()) {
			final Type childType = child.getType();
			if (!childType.equals(resultType)) {
				return null;
			}
		}
		return resultType;
	}

	public Type typeCheck(ITypeCheckMediator mediator,
			ExtendedExpression expression) {
		final Type resultType = mediator.getFormulaFactory().makeIntegerType();
		for (Expression child : expression.getChildExpressions()) {
			mediator.sameType(child.getType(), resultType);
		}
		return resultType;
	}

	public void checkPreconditions(Expression[] expressions,
			Predicate[] predicates) {
		Assert.isTrue(expressions.length >= 2);
		Assert.isTrue(predicates.length == 0);
	}

	public String getSyntaxSymbol() {
		return "+";
	}

	public Predicate getWDPredicate(IWDMediator mediator,
			IExtendedFormula formula) {
		return mediator.makeChildWDConjunction(formula);
	}

	public void toString(IToStringMediator mediator, IExtendedFormula formula) {
		final Expression[] childExpressions = formula.getChildExpressions();
		mediator.append(childExpressions[0], false);
		mediator.append(getSyntaxSymbol());
		mediator.append(childExpressions[1], true);
	}

	public boolean isFlattenable() {
		return false;
	}

}

Static Checker requirements

The static checker is involved in:

  • static checking an extension definition (pre deployment)
TODO
  • static checking a model that uses extensions (post deployment);
to that purpose, (deployed) extensions need to be placed in the build dependency graph before models that use them
it must check that these (deployed) extensions are present in the project
it needs to get the appropriate FormulaFactory for parsing
it must be aware of extensions being added/deleted/replaced to reprocess dependent models

Proof Obligation Generator requirements

TODO

Provers requirements

TODO

Extension compatibility issues

TODO

User Input Summarization

Identified required data entail the following user input:

  • id:
a String id
  • type:
either EXPRESSION or PREDICATE
  • keyboard:
a list of associations 'symbol <-> ASCII shortcut' for uncommon symbols
  • notation:
a choice between
  • fixed-size:
  • prefix: \operatorname{op}(a,b,c)
  • infix: a ~ \lozenge ~ b ~ \lozenge ~ c
the number of children (3 here) is given
for each child, the type (Expression or Predicate) is given
only one operator symbol is provided
or
  • variable-size notation:
  • prefix: \operatorname{op}(x_1,\ldots,x_n)
  • infix: x_1 ~ \lozenge ~ \ldots ~ \lozenge ~ x_n
the minimum number of children is given (for infix operators, the minimum must be 2 or more)
all children bear the same type, one of Expression or Predicate
only one operator symbol is provided
  • parsing:
compatibility:
  • a compatibility group id (an existing one or a new one)
  • a list of compatibility group ids compatible with this group
  • a list of other extension ids in this compatibility group compatible with this extension
precedence:
  • a precedence group id (an existing one or a new one)
  • a list of precedence group ids with higher priority than this group
  • a list of precedence group ids with lower priority than this group
  • a list of other extension ids in this precedence group with higher priority than this extension
  • a list of other extension ids in this precedence group with lower priority than this extension
As these informations have a global scope, we may think about more convenient ways to input/review them, avoiding a manual scanning of all individual extensions.
  • type rule:
  • a type predicate
  • (for EXPRESSION) a type expression
  • well-definedness:
a choice between:
  • the pre-defined WD condition: 'children WD conjunction'
or
  • a custom well-definedness predicate

Impact on other tools

Impacted plug-ins (use a factory to build formulæ):

  • org.eventb.core
In particular, the static checker and proof obligation generator are impacted.
  • org.eventb.core.seqprover
  • org.eventb.pp
  • org.eventb.pptrans
  • org.eventb.ui

Identified Problems

The parser shall enforce verifications to detect the following situations:

  • Two mathematical extensions are not compatible (the extensions define symbols with the same name but with a different semantics).
  • A mathematical extension is added to a model and there is a conflict between a symbol and an identifier.
  • An identifier which conflicts with a symbol of a visible mathematical extension is added to a model.

Beyond that, the following situations are problematic:

  • A formula has been written with a given parser configuration and is read with another parser configuration.
As a consequence, it appears as necessary to remember the parser configuration.
The static checker will then have a way to invalid the sources of conflicts (e.g., priority of operators, etc).
The static checker will then have a way to invalid the formula upon detecting a conflict (name clash, associativity change, semantic change...) mathieu
  • A proof may free a quantified expression which is in conflict with a mathematical extension.
SOLUTION #1: Renaming the conflicting identifiers in proofs?

Open Questions

New types

Which option should we prefer for new types?

  • OPTION #1: Transparent mode.
In transparent mode, it is always referred to the base type. As a consequence, the type conversion is implicitly supported (weak typing).
For example, it is possible to define the DISTANCE and SPEED types, which are both derived from the \intg base type, and to multiply a value of the former type with a value of the latter type.
  • OPTION #2: Opaque mode.
In opaque mode, it is never referred to the base type. As a consequence, values of one type cannot be converted to another type (strong typing).
Thus, the above multiplication is not allowed.
This approach has at least two advantages:
  • Stronger type checking.
  • Better prover performances.
It also has some disadvantages:
  • need of extractors to convert back to base types.
  • need of extra circuitry to allow things like x:=d*2 where x, d are of type DISTANCE
  • OPTION #3: Mixed mode.
In mixed mode, the transparent mode is applied to scalar types and the opaque mode is applied to other types.

Scope of the mathematical extensions

  • OPTION #1: Project scope.
The mathematical extensions are implicitly visible to all components of the project that has imported them.
  • OPTION #2: Component scope.
The mathematical extensions are only visible to the components that have explicitly imported them. However, note that this visibility is propagated through the hierarchy of contexts and machines (EXTENDS, SEES and REFINES clauses).
An issue has been identified. Suppose that ext1 extension is visible to component C1 and ext2 is visible to component C2, and there is no compatibility issue between ext1 and ext2. It is not excluded that an identifier declared in C1 conflict with a symbol in ext2. As a consequence, a global verification is required when adding a new mathematical extension.

Bibliography

This proposal consists in considering three kinds of extension:
  1. Extensions of set-theoretic expressions or predicates: example extensions of this kind consist in adding the transitive closure of relations or various ordered relations.
  2. Extensions of the library of theorems for predicates and operators.
  3. Extensions of the Set Theory itself through the definition of algebraic types such as lists or ordered trees using new set constructors.