B LANGUAGE REFERENCE MANUAL

Transcription

1 B LANGUAGE REFERENCE MANUAL VERSION 1.8.5

2 2 B LANGUAGE REFERENCE MANUAL VERSION Atelier B is a product developed in collaboration with Jean Raymond ABRIAL Document created by ClearSy This Document is the property of ClearSy and all reproduction, even partial in any form whatsoever is strictly forbidden without written authorization All quoted product names are trademarks registered by their respective authors If you find mistakes or inaccuracies, please contact the maintenance service: maintenance.atelierb@clearsy.com Tel. : (+33) Fax : (+33) ClearSy Support Atelier B Europarc Pichaury, Bât. C Aix-en-Provence Cedex 3 FRANCE

3 Contents i CONTENTS 1. INTRODUCTION 1 2. BASIC CONCEPTS Lexical Conventions Syntactic conventions The DEFINITIONS Clause Useful Syntax Rules TYPING Typing foundations B Types Typing abstract data Types and constraints of concrete data Typing of Concrete Constants Typing of Concrete Variables Typing operation input parameters Typing machine parameters Typing local variables and operation output parameters PREDICATES Propositions Quantified Predicates Equality Predicates Belonging Predicates Inclusion Predicates Integer Comparison Predicates EXPRESSIONS Primary Expressions Boolean Expressions Arithmetical Expressions Arithmetical Expressions (continued) Expressions of Couples Building Sets Set List Expressions Set List Expressions (continued) Record expressions Sets of Relations Expressions of Relations Expressions of Relations (continued) 58

4 ii B Language Reference Manual - Version Expressions of Relations (continued) Expressions of Relations (continued) Sets of Functions Expressions of Functions Sets of Sequences Sequence Expressions Sequence Expressions (continued) Tree sets Tree Expressions Tree nodes expressions 77 Definitions Binary Tree expressions SUBSTITUTIONS Block substitution Identical substitution Becomes Equal Substitution Precondition Substitution Assertion Substitution Bounded choice Substitution IF conditional substitution Conditional Bounded choice Substitution Case Conditional Substitution Unbounded choice Substitution Local Definition Substitution Becomes Element of Substitution Becomes such that Substitution Local Variable Substitution Sequencing Substitution Operation Call Substitution While Loop Substitution Simultaneous Substitution COMPONENTS Abstract Machine Header Refinement Implementation The CONSTRAINTS Clause The REFINES Clause The IMPORTS Clause 118

5 Contents iii 7.8 The SEES Clause The INCLUDES Clause The PROMOTES Clause The EXTENDS Clause The USES Clause The SETS Clause The CONCRETE_CONSTANTS Clause The ABSTRACT_CONSTANTS Clause The PROPERTIES Clause The VALUES Clause The CONCRETE_VARIABLES Clause The ABSTRACT_VARIABLES Clause The INVARIANT Clause The ASSERTIONS Clause The INITIALISATION Clause The OPERATIONS Clause The LOCAL_OPERATIONS Clause Specificities of the B0 language Array controls in B TERMS CONDITIONS Instructions Identifier Anti-Collision Rules B ARCHITECTURE Introduction B Module B Project Libraries 184

6 iv B Language Reference Manual - Version RELEASE NOTES B language Manual Reference, release (commercial release delivered with Atelier B, release 3.6) Aim: remark integration for Atelier B, release Precisions concerning the equivalent model of local operations 2. Restriction concerning the empty set 3. Syntax modifications of relation composition and parallel product in conformity with the existing syntaxic analyser 4. Restriction addition for the operation call x, x c op B language Manual Reference, release (commercial release delivered with Atelier B, beta release 3.6) Aim: User remark integration since the last commercial release Constraints on the literal integers: pointer in the lexical part on a syntaxic part 2. Correction to the definition of the mod operator 3. Correction of the exemple concerning the power operator 4. Correction of the typing of the rel(r) expression 5. Correction of the extension sequence definition 6. Correction of the well defineness of the operators: first, last, front, tail, q and w ; modification of the description of the operators q and w 7. Correction of the definition of rev(s) 8. Correction of the definition of j 9. Modification of the instruction description «becomes equal to» 10. Correction of the CASE syntax and modification in the order of productions on the substitutions 11. Correction of the well defineness of const(x,q) and infix(t) 12. Modification of the cat definition 13. Correction of the example using bin 14. The SET clause is forbidden in a definition

7 Contents v 15. Suppression of the restriction on the machine set parameter typing. One need only indicate that they are types and apply the typing verification rules. 16. Update of priorities of B operators given in appendix, in accordance with the priorities defined in the Atelier B 17. Correction of the definition of conc(s) 18. Addition of the type of sizet(t) 19. Addition of grammatical productions on the tree expressions 20. Correction on the binary tree restrictions 21. Correction on the definition of empty s or p 22. Precision in the visibility tables on the non homonymous nature of data associated to a component 23. Correction on the description of the integer division 24. Modification of the restriction on the parallel call of two operations of an included machine: only modification operation call is forbidden 25. Precision on the trees: trees are never empty 26. Addition of % in the expression list introducing the quantified variables 27. Modification of the syntax for the expressions using several parameters. 28. Addition in the simple term of bool and access to an array element or a record element in the arithmetic expressions 29. Modification of the visibility table of local operations in an implementation with regard to its abstraction 30. B operator grouping in the index under the heading # 31. The effect of deferred set type change, during the valuation in implementation, enlarges on the PROPERTIES clause B language Manual Reference, release (Atelier B, internal release 3.6) Aim: local operation integration for Atelier B, release Typing: data typing array, operation input parameter typing and operation output parameter typing 2. Simultaneous substitution: modification of the constraint concerning the parallel modification of distinct variables. Restriction on the parallel calls of imported operations 3. The OPERATIONS clause: new restrictions. Now this clause contains the implementations of local operations 4. The LOCAL_OPERATIONS clause is a new clause which specifies the local operations 5. Identifier anti-collision controls

8 vi B Language Reference Manual - Version Atelier B restriction : new restriction on the output parameters with regard to local operations (FT2229) 7. Glossary: modification of operation definitions and addition of local operations 8. Visibility tables of implementation: addition of a new column for the LOCAL_OPERATIONS clause and addition of a new line for the local operations 9. Introduction of the word LOCAL_OPERATIONS as reserved keyword B language Manual Reference, release (Atelier B, release 3.5) Aim: corrections of errors and inaccuracies detected by the Atelier B team. Release Precision concerning the using of symbol $0 in the while loop (refer to section 5.1, Primary Expressions, and section 6.17, While Loop Substitution) B language Manual Reference, release (commercial release delivered with Atelier B, release 3.5) Aim: correction of the errors detected by the Atelier B team and integration of remarks made by the rereading committee during the meeting number 6 (30/03/98) 1. Corrections concerning the tree integration in the B grammar (index and BNF) 2. Correction concerning the definitions: the body 3. Correction concerning the BNF 4. Corrections of literal string definitions and comments 5. Correction $0 in the loop ASSERT 6. Suppression of the syntax controls of the presence of the clauses PROPERTIES and INVARIANT 7. Visibility modification of valuations 8. Grammar correction 9. Correction of the definition of Modification of syntax rules 11. Addition of the rule (expression_arithmetic) 12. Suppression of unions of concrete arrays

9 Contents vii B language Manual Reference, release 1.8 (commercial release delivered with Atelier B, beta release 3.5) Aim: evolution of the language supported by the Atelier B, release 3.5 : definition files and records. Trees are not supported by Atelier B release 3.5

10

11 Introduction 1 1. INTRODUCTION Preface The B Language Reference Manual describes the B language supported by Atelier B release 3.6. This language is based on the language presented in The B-Book, however some progresses such as trees, recursivity or multiple refinements are not currently supported by B language. History The B method is a formal method enabling the development of secure programs. It was created by Jean-Raymond Abrial, who already during the 1980s, took part in the creation of the Z notation. G. Laffite, F. Mejia and I. McNeal also contributed to its progressive development. In addition, the B method is based on the scientific work undertaken at Oxford university, in the context of the Programming Research Group directed by C.A.R. Hoare. The B-Book by J.R. Abrial is the fundamental work that describes the B method. Aim The aim of this document is to define the B language precisely, in order to produce a B language reference manual. It is mainly intended for users who perform developments using the B method, and also for all those who wish to discover the possibilities provided by the B language. The language described in this document does not make up a standard itself, however it tends to approach, as closely as possible, the future standard. Presenting the B method The development of a project using the B method comprises two activities that are closely linked: writing formal texts and proving these same texts. The writing activity comprises writing the specifications for abstract machines using high level mathematical formalism that is highly expressive. In this way, a B specification comprises data (that may be expressed among other ways using integers, Boolean values, sets, relations, functions or successions), of invariable properties that relate to the data (expressed using logic applied to first order predicates), and finally services that allow the initialization and later changes to the data (the transformations to the data are expressed using substitutions). The proof activity for a B specification comprises performing a number of demonstrations in order to prove the establishment and conservation of invariable data properties in the specification (e.g. it is necessary to prove that a service call retains the invariable properties). The generation of proofs to be shown must be completely systematic. It is based especially on the transformation of predicates using substitutions. The development of an abstract machine continues using an extension to the write activity during the successive refinement steps. Refining a specification comprises reformulating it so as to providing it with more and more concrete solutions, but also to enrich it. The proof activity relating to refinements also comprises performing a number of static checks and demonstrations in order to prove that the refinement is a valid reformulation of the specification. The last level of refinement of an abstract machine is called the implementation. It is subject to some additional constraints: for example it can

12 2 B Language Reference Manual - Version only handle concrete data or substitutions. These constraints make it a programming language that is similar to an imperative language. In this way, it may therefore be run directly on a computer system, using either a dedicated computer or through an intermediate step for automatic translation to Ada, safety Ada or C++. Reading guide Chapter 2 Conventions presents the principles that apply to the analysis of a text written in B language: lexical analysis, syntax analysis and semantic analysis. It specifies the lexical conventions and describes the different kinds of lexical units. Finally, it presents the syntax conventions used in the rest of the document in order to describe B language grammar. Chapter 3 Typing presents the different forms of data that can be represented in B language, then after introducing types into B, it describes how the typing of data is expressed using typing predicates. Finally, it presents the special case of checking the array type. Chapter 4 Predicates presents the predicate language. Chapter 5 Expressions presents the expression language. Chapter 6 Substitutions presents the substitution language. Chapter 7 Components describes the body of the B components, clause by clause, i.e. need it be reminded, the abstract machines, the refinements and the implementations. It also presents the identifier collision avoidance rules that apply to the components. Chapter 8 Architecture presents the general layout of a B project. It describes the modules, their component (the abstract machines, the refinements and the implementations), the links that exist between the components. Finally, it presents the libraries. Appendix A Symbols presents the table of keywords and the table of operators with their priorities. Appendix B Syntax summarizes B language grammar rules. Appendix C Visibility Tables groups the component visibility rules for a component in relation to the components that it is linked to. Appendix D presents the Atelier B V3.6 Restrictions relating to B language. Appendix E is the Glossary. Appendix F is the Index

13 Typing 3 2. BASIC CONCEPTS This chapter presents the general principles of the formal analysis of the B language, along with the lexical and syntactic conventions which have been adopted in the rest of the document. A B project is made up of a certain number of components (see chapter 7 Components). Each component is stored in a separate file. The analysis of a component is split into three successive parts: lexical analysis, syntactic analysis and semantic analysis. Lexical analysis Lexical analysis consists in checking that the component is made up of a stream of valid lexems, and in performing the analysis and the replacement of textual definitions (refer to section 2.3 The Definitions Clause). On that occasion the elements of the terminal vocabulary of B, such as identifiers, are defined. Syntactic analysis Syntactic analysis verifies that the stream of lexems which makes up a component respects the grammatical production rules of B language. These rules are gathered in the appendix B.1. Semantic Analysis Lastly, semantic analysis allows checks that the component has a meaning which is in conformity with the B method. In B, semantic analysis can be divided into two phases, a phase of static verification and a phase of proof. The phase of static verification carries out the automatic controls described below: The expressions type check verifies that the data has been typed correctly and that the expressions used within predicates, other expressions or substitutions, are of compatible types (refer to section 3.1 Typing Foundations). These checks are specified in the " Typing Rules" heading for each predicate, expression or substitution. The scope resolution links each use of an identifier to its definition, i.e. the declaration that defines it. Using the scope rules provided for each predicate, expression or substitution carries out the scope resolution. The visibility check ensures that the use of a global data in a component clause respects a valid access mode (read or write mode access).the access modes allowed are specified in the visibility tables (refer to Appendix C) The identifier collision checks ensure there is no ambiguity when using data (see chapter 7.26 Identifier Anti-Collision Rules). The semantic restrictions described in the "restrictions" headings in the Predicates, Expressions, Substitutions and Components chapters provides the list of static checks that are not taken into account by the checks described above. During the proof phase, certain properties for which there is no decision procedure are demonstrated. These properties are called Proof Obligations. They are generated systematically from the B components that have already been proved statically. For a B component to be declared correct, all of its Proof Obligations must have been proved by a mathematical demonstration.

14 4 B Language Reference Manual - Version In this document, the static semantic checks are described in detail, and the proofs are mentioned but not detailed (refer to the Proof Obligations Manual).

15 Typing Lexical Conventions In B language, there are four sorts of lexical units: keywords and operators identifiers literal integers literal character strings. The lexical analysis of a component consists in breaking down its text into a succession of lexems from the beginning of the text, up to the end, while eliminating the superfluous spacing characters and the comments. The formalism used to describe the lexical units is that of the lexical analyser LEX, which conventions are shown below: Regular Expression String Example x The x character b : the b letter [x] The x character [-] : the minus sign [xy] The x or the y character [bb] : the b letter or the B letter [x-y] Any character in the x..y interval, [a-z] : a lower case letter according to ASCII order [^x] Any character but x [^\ ] : anything but a quote x? x is optional [\-]? 0 : 0 or 0 x* 0 to n occurrences of the x character, [0-9]* : a positive integer, or nothing x+ 1 to n occurrences of the x [0-9]+ : a positive integer character. Any character but a carriage return Here is the description of each type of lexical unit as well as that of the spacing and comment characters. Keywords and Operators Keywords and operators are made up of a non-empty sequence of printable characters. Their list is provided in Appendix A. The mathematical symbols used in B Language have their equivalent in ASCII characters. So as to make the reading of this document easier, only the mathematical symbols will be used. The correspondence between the two notations is given in Appendix A. In order to simplify the syntax of the language, all the operators are given a priority rank as well as an associativity (left or right). Thanks to these two properties, no ambiguity can remain during the syntactic analysis of an expression, or of a predicate made up of several operators. Identifiers Ident : [a-za-z][a-za-z0-9_] * An identifier is a sequence of letters, figures or of underline characters _. The first character must be a letter. Upper and lower case letters are distinguished. An identifier may be of any size. The dot character "." is not permitted for identifiers. In B language, the dot separates the different renaming prefixes of a renamed component (see chapter 8.3, Instanciation and renaming).

16 6 B Language Reference Manual - Version Literal Integers Litéral_integer : [\-]? [0-9] + Literal integers are sequences of figures, which can be preceded by a minus sign "-" so as to designate negative integers. Literal character strings Character_string : [ ][.] * [ ] Literal character strings are sequences of characters contained inside quotation marks. All printable ASCII characters are accepted except for the quotation marks "" "" which are used to identify the literal character strings, and the new line character. Comments Comments are bounded by the start-of-comment lexem /* and the end-of-comment lexem */. The contents of a comment are made of a set of 0 to N printable ASCII characters, with the exception of the two consecutive characters */ those build the end-of-comment lexem. In this way, comments can not be nested. Spacing characters Spacing characters are the space character ' ', the horizontal and vertical tab characters (HT and VT), the new line characters (CR and FF). The spacing characters are used to separate the lexems. When several spacing characters are used in succession, they are considered like a single space. Spacing characters are necessary to separate a keyword from an identifier. They allow the user complete freedom in choosing the page layout of its B source text.

17 Typing Syntactic conventions The formalism retained for representing the B language syntax is a variation of the BNF and EBNF formalisms, of which the conventions are as follows: keywords and operators are represented between quotation marks. the other elements of the terminal vocabulary (identifiers, literal integers and literal character strings) are shown in a normal font (neither in italics nor in bold type). The non-terminal elements of vocabulary are shown in italics. a ::= b represents a grammar production. a is a member of the non-terminal vocabulary, and b is a sequence of concatenated vocabulary items. ( a ) represents the a item a b represents the a item or the b item [ a ] represents the optional a item a* represents n concatenated instances of a, where n > 0 a + represents n concatenated instances of a, where n > 1 a *b represents n concatenated instances of a, separated by b, where n > 0 a +b represents n concatenated instances of a, separated by b, where n > 1 Attention The characters "()[] +* are part of the meta-language of grammar description. They must not be mistaken for operators of B language. The latter are represented between quotation marks, like other keywords and operators of B language. Example Clause_abstract_variables ::= ABSTRACT_VARIABLES Ident_ren +, This grammar production can be used to write the following text: ABSTRACT_VARIABLES Var1, instb1.instc2.var2, instd3.abstr_var

18 8 B Language Reference Manual - Version The DEFINITIONS Clause Syntax The syntactic description of the DEFINITIONS clause uses the BNF notation described in section 2.2 Syntactic conventions, and not the LEX notation given previously. Definitions_clause ::= DEFINITIONS Definition + ; Definition ::= Ident [ ( Ident +, ) ] == Lexem * < Filename > Filename Definition_call ::= Ident [ ( (Lexem+)+, ) ] The terminal Lexem refers to any lexem among the following lexical units: keywords and operators, identifiers, literal integers and literal character strings (refer to section 2.1 Lexical Conventions). The terminal Filename refers to the name of a file, which can include a relative or absolute path, according to the rules of the operating system with which Atelier B is being used. Description The definition clause contains definition files to be included and explicit declarations of textual definitions of a component. The explicit definitions may have parameters. The definition calls located within the text of the component are replaced during the lexical analysis phase, before the syntax analysis. This is the reason why we are presenting the Definitions clause in this chapter. The scope of a definition located in a component is the whole of the component, including the text situated before the declaration of the definition. Restrictions 1. The various definitions of a component must all have different names. 2. A definition must not use the keywords reserved for the header of a component, or clause names. These are the following keywords: MACHINE, REFINEMENT, IMPLEMENTATION, REFINES, DEFINITIONS, IMPORTS, SEES, INCLUDES, USES, EXTENDS, PROMOTES, SETS, ABSTRACT_CONSTANTS, CONCRETE_CONSTANTS, CONSTANTS, VALUES, ABSTRACT_VARIABLES, VARIABLES, CONCRETE_VARIABLES, INVARIANT, ASSERTIONS, INITIALISATION, OPERATIONS. 3. The optional formal parameters of a definition must all have different names. 4. The operator "==" is illegal on the right hand side of a definition, i.e. in the part located after the "==" operator. 5. The definitions may be dependent on other definitions, provided that there is no cyclic references in their dependencies. 6. When a definition call is made, i.e. when an identifier has the name of a definition outside the definition left part, the name of the definition must be followed by as many effective parameters as there are formal parameters. 7. In the case of the inclusion of a definition file between quotation marks, the name used must designate a file from the current directory, containing the B source file. 8. In the case of the inclusion of a definition file between chevrons (the characters "<" and ">"), the name used must designate a file located in one of the included definitions files

19 Typing 9 directory. 9. A definitions file must only contain, without taking the commentaries into account, a DEFINITIONS clause respecting the rules described in this paragraph. 10. A definitions file can include other definition files, but these inclusions must not lead to cycles. USE A definition is either a reference to a definitions file, or an explicit textual definition. The definitions contained in the definition files are included in the list of definitions of a component as if they were explicit definitions. This allows the sharing of definitions between several components. Indeed, these components need only to include the same definition clause. If the name of a definition file is between inverted quotation mark, the file is sought from the local directory, where the component being analysed can be found. If the name of a definition file is between chevrons, the file is looked up in order, from each definition directory. This ordered list of directories is supplied by the user of Atelier B. The name of a definition is an identifier. A definition has parameters if its name is followed by a list of identifiers, which are its formal parameters. The part of a definition located after the "==" operator forms the replacement text for the definition. It is called the definitions body. The body of a definition is finished when one of the following elements is found: the name of a clause (the list of which is given in Restriction 2), the end of a component, that is to say the word END or a ';' character followed by another definition. EXAMPLES... DEFINITIONS Composition (f, g) == f ; g ; AffectSeq (x, v) == x := 2 v + 1 ; CONCRETE_CONSTANTS... The body of the Composition definition is f ; g. The last ; separates this definition from the next one. The body of the AffectSeq definition is x := 2 v + 1. The last ; is part of AffectSeq since the DEFINITIONS clause ends as the reserved keyword CONCRETE_CONSTANT is found.

20 10 B Language Reference Manual - Version MACHINE MA DEFINITIONS "common1.def" ; <common2.def> ; begin == -2 * UNIT ; end == 10 * UNIT SEES... END common1.def DEFINITIONS UNIT == 16 common2.def DEFINITIONS T == TRUE ; F == FALSE The list of definitions of the component MA is made up of the explicit definitions begin and end as well as the definitions of files common1.def and common2.def. The common1.def file is looked up from the local directory, whereas the common2.def is looked up from the definitions files inclusion directories. Definition call A definition call consists of using the definition name, and providing as many effective parameters as the definition has formal parameters. Once the definition call has been expanded, the usual syntactic rules of component apply. VISIBILITY The definitions of a component are local to that component. They are not therefore accessible by the components that are dependent on it. So as to share the definitions, they can be stored in a definition file and be included several times in this file. EXAMPLES... DEFINITIONS INIT_VAL == -1 ; Sum (x1, x2) == ((x1) + (x2)) ; INIT_BLOC == BEGIN Var1 := INIT_VAL ; Var2 := Var1 + 1 END ; CONCRETE_CONSTANTS... Brackets around formal parameters x1 and x2 in the Sum definition ensure that the sum of x1 and x2 will always be performed, even if this definition is called from inside and expression containing operators with a higher priority than +.

21 Typing Useful Syntax Rules The following syntax rules are used in the rest of this document in order to simplify the B language syntax. Syntax List_Ident ::= Ident ( Ident +, ) Ren_ident ::= Ident +, RESTRICTIONS 1. When there is a list of identifiers containing several elements, each identifier must be different. 2. When a renamed identifier is made up of several identifiers, the latter must only be separated by the characters'.', spaces and commentaries are prohibited. DESCRIPTION The non-terminal List_ident represents a list from 1 to n identifiers. If the list contains several identifiers, then it must be placed between brackets. Such a list is used to declare data within predicates or or expressions Σ, Π, U, I or { }. The non-terminal Ren_Ident represents an identifier which may have been renamed. A renamed identifier has a prefix made up of 1 to n identifiers separated by the dot character. Renamed identifiers designate data from renamed machines (see chapter 5.1 Primary Expressions). EXAMPLES (x, y, z) is the list of the three pieces of data: x, y, z. new.var refers to the data var from a renamed machine with the prefix new.

22 12 B Language Reference Manual - Version TYPING 3.1 Typing foundations The typing in B is a static checking mechanism of B language data and expressions. The type check of a B component must be done before its proof. The concept of B type is based on the concept of a set, and the monotony property of inclusion. Let E be an expression, and S and T be sets such that S ( T. If E : S then E : T. The largest set in which E is contained is called the type of E. In B language, typing is present in three forms: built-in B language types, data typing and type checking. B language types The possible types in B language are the basic types and the types built from these using the Cartesian product, the power-set (the set of subsets) and the set of records. This mechanism is described in detail in 3.2. Data typing In B language, any data item used in a predicate or in a substitution and that has not yet been assigned a type must be typed. This typing is performed when the data is used for the first time, by scanning the text of the predicate or the substitution from where it starts. Typing is performed using specific predicates or substitutions called typing predicates and typing substitutions, and using a type inference mechanism. The data type is deduced from the predicate or the substitution and from the type of the other data involved. The following sections present the typing predicates that depend on the type of data and the typing substitutions made. The table below presents for each type of B language data, the clause where it is typed and how it is typed. Type of data Typing clause Typing method scalar machine parameter CONSTRAINTS clause Typing predicate (identifier in lowercase) Set machine parameter (identifier without lowercase) Forms a basic type Deferred or enumerated set SETS clause Forms a basic type Element from an enumerated set SETS clause Implicitly typed by the enumerated set Concrete constant PROPERTIES clause Typing predicate for concrete constants Abstract constant PROPERTIES clause Typing predicate for abstract data Concrete variable INVARIANT clause Typing predicate for concrete variable Abstract variable INVARIANT clause Typing predicate for abstract data Operation input parameter Operation output parameter OPERATIONS clause of abstract machine, in a precondition OPERATIONS clause of abstract machine Typing predicate for operation input parameter Typing substitution

23 Typing 13 Local operation input parameter LOCAL_OPERATIONS clause, in a precondition Typing predicate for operation input parameter Local operation output parameter LOCAL_OPERATIONS clause Typing substitution Predicate variable or, for expression,, U or I, or ANY or LET substitute Local variable (VAR substitute) Any clause that uses a predicate, an expression or a substitute INITIALISATION or OPERATIONS clause Typing the predicate for abstract data Typing a substitution Type checking Finally, when using data that is already typed in expressions, predicates or substitutions, the typing rules for these expressions, predicates or substitutions must be checked. These rules are provided in the description of each predicate, expression or substitution, in chapters 4, 5 and 6.

24 14 B Language Reference Manual - Version B Types Syntax Type ::= Basic_type P ( Type ) Type x Type struct ( (Ident : Type) +, ) ( Type ) Basic_type ::= Z BOOL STRING Ident Description A B type is either a basic type, or a type built on a type constructor. The basic types are: the set of relative integers Z, the set of Boolean BOOL, defined as BOOL = {FALSE, TRUE}, with TRUE d FALSE the set of character strings STRING, the deferred sets and enumerated sets introduced in the SETS clause, as well as machine set formal parameters which are considered as deferred sets. There are three type constructors: the power-set 'P', the Cartesian product '*' and the collection of records labelled 'struct'. Let T, T1, T2, T3, T4 be types: P(T) designates the power-set or the set of subsets of T, i.e. the set the elements of which are sets of elements of T, T1* T2 designates the Cartesian product of the sets T1 and T2, i.e. the set of ordered pairs, the first element of which is of the type T1 and the second is of the type T2. Since the operator '*' is associative to the right, the type T1 * T2 * T3 * T4 designates the type ((T1 * T2 ) * T3) * T4. Let n be an integer greater or equal than 1, T1,..., Tn, be types and Ident 1... Ident n be identifiers distinct two by two. Then the record type struct(ident 1 :T1,..., Ident n :Tn) designates the set formed by an ordered collection of n types called record fields. Each field has a name Ident called label. These record type labels must be distinct two by two. EXAMPLES The type of expression 3 is Z The type of expression { -5, 3, -1, 8 } is P(Z) The type of expression (0..10) * BOOL 3 ABS1 is P(P(Z*BOOL*ABS1)) The type of expression rec(a : 5, b : TRUE) is struct(a : Z, b : BOOL)

25 Typing Typing abstract data Syntax Typing_abstract_data ::= Ident " " Expression +" " Ident " " Expression Ident " " Expression Ident +", " "=" Expression +", " Description The term abstract data applies to an abstract constant, an abstract variable or data introduced by an ANY, LET substitution or by a predicate! or, or,,, { }, expression (refer to section 3.1 Typing foundations ). The typing predicates for abstract data are specific elementary predicates. Each typing predicate is used to set the type of one or more abstract data elements. It is separated from the preceding and successive predicates by a conjunction. The elementary typing predicates are belonging, inclusion and equals. The abstract data to type must be in the left hand part of the belonging, inclusion or equals operator. The right hand part is made up of an expression where all of the components are accessible and previously typed (refer to Typing Order, below). The type of the abstract data in the left part is then determined by applying the typing rules for the used predicate. Typing order The data typing mechanism used within a predicate consists of scanning the entire text of the predicate from start to finish. When a not yet typed data element appears in the left hand side of a typing predicate, the data element is typed and remains so in the rest of the text of the predicate. Examples VarRaf1 INT VarRaf2 NAT VarRaf3 = TRUE VarRaf4 (0.. 5) (0.. 10) VarRaf5 Z VarRaf6 NAT VarRaf7 NAT 1 ( ) VarRaf8 = (0.. 4) {FALSE} As the type of INT is P(Z) and VarRaf1 is typed using the operator, the type of VarRaf1 is Z. As the type of NAT is P(Z) and VarRaf2 is typed using the operator, the type of VarRaf2 is P(Z). As the type of TRUE is BOOL and VarRaf3 is typed using the operator =, the type of VarRaf3 is BOOL. In the same way, the type of VarRaf4 is P(Z Z), the type of VarRaf5 is Z, the type of VarRaf6 is P(Z), the type of VarRaf7 is P(Z), the type of VarRaf8 is P(Z BOOL).

26 16 B Language Reference Manual - Version Types and constraints of concrete data The concrete data of a B module are data which will be part of the program associated to a module (see section 8.2 B Module). Since concrete data must be able to be implemented by a program, a number of constraints have been fixed so as to differentiate concrete data from data which is not concrete. These constraints are necessarily arbitrary, but they have been established by considering what programming languages such as Ada or C++ can easily implement, and by trying to give as much flexibility as possible to B Language users. In this way, integers, booleans or arrays will be able to be implemented (perhaps with certain constraints), but not the data which value is {-1, 5, 8} because it is not directly and simply implementable in classical programming languages. The most important of these constraints is the type of data. For example, a piece of data of type P(Z * P(Z)) which represents a set of couples the first elements of which are integers, and the second elements are sets of integers is not retained as being concrete because it is too far from what a programming language can implement directly. There are other constraints than the type. For example, the only concrete data integers are those which are contained between the smallest implementable integer and the largest implementable integer for a given target machine. Finally, the constraints concerning concrete data depend on the nature of the data. For example, concrete constants can be intervals of integers - but the concrete variables can not. We are first going to describe all the possible categories of concrete data. Then we will present a table giving the authorised categories for each kind of concrete data. DEFERRED OR ENUMERATED SETS TYPE A deferred or enumerated set Set is of type P(Set) CONSTRAINTS There is no constraint for deferred and enumerated sets. INTEGERS TYPE Concrete integers are of the Z type. CONSTRAINTS Concrete integers must belong to the INT interval whose inferior and superior bounds are the predefined constants MININT and MAXINT. The value of these constants can be parameterized; it depends on the target machine, on which the program associated to a B project will have to work. These values must be placed in a way that any integer comprised between MININT and MAXINT can be directly represented without raising a data overflow on the target machine. Booleans Type Booleans are of the BOOL type.

27 Typing 17 Constraints There is no constraint. Elements of abstract or enumerated sets Type The elements belonging to a deferred or enumerated set Set are of the type Set Constraints There is no constraint. Sub-sets of integers or elements of deferred sets. ARRAYS TYPE Concrete sub-sets of integers are of type P(Z). Concrete sub-sets of elements of a deferred set Set are of type P(Set) Constraints Concrete sub-sets of integers must be concrete intervals of integers. Concrete sub-sets of elements of a deferred set must be intervals of concrete integers, when the deferred set is valued by an interval of integers (see section 7.17 The VALUES Clause). TYPE Concrete arrays are of the type P(T1 *... * Tn), where n > 1 and each Ti type is a base type other than the STRING type. Constraints Before defining the notion of a concrete array, we introduce the notion of simple concrete set. A simple concrete set is a deferred or enumerated set, the boolean values set or an interval of concrete integers or a concrete sub-set of a deferred set. A concrete array is a total function, of which the original set is the Cartesian product of n simple concrete sets (where n > 1) and the final set of which is a simple concrete set. The n-1 simple sets which make up the domain of definition of the array are also called the index sets of the array. EXAMPLES Tab1 : (0..4) 3 INT & Tab2 : AbstractSet1 * EnumeratedSet1 * BOOL 7 BOOL & Tab3 : (-1.. 1) * IntervalCst1 5 (0..100) & Tab4 : EnumeratedSet1 9 NAT & Tab5 : (0..8) 3 INT The concrete array Tab1 is a total function of the interval (0..4) in the INT set. The concrete array Tab2 is a total surjection of the Cartesian product of the simple sets AbstractSet1, EnumeratedSet1 and BOOL towards the BOOL set.

28 18 B Language Reference Manual - Version RECORDS TYPE The type of concrete records is defined by induction. A concrete record type is a record type in which field is of one of the following types : Z, BOOL, a deferred set, an enumerated set, a concrete array type or a concrete record type. CONSTRAINTS The constraints on concrete record data are defined by induction. Each field of a concrete record must be a piece of concrete data. More precisely, if one of the fields of a concrete record is itself a record, then each field of the latter must in its turn be a piece of concrete data. EXAMPLE Year : struct( Year_number : INT, Leap_year : BOOL, Number_of_days : (1..12) 3 (28..31), Weather : struct( Average_Temperature : (1..12) 3INT, Average_Rain : (1..12) 3 INT) ) The concrete record Year contains four fields : the Year_number field is a concrete integer, the Leap_year field is a Boolean, the Number_of_days field is a concrete array and the Weather field is a concrete record which has got two concrete array fields, Average_Temperature and Average_Rain. CHARACTER STRINGS TYPE Character strings are of the STRING type. CONSTRAINTS There is no constraint. Quick reference table The following table sums up for each piece of concrete data which are the authorised types of concrete data.

29 Typing 19 Concrete type Deferred or enumerate Integer Boolean Item belonging to a deffered of Interval of integers or sub-set of a Array Record Character string d set enumerated set deferred set Nature Machine set * * formal parameter Enumerated or * deferred set Machine scalar * * * formal parameter Literal enumerated * value Concrete constant * * * * * * Concrete variable * * * * * Operation input * * * * * * parameter (local or non local) Operation output * * * * * parameter (local or non local) Local variable * * * * *

30 20 B Language Reference Manual - Version Typing of Concrete Constants Syntax Concrete_constant_typing ::= Ident+, : Typing_belongs_to_concrete_data + * Ident = Typing_equals_concrete_constant Ident ( Simple_set Ident è Simple_set Typing_belongs_to_concrete_data ::= Simple_set Simple_set + x 3 Simple_set Simple_set + x 5 Simple_set Simple_set + x 7 Simple_set Simple_set + x 9 Simple_set { Simple_term +, } struct ( (Ident : Typing_belongs_to_concrete_data) +, ) Typing_equals_concrete_constant ::= Term Array_expr B0_interval B0_integer_set rec ( ( [ Ident : ] ( Term Array_expr) ) +, ) Simple_set ::= B0_simple_set BOOL B0_interval Ident B0_Simple_set ::= NAT NAT 1 INT Array_expr ::= Ident { (Simple_term + m m Term) +, } Simple_set + * * { Term } B0_interval ::= Arithmetic_expression.. Arithmetic_expression B0_integer_set Description Concrete constants are typed with the help of typing predicates used in the PROPERTIES clauses. The typing predicates of concrete constants follow the same

31 Typing 21 principles as the typing predicates of abstract data (refer to section 3.4 Types and constraints of concrete data.), while having additional constraints: the right hand side of the predicate must type each constant with a concrete constant type (see 3.4, Types and constraints of concrete data). Only the elementary expressions whose syntax is given below are authorised. They are: belonging to a simple set, which is a scalar set. Example: Cst1 : INT & Cst2 : BOOL & Cst3 : 0..5 & Cst4 : IntervalCst1 & Cst5 : AbstractSet1 & Cst6 : EnumeratedSet1 These typing predicates can also be written as follows: Cst1, Cst2, Cst3, Cst4, Cst5, Cst6 : INT * BOOL * (0..5) * IntervalCst1 * AbstractSet1 * EnumeratedSet1 belonging to a set of total functions. The index sets and arrival set of the function must be simple sets. Example: Arr1 : (0..4) 3 INT & Arr2 : AbstractSet1 * EnumeratedSet1 * BOOL 5 BOOL & Arr3 : (-1.. 1) * IntervalCst1 5 (0..100) & Arr4 : EnumeratedSet1 9 NAT belonging to a scalar set defined in extension. Example: Cst7 : { 0, 3, 7, -8 } & Cst8 : { bleu, white, red } equality with an identifier which refers to a scalar data. Example: Cst10 = red & Cst11 = Cst10 equality with an arithmetic or Boolean expression. Example: Cst12 = IntCst1 + 2 * (IntCst2 1) & Cst13 = 0 & Cst14 = FALSE & Cst15 = bool( Cst12 < 10 \/ Cst12 > 20) equality with an array expression Example: Arr5 = (0..4) * { 0 } & Arr6 = (0..2) * { TRUE } inclusion in a simple set. Example: IntervCst16 <: INT &

32 22 B Language Reference Manual - Version IntervCst17 ( AbstractSet1 & IntervCst18 ( & IntervCst19 è IntervCst16 belonging to a record set. Example: RecCst : struct(masc : BOOL, age : 0.255)

33 Typing Typing of Concrete Variables Syntax Concrete_variable_typing ::= Ident +, : Typing_belongs_to_concrete_data + x Ident = Term Typing_belongs_to_concrete_data ::= Simple_set Simple_set + * 3 Simple_set Simple_set + * 5 Simple_set Simple_set + * 7 Simple_set Simple_set + * 9 Simple_set { Simple_term +, } struct ( (Ident : Typing_belongs_to_concrete_data) +, ) Description Concrete variables are typed with the help of typing predicates used in the INVARIANT clause. The typing predicates of concrete variables follow the same principles as the typing predicates of abstract data (refer to section 3.4 Types and constraints of concrete data), while having additional constraints: only the belongs to and is equal to predicates are allowed to type concrete variables. Inclusion is forbidden because a concrete variable cannot be a set. Moreover, the right hand side of the predicate must type the variable with a concrete variable type (see section 3.4 Types and constraints of concrete data). Only the elementary expressions whose syntax is given below are authorised. They are: belonging to a simple set (which is a set of scalars) Example: Var1 : INT & Var2 : BOOL & Var3 : 0..5 & Var4 : IntervalCst1 & Var5 : AbstractSet1 & Var6 : EnumeratedSet1 These typing predicates can also be written as follows : Var1, Var2, Var3, Var4, Var5, Var6 : INT * BOOL * (0..5) * IntervCst1 * AbstractSet1 * EnumeratedSet1 belonging of a set of total functions. The index and arrival sets of the function must be simple sets. Example: Arr1 : (0..4) 3 INT & Arr2 : AbstractSet1 * EnumeratedSet1 * BOOL 5 BOOL & Arr3 : (-1.. 1) * IntervalCst1 5 (0..100) Arr4 : EnumeratedSet1 9 NAT belonging to an extensive set of scalars.

34 24 B Language Reference Manual - Version Example: Var7 : { 0, 3, 7, -8 } & Var8 : { blue, white, red } equality with an identifier which refers to a scalar data. Example: Var10 = red & Var11 = Var10 equality with an arithmetic or Boolean expression. Example: Var12 = IntervalCst1 + 2 * (IntervalCst2 1) & Var13 = 0 & Var14 = FALSE & Var15 = bool(var12 < 10 \/ Var12 > 20) belonging to a set of records. Example: Var16 : struct(value : INT, status : BOOL)

35 Typing Typing operation input parameters Syntax Operation_input_parameter_typing ::= Ident +, : Typing_belongs_to_concrete_data + x Ident = Term Typing_belongs_to_input_parameter ::= Simple_set Simple_set + x 3 Simple_set Simple_set + x 5 Simple_set Simple_set + x 7 Simple_set Simple_set + x 9 Simple_set { Simple_term +, } struct ( (Ident : Typing_belongs_to_concrete_data) +, ) STRING Description Operation input parameters are typed inside typing predicates used in a precondition (see section 7.23 The OPERATIONS Clause). There are two different ways of typing operation input parameters, distinguished by the operation belongs to a module which has an associated source code (developed or base module), or if it belongs to an abstract module (see section 8.2 B Module). In the first case, operation input parameters typing predicates follow the same principles as concrete variables typing predicates, while adding another possibility, which is belonging to the set of character strings, STRING. An operation input parameter can therefore be a string of characters. Example: Var 17 : STRING If the operation belongs to an abstract module, the operation input parameters are abstract data (see section 3.3 Typing abstract data). Indeed, since an abstract module does not have an associated code, its operation can not be called from an implementation. It is therefore not necessary for its input parameters to be concrete.

36 26 B Language Reference Manual - Version Typing machine parameters Syntax Typing_machine_parameter ::= Ident +, : Typing_belongs_to_machine_parameter +, Ident +, = Term +, Typing_belongs_to_machine_parameter ::= Integer_Set BOOL Interval Ident Integer_Set ::= Z N N 1 NAT NAT 1 INT Description The scalar parameters of an abstract machine are typed with typing predicates in the section 7.5 The CONSTRAINTS Clause. The typing predicates of the scalar parameters of a machine follow the same principles as the typing predicates of abstract data.(refer section 3.3 Typing of abstract data), to which they add a certain number of restrictions. The only allowed types to explicitly type the scalar parameters of a machine are Z, BOOL and the set parameters of the abstract machine. The set parameters are exactly the parameters represented by the identifiers without any lower case letter. The formal scalar parameters that have already been typed in a typing predicate can be used to type another formal scalar parameter.