Formal Speci�cation|Z Notation|Syntax, Type and SemanticsConsensus Working Draft 2.6August 24, 2000Developed by members of the Z Standards PanelBSI Panel IST/5/-/19/2 (Z Notation)ISO Panel JTC1/SC22/WG19 (Rapporteur Group for Z)Project number JTC1.22.45Project editor: Ian Toynian@cs.york.ac.ukhttp://www.cs.york.ac.uk/~ian/zstan/

This is a Working Draft by the Z Standards Panel. It has evolved from Consensus Working Draft 2.5 of June 20,2000 according to remarks received and discussed at Meeting 56 of the Z Panel.

ISO/IEC 13568:2000(E)Contents PageForeword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Terms and de�nitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Symbols and de�nitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Z characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Lexis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Concrete syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 Characterisation rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3810 Annotated syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4011 Prelude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4312 Syntactic transformation rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4413 Type inference rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5414 Semantic transformation rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6615 Semantic relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Annex A (normative) Mark-ups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Annex B (normative) Mathematical toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Annex C (normative) Organisation by concrete syntax production . . . . . . . . . . . . . . . . . . . . . . 107Annex D (informative) Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Annex E (informative) Conventions for state-based descriptions . . . . . . . . . . . . . . . . . . . . . . . . 166Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169ii c ISO/IEC 2000|All rights reserved

ISO/IEC 13568:2000(E)Figures1 Phases of the de�nition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15B.1 Parent relation between sections of the mathematical toolkit . . . . . . . . . . . . . . . . . . . . . . . 90D.1 Parse tree of birthday book example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155D.2 Annotated parse tree of part of axiomatic example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158D.3 Annotated parse tree of part of generic example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161D.4 Annotated parse tree of chained relation example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Tables1 Syntactic metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Parentheses in metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Propositional connectives in metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Quanti�ers in metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Abbreviations in quanti�cations in metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Conditional expression in metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Propositions about sets in metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Basic set operations in metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Powerset in metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710 Operations on numbers in metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711 Decorations of names in metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712 Tuples and Cartesian products in metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713 Function comprehensions in metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814 Relations in metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815 Proposition about relations in metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816 Functions in metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817 Function use in metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918 Sequences in metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919 Disjointness in metalanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920 Metavariables for phrases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021 Metavariables for operator words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1122 Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1123 Metavariables for environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1224 Type sequents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1225 Semantic universe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1326 Variables over semantic universe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1327 Semantic relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1428 Semantic idioms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1429 Operator precedences and associativities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

c ISO/IEC 2000|All rights reserved iii

ISO/IEC 13568:2000(E)ForewordISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commis-sion) form the specialized system for worldwide standardization. National bodies that are members of ISO orIEC participate in the development of International Standards through technical committees established by therespective organization to deal with particular �elds of technical activity. ISO and IEC technical committeescollaborate in �elds of mutual interest. Other international organizations, governmental and non-governmental,in liaison with ISO and IEC, also take part in the work.International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.In the �eld of Information Technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC1. Draft International Standards adopted by the joint technical committee are circulated to national bodies forvoting. Publication as an International Standard requires approval by at least 75% of the national bodies castinga vote.Attention is drawn to the possibility that some of the elements of this International Standard may be the subjectof patent rights. ISO and IEC shall not be held responsible for identifying any or all of such patent rights.International Standard ISO/IEC 13568 was prepared by Joint Technical Committee ISO/IEC JTC 1, InformationTechnology, Subcommittee SC 22, Programming languages, their environments and system software interfaces.Annexes A to C form a normative part of this International Standard. Annexes D and E are for information only.

iv c ISO/IEC 2000|All rights reserved

ISO/IEC 13568:2000(E)IntroductionThis International Standard speci�es the syntax, type and semantics of the Z notation, as used in formal speci�-cation.A speci�cation of a system should aid understanding of that system, assisting development and maintenance of thesystem. Speci�cations need express only abstract properties, unlike implementations such as detailed algorithms,physical circuits, etc. Speci�cations may be loose, allowing re�nement to many di�erent implementations. Suchabstract and loose speci�cations can be written in Z.A speci�cation written in Z models the speci�ed system: it names the components of the system and expressesthe constraints between those components. The meaning of a Z speci�cation|its semantics|is de�ned as theset of interpretations (values for the named components) that are consistent with the constraints.Z uses mathematical notation, hence speci�cations written in Z are said to be formal: the meaning is capturedby the form of the mathematics used, independent of the names chosen. This formal basis enables mathematicalreasoning, and hence proofs that desired properties are consequences of the speci�cation. The soundness ofinference rules used in such reasoning should be proven relative to the semantics of the Z notation.This International Standard establishes precise syntax and semantics for a system of notation for mathematics,providing a basis on which further mathematics can be formalized.Particular characteristics of Z include:� its extensible toolkit of mathematical notation;� its schema notation for specifying structures in the system and for structuring the speci�cation itself; and� its decidable type system, which allows some well-formedness checks on a speci�cation to be performedautomatically.Examples of the kinds of systems that have been speci�ed in Z include:� safety critical systems, such as railway signalling, medical devices, and nuclear power systems;� security systems, such as transaction processing systems, and communications; and� general systems, such as programming languages and oating point processors.Standard Z will also be appropriate for use in:� formalizing the semantics of other notations, especially in standards documents.This is the �rst ISO standard for the Z notation. Much has already been published about Z. Most uses of theZ notation have been based on the examples in the book \Speci�cation Case Studies" edited by Hayes [2][3].Early de�nitions of the notation were made by Sufrin [13] and by King et al [7]. Spivey's doctoral thesis showedthat the semantics of the notation could be de�ned in terms of sets of models in ZF set theory [10]. His book\The Z Notation|A Reference Manual" [11][12] is the most complete de�nition of the notation, prior to thisInternational Standard. Di�erences between Z as de�ned here and as de�ned in [12] are discussed in [14]. ThisInternational Standard addresses issues that have been resolved in di�erent ways by di�erent users, and henceencourages interchange of speci�cations between diverse tools. It also aims to be a complete formal de�nition ofZ.c ISO/IEC 2000|All rights reserved v

ISO/IEC 13568:2000(E)

vi c ISO/IEC 2000|All rights reserved

INTERNATIONAL STANDARD ISO/IEC 13568:2000(E)Formal Speci�cation|Z Notation|Syntax, Type and Semantics1 ScopeThe following are within the scope of this International Standard:� the syntax of the Z notation;� the type system of the Z notation;� the semantics of the Z notation;� a toolkit of widely used mathematical operators;� LATEX [9] and email mark-ups of the Z notation.The following are outside the scope of this International Standard:� any method of using Z, though an informative annex (E) describes one widely-used convention.2 Normative referencesThe following normative documents contain provisions which, through reference in this text, constitute provisionsof this International Standard. For dated references, subsequent amendments to, or revisions of, any of thesepublications do not apply. However, parties to agreements based on this International Standard are encouragedto investigate the possibility of applying the most recent editions of the normative documents indicated below.For undated references, the latest edition of the normative document referred to applies. Members of ISO andIEC maintain registers of currently valid International Standards.ISO/IEC 10646-1:2000, Information Technology|Universal Multiple-Octet Coded Character Set (UCS)|Part 1:Architecture and Basic Multilingual Plane, plus its amendments and corrigendaISO/IEC FCD 10646-2, Information Technology|Universal Multiple-Octet Coded Character Set (UCS)|Part 2:Secondary Multilingual Plane for scripts and symbols, Supplementary Plane for CJK Ideographs, Special PurposePlaneISO/IEC 14977:1996, Information Technology|Syntactic Metalanguage|Extended BNF3 Terms and de�nitionsFor the purposes of this International Standard, the following de�nitions of terms apply. Italicized terms inde�nitions are themselves de�ned in this list.3.1binding�nite function from names to valuesc ISO/IEC 2000|All rights reserved 1

4 Symbols and de�nitions ISO/IEC 13568:2000(E)4 Symbols and de�nitionsFor the purposes of this International Standard, the following de�nitions of symbols apply.4.1 Syntactic metalanguageThe syntactic metalanguage used is the subset of the standard ISO/IEC 14977:1996 [6] summarised in Table 1,with modi�cations so that the mathematical symbols of Z can be presented in a more comprehensible way.Table 1 { Syntactic metalanguageSymbol De�nition= de�nes a non-terminal on the left in terms of the syntax on the right.| separates alternatives., separates notations to be concatenated.| separates notation on the left from notation to be excepted on the right.{ } delimit notation to be repeated zero or more times.[ ] delimit optional notation.( ) are grouping brackets (parentheses).' ' delimit a terminal symbol.; terminates a de�nition.(* *) delimit commentary.The in�x operators | and , have precedence such that parentheses are needed when concatenating alternations,but not when alternating between concatenations. The exception notation is always used with parentheses, makingits precedence irrelevant. Whitespace separates tokens of the syntactic metalanguage; it is otherwise ignored.EXAMPLE The lexis of a NUMERAL token, and its informal reading, are as follows.NUMERAL = NUMERAL , DIGIT| DIGIT;The non-terminal symbol NUMERAL stands for a maximal sequence of one or more digit characters (without interveningwhite space).The changes to ISO/IEC 14977:1996 allow use of mathematical symbols in the names of non-terminals, and areformally de�ned as follows.NOTE 1 The question marks delimit the formal de�nition, as required by ISO/IEC 14977:1996.?Meta identifier character = all cases from ISO/IEC 14977:1996| '`' | '8 ' | '9 ' | '�' | ',' | ')' | '_' | '^' | ': ' | '2'| '� ' | '� ' | 'o9' | '>>' | '�' | '�' | 'P' | '� '| 'f' | 'g' | '(' | ')' | '[' | ']' | 'hj' | 'ji' | 'hh' | 'ii'| 'j' | ';' | ':' | '=' | '; ' | ':' | '=' | 'n' | ' ' | '&' | ' oo ';? NOTE 2 This anticipates a future version of ISO/IEC 14977:1996 permitting use of the characters of ISO/IEC10646. It also anticipates a future version of ISO/IEC 10646 including all of these mathematical symbols (most arealready included and the rest have been proposed).The new Meta identifier characters '(', ')', '[', ']', 'f', 'g', ';', 'j', '&', '; ' and '=' overload existing metalan-guage characters. Uses of them as Meta identifier characters are with the common su�x -tok, e.g. (-tok,which may be viewed as a post�x metalanguage operator.c ISO/IEC 2000|All rights reserved 3

ISO/IEC 13568:2000(E) 4 Symbols and de�nitionsA further change to ISO/IEC 14977:1996 is the use of multiple fonts: metalanguage characters and non-terminalsare in Typewriter, those non-terminals that correspond to Z tokens appear as those Z tokens normally appear,typically in Roman, and comments are in Italic.The syntactic metalanguage is used in de�ning Z characters, lexis, concrete syntax and annotated syntax.4.2 Mathematical metalanguage4.2.1 IntroductionLogic and Zermelo-Fraenkel set theory are the basis for the semantics of Z. In this section the speci�c notationsused are described. The notations used here are deliberately similar in appearance to those of Z itself, but aregrounded only on the logic and set theory developed by the wider mathematical community.The mathematical metalanguage is used in type inference rules and in semantic relations.4.2.2 ParenthesesThe forms of proposition and expression are given below. Where there could be any ambiguity in the parsing,usually parentheses have been used to clarify, but in any other case the precedence conventions of Z itself areintended to be used.The use of parentheses is given in tabular form in Table 2, where p stands for any proposition and e stands forany expression. Table 2 { Parentheses in metalanguageNotation De�nition(p) p(e) eThe same brackets symbols are used around pairs and tuple extensions (Table 12), but those cannot be omittedin this way.4.2.3 Propositions4.2.3.1 IntroductionThe value of a metalanguage proposition is either true or false. The values true and false are distinct. In thisInternational Standard, no proposition of the metalanguage is both true and false; that is, this metatheory isconsistent. Furthermore, every proposition is either true or false, even where it is not possible to say which; thatis, the logic is two-valued.4.2.3.2 Propositional connectivesThe propositional connectives of negation, conjunction and disjunction are used. In Table 3 and later, p, p2, etc,represent arbitrary propositions.Table 3 { Propositional connectives in metalanguageNotation Name De�nition: p negation true i� p is falsep1 ^ p2 conjunction true i� p1 and p2 are both truep1 _ p2 disjunction false i� p1 and p2 are both falseConjunction is also sometimes indicated by writing propositions on successive lines, as a vertical list.4 c ISO/IEC 2000|All rights reserved

4 Symbols and de�nitions ISO/IEC 13568:2000(E)4.2.3.3 Quanti�ersExistential, universal and unique-existential quanti�ers are used. In Tables 4 and 5 and later, i , i2, etc, representarbitrary names, e, e2, etc, represent arbitrary expressions, and ::: represents zero or more repetitions of thesurrounding formulae; in these tables, the propositions can contain references to the names, but the expressionscannot. Table 4 { Quanti�ers in metalanguageNotation Name De�nition9 i1 : e1; :::; in : en � p existential quanti�cation there exist (9 ) values of i1 in set e1, ..., in in seten (i1 : e1; :::; in : en ) such that (�) p is true8 i1 : e1; :::; in : en � p universal quanti�cation for all (8 ) values of i1 in set e1, ..., in in set en(i1 : e1; :::; in : en ), it is true that (�) p is true91 i1 : e1; :::; in : en � p unique existential quanti�cation there exists exactly one (91) con�guration of val-ues i1 in set e1, ..., in in set en (i1 : e1; :::; in :en ) such that (�) p is trueCertain abbreviations in the writing of quanti�cations are permitted, as given in Table 5. They shall be appliedrepeatedly until none of them is applicable.Table 5 { Abbreviations in quanti�cations in metalanguageNotation De�nitioni1; i2; :::; in : e i1 : e; i2; :::; in : e9 i1 : e1; :::; in : en j p1 � p2 9 i1 : r1; :::; in : en � p1 ^ p28 i1 : e1; :::; in : en j p1 � p2 8 i1 : e1; :::; in : en � (: p1) _ p291 i1 : e1; :::; in : en j p1 � p2 91 i1 : e1; :::; in : en � p1 ^ p24.2.3.4 Conditional expressionThe conditional expression allows the choice between two alternative values according to the truth or falsity of agiven proposition, as de�ned in Table 6.Table 6 { Conditional expression in metalanguageNotation De�nitionif p then e1 else e2 either p is true and e1 is the value, or p is false and e2 is the value4.2.4 Sets4.2.4.1 IntroductionThe notation used here is based on Zermelo-Fraenkel set theory, as described in for example [1], and the presenta-tion here is guided by the order given there. In that theory there are only sets. Members of sets can only be othersets. The word \element" may be used loosely when referring to set members treated as atomic, without regardto their set nature. If metalanguage operations are applied to inappropriate arguments, they produce unspeci�edresults rather than being unde�ned.4.2.4.2 The universeThe universe, W , denotes a world of sets, providing semantic values for Z expressions. W is big enough to containthe set NAME, from which Z names are drawn, and an in�nite set and be closed under formation of powerset andc ISO/IEC 2000|All rights reserved 5

ISO/IEC 13568:2000(E) 4 Symbols and de�nitionsproducts. The formation of a suitable W comprising models of sets, tuples and bindings, as needed to model Z,is well-known in ZF set theory and is assumed in this International Standard.4.2.4.3 Propositions about sets and elementsThe simplest propositions about sets are the relationships of membership, non-membership, subset and equalitybetween sets or their elements, as detailed in Table 7.Table 7 { Propositions about sets in metalanguageNotation Name De�nitione1 2 e1 membership true i� e1 is a member of set e2e1 62 e2 non-membership : e1 2 e2e1 � e2 subset 8 i : e1 � i 2 e2e1 = e2 equality for e1 and e2 considered as sets, e1 � e2 ^ e2 � e14.2.4.4 Basic set operationsZF set theory constructs its repertoire of set operations starting with the axiom of empty set, then showing howto build up sets using the axioms of pairing and of union, and how to trim them back with the axiom of subsetor separation.For the purposes of this mathematical metalanguage, the simplest form of set comprehension is de�ned directlyusing the axiom of separation in Table 8. The existence of a universal set W is assumed. Other forms of setcomprehension are de�ned in terms of the simplest form, using rules in which w is any name distinct from thosealready in use. Also de�ned in Table 8 are notations for empty set, �nite set extensions, unions, intersections anddi�erences. Table 8 { Basic set operations in metalanguageNotation Name De�nitionfi : e j pg set comprehension subset of elements i of e such that p, by axiom of separationfi1 : e1; :::; in : en � eg set comprehension fw : W j 9 i1 : e1; :::; in : en � w = egfi1 : e1; :::; in : en j p � eg set comprehension fw : W j 9 i1 : e1; :::; in : en � p ^ w = eg? empty set fi : W j falsegfg empty set fi : W j falsegfeg singleton set fi : W j i = ege1 [ e2 union fi : W j i 2 e1 _ i 2 e2gfe1; e2; :::; eng set extension fe1g [ fe2; :::; enge1 \ e2 intersection fi : e1 j i 2 e2ge1 n e2 di�erence fi : e1 j i 62 e2g4.2.4.5 PowersetsThe axiom of powers asserts the existence of a powerset, which is the set of all subsets of a set. The set of all�nite subsets is a subset of the powerset. It is the smallest set containing the empty set and all singleton subsetsof e and closed under the operation of forming the union with singleton subsets of e. Their forms are given inTable 9.4.2.5 NumbersNumbers are not primitive in Zermelo-Fraenkel set theory, but there are several well established ways of repre-senting them. The choice of coding is irrelevant here and so is not speci�ed. There are notations to measure thecardinality of a �nite set, to de�ne addition of natural numbers and to form the set of natural numbers betweentwo stated natural numbers, as given in Table 10.6 c ISO/IEC 2000|All rights reserved

4 Symbols and de�nitions ISO/IEC 13568:2000(E)Table 9 { Powerset in metalanguageNotation Name De�nitionP e set of all subsets fi : W j i � egF e set of all �nite subsets fi1 : W j 8 i2 : PP e j ? 2 i2 ^ (8 i3 : i2 � 8 i4 : e � i3[fi4g 2 i2) � i1 2 i2gTable 10 { Operations on numbers in metalanguageNotation De�nitione1 + e2 sum of natural numbers e1 and e2# e cardinality of �nite set ee1 : : e2 set of natural numbers between e1 and e2 inclusive4.2.6 NamesNames are needed for this International Standard. There are several ways of representing names in Zermelo-Fraenkel set theory. The choice of coding is irrelevant here and so is not speci�ed. Only one operation is neededon names; it is an in�x operation with highest precedence, and is de�ned in Table 11.Table 11 { Decorations of names in metalanguageNotation De�nitioni decor + the name that is like i but with the extra stroke +4.2.7 Tuples and Cartesian productsTuples and Cartesian products are not primitive in Zermelo-Fraenkel set theory, but there are various ways inwhich they may be represented within that theory, such as the well-known encoding given by Kuratowski [1]. Thechoice of coding is irrelevant here and so is not speci�ed. In this International Standard, particular names arealways known either to have tuples or Cartesian products as their values, or not to have such values. Thereforethere is never any possibility of accidental confusion between the encoding used to represent the tuple and anyother value which is not a tuple.In this mathematical metalanguage, tuples and Cartesian products with more than two components are interpretedas nested binary tuples and products, unlike in Z.The syntactic forms are given in Table 12.Table 12 { Tuples and Cartesian products in metalanguageNotation Name De�nition(e1; e2) paire1 7! e2 maplet (e1; e2)�rst e �rst(e1; e2) = e1second e second(e1; e2) = e2e1 � e2 fi1 : e1; i2 : e2 � (i1; i2)g(e1; e2; :::; en ) tuple extension (e1; (e2; :::; en )) where n � 2e1 � e2 � :::� en Cartesian product e1 � (e2 � :::� en ) where n � 2e " n iterated product e � :::� e where there are n � 2 occurrences of ec ISO/IEC 2000|All rights reserved 7

ISO/IEC 13568:2000(E) 4 Symbols and de�nitionsThe brackets delimiting a pair or tuple extension written with commas may not be omitted|they are not groupingparentheses.4.2.8 Function comprehensionsTable 13 de�nes the notation for � , which is a form of comprehension convenient when de�ning functions.Table 13 { Function comprehensions in metalanguageNotation De�nition� i : e1 � e2 fi : e1 � i 7! e2g� i : e1 j p � e2 fi : e1 j p � i 7! e2g� i1 : e1; :::; in : en � e fi1 : e1; :::; in : en � (i1; :::; in ) 7! eg� i1 : e1; :::; in : en j p � e fi1 : e1; :::; in : en j p � (i1; :::; in ) 7! eg4.2.9 RelationsA relation is de�ned to be a set of Cartesian pairs. There are several operations involving relations, which aregiven equivalences in Table 14. A proposition about relations is given in Table 15.Table 14 { Relations in metalanguageNotation Name De�nitionid e identity function � i : e � idom e domain fi : e � �rst ige� relational inversion fi : e � second i 7! �rst ige1 C e2 domain restriction fi : e2 j �rst i 2 e1ge1 �C e2 domain subtraction fi : e2 j �rst i 62 e1ge1(j e2 j) relational image fi : e1 j �rst i 2 e2 � second ige1 o9 e2 relational composition fi1 : e1; i2 : e2 j second i1 = �rst i2 � �rst i1 7! second i2ge1 � e2 relational overriding ((dom e2)�C e1) [ e2Table 15 { Proposition about relations in metalanguageNotation Name De�nitione1 � e2 compatible relations (dom e2)C e1 = (dom e1)C e24.2.10 FunctionsA function is a particular form of relation, where each domain element has only one corresponding range element.Table 16 shows the various forms of function that are identi�ed, each being a set of functions.Table 16 { Functions in metalanguageNotation Name De�nitione1 7! e2 functions fi1 : P (e1 � e2) j 8 i2; i3 : i1 j �rst i2 = �rst i3 � second i2 = second i3ge1 ! e2 total functions fi : e1 7! e2 j dom i = e1ge1 �! e2 bijections fi : e1 ! e2 j i� 2 e2 ! e1ge1 7 7! e2 �nite functions fi : F (e1 � e2) j i 2 e1 7! e2g4.2.10.1 Function useA function can be juxtaposed with an argument to produce a result, using the notation of Table 17. Metalanguagenotations introduced above that match the e1 e2 pattern, such as dom e, are not applications in this sense.8 c ISO/IEC 2000|All rights reserved

4 Symbols and de�nitions ISO/IEC 13568:2000(E)Table 17 { Function use in metalanguageNotation Name De�nitione1 e2 application if there exists a unique e3 such that e2 7! e3 is in e1,then the value of e1 e2 is e3, otherwise each e1 e2 has a�xed but unknown value4.2.11 SequencesA sequence is a particular form of function, where the domain elements are all the natural numbers from 1 to thelength of the sequence. Table 18 { Sequences in metalanguageNotation Name De�nitionhe1; ::::; eni sequence f1 7! e1; :::;n 7! eng4.2.12 DisjointnessA labelled family of sets is disjoint when any distinct pair yields sets with no members in common.Table 19 { Disjointness in metalanguageNotation Name De�nitiondisjoint e disjointness 8 e1; e2 : dom e j e1 6= e2 � e e1 \ e e2 = ?4.3 Transformation metalanguageEach transformation rule is written in the following form.concrete phrase template =) less concrete phrase templateThe phrase templates are patterns; they are not speci�c sentences and they are not written in the syntacticmetalanguage. These patterns are written in a notation based on the concrete and annotated syntaxes, withmetavariables appearing in place of syntactically well-formed phrases. Where several phrases of the same syntacticclasses have to be distinguished, these metavariables are given distinct numeric subscripts. The letters k , m , n , rare used as metavariables for such numeric subscripts. The patterns can be viewed either as using the non-terminalsymbols of the Z lexis with the -tok su�xes omitted from mathematical symbols, or as using the mathematicalrendering with the box tokens in place of paragraph outlines. Transformations map parse trees of phrases toother parse trees. The metavariables are de�ned in Tables 20 and 21 (the phrases being de�ned in clauses 7 and8, and the operator words in 7.4.4).EXAMPLE 1 The syntactic transformation rule for a schema de�nition paragraph, and an informal reading of it,are as follows. SCH i t END =) AX [i == t] ENDA schema de�nition paragraph is formed from a box token SCH, a name i, a schema text t, and an END token. Anequivalent axiomatic description paragraph is that which would be written textually as a box token AX, a [ token, theoriginal name i, a == token, the original schema text t, a ] token, and an END token.EXAMPLE 2 The semantic transformation rule for a schema hiding expression, and an informal reading of it, areas follows. (e oo P[�]) n (i1; :::; in) =) 9 i1 : carrier (� i1); :::; in : carrier (� in) � ec ISO/IEC 2000|All rights reserved 9

ISO/IEC 13568:2000(E) 4 Symbols and de�nitionsTable 20 { Metavariables for phrasesSymbol De�nitionb denotes a list of digits within a NUMERAL token.c denotes a digit within a NUMERAL token.d denotes a Paragraph phrase (d for de�nition/description).de denotes a Declaration phrase.e denotes an Expression phrase.f denotes a free type's NAME token.g denotes an injection's NAME token (g for ingection).h denotes an element's NAME token (h for helement).i, j denote NAME tokens or DeclName or RefName phrases (i for identi�er).p denotes a Predicate phrase.s denotes a Section phrase.al denotes an ExpressionList phrase (al for list argument).t denotes a SchemaText phrase (t for text).u, v , w , x , y denote distinct names for new local declarations.z denotes a Specification sentence.� denotes a Type phrase.� denotes a Signature phrase.+ denotes a STROKE token.� denotes a { STROKE } phrase.... denotes elision of repetitions of surrounding phrases, the total number ofrepetitions depending on syntax.A schema with signature � from which some names are hidden is semantically equivalent to the schema existentialquanti�cation of the hidden names from the schema. Each name is declared with the set that is the carrier set of thetype of the name in the signature of the schema.The applicability of a transformation rule can be guarded by a condition written above the =) symbol. Localde�nitions can be associated with a transformation rule by appending a where clause, in which later de�nitionscan refer to earlier de�nitions.The transformation rule metalanguage is used in de�ning characterisation rules, syntactic transformation rules,type inference rules, and semantic transformation rules.4.4 Type inference rule metalanguageEach type inference rule is written in the following form.type subsequentstype sequent (side�condition)where local�declarationand :::This can be read as: if the type subsequents are valid, and the side-condition is true, then the type sequent isvalid, in the context of the zero-or-more local declarations. The side-condition is optional; if omitted, the typeinference rule is equivalent to one with a true side-condition.The annotated syntax establishes notation for writing types as Type phrases and for writing signatures asSignature phrases. The oo operator allows annotations such as types to be associated with other phrases.Determining whether a type sequent is valid or not involves manipulation of types and signatures. This requiresviewing types and signatures as values, and having a mathematical notation to do the manipulation. Signaturesare viewed as functions from names to type values. Type is used to denote the set of type values as well as the set10 c ISO/IEC 2000|All rights reserved

4 Symbols and de�nitions ISO/IEC 13568:2000(E)Table 21 { Metavariables for operator wordsSymbol De�nitionel denotes an EL token.elp denotes an ELP token.er denotes an ER token.ere denotes an ERE token.erep denotes an EREP token.erp denotes an ERP token.es denotes an ES token.ess denotes an ES token or SS token.in denotes an I token.ip denotes an IP token or 2 token or = token.ln denotes an L token.lp denotes an LP token.post denotes a POST token.postp denotes a POSTP token.pre denotes a PRE token.prep denotes a PREP token.sr denotes an SR token.sre denotes an SRE token.srep denotes an SREP token.srp denotes an SRP token.ss denotes an SS token.of type phrases, the appropriate interpretation being distinguished by context of use. Similarly, NAME is also usedto denote a set of name values. These values all lie within the type universe. A type's NAME has a correspondingtype value in the type universe whereas its carrier set is in the semantic universe.Type values are formed from just �nite sets and ordered pairs, so the mathematical metalanguage introduced insection 4.2 su�ces for their manipulation.Details of which names are in scope are kept in environments. The various kinds of environment are de�ned inTable 22, and metavariables for environments are de�ned in Table 23.Table 22 { EnvironmentsSymbol De�nitionTypeEnv denotes type environments, where TypeEnv == NAME 7 7! Type. Type en-vironments associate names with types. They are like signatures, but areused in di�erent contexts.SectTypeEnv denotes section-type environments, where SectTypeEnv == NAME 7 7!(NAME�Type). Section-type environments associate names of declarationswith the name of the ancestral section that originally declared the namepaired with its type.SectEnv denotes section environments, where SectEnv == NAME 7 7! SectTypeEnv.Section environments associate section names with section-type environ-ments.Type sequents are written using a ` symbol superscripted with a mnemonic letter to distinguish the syntax ofc ISO/IEC 2000|All rights reserved 11

ISO/IEC 13568:2000(E) 4 Symbols and de�nitionsTable 23 { Metavariables for environmentsSymbol De�nition� denotes a type environment, � : TypeEnv.� denotes a section-type environment, � : SectTypeEnv.� denotes a section environment, � : SectEnv.the phrase appearing to its right|see Table 24.Table 24 { Type sequentsSymbol De�nitionZ z a type sequent asserting that speci�cation z is well-typed.� S s oo � a type sequent asserting that, in the context of section environment �,section s has section-type environment �.� D d oo � a type sequent asserting that, in the context of type environment �, theparagraph d has signature �.� P p a type sequent asserting that, in the context of type environment �, thepredicate p is well-typed.� E e oo � a type sequent asserting that, in the context of type environment �, theexpression e has type �.NOTE 1 These superscripts are the same as the superscripts used on the [[ ]] semantic brackets in the semanticrelations below.NOTE 2 Unlike the `? symbol of Z, there is no ? as these sequents are decidable.The annotated phrases to the right of ` in type sequents are phrase templates written using the same metavariablesas the syntactic transformation rules; see Table 20.EXAMPLE The type inference rule for a schema conjunction expression, and its informal reading, are as follows.� E e1 oo �1 � E e2 oo �2� E (e1 oo �1) ^ (e2 oo �2) oo �30B@ �1 = P[�1]�2 = P[�2]�1 � �2�3 = P[�1 [ �2] 1CAIn a schema conjunction expression e1 ^ e2, expressions e1 and e2 shall be schemas, and their signatures shall becompatible. The type of the whole expression is that of the schema whose signature is the union of those of expressionse1 and e2.NOTE 3 The metavariables �1 and �2 denote syntactic phrases. These are mapped implicitly to type values,so that the set union can be computed, and the resulting signature is implicitly mapped back to a syntacticphrase. These mappings are not made explicit as they would make the type inference rules harder to read, e.g.[[ [[�1]] [ [[�2]] ]].This metalanguage is used in de�ning type inference rules.12 c ISO/IEC 2000|All rights reserved

5 Conformance ISO/IEC 13568:2000(E)4.5 Semantic relation metalanguageMost semantic relations are equations written in the following form.[[phrase template]] = semanticsWhere the de�nition is only partial, the equality notation is not appropriate, and instead a lower bound is speci�edon the semantics. semantics � [[ � e1 � e2 ]]EThe phrase templates use the same metavariables as used by the syntactic transformation rules|see Table 20.Symbols concerned with the domain of the semantic de�nitions are listed in Tables 25 and 26.Table 25 { Semantic universeSymbol De�nitionU denotes the semantic universe, providing semantic values for all Z values,where U == W [ (W " n ! W ). U comprises W and Z generic de�nitionseach as a function from the semantic values of its instantiating expressions(a tuple in W ) to a member of W .Model denotes models, where Model == NAME 7 7! U. Models associate names ofdeclarations with semantic values. They are applied only to names in theirdomains, as guaranteed by well-typedness.SectionModels denotes functions from sections' names to their sets of models, whereSectionModels == NAME 7 7! PModel .Table 26 { Variables over semantic universeSymbol De�nitionM denotes a model, M : Model .T denotes a section's name and its set of models, T : SectionModels .t denotes a binding semantic value, t : NAME 7 7! W .g denotes a generic semantic value, g : W ! W .w ; x ; y denote non-generic semantic values, w : W ; x : W ; y : W .The meaning of a phrase template is given by a semantic relation from the Z phrase in terms of operations of ZFset theory on the semantic universe. There are di�erent semantic relations for each syntactic notation, writtenusing the conventional [[ ]] semantic brackets, but here superscripted with a mnemonic letter to distinguish thesyntax of phrase appearing within them|see Table 27.NOTE The superscripts are the same as those used on the ` of type sequents in the type inference rules above.EXAMPLE The semantic relation for a conjunction predicate, and its informal reading, are as follows. The con-junction predicate p1 ^ p2 is true if and only if p1 and p2 are true.[[ p1 ^ p2 ]]P = [[ p1 ]]P \ [[ p2 ]]PIn terms of the semantic universe, it is true in those models in which both p1 and p2 are true, and is false otherwise.Within the semantic relations, the idioms listed in Table 28 occur repeatedly.Semantic relation metalanguage is used in de�ning semantic relations.c ISO/IEC 2000|All rights reserved 13

ISO/IEC 13568:2000(E) 5 ConformanceTable 27 { Semantic relationsSymbol De�nition[[ z ]]Z denotes the meaning of speci�cation z, where [[ z ]]Z 2 SectionModels . Themeaning of a speci�cation is the function from its sections' names to theirsets of models.[[ s ]]S denotes the meaning of section s, where [[ s ]]S 2 SectionModels 7!SectionModels . The meaning of a section is given by the extension ofa SectionModels function with an extra maplet corresponding to the givensection.[[ d ]]D denotes the meaning of paragraph d, where [[ d ]]D 2 Model $ Model . Themeaning of a paragraph relates a model to that model extended accordingto that paragraph.[[ p ]]P denotes the meaning of predicate p, where [[ p ]]P 2 PModel . The meaningof a predicate is the set of all models in which that predicate is true.[[ e ]]E denotes the meaning of expression e, where [[ e ]]E 2 Model ! W . Themeaning of an expression is a function returning the semantic value of theexpression in the given model.[[ � ]]T denotes the meaning of type �, where [[ � ]]T 2 Model 7! P U. The meaningof a type is the semantic value of its carrier set, as determined from thegiven model.Table 28 { Semantic idiomsIdiom Description[[ e ]]EM denotes the value of expression e in model MM � t denotes the model M giving semantic values for more global declarationsoverridden by the binding t giving the semantic values of locally declarednames5 Conformance5.1 Phases of the de�nitionThe de�nition of the Z notation is divided into a sequence of phases, as illustrated in Figure 1. Each arrowrepresents a phase from a representation of a Z speci�cation at its source to another representation of the Zspeci�cation at its target. The phase is named at the left margin. Some phases detect errors in the speci�cation;these are shown drawn o� to the right-hand side.NOTE 1 Figure 1 shows the order in which the phases are applied, and where errors are detected; it does not showinformation ows.NOTE 2 The arrows are analogous to total and partial function arrows in the Z mathematical toolkit, but drawnvertically.14 c ISO/IEC 2000|All rights reserved

5 Conformance ISO/IEC 13568:2000(E)Figure 1 { Phases of the de�nitionsource textmark-up ? mark-up errorsequence of Z characterslexing ? lexical errorsequence of tokensparsing ? syntax errorparse tree of concrete syntax sentencecharacterising ?characterised parse tree of concrete syntax sentencesyntactic transformation ?parse tree of annotated syntax sentencetype inference ? type errorfully annotated parse tree of annotated syntax sentencesemantic transformation ?fully annotated parse tree of sentence of subset of annotated syntaxsemantic relation ?meaning in ZF set theory

c ISO/IEC 2000|All rights reserved 15

ISO/IEC 13568:2000(E) 5 Conformance5.2 Conformance requirements5.2.1 Speci�cation conformanceFor a Z speci�cation to conform to this International Standard, no errors shall be detected by any of the phasesshown in Figure 1. In words, for a Z speci�cation to conform to this International Standard, its formal text shallbe valid mark-up of a sequence of Z characters, that can be lexed as a valid sequence of tokens, that can be parsedas a sentence of the concrete syntax, and that is well-typed according to the type inference system.NOTE The presence of sections that have no models does not a�ect the conformance of their speci�cation.5.2.2 Mark-up conformanceA mark-up for Z based on LATEX [9] conforms to this International Standard if and only if it follows the rulesgiven for LATEX mark-up in A.2.A mark-up for Z used in email correspondence conforms to this International Standard if and only if it followsthe rules given for email mark-up in A.3.Mark-up for Z based on any other mark-up language is permitted; it shall be possible to de�ne a functionalmapping from that mark-up to sequences of Z characters.The ISO/IEC 10646 representation may be used directly|the identity function is an acceptable mapping.5.2.3 Deductive system conformanceA Z deductive system conforms to this International Standard if and only if its rules are sound with respect tothe semantics, i.e. if both of the following conditions hold:a) all of its axioms hold in all models of all Z speci�cations, i.e. for any axiom p,[[ p ]]P = Modelb) all of its rules of inference have the property that the intersection of the sets of models of each of the premisesis contained in the model of the conclusion, i.e. for any rule of inference where p is deduced from p1, ... pn,[[ p1 ]]P \ ::: \ [[ pn ]]P � [[ p ]]PAll constraints appearing before a conjecture in a speci�cation may be used as premises in inferences aboutthat conjecture. A Z deductive system should document whether or not it allows constraints appearing after aconjecture in a speci�cation to be used as premises in inferences about that conjecture.The semantic relation is de�ned loosely in this International Standard, so as to permit alternative treatments ofunde�nedness. A Z deductive system may take a particular position on unde�nedness. That position should beclearly documented.5.2.4 Mathematical toolkit conformanceA Z section whose name is the same as a section of the mathematical toolkit of annex B conforms to thisInternational Standard if and only if it de�nes the same set of models as that section of the mathematical toolkit.A Z section whose name is prelude conforms to this International Standard if and only if it de�nes the same setof models as the section in clause 11.A mathematical toolkit conforms to this standard if it de�nes a conformant section called standard toolkit.NOTE 1 The set of models de�ned by a section within a speci�cation may be found by applying the meaning ofthe speci�cation to the section's name.NOTE 2 A conforming section of the toolkit may formulate its de�nitions di�erently from those in annex B.16 c ISO/IEC 2000|All rights reserved

6 Z characters ISO/IEC 13568:2000(E)NOTE 3 A conforming section of the toolkit may partition its de�nitions amongst parent sections that di�er fromthose in annex B.NOTE 4 Alternative and additional toolkits are not precluded, but are required to have di�erent section names toavoid confusion.NOTE 5 Some names are loosely de�ned, such as A , and may be further constrained by sections that use toolkitsections, but not by toolkit sections themselves.5.2.5 Support tool conformanceA strongly conforming Z support tool shall recognise at least one conforming mark-up, accepting all conforming Zspeci�cations presented to it, and rejecting all non-conforming Z speci�cations presented to it. A weakly conform-ing Z support tool shall never accept a non-conforming Z speci�cation, nor reject a conforming Z speci�cation,but it may state that it is unable to determine whether or not a Z speci�cation conforms.NOTE Strong conformance can be summarised as always being right, whereas weak conformance is never beingwrong.EXAMPLE A tool would be weakly conformant if it were to announce its inability to determine the conformanceof a Z speci�cation that used names longer than the tool could handle, but would be non-conformant if it silentlytruncated long names.Certain exceptions to general rules are anticipated and permitted in subsequent clauses, because of, for example,implementation considerations or for backwards compatibility with pre-existing tools.5.3 Structure of this documentThe phases in the de�nition of the Z notation, and the representations of speci�cations manipulated by thosephases, as illustrated in Figure 1, are speci�ed in the following clauses and annexes.Annex A, Mark-ups, speci�es two source text representations and corresponding mark-up phases for translatingsource text to sequences of Z characters.Clause 6 speci�es the Z characters by their appearances and their names in ISO/IEC 10646.Clause 7, Lexis, speci�es tokens and the lexing phase that translates a sequence of Z characters to a sequence oftokens.Clause 8 speci�es the grammar of the concrete syntax, and hence abstractly speci�es the parsing phase thattranslates a sequence of tokens to a parse tree of a concrete syntax sentence. Some information from parsingoperator template paragraphs is fed back to the lexis phase.Clause 9 speci�es the characterising phase, during which characteristic tuples are made explicit in the parse treeof a concrete syntax sentence.Clause 10 speci�es the grammar of the annotated syntax, de�ning the target language for the syntactic transfor-mation phase.Clause 11 speci�es the prelude section, providing an initial environment of de�nitions.Clause 12 speci�es the syntactic transformation phase that translates a parse tree of a concrete syntax sentenceto a parse tree of an equivalent annotated syntax sentence.Clause 13 speci�es the type inference phase, during which type annotations are added to the parse tree of theannotated syntax sentence, and reference expressions that refer to generic de�nitions are translated to genericinstantiation expressions.Clause 14 speci�es the semantic transformation phase, during which some annotated parse trees are translatedto equivalent other annotated parse trees.Clause 15 speci�es the semantic relation between a sentence of the remaining annotated syntax and its meaningin ZF set theory.c ISO/IEC 2000|All rights reserved 17

ISO/IEC 13568:2000(E) 6 Z charactersAnnex C duplicates those parts of the de�nition that �t into an organisation by concrete syntax production.6 Z characters6.1 IntroductionA Z character is the smallest unit of information in this International Standard; Z characters are used to buildtokens (clause 7), which are in turn the units of information in the concrete syntax (clause 8). The Z charactersare de�ned by reference to ISO/IEC 10646-1 and ISO/IEC 10646-2: for each Z character is listed its appearance,code position and name.Many Z characters are not present in the standard 7-bit ASCII encoding [4]. It is possible to represent Zcharacters in ASCII, by de�ning a mark-up, where several ASCII characters are used together to represent asingle Z character. This International Standard de�nes some ASCII mark-ups in annex A by relation to theISO/IEC 10646 representation de�ned here. Other mark-ups of Z characters can similarly be de�ned by relationto the ISO/IEC 10646 representation.6.2 Formal de�nition of Z charactersZCHAR = DIGIT | LETTER | SPECIAL | SYMBOL ;DIGIT = '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'| any other ISO/IEC 10646 character with the `decimal' property (as supported);LETTER = LATIN | GREEK | OTHERLETTER| any characters of the mathematical toolkit with `letter' property (as supported)| any other ISO/IEC 10646 characters with the `letter' property (as supported);LATIN = 'A' | 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H ' | 'I'| 'J' | 'K' | 'L' | 'M ' | 'N ' | 'O' | 'P' | 'Q' | 'R'| 'S' | 'T' | 'U ' | 'V ' | 'W ' | 'X' | 'Y ' | 'Z'| 'a' | 'b' | 'c' | 'd' | 'e' | 'f ' | 'g' | 'h' | 'i'| 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r'| 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z';GREEK = '�' | '�' | '�' | '�' | '�' ;OTHERLETTER = 'A ' | 'N' | 'P' ;SPECIAL = STROKECHAR | WORDGLUE | BRACKET | BOXCHAR | SPACE ;STROKECHAR = '0' | '!' | '?' ;WORDGLUE = '%' | '.' | '&' | '-' | ' ' ;BRACKET = '(' | ')' | '[' | ']' | 'f' | 'g' | 'hj' | 'ji' | 'hh' | 'ii' ;BOXCHAR = AXCHAR | SCHCHAR | GENCHAR | ENDCHAR | NLCHAR ;SYMBOL = 'j' | '&' | '`' | '^' | '_' | ')' | ',' | ':' | '8' | '9'| '�' | '=' | '=' | '2' | ':' | '; ' | ';' | ':' | '�'| 'n' | '�' | 'o9' | '>>' | '+'| any characters of the mathematical toolkit not included above (as supported)| any other ISO/IEC 10646 characters not included above (as supported);18 c ISO/IEC 2000|All rights reserved

6 Z characters ISO/IEC 13568:2000(E)6.3 Additional restrictions and notesThe word supported means available for use in presenting a speci�cation.The characters enumerated in the formal de�nition are those used by the core language; they shall be supported.If the mathematical toolkit is supported, then its characters shall be supported. The \other ISO/IEC 10646characters" may also be supported, extending DIGIT, LETTER or SYMBOL according to their property, but notextending SPECIAL. Use of characters that are absent from ISO/IEC 10646 is permitted, but there is no standardway of distinguishing which of DIGIT, LETTER or SYMBOL (not SPECIAL) they extend, and speci�cations usingthem might not be interchangeable between tools.SPACE is a Z character that serves to separate two sequences of Z characters that would otherwise be mis-lexedas a single token.NOTE 1 STROKECHAR characters are used in STROKE tokens in the lexis.NOTE 2 WORDGLUE characters are used in building NAME tokens in the lexis.NOTE 3 BOXCHAR characters correspond to Z's distinctive boxes around paragraphs.6.4 Z character representations6.4.1 IntroductionThe following tables show the Z characters in their mathematical representation. (Other representations are givenin annex A.) The columns give:Math: The representation for rendering the character on a high resolution device, such as a bit-mappedscreen, or on paper (either hand-written, or printed).Code position: The encoding of the Z character in ISO/IEC 10646. Encodings that are enclosed in bracketsare ones that have been assigned by the Unicode Technical Committee to appear in a future version of theirstandard [5], but which are not yet known to have been adopted into ISO/IEC 10646.Character name: The name for the character in ISO/IEC 10646 or, in the case of characters with bracketedcode positions, the name suggested by the Unicode Technical Committee.NOTE 1 The code position column is included to assist location of the characters by many users; it is not necessaryfor de�nition of the characters.NOTE 2 From the point of view of conformance, only those Z characters with code positions already registered inISO/IEC 10646 are relevant. When the other Z characters are adopted into ISO/IEC 10646, a Technical Corrigendumto the present standard will be issued.6.4.2 Digit charactersMath Code position Character name0 0000 0030 DIGIT ZERO... ... ...9 0000 0039 DIGIT NINEc ISO/IEC 2000|All rights reserved 19

ISO/IEC 13568:2000(E) 6 Z characters6.4.3 Letter characters6.4.3.1 Latin alphabet charactersMath Code position Character nameA 0000 0041 LATIN CAPITAL LETTER A... ... ...Z 0000 005A LATIN CAPITAL LETTER Za 0000 0061 LATIN SMALL LETTER A... ... ...z 0000 007A LATIN SMALL LETTER Z6.4.3.2 Greek alphabet charactersThe Greek alphabet characters used by the core language are those listed here.Math Code position Character name� 0000 0394 GREEK CAPITAL LETTER DELTA� 0000 039E GREEK CAPITAL LETTER XI� 0000 03B8 GREEK SMALL LETTER THETA� 0000 03BB GREEK SMALL LETTER LAMBDA� 0000 03BC GREEK SMALL LETTER MU6.4.3.3 Other Z core language letter charactersThe other Z core language characters with the ISO/IEC 10646 `letter' property are listed here. (These charactersare introduced in the prelude, clause 11.)Math Code position Character nameA [0001 D538] MATH OPEN-FACE CAPITAL AN 0000 2115 DOUBLE-STRUCK CAPITAL NP 0000 2119 DOUBLE-STRUCK CAPITAL P6.4.4 Special characters6.4.4.1 Stroke charactersMath Code position Character name0 0000 02B9 MODIFIER LETTER PRIME! 0000 0021 EXCLAMATION MARK? 0000 003F QUESTION MARK6.4.4.2 Word glue charactersThe characters '%', '.', '&', and '-' may be presented as in-line literals, or they may indicate a rais-ing/lowering of the text, and possible size change. Such rendering details are not de�ned here.Math Code position Character name% 0000 2197 NORTH EAST ARROW. 0000 2199 SOUTH WEST ARROW& 0000 2198 SOUTH EAST ARROW- 0000 2196 NORTH WEST ARROW0000 005F LOW LINE20 c ISO/IEC 2000|All rights reserved

6 Z characters ISO/IEC 13568:2000(E)6.4.4.3 Bracket charactersMath Code position Character name( 0000 0028 LEFT PARENTHESIS) 0000 0029 RIGHT PARENTHESIS[ 0000 005B LEFT SQUARE BRACKET] 0000 005D RIGHT SQUARE BRACKETf 0000 007B LEFT CURLY BRACKETg 0000 007D RIGHT CURLY BRACKEThj [0000 2989] Z NOTATION LEFT BINDING BRACKETji [0000 298A] Z NOTATION RIGHT BINDING BRACKEThh 0000 300A LEFT DOUBLE ANGLE BRACKETii 0000 300B RIGHT DOUBLE ANGLE BRACKET6.4.4.4 Box charactersThe ENDCHAR character is used to mark the end of a Paragraph. The NLCHAR character is used to mark a hardnewline (see section 7.5). The box rendering of the BOXCHAR characters is as lines drawn around the Z text (seesection 8.5).Z character Simple rendering Code position Character nameAXCHAR j 0000 2577 BOX DRAWINGS LIGHT DOWNSCHCHAR p 0000 250C BOX DRAWINGS LIGHT DOWN AND RIGHTGENCHAR = 0000 2550 BOX DRAWINGS DOUBLE HORIZONTALENDCHAR (new line) 0000 2029 PARAGRAPH SEPARATORNLCHAR (new line) 0000 2028 LINE SEPARATOR6.4.4.5 SPACE characterZ character Code position Character nameSPACE 0000 0020 SPACE

c ISO/IEC 2000|All rights reserved 21

ISO/IEC 13568:2000(E) 6 Z characters6.4.5 Symbol characters except mathematical toolkit charactersMath Code position Character namej 0000 007C VERTICAL LINE& 0000 0026 AMPERSAND` 0000 22A2 RIGHT TACK^ 0000 2227 LOGICAL AND_ 0000 2228 LOGICAL OR) 0000 21D2 RIGHTWARDS DOUBLE ARROW, 0000 21D4 LEFT RIGHT DOUBLE ARROW: 0000 00AC NOT SIGN8 0000 2200 FOR ALL9 0000 2203 THERE EXISTS� 0000 00D7 MULTIPLICATION SIGN= 0000 002F SOLIDUS= 0000 003D EQUALS SIGN2 0000 2208 ELEMENT OF: 0000 003A COLON; 0000 003B SEMICOLON; 0000 002C COMMA: 0000 002E FULL STOP� [0000 2981] Z NOTATION SPOTn [0000 2055] BIG REVERSE SOLIDUS� [0000 2A21] Z NOTATION SCHEMA PROJECTIONo9 [0000 2A1F] Z NOTATION SCHEMA COMPOSITION>> [0000 2A20] Z NOTATION SCHEMA PIPING+ 0000 002B PLUS SIGNoo [0000 2982] Z NOTATION TYPE COLON6.4.6 Mathematical toolkit charactersThe mathematical toolkit (annex B) need not be supported by an implementation. If it is supported, it shall usethe representations given here.Mathematical toolkit names that use only Z core language characters, or combinations of Z characters de�nedhere, are not themselves listed here.

22 c ISO/IEC 2000|All rights reserved

6 Z characters ISO/IEC 13568:2000(E)Math Code position Character name$ 0000 2194 LEFT RIGHT ARROW! 0000 2192 RIGHTWARDS ARROW6= 0000 2260 NOT EQUAL TO62 0000 2209 NOT AN ELEMENT OF? 0000 2205 EMPTY SET� 0000 2286 SUBSET OF OR EQUAL TO� 0000 2282 SUBSET OF[ 0000 222A UNION\ 0000 2229 INTERSECTIONn 0000 005C REVERSE SOLIDUS 0000 2296 CIRCLED MINUSS 0000 22C3 N-ARY UNIONT 0000 22C2 N-ARY INTERSECTIONF [0001 D53D] MATH OPEN-FACE CAPITAL F7! 0000 21A6 RIGHTWARDS ARROW FROM BARo9 [0000 2A3E] Z NOTATION RELATIONAL COMPOSITION� 0000 2218 RING OPERATORC 0000 25C1 WHITE LEFT-POINTING TRIANGLEB 0000 25B7 WHITE RIGHT-POINTING TRIANGLE�C [0000 2A64] Z NOTATION DOMAIN ANTIRESTRICTION�B [0000 2A65] Z NOTATION RANGE ANTIRESTRICTION� 0000 007E TILDE(j [0000 2987] Z NOTATION LEFT IMAGE BRACKETj) [0000 2988] Z NOTATION RIGHT IMAGE BRACKET� 0000 2295 CIRCLED PLUS7! [0000 21F8] RIGHTWARDS ARROW WITH VERTICAL STROKE7� [0000 2914] RIGHTWARDS ARROW WITH TAIL WITH VERTICAL STROKE� 0000 21A3 RIGHTWARDS ARROW WITH TAIL7!! [0000 2900] RIGHTWARDS TWO-HEADED ARROW WITH VERTICAL STROKE!! 0000 21A0 RIGHTWARDS TWO-HEADED ARROW�! [0000 2916] RIGHTWARDS TWO-HEADED ARROW WITH TAIL7 7! [0000 21FB] RIGHTWARDS ARROW WITH DOUBLE VERTICAL STROKE7 7� [0000 2915] RIGHTWARDS ARROW WITH TAIL WITH DOUBLE VERTICAL STROKEZ 0000 2124 DOUBLE-STRUCK CAPITAL Z- 0000 002D HYPHEN-MINUS� 0000 2212 MINUS SIGN� 0000 2264 LESS-THAN OR EQUAL TO< 0000 003C LESS-THAN SIGN� 0000 2265 GREATER-THAN OR EQUAL TO> 0000 003E GREATER-THAN SIGN# 0000 0023 NUMBER SIGNh 0000 2329 LEFT-POINTING ANGLE BRACKETi 0000 232A RIGHT-POINTING ANGLE BRACKETa 0000 2040 CHARACTER TIE� 0000 21BF UPWARDS HARPOON WITH BARB LEFTWARDS� 0000 21BE UPWARDS HARPOON WITH BARB RIGHTWARDS6.4.7 Renderings of Z charactersRenderings of Z characters are called glyphs (following the terminology of ISO/IEC 10646). A rendering of a Zcharacter on a graphics screen is typically di�erent from its rendering on a piece of paper: the glyphs used for Zcharacters are device-dependent.c ISO/IEC 2000|All rights reserved 23

ISO/IEC 13568:2000(E) 7 LexisA Z character may also be rendered using di�erent glyphs at di�erent places in a speci�cation, for reasons ofemphasis or aesthetics, but such di�erent glyphs still represent the same Z character. For example, `d ', `d', `d'and `d' are all the same Z character.For historical reasons, some di�erent Z characters have similar-looking renderings. In particular:� schema composition `o9' and the mathematical toolkit character relational composition `o9' are di�erent Zcharacters;� schema projection `�' and the mathematical toolkit character �lter `�' are di�erent Z characters;� schema hiding `n' and the mathematical toolkit character set minus `n' are di�erent Z characters.7 Lexis7.1 IntroductionThe lexis speci�es a function from sequences of Z characters to sequences of tokens. The domain of the functioninvolves all the Z characters of clause 6. The range of the function involves all the tokens used in clause 8. Thefunction is partial: sequences of Z characters that do not conform to the lexis are excluded from consideration atthis stage.The lexis is composed of two parts: a context-free part followed by a context-sensitive part. The former translatesthe stream of Z characters into a stream of DECORWORDs and tokens. The latter classi�es each DECORWORD as beinga keyword, an operator token, or a NAME token, taking into account the lexical scopes of the operators (see 7.4.4).7.2 Formal de�nition of context-free lexisTOKENSTREAM = { SPACE } , { TOKEN , { SPACE } } ;TOKEN = DECORWORD | NUMERAL | STROKE| (-tok | )-tok | [-tok | ]-tok | f-tok | g-tok | hj | ji | hh | ii| AX | GENAX | SCH | GENSCH | END | NL;DECORWORD = WORD , { STROKE } ;WORD = WORDPART , { WORDPART }| LETTER , ALPHASTR , { WORDPART }| SYMBOL , SYMBOLSTR , { WORDPART };WORDPART = WORDGLUE , ( ALPHASTR | SYMBOLSTR ) ;ALPHASTR = { LETTER | DIGIT } ;SYMBOLSTR = { SYMBOL } ;NUMERAL = NUMERAL , DIGIT| DIGIT;STROKE = STROKECHAR| '&' , DIGIT , '-';24 c ISO/IEC 2000|All rights reserved

7 Lexis ISO/IEC 13568:2000(E)(-tok = '(' ;)-tok = ')' ;[-tok = '[' ;]-tok = ']' ;f-tok = 'f' ;g-tok = 'g' ;hj = 'hj' ;ji = 'ji' ;hh = 'hh' ;ii = 'ii' ;AX = AXCHAR ;SCH = SCHCHAR ;GENAX = AXCHAR , GENCHAR ;GENSCH = SCHCHAR , GENCHAR ;END = ENDCHAR ;NL = NLCHAR ;7.3 Additional lexical restrictions, notes and examplesSPACE is not itself lexed as part of any token. It can be used freely between tokens. The cases where its use isnecessary are: between two WORDs, which would otherwise be lexed as a single WORD; between an alphabetic WORDand a NUMERAL, which would otherwise be lexed as a single WORD; between a DECORWORD and a STROKE (a decorationexpression), which would otherwise be lexed as a single DECORWORD; and between two consecutive NUMERALs, whichwould otherwise be lexed as a single NUMERAL.Words are formed from alphanumeric and symbolic parts.EXAMPLE 1 The following strings of Z characters are single DECORWORDs: `&+=', `x + y ', `x+y ', `x+y ', `x++y '.However, `x+y ' comprises the three DECORWORDs `x ', `+' and `y '.EXAMPLE 2 The following strings of Z characters are single DECORWORDs: `�S ', `�S ', `9�', `9 X ', `9X '. However,`9X ' is the keyword token `9', followed by the DECORWORD `X '.EXAMPLE 3 The following strings of Z characters are single DECORWORDs: `�:2', `x : e', `x :e '. However, `x :e' is theword `x ', followed by the keyword token `:', followed by the DECORWORD `e'.The concrete syntax allows a RefName, which may be a NAME that includes strokes; it also allows an expressionto be decorated with a stroke. When the decorated expression is a NAME, the lexis disambiguates the two casesby using the white space between the DECORWORD and the STROKE: in the absence of any white space, the strokeshall be lexed as part of the DECORWORD; in the presence of white space, the stroke shall be lexed as a decorationon the expression.EXAMPLE 4 x ! is the DECORWORD comprising the WORD `x ' followed by the STROKE `!'.x ! is the decorated expression comprising the RefName expression `x ' decorated with the STROKE `!'.x ! ! is the decorated expression comprising the RefName expression `x !' decorated with the STROKE `!'.The lexis allows a WORD to include subscript digits; it also allows a DECORWORD to be decorated with subscriptdigits. Trailing subscript digits shall be lexed as strokes, not as part of a WORD.EXAMPLE 5 xa1 is a DECORWORD comprising the WORD `xa ' and the STROKE `1'.xa? is a DECORWORD comprising the WORD `xa ' and the STROKE `?'.x1a is a DECORWORD comprising the WORD `x1a ' and no strokes.A multi-digit last WORDPART enclosed in a & . . .- pair is deprecated, because of the visual ambiguity withmultiple STROKE subscript digits.NOTE 1 There is no need for any particular mark-up to follow these rules; this syntax applies only to tokens builtfrom Z characters.c ISO/IEC 2000|All rights reserved 25

ISO/IEC 13568:2000(E) 7 LexisNOTE 2 Although a parser does not need to know the spelling of particular instances of DECORWORD, NUMERAL,STROKE, etc tokens, subsequent phases of processing such as typechecking do. This relation between instances oftokens and spellings is not explicitly formalized here.Some tools may impose restrictions on the forms of some names. Section names that are entirely alphanumeric,capitalized and short are the most likely to be portable between tools.7.4 Context-sensitive lexis7.4.1 IntroductionThe context-sensitive part of lexis maps each DECORWORD to either a keyword token, an operator token, or a NAMEtoken. It also strips all SPACEs from the token stream, and forwards all other tokens unchanged.If a DECORWORD's spelling is exactly that of a keyword, the DECORWORD is mapped to the corresponding keywordtoken. Otherwise, if the DECORWORD's WORD part's spelling is that of an operator word, the DECORWORD is mappedto the relevant operator token. Otherwise, the DECORWORD is mapped to a NAME token.In the case of a NAME token, for every '&' WORDGLUE character in its WORD part, there shall be a paired following'-' WORDGLUE character, for every '%' WORDGLUE character in its WORD part, there shall be a paired following'.' WORDGLUE character, and these shall occur only in nested pairs.NOTE 1 Operators have a similar restriction applied to the whole operator name (12.2.8), not to the individualwords within the operator.The keywords are as listed in the following tables. No other spellings give rise to keyword tokens. The columnsgive:Spelling: The sequence of Z characters representing the rendering of the token on a high resolution device,such as a bit-mapped screen, or on paper (either hand-written, or printed).Token: The token used for that keyword in the concrete syntax.Token name: A suggested form for reading the keyword out loud, suitable for use in reviews, or for dis-cussing speci�cations over the telephone. In the following, an English language form is given; for othernatural languages, other forms may be de�ned.NOTE 2 Even where a keyword consists of a single Z character, the token name tends to re ect the keyword'sfunction rather than the form of the Z character.

26 c ISO/IEC 2000|All rights reserved

7 Lexis ISO/IEC 13568:2000(E)7.4.2 Alphabetic keywordsSpelling Token Token nameelse else elsefalse false falsefunction function functiongeneric generic genericif if ifleftassoc leftassoc left [associative]let let letP P powersetparents parents parentspre pre pre[condition]relation relation relationrightassoc rightassoc right [associative]section section sectionthen then thentrue true true7.4.3 Symbolic keywordsSpelling Token Token name: : colon== == de�ne equal; ;-tok comma::= ::= free equalsj j-tok bar& & and also [free types]n n hide= = rename: : select j dot; ; -tok semi[colon]arg[ument]; ; ; ; list arg[ument]= =-tok equalsEXAMPLE 1 = is recognised as the keyword token =-tok; := is recognised as a NAME token; ::= is recognised as thekeyword token.

c ISO/IEC 2000|All rights reserved 27

ISO/IEC 13568:2000(E) 7 LexisSpelling Token Token name`? `? conjecture8 8 for all� � spot j fat dot9 9 exists91 91 unique exists, , equivalent j if and only if) ) implies_ _ or^ ^ and: : not2 2 in j member of j element of� � project� � cross� � lambda� � mu� � thetao9 o9 schema compose>> >> schema pipeEXAMPLE 2 9 and 91 (`9', `&', `1', `-') are recognised as keyword tokens; 90 (`9', `&', `0', `-') is recognised asa NAME token.EXAMPLE 3 � is recognised as the keyword token; �x is recognised as a NAME token; � x is recognised as thekeyword token followed by a NAME token.7.4.4 User-de�ned operatorsEach operator template creates additional keyword-like associations between WORDs and operator tokens. Thescope of these associations is the whole of the section in which the operator template appears (not just fromthe operator template onwards), as well as all sections of which that section is an ancestor, excluding sectionheaders.NOTE The set of active associations is always a function. This International Standard does not specify how thatfunction is determined: operator template paragraphs provide the information, yet in their concrete syntax it isassumed that the function is already known.The appropriate token for an operator word is as follows.

28 c ISO/IEC 2000|All rights reserved

7 Lexis ISO/IEC 13568:2000(E)PREP pre�x unary relationPRE pre�x unary function or genericPOSTP post�x unary relationPOST post�x unary function or genericIP in�x binary relationI in�x binary function or genericLP left bracket of non-unary relationL left bracket of non-unary function or genericELP �rst word preceded by expression of non-unary relationEL �rst word preceded by expression of non-unary function or genericERP right bracket preceded by expression of non-unary relationER right bracket preceded by expression of non-unary function or genericSRP right bracket preceded by list argument of non-unary relationSR right bracket preceded by list argument of non-unary function or genericEREP last word followed by expression and preceded by expression of tertiary or higher relationERE last word followed by expression and preceded by expression of tertiary or higher function or genericSREP last word followed by expression and preceded by list argument of tertiary or higher relationSRE last word followed by expression and preceded by list argument of tertiary or higher function or genericES middle word preceded by expression of non-unary operatorSS middle word preceded by list argument of non-unary operatorEXAMPLE 1 The operator template paragraph for the ( + ) operator adds one entry to the mapping.Spelling Token+ IEXAMPLE 2 The operator template paragraph for the ( (j j)) operator adds two entries to the mapping.Spelling Token(j ELj) EREXAMPLE 3 The operator template paragraph for the (disjoint ) operator adds one entry to the mapping.Spelling Tokendisjoint PREPEXAMPLE 4 The operator template paragraph for the (h i) operator adds two entries to the mapping.Spelling Tokenh Li SR7.5 NewlinesThe Z character NLCHAR is lexed either as a token separator (like the SPACE character) or as the token NL,depending on its context. A soft newline is a NLCHAR that is lexed as a token separator. A hard newline is aNLCHAR that is lexed as a NL token.Tokens are assigned to a newline category, namely BOTH, AFTER, BEFORE or NEITHER, based on whetherthat token could start or end a Z phrase.c ISO/IEC 2000|All rights reserved 29

ISO/IEC 13568:2000(E) 8 Concrete syntax� BOTH: newlines are soft before and after the token, because it is in�x, something else has to appear beforeit and after it.else function generic leftassoc parents relation rightassoc section then::= j-tok hh ii & `? ; ; ^ _ ) , � = =-tok 2 == : ; -tok ;-tok : � n � o9 >>I IP EL ELP ERE EREP ES SS SRE SREPAll newlines are soft outside of a DeclPart or a Predicate.NOTE Tokens that cannot appear in these contexts are in category BOTH. This includes the box tokens.Newlines at the very beginning or end of a speci�cation are soft.� AFTER: newlines are soft after the token, because it is pre�x, something else has to appear after it.if let pre[�tok : 8 9 91 P (�tok f�tok hj � � �PRE PREP L LP� BEFORE: newlines are soft before the token, because it is post�x, something else has to appear before it.]�tok )�tok g�tok jiPOST POSTP ER ERP SR SRP� NEITHER: no newlines are soft, because such a token is no�x, nothing else need appear before or after it.false trueNAME NUMERAL STROKEFor each NLCHAR, the newline categories of the closest token generated from the preceding Z characters and thetoken generated from the immediately following Z characters are examined. If either token allows the newline tobe soft in that position, it is soft, otherwise it is hard (and hence recognised as a NL token).The operator template paragraph allows the de�nition of various mix�x names (see section 7.4.4), which areplaced in the appropriate newline category. Other (ordinary) user declared names are no�x, and so are placed inNEITHER.Consecutive NLCHARs are treated the same as a single NLCHAR.8 Concrete syntax8.1 IntroductionThe concrete syntax de�nes the syntax of the Z language: every sentence of the Z language is recognised bythis syntax, and all sentences recognised by this syntax are sentences of the Z language. The concrete syntaxis written in terms of the tokens generated by the lexis (clause 7). There are no terminal symbols within thissyntax, so as to establish a formal connection with that lexis. Sequences of tokens that are not recognised by thissyntax are not sentences of the Z language and are thus excluded from consideration by subsequent phases andso are not given a semantics by this International Standard.A parser conforming to this concrete syntax converts a concrete sentence to a parse tree.The non-terminal symbols of the concrete syntax that are written as mathematical symbols or are entirelyCAPITALIZED or Roman are Z tokens de�ned in the lexis (claue 7). The other non-terminal symbols are writtenin MixedCase and are de�ned within the concrete syntax.30 c ISO/IEC 2000|All rights reserved

8 Concrete syntax ISO/IEC 13568:2000(E)8.2 Formal de�nition of concrete syntaxSpecification = { Section } (* sectioned speci�cation *)| { Paragraph } (* anonymous speci�cation *);Section = section , NAME , parents , [ NAME , { ;-tok , NAME } ] , END ,{ Paragraph } (* inheriting section *)| section , NAME , END , { Paragraph } (* base section *);Paragraph = [-tok , NAME , { ;-tok , NAME } , ]-tok , END (* given types *)| AX , SchemaText , END (* axiomatic description *)| SCH , NAME , SchemaText , END (* schema de�nition *)| GENAX , [-tok , Formals , ]-tok , SchemaText , END(* generic axiomatic description *)| GENSCH , NAME , [-tok , Formals , ]-tok , SchemaText , END(* generic schema de�nition *)| DeclName , == , Expression , END (* horizontal de�nition *)| NAME , [-tok , Formals , ]-tok , == , Expression , END(* generic horizontal de�nition *)| GenName , == , Expression , END (* generic operator de�nition *)| Freetype , { & , Freetype } , END (* free types *)| `? , Predicate , END (* conjecture *)| [-tok , Formals , ]-tok , `? , Predicate , END (* generic conjecture *)| OperatorTemplate , END (* operator template *);Freetype = NAME , ::= , Branch , { j-tok , Branch } ; (* free type *)Branch = DeclName , [ hh , Expression , ii ] ; (* element or injection *)Formals = NAME , { ;-tok , NAME } ; (* generic parameters *)Predicate = Predicate , NL , Predicate (* newline conjunction *)| Predicate , ; -tok , Predicate (* semicolon conjunction *)| 8 , SchemaText , � , Predicate (* universal quanti�cation *)| 9 , SchemaText , � , Predicate (* existential quanti�cation *)| 91 , SchemaText , � , Predicate (* unique existential quanti�cation *)| Predicate , , , Predicate (* equivalence *)| Predicate , ) , Predicate (* implication *)| Predicate , _ , Predicate (* disjunction *)| Predicate , ^ , Predicate (* conjunction *)| : , Predicate (* negation *)| Relation (* relation operator application *)| Expression (* schema predicate *)| true (* truth *)| false (* falsity *)| (-tok , Predicate , )-tok (* parenthesized predicate *);c ISO/IEC 2000|All rights reserved 31

ISO/IEC 13568:2000(E) 8 Concrete syntaxExpression = 8 , SchemaText , � , Expression (* schema universal quanti�cation *)| 9 , SchemaText , � , Expression (* schema existential quanti�cation *)| 91 , SchemaText , � , Expression (* schema unique existential quanti�cation *)| � , SchemaText , � , Expression (* function construction *)| � , SchemaText , � , Expression (* de�nite description *)| let , DeclName , == , Expression{ ; -tok , DeclName , == , Expression }, � , Expression (* substitution expression *)| Expression , , , Expression (* schema equivalence *)| Expression , ) , Expression (* schema implication *)| Expression , _ , Expression (* schema disjunction *)| Expression , ^ , Expression (* schema conjunction *)| : , Expression (* schema negation *)| if , Predicate , then , Expression , else , Expression (* conditional *)| Expression , o9 , Expression (* schema composition *)| Expression , >> , Expression (* schema piping *)| Expression , n , (-tok , DeclName , { ;-tok , DeclName } , )-tok(* schema hiding *)| Expression , � , Expression (* schema projection *)| pre , Expression (* schema precondition *)| Expression , � , Expression , { � , Expression } (* Cartesian product *)| P , Expression (* powerset *)| Application (* function and generic operator application *)| Expression , Expression (* application *)| Expression , STROKE (* schema decoration *)| Expression , [-tok , DeclName , = , DeclName ,{ ;-tok , DeclName , = , DeclName } , ]-tok (* schema renaming *)| Expression , : , RefName (* binding selection *)| Expression , : , NUMERAL (* tuple selection *)| � , Expression , { STROKE } (* binding construction *)| RefName (* reference *)| RefName , [-tok , Expression , { ;-tok , Expression } , ]-tok(* generic instantiation *)| NUMERAL (* number literal *)| f-tok , [ Expression , { ;-tok , Expression } ] , g-tok (* set extension *)| f-tok , SchemaText , � , Expression , g-tok (* set comprehension *)| ( ( f-tok , SchemaText , g-tok ) | ( f-tok , g-tok ) )| ( f-tok , Expression , g-tok )(* characteristic set comprehension *)| ( [-tok , SchemaText , ]-tok ) | ( [-tok , Expression , ]-tok )(* schema construction *)| hj , [ DeclName , == , Expression ,{ ;-tok , DeclName , == , Expression } ] , ji (* binding extension *)| (-tok , Expression , ;-tok , Expression , { ;-tok , Expression } , )-tok(* tuple extension *)| (-tok , � , SchemaText , )-tok (* characteristic de�nite description *)| (-tok , Expression , )-tok (* parenthesized expression *);SchemaText = [ DeclPart ] , [ j-tok , Predicate ] ;DeclPart = Declaration , { ( ; -tok | NL ) , Declaration } ;32 c ISO/IEC 2000|All rights reserved

8 Concrete syntax ISO/IEC 13568:2000(E)Declaration = DeclName , { ;-tok , DeclName } , : , Expression| DeclName , == , Expression| Expression;OperatorTemplate = relation , Template| function , CategoryTemplate| generic , CategoryTemplate;CategoryTemplate = Prec , PrefixTemplate| Prec , PostfixTemplate| Prec , Assoc , InfixTemplate| NofixTemplate;Prec = NUMERAL ;Assoc = leftassoc| rightassoc;Template = PrefixTemplate| PostfixTemplate| InfixTemplate| NofixTemplate;PrefixTemplate = (-tok , PrefixName , )-tok| (-tok , P , , )-tok;PostfixTemplate = (-tok , PostfixName , )-tok ;InfixTemplate = (-tok , InfixName , )-tok ;NofixTemplate = (-tok , NofixName , )-tok ;DeclName = NAME| OpName;RefName = NAME| (-tok , OpName , )-tok;OpName = PrefixName| PostfixName| InfixName| NofixName;PrefixName = PRE ,| PREP ,| L , { , ES | ; ; , SS } , ( , ERE | ; ; , SRE ) ,| LP , { , ES | ; ; , SS } , ( , EREP | ; ; , SREP ) ,;c ISO/IEC 2000|All rights reserved 33

ISO/IEC 13568:2000(E) 8 Concrete syntaxPostfixName = , POST| , POSTP| , EL , { , ES | ; ; , SS } , ( , ER | ; ; , SR )| , ELP , { , ES | ; ; , SS } , ( , ERP | ; ; , SRP );InfixName = , I ,| , IP ,| , EL , { , ES | ; ; , SS } , ( , ERE | ; ; , SRE ) ,| , ELP , { , ES | ; ; , SS } , ( , EREP | ; ; , SREP ) ,;NofixName = L , { , ES | ; ; , SS } , ( , ER | ; ; , SR )| LP , { , ES | ; ; , SS } , ( , ERP | ; ; , SRP );GenName = PrefixGenName| PostfixGenName| InfixGenName| NofixGenName;PrefixGenName = PRE , NAME| L , { NAME , ( ES | SS ) } , NAME , ( ERE | SRE ) , NAME;PostfixGenName = NAME , POST| NAME , EL , { NAME , ( ES | SS ) } , NAME , ( ER | SR );InfixGenName = NAME , I , NAME| NAME , EL , { NAME , ( ES | SS ) } , NAME , ( ERE | SRE ) , NAME;NofixGenName = L , { NAME , ( ES | SS ) } , NAME , ( ER | SR ) ;Relation = PrefixRel| PostfixRel| InfixRel| NofixRel;PrefixRel = PREP , Expression| LP , ExpSep , ( Expression , EREP | ExpressionList , SREP ) , Expression;PostfixRel = Expression , POSTP| Expression , ELP , ExpSep , ( Expression , ERP | ExpressionList , SRP );InfixRel = Expression , ( 2 | =-tok | IP ) , Expression{ ( 2 | =-tok | IP ) , Expression }| Expression , ELP , ExpSep ,( Expression , EREP | ExpressionList , SREP ) , Expression;NofixRel = LP , ExpSep , ( Expression , ERP | ExpressionList , SRP ) ;34 c ISO/IEC 2000|All rights reserved

8 Concrete syntax ISO/IEC 13568:2000(E)Application = PrefixApp| PostfixApp| InfixApp| NofixApp;PrefixApp = PRE , Expression| L , ExpSep , ( Expression , ERE | ExpressionList , SRE ) , Expression;PostfixApp = Expression , POST| Expression , EL , ExpSep , ( Expression , ER | ExpressionList , SR );InfixApp = Expression , I , Expression| Expression , EL , ExpSep ,( Expression , ERE | ExpressionList , SRE ) , Expression;NofixApp = L , ExpSep , ( Expression , ER | ExpressionList , SR ) ;ExpSep = { Expression , ES | ExpressionList , SS } ;ExpressionList = [ Expression , { ;-tok , Expression } ] ;8.3 Operator precedences and associativitiesTable 29 de�nes the relative precedences of the productions of Expression and Predicate. The rows in the tableare ordered so that the entries with higher precedence (and so that bind more strongly) appear nearer the top of thetable than those with lower precedence (that bind more weakly). Associativity has signi�cance only in determiningthe nesting of applications involving non-associative operators of the same precedence. Explicitly-de�ned functionand generic operator applications have a range of precedences speci�ed numerically in the corresponding operatortemplate paragraph. Cartesian product expressions have precedence value 8 and powerset expressions haveprecedence value 80 within that numeric range.8.4 Additional syntactic restrictions and notesAll pre�x operators are right associative. All post�x operators are left associative. Di�erent associativities shallnot be used at the same precedence level by operator template paragraphs in the same scope.STROKE is used in three contexts: within NAMEs, in binding construction expressions, and in schema decorationexpressions. The condition for a STROKE to be considered as part of a NAME was given in 7.3. Other STROKEs areconsidered to be parts of binding construction expressions if they can be when interpreted from left to right. Theschema decoration expression interpretation is considered last.EXAMPLE 1 In �S 0 0 0, the �rst 0 is part of the NAME S 0, the second 0 can be part of the binding constructionexpression, and the third 0 is syntactically part of a schema decoration expression, though that will be rejected bythe type inference rules as only schemas can be decorated, not bindings.A predicate can be just an expression, yet the same logical operators (^, _, : , ), ,, 8 , 9 , 91 ) can be usedin both expressions and predicates. Where a predicate is expected, and one of these logical operators is used onexpressions, there is an ambiguity: either the whole logical operation is an expression and that expression is usedas a predicate, or the whole logical operation is a predicate involving expressions each used as a predicate. Thisambiguity is benign, as both interpretations have the same precedence, associativity and meaning.The NUMERAL in a tuple selection expression is interpreted in decimal (base ten). That the number is in theappropriate range is checked by the relevant type inference rule (13.2.6.7). Leading zeroes shall be accepted andignored.c ISO/IEC 2000|All rights reserved 35

ISO/IEC 13568:2000(E) 8 Concrete syntaxTable 29 { Operator precedences and associativitiesProductions Associativitybinding constructionbinding selection, tuple selectionschema renamingschema decorationapplication leftCartesian product, powerset, function and generic operator applicationschema preconditionschema projection leftschema hidingschema pipingschema compositionconditionalsubstitution expressionde�nite descriptionfunction constructionrelation operator applicationnegationconjunctiondisjunctionimplication rightequivalenceuniversal, existential and unique existential quanti�cationsnewline conjunction, semicolon conjunctionA section header shall be parsed in its entirety before bringing the declarations and operator templates of itsparent sections into scope.NOTE 1 This prevents surprises when the name of a parent section is the same as the name of an operator de�nedin another parent.In the Template rule's auxiliaries, the name of each of the operator tokens shall not have any STROKEs.NOTE 2 This is so that any common decoration of those words can be treated as an application of a decoratedinstance of that operator.NOTE 3 The order of productions in the Predicate and Expression rules is based roughly on the precedences oftheir operators. Some productions have the same precedence as their neighbours, and so the separate table of operatorprecedences is necessary.NOTE 4 One way of parsing nested operator applications at di�erent user-de�ned levels of precedence and asso-ciativity is explained by Lalonde and des Rivieres [8]. Using distinct variants of the operator tokens PREj:::jSS forrelational operators from those for function and generic operators allows that transformation to avoid dealing withthose notations whose precedences lie between the relations and the functions, such as the schema operations.NOTE 5 The juxtaposition of two expressions e1e2 is always parsed as the application of function e1 to argumente2, never as the application of relation e1 to argument e2 which in some previous dialects of Z, e.g. King et al [7],was equivalent to the relation e2 2 e1. In Standard Z, membership is the normal form of all relational predicates (see12.2.10), and juxtaposition is the normal form (canonical representation) of all application expressions (see 12.2.11).NOTE 6 In the PrefixTemplate rule, the production for powerset enables explicit de�nition of P1 in the mathe-matical toolkit to coexist with the treatment of P as a keyword by the lexis.NOTE 7 The syntax of conjectures is deliberately simple. This is so as to be compatible with the syntaxes ofsequents as found in as many di�erent theorem provers as possible, while establishing a common form to enable36 c ISO/IEC 2000|All rights reserved

8 Concrete syntax ISO/IEC 13568:2000(E)interchange.NOTE 8 Implementations of parsers commonly inspect the next token from the input stream and have to decidethere and then whether that token is another token in an incomplete phrase or whether the current phrase is completeand the token is starting a new phrase. The tokens de�ned by the lexis (clause 7) are insu�cient for such animplementation of a parser.EXAMPLE 2 At the �rst comma in the set extension fx ; y ; zg the x shall be seen to be an expression, yet thephrase might yet turn out to be the set comprehension fx ; y ; z : eg.EXAMPLE 3 At the opening square bracket in the application to a schema construction i [e1; e2] the name ishall be seen to be an expression, yet the phrase might yet turn out to be the generic instantiation i [e1].One solution to such problems is to try all possible parses and accept the one that works. Another solution is tohave the lexer lookahead far enough to be able to distinguish which of the alternative cases is present, and to providethe parser with one of several distinct tokens. Expressions fx ; y ; zg and fx ; y ; z : eg can be distinguished by lookingahead from a comma, over following alternating names (including operator names) and commas, for a : or == token,and using distinct comma tokens depending on whether that is seen or not. Expressions i [e1; e2] and i [e1] can bedistinguished by looking ahead from the open square bracket for the matching closing square bracket, stopping if a; -tok, :, == or j-tok token is encountered, and using distinct open square bracket tokens for the matched and stoppedcases.NOTE 9 An ExpressionList phrase will be regarded as an expression whose value is a sequence (see 12.2.12).In de�ning operators that take such ExpressionLists as arguments, it is convenient to have the operations ofsequence toolkit (see B.8) in scope.NOTE 10 The ExpressionList rule is used only in operator applications, not in set extension, tuple extension andgeneric instantiation expressions, so that syntactic transformation 12.2.12 is applied only to operator applications.8.5 Box renderingsThere are two di�erent sets of box renderings in widespread use, as illustrated here. Any particular presentationof a section shall use one set or the other throughout. The middle line shall be omitted when the paragraph hasno predicates, but otherwise shall be retained if the paragraph has no declarations. The outlines need be only aswide as the text, but are here shown as wide as the page.8.5.1 First box renderingThe following four paragraphs illustrate the �rst of two alternative renderings of box tokens.An axiomatic paragraph, involving the AX, j-tok and END tokens, shall have this box rendering.DeclPartPredicateA schema paragraph, involving the SCH, j-tok and END tokens, shall have this box rendering.NAMEDeclPartPredicateA generic axiomatic paragraph, involving the GENAX, j-tok and END tokens, shall have this box rendering.[Formals]DeclPartPredicatec ISO/IEC 2000|All rights reserved 37

ISO/IEC 13568:2000(E) 9 Characterisation rulesA generic schema paragraph, involving the GENSCH, j-tok and END tokens, shall have this box rendering.NAME [Formals]DeclPartPredicate8.5.2 Second box renderingThe following four paragraphs illustrate the second of two alternative renderings of box tokens.An axiomatic paragraph, involving the AX, j-tok and END tokens, shall have this box rendering.DeclPartPredicateA schema paragraph, involving the SCH, j-tok and END tokens, shall have this box rendering.NAMEDeclPartPredicateA generic axiomatic paragraph, involving the GENAX, j-tok and END tokens, shall have this box rendering.[Formals]DeclPartPredicateA generic schema paragraph, involving the GENSCH, j-tok and END tokens, shall have this box rendering.NAME [Formals]DeclPartPredicate9 Characterisation rules9.1 IntroductionThe characterisation rules together map the parse tree of a concrete syntax sentence to the parse tree of anequivalent concrete syntax sentence in which all implicit characteristic tuples have been made explicit.Only concrete trees that are mapped to di�erent trees are given explicit characterisation rules. The characterisa-tion rules are listed in the same order as the corresponding productions of the concrete syntax.Characteristic tuples are calculated from schema texts by the metalanguage function chartuple (9.2).9.2 Characteristic tupleA characteristic tuple is computed in two phases: charac, which returns a sequence of expressions, and mktuple,which converts that sequence into the characteristic tuple.chartuple t = mktuple (charac t)38 c ISO/IEC 2000|All rights reserved

10 Annotated syntax ISO/IEC 13568:2000(E)Sequences of expressions are enclosed between metalanguage brackets h and i, in general he1; :::; eni. Two se-quences of expressions are concatenated by the a operator.he1; :::; enia hen+1; :::; en+mi = he1; :::; en; en+1; :::; en+miUnlike the mathematical metalanguage of 4.2, the operands of these two notations are not semantic values butparse trees of the concrete syntax.charac (de1; :::; den j p) = charac (de1; :::; den)charac (de1; :::; den) = charac de1 a :::a charac den where n � 1charac () = hhj jiicharac (i1; :::; in : e) = hi1; :::; inicharac (i == e) = hiicharac e � = h� e�imktuple hei = emktuple he1; :::; eni = (e1; :::; en) where n � 2NOTE 1 In the last case of charac, the type inference rule 13.2.6.9 ensures that e is a schema.NOTE 2 Inmktuple, the result is a Z expression, so the brackets in its second equation are those of a tuple extension.9.3 Formal de�nition of characterisation rules9.3.1 Function construction expressionThe value of the function construction expression � t � e is the function associating values of the characteristictuple of t with corresponding values of e.� t � e =) ft � (chartuple t; e)gIt is semantically equivalent to the set of pairs representation of that function.9.3.2 Characteristic set comprehension expressionThe value of the characteristic set comprehension expression ftg is the set of the values of the characteristic tupleof t. ftg =) ft � chartuple tgIt is semantically equivalent to the corresponding set comprehension expression in which the characteristic tupleis made explicit.9.3.3 Characteristic de�nite description expressionThe value of the characteristic de�nite description expression (� t) is the sole value of the characteristic tuple ofschema text t. (� t) =) � t � chartuple tIt is semantically equivalent to the corresponding de�nite description expression in which the characteristic tupleis made explicit.c ISO/IEC 2000|All rights reserved 39

ISO/IEC 13568:2000(E) 10 Annotated syntax10 Annotated syntax10.1 IntroductionThe annotated syntax de�nes a language that includes all sentences that could be produced by application of thesyntactic transformation rules (clause 12) to sentences of the concrete syntax (clause 8). This language's set ofsentences would be a subset of that de�ned by the concrete syntax but for introduction of type annotations anduse of expressions in place of schema texts.Like the concrete syntax, this annotated syntax is written in terms of the tokens generated by the lexis; thereare no terminal symbols within this syntax. Three additional tokens are used besides those de�ned in the lexis:GIVEN, GENTYPE, and oo. An additional character, 1, in included in the STROKECHAR andWORDGLUE classes.It is assumed that 1 is distinct from the characters used in concrete phrases. This restriction ensures that itsuse in forming single names from the constituent words of operators produces results that cannot clash with anyother names. It also ensures that its use as a stroke on inclusion declarations cannot result in any captures ofreferences to other declarations. Further characters � and ~ are included in the STROKECHAR class. They are alsoassumed to be distinct from the characters used in concrete phrases. They are used in de�ning the semantics oftypes, again for the purpose of avoiding variable captures.There are no parentheses in the annotated syntax as de�ned here. A sentence or phrase of the annotatedsyntax should be thought of as a tree structure of nested formulae. When presented as linear text, however, theprecedences of the concrete syntax may be assumed and parentheses may be inserted to override those precedences.The precedence of the type annotation oo operator is then weaker than all other operators, and the precedencesand associativities of the type notations are analogous to those of the concrete notations of similar appearance.NOTE 1 This annotated syntax permits some veri�cation of the syntactic transformation rules to be performed.NOTE 2 The annotated syntax is similar to an abstract syntax used in a tool, but the level of abstraction e�ectedby the characterization rules and syntactic transformation rules might not be appropriate for a tool.10.2 Formal de�nition of annotated syntaxSpecification = { Section } ; (* sectioned speci�cation *)Section = section , NAME , parents , [ NAME , { ;-tok , NAME } ] , END ,{ Paragraph } , [ oo , SectTypeEnv ] ; (* inheriting section *)Paragraph = [-tok , NAME , { ;-tok , NAME } , ]-tok , END ,[ oo , Signature ] (* given types *)| AX , Expression , END ,[ oo , Signature ] (* axiomatic description *)| GENAX , [-tok , NAME , { ;-tok , NAME } , ]-tok , Expression , END ,[ oo , Signature ] (* generic axiomatic description *)| NAME , ::= , NAME , [ hh , Expression , ii ] ,{ j-tok , NAME , [ hh , Expression , ii ] } ,{ & , NAME , ::= , NAME , [ hh , Expression , ii ] ,{ j-tok , NAME , [ hh , Expression , ii ] } } , END ,[ oo , Signature ] (* free types *)| `? , Predicate , END ,[ oo , Signature ] (* conjecture *)| [-tok , NAME , { ;-tok , NAME } , ]-tok , `? , Predicate , END ,[ oo , Signature ] (* generic conjecture *);40 c ISO/IEC 2000|All rights reserved

10 Annotated syntax ISO/IEC 13568:2000(E)Predicate = Expression , 2 , Expression (* membership *)| true (* truth *)| : , Predicate (* negation *)| Predicate , ^ , Predicate (* conjunction *)| 8 , Expression , � , Predicate (* universal quanti�cation *)| 91 , Expression , � , Predicate (* unique existential quanti�cation *);

c ISO/IEC 2000|All rights reserved 41

ISO/IEC 13568:2000(E) 10 Annotated syntaxExpression = NAME ,[ oo , Type ] (* reference *)| NAME , [-tok , Expression , { ;-tok , Expression } , ]-tok ,[ oo , Type ] (* generic instantiation *)| f-tok , [ Expression , { ;-tok , Expression } ] , g-tok ,[ oo , Type ] (* set extension *)| f-tok , Expression , � , Expression , g-tok ,[ oo , Type ] (* set comprehension *)| P , Expression ,[ oo , Type ] (* powerset *)| (-tok , Expression , ;-tok , Expression , { ;-tok , Expression } , )-tok ,[ oo , Type ] (* tuple extension *)| Expression , : , NUMERAL ,[ oo , Type ] (* tuple selection *)| hj , NAME , == , Expression ,{ ;-tok , NAME , == , Expression } , ji ,[ oo , Type ] (* binding extension *)| � , Expression , { STROKE } ,[ oo , Type ] (* binding construction *)| Expression , : , NAME ,[ oo , Type ] (* binding selection *)| Expression , Expression ,[ oo , Type ] (* application *)| � , Expression , � , Expression ,[ oo , Type ] (* de�nite description *)| [-tok , NAME , : , Expression , ]-tok ,[ oo , Type ] (* variable construction *)| [-tok , Expression , j-tok , Predicate , ]-tok ,[ oo , Type ] (* schema construction *)| : , Expression ,[ oo , Type ] (* schema negation *)| Expression , ^ , Expression ,[ oo , Type ] (* schema conjunction *)| Expression , n , (-tok , NAME , { ;-tok , NAME } , )-tok ,[ oo , Type ] (* schema hiding *)| 8 , Expression , � , Expression ,[ oo , Type ] (* schema universal quanti�cation *)| 91 , Expression , � , Expression ,[ oo , Type ] (* schema unique existential quanti�cation *)| Expression , [-tok , NAME , = , NAME ,{ ;-tok , NAME , = , NAME } , ]-tok ,[ oo , Type ] (* schema renaming *)| pre , Expression ,[ oo , Type ] (* schema precondition *)| Expression , o9 , Expression ,[ oo , Type ] (* schema composition *)| Expression , >> , Expression ,[ oo , Type ] (* schema piping *)| Expression , STROKE ,[ oo , Type ] (* schema decoration *);42 c ISO/IEC 2000|All rights reserved

11 Prelude ISO/IEC 13568:2000(E)SectTypeEnv = [ NAME , : , (-tok , NAME , ;-tok , Type , )-tok ,{ ; -tok , NAME , : , (-tok , NAME , ;-tok , Type , )-tok } ] ;Type = GIVEN , NAME (* given type *)| GENTYPE , NAME (* generic parameter type *)| P , Type (* powerset type *)| Type , � , Type , { � , Type } (* Cartesian product type *)| [-tok , Signature , ]-tok (* schema type *)| [-tok , NAME , { ;-tok , NAME } , ]-tok ,Type , [ ;-tok , Type ] (* generic type *)| � , { STROKE } (* variable type *);Signature = [ NAME , : , Type , { ; -tok , NAME , : , Type } ]| � , { STROKE } (* variable signature *)| � (* empty signature *);10.3 NotesNOTE 1 More free types than necessary are permitted by this syntax: as a result of syntactic transformation12.2.3.5, all elements appear before all injections.NOTE 2 More types than necessary are permitted by this syntax: generic type notation is used at only the outermostlevel of a type.11 Prelude11.1 IntroductionThe prelude is a Z section. It is an implicit parent of every other section. It assists in de�ning the meaningof number literal expressions (see 12.2.6.9), and the list arguments of operators (see 12.2.12), via syntactictransformation rules later in this International Standard. The prelude is presented here using the mathematicallexis.11.2 Formal de�nition of preludesection preludeThe section is called prelude and has no parents.generic 80 ( P )The precedence of the pre�x generic operator P is 80.[A ]The given type A , pronounced \arithmos", provides a supply of values for use in specifying number systems.N : PAThe set of natural numbers, N, is a subset of A .number literal 0 : Nnumber literal 1 : N0 and 1 are natural numbers, all uses of which are transformed to references to these declarations (see 12.2.6.9).function 30 leftassoc ( + )c ISO/IEC 2000|All rights reserved 43

ISO/IEC 13568:2000(E) 12 Syntactic transformation rules+ : P ((A � A ) � A )8m;n : N � 91 p : ( + ) � p:1 = (m;n)8m;n : N � m + n 2 N8m;n : N j m + 1 = n + 1 � m = n8m : N � : m + 1 = 08w : P N j 0 2 w ^ (8 y : w � y + 1 2 w) � w = N8m : N � m + 0 = m8m;n : N � m + (n + 1) = m + n + 1Addition is de�ned here for natural numbers. (It is extended to integers in the mathematical toolkit, annex B.)Addition is a function. The sum of two natural numbers is a natural number. The operation of adding 1 is aninjection on natural numbers, and produces a result di�erent from 0. There is an induction constraint that allnatural numbers are either 0 or are formed by adding 1 to another natural number. 0 is an identity of addition.Addition is associative.NOTE The de�nition of addition is equivalent to the following de�nition, which is written using notation from themathematical toolkit (and so is unsuitable as the normative de�nition here).+ : A � A $ A(N � N) C ( + ) 2 (N � N) ! N�n : N � n + 1 2 N � Ndisjointhf0g; fn : N � n + 1gi8w : PN j f0g [ fn : w � n + 1g � w � w = N8m : N � m + 0 = m8m; n : N � m + (n + 1) = m + n + 112 Syntactic transformation rules12.1 IntroductionThe syntactic transformation rules together map the parse tree of a concrete syntax sentence to the parse tree ofa semantically equivalent annotated syntax sentence. The resulting annotated parse trees may refer to de�nitionsof the prelude.Although exhaustive application of the syntactic transformation rules produces annotated parse trees, individualsyntactic transformation rules can produce a mixture of concrete and annotated notation. Explicit distinction ofthe two is not done, as it would be cumbersome and detract from readability.Only concrete trees that are not in the annotated syntax are given explicit syntactic transformation rules. Thesyntactic transformation rules are listed in the same order as the corresponding productions of the concretesyntax. Where an individual concrete syntax production is expressed using alternations, a separate syntactictransformation rule is given for each alternative.All applications of syntactic transformation rules that generate new declarations shall choose the names of thosedeclarations to be such that they do not capture references during subsequent typechecking.Rules that generate type annotations generate annotations with fresh variables each time they are applied.12.2 Formal de�nition of syntactic transformation rules12.2.1 Speci�cation12.2.1.1 Anonymous speci�cationThe anonymous speci�cation d1 ::: dn is semantically equivalent to the sectioned speci�cation comprising a singlesection containing those paragraphs with the mathematical toolkit of annex B as its parent.d1 ::: dn =) Mathematical toolkit section Speci�cation parents standard toolkit END d1 ::: dn44 c ISO/IEC 2000|All rights reserved

12 Syntactic transformation rules ISO/IEC 13568:2000(E)In this transformation, Mathematical toolkit denotes the entire text of annex B. The name given to the sectionis not important: it need not be Speci�cation, though it may not be prelude or that of any section of themathematical toolkit.12.2.2 Section12.2.2.1 Base sectionThe base section section i END d1 ::: dn is semantically equivalent to the inheriting section that inherits from noparents (bar prelude). section i END d1 ::: dn =) section i parents END d1 ::: dn12.2.3 Paragraph12.2.3.1 Schema de�nition paragraphThe schema de�nition paragraph SCH i t END introduces the global name i, associating it with the schema thatis the value of t. SCH i t END =) AX [i == t] ENDThe paragraph is semantically equivalent to the axiomatic description paragraph whose sole declaration associatesthe schema's name with the expression resulting from syntactic transformation of the schema text.12.2.3.2 Generic schema de�nition paragraphThe generic schema de�nition paragraph GENSCH i [i1; :::; in] t END can be instantiated to produce a schemade�nition paragraph. GENSCH i [i1; :::; in] t END =) GENAX [i1; :::; in] [i == t] ENDIt is semantically equivalent to the generic axiomatic description paragraph with the same generic parameters andwhose sole declaration associates the schema's name with the expression resulting from syntactic transformationof the schema text.12.2.3.3 Horizontal de�nition paragraphThe horizontal de�nition paragraph i == e END introduces the global name i, associating with it the value of e.i == e END =) AX [i == e] ENDIt is semantically equivalent to the axiomatic description paragraph that introduces the same single declaration.12.2.3.4 Generic horizontal de�nition paragraphThe generic horizontal de�nition paragraph i [i1; :::; in] == e END can be instantiated to produce a horizontalde�nition paragraph. i [i1; :::; in] == e END =) GENAX [i1; :::; in] [i == e] ENDIt is semantically equivalent to the generic axiomatic description paragraph with the same generic parametersand that introduces the same single declaration.12.2.3.5 Free types paragraphThe transformation of free types paragraphs is done in two stages. First, the branches are permuted to bringelements to the front and injections to the rear.::: j ghheii j h j ::: =) ::: j h j ghheii j :::Exhaustive application of this syntactic transformation rule e�ects a sort.The second stage requires implicit generic instantiations to have been �lled in, which is done during typechecking(section 13.2.3.3). Hence that second stage is delayed until after typechecking, where it appears in the form of asemantic transformation rule (section 14.2.3.1).c ISO/IEC 2000|All rights reserved 45

ISO/IEC 13568:2000(E) 12 Syntactic transformation rules12.2.4 Operator templateThere are no syntactic transformation rules for operator template paragraphs; rather, operator template para-graphs determine which syntactic transformation rule to use for each phrase that refers to or applies an operator.12.2.5 Predicate12.2.5.1 Newline conjunction predicateThe newline conjunction predicate p1 NL p2 is true if and only if both its predicates are true.p1 NL p2 =) p1 ^ p2It is semantically equivalent to the conjunction predicate p1 ^ p2.12.2.5.2 Semicolon conjunction predicateThe semicolon conjunction predicate p1; p2 is true if and only if both its predicates are true.p1; p2 =) p1 ^ p2It is semantically equivalent to the conjunction predicate p1 ^ p2.12.2.5.3 Existential quanti�cation predicateThe existential quanti�cation predicate 9 t � p is true if and only if p is true for at least one value of t.9 t � p =) : 8 t � : pIt is semantically equivalent to p being false for not all values of t.12.2.5.4 Equivalence predicateThe equivalence predicate p1 , p2 is true if and only if both p1 and p2 are true or neither is true.p1 , p2 =) (p1 ) p2) ^ (p2 ) p1)It is semantically equivalent to each of p1 and p2 being true if the other is true.12.2.5.5 Implication predicateThe implication predicate p1 ) p2 is true if and only if p2 is true if p1 is true.p1 ) p2 =) : p1 _ p2It is semantically equivalent to p1 being false disjoined with p2 being true.12.2.5.6 Disjunction predicateThe disjunction predicate p1 _ p2 is true if and only if at least one of p1 and p2 is true.p1 _ p2 =) : (: p1 ^ : p2)It is semantically equivalent to not both of p1 and p2 being false.12.2.5.7 Schema predicateThe schema predicate e is true if and only if the binding of the names in the signature of schema e satis�es theconstraints of that schema. e =) � e 2 eIt is semantically equivalent to the binding constructed by � e being a member of the set denoted by schema e.46 c ISO/IEC 2000|All rights reserved

12 Syntactic transformation rules ISO/IEC 13568:2000(E)12.2.5.8 Falsity predicateThe falsity predicate false is never true. false =) : trueIt is semantically equivalent to the negation of true.12.2.5.9 Parenthesized predicateThe parenthesized predicate (p) is true if and only if p is true.(p) =) pIt is semantically equivalent to p.12.2.6 Expression12.2.6.1 Schema existential quanti�cation expressionThe value of the schema existential quanti�cation expression 9 t � e is the set of bindings of schema e restrictedto exclude names that are in the signature of t, for at least one binding of the schema t.9 t � e =) : 8 t � : eIt is semantically equivalent to the result of applying de Morgan's law.12.2.6.2 Substitution expressionThe value of the substitution expression let i1 == e1; :::; in == en � e is the value of e when all of its referencesto the names have been substituted by the values of the corresponding expressions.let i1 == e1; :::; in == en � e =) � i1 == e1; :::; in == in � eIt is semantically equivalent to the similar de�nite description expression.12.2.6.3 Schema equivalence expressionThe value of the schema equivalence expression e1 , e2 is that schema whose signature is the union of those ofschemas e1 and e2, and whose bindings are those whose relevant restrictions are either both or neither in e1 ande2. e1 , e2 =) (e1 ) e2) ^ (e2 ) e1)It is semantically equivalent to the schema conjunction shown above.12.2.6.4 Schema implication expressionThe value of the schema implication expression e1 ) e2 is that schema whose signature is the union of those ofschemas e1 and e2, and whose bindings are those whose restriction to the signature of e2 is in the value of e2 ifits restriction to the signature of e1 is in the value of e1.e1 ) e2 =) : e1 _ e2It is semantically equivalent to the schema disjunction shown above.12.2.6.5 Schema disjunction expressionThe value of the schema disjunction expression e1 _ e2 is that schema whose signature is the union of those ofschemas e1 and e2, and whose bindings are those whose restriction to the signature of e1 is in the value of e1 orits restriction to the signature of e2 is in the value of e2.e1 _ e2 =) : (: e1 ^ : e2)It is semantically equivalent to the schema negation shown above.c ISO/IEC 2000|All rights reserved 47

ISO/IEC 13568:2000(E) 12 Syntactic transformation rules12.2.6.6 Conditional expressionThe value of the conditional expression if p then e1 else e2 is the value of e1 if p is true, and is the value of e2 ifp is false. if p then e1 else e2 =) � i : fe1; e2g j p ^ i = e1 _ : p ^ i = e2 � iIt is semantically equivalent to the de�nite description expression whose value is either that of e1 or that of e2such that if p is true then it is e1 or if p is false then it is e2.12.2.6.7 Schema projection expressionThe value of the schema projection expression e1 � e2 is the schema that is like the conjunction e1 ^ e2 but whosesignature is restricted to just that of schema e2.e1 � e2 =) fe1; e2 � � e2gIt is semantically equivalent to that set of bindings of names in the signature of e2 to values that satisfy theconstraints of both e1 and e2.12.2.6.8 Cartesian product expressionThe value of the Cartesian product expression e1� :::� en is the set of all tuples whose components are membersof the corresponding sets that are the values of its expressions.e1 � :::� en =) fi1 : e1; :::; in : en � (i1; :::; in)gIt is semantically equivalent to the set comprehension expression that declares members of the sets and assemblesthose members into tuples.12.2.6.9 Number literal expressionThe value of the multiple-digit number literal expression bc is the number that it denotes.bc =) b + b + b + b + b +b + b + b + b + b + cIt is semantically equivalent to the sum of ten repetitions of the number literal expression b formed from all butthe last digit, added to that last digit. 0 =) number literal 01 =) number literal 12 =) 1 + 13 =) 2 + 14 =) 3 + 15 =) 4 + 16 =) 5 + 17 =) 6 + 18 =) 7 + 19 =) 8 + 1The number literal expressions 0 and 1 are semantically equivalent to number literal 0 and number literal 1 re-spectively as de�ned in section prelude. The remaining digits are de�ned as being successors of their predecessors,using the function + as de�ned in section prelude.NOTE These syntactic transformations are applied only to NUMERAL tokens that form number literal expressions,not to other NUMERAL tokens (those in tuple selection expressions and operator template paragraphs), as those otheroccurrences of NUMERAL do not have semantic values associated with them.48 c ISO/IEC 2000|All rights reserved

12 Syntactic transformation rules ISO/IEC 13568:2000(E)12.2.6.10 Schema construction expressionThe value of the schema construction expression [t] is that schema whose signature is the names declared by theschema text t, and whose bindings are those that satisfy the constraints in t.[t] =) tIt is semantically equivalent to the schema resulting from syntactic transformation of the schema text t.12.2.6.11 Parenthesized expressionThe value of the parenthesized expression (e) is the value of expression e.(e) =) eIt is semantically equivalent to e.12.2.7 Schema textThere is no separate schema text class in the annotated syntax: all concrete schema texts are transformed toexpressions.12.2.7.1 DeclarationEach declaration is transformed to an equivalent expression.A constant declaration is equivalent to a variable declaration in which the variable ranges over a singleton set.i == e =) i : fegA comma-separated multiple declaration is equivalent to the conjunction of variable construction expressions inwhich all variables are constrained to be of the same type.i1; :::; in : e =) [i1 : e oo �1] ^ ::: ^ [in : e oo �1]12.2.7.2 DeclPartEach declaration part is transformed to an equivalent expression.de1; :::; den =) de1 ^ ::: ^ denIf NL tokens have been used in place of any ; s, the same transformation to ^ applies.12.2.7.3 SchemaTextGiven the above transformations of Declaration and DeclPart, any DeclPart in a SchemaText can be assumedto be a single expression.A SchemaText with non-empty DeclPart and Predicate is equivalent to the schema construction expressioncontaining that schema text. e j p =) [e j p]If both DeclPart and Predicate are omitted, the schema text is equivalent to the set containing the emptybinding. =) fhj jigIf just the DeclPart is omitted, the schema text is equivalent to the schema construction expression in whichthere is a set containing the empty binding. j p =) [fhj jig j p]c ISO/IEC 2000|All rights reserved 49

ISO/IEC 13568:2000(E) 12 Syntactic transformation rules12.2.8 NameThese syntactic transformation rules address the concrete syntax productions DeclName, RefName, and OpName.All operator names are transformed to NAMEs, by removing spaces and replacing each by a Z character that isnot acceptable in concrete NAMEs. The Z character 1 is used for this purpose here. The resulting name is giventhe same STROKEs as the component names of the operator, all of which shall have the same STROKEs.Each resulting NAME should be one for which there is an operator template paragraph in scope.NOTE This excludes names made up of words from di�erent operator templates.EXAMPLE Given the operator templatesgeneric 30 leftassoc ( a b )generic 40 leftassoc ( c d )the following declaration conforms to the syntax but is excluded by this restriction.X a Y d Z == X �Y � ZIn every operator name generated by syntactic transformation, for every '&' WORDGLUE character in its WORDpart, there shall be a paired following '-' WORDGLUE character, for every '%' WORDGLUE character in its WORDpart, there shall be a paired following '.' WORDGLUE character, and these shall occur only in nested pairs.12.2.8.1 PrefixName pre =) pre1prep =) prep1ln ess1 ::: essn�2 ere =) ln1ess1:::1essn�21ere1ln ess1 ::: essn�2 sre =) ln1ess1:::1essn�21sre1lp ess1 ::: essn�2 erep =) lp1ess1:::1essn�21erep1lp ess1 ::: essn�2 srep =) lp1ess1:::1essn�21srep112.2.8.2 PostfixName post =) 1postpostp =) 1postpel ess2 ::: essn�1 er =) 1el1ess2:::1essn�11erel ess2 ::: essn�1 sr =) 1el1ess2:::1essn�11srelp ess2 ::: essn�1 erp =) 1elp1ess2:::1essn�11erpelp ess2 ::: essn�1 srp =) 1elp1ess2:::1essn�11srp12.2.8.3 InfixName in =) 1in1ip =) 1ip150 c ISO/IEC 2000|All rights reserved

12 Syntactic transformation rules ISO/IEC 13568:2000(E)el ess2 ::: essn�2 ere =) 1el1ess2:::1essn�21ere1el ess2 ::: essn�2 sre =) 1el1ess2:::1essn�21sre1elp ess2 ::: essn�2 erep =) 1elp1ess2:::1essn�21erep1elp ess2 ::: essn�2 srep =) 1elp1ess2:::1essn�21srep112.2.8.4 NofixName ln ess1 ::: essn�1 er =) ln1ess1:::1essn�11erln ess1 ::: essn�1 sr =) ln1ess1:::1essn�11srlp ess1 ::: essn�1 erp =) ln1ess1:::1essn�11erplp ess1 ::: essn�1 srp =) ln1ess1:::1essn�11srp12.2.9 Generic nameAll generic names are transformed to juxtapositions of NAMEs and generic parameter lists. This causes the genericoperator de�nition paragraphs in which they appear to become generic horizontal de�nition paragraphs, and thusbe amenable to further syntactic transformation.Each resulting NAME should be one for which there is an operator template paragraph in scope (see 12.2.8).12.2.9.1 PrefixGenName pre i =) pre1 [i]ln i1 ess1 ::: in�2 essn�2 in�1 ere in =) ln1ess1:::1essn�21ere1 [i1; :::; in�2; in�1; in]ln i1 ess1 ::: in�2 essn�2 in�1 sre in =) ln1ess1:::1essn�21sre1 [i1; :::; in�2; in�1; in]12.2.9.2 PostfixGenName i post =) 1post [i]i1el i2 ess2 ::: in�1 essn�1 in er =) 1el1ess2:::1essn�11er [i1; i2; :::; in�1; in]i1el i2 ess2 ::: in�1 essn�1 in sr =) 1el1ess2:::1essn�11sr [i1; i2; :::; in�1; in]12.2.9.3 InfixGenName i1in i2 =) 1in1 [i1; i2]i1el i2 ess2 ::: in�2 essn�2 in�1 ere in =) 1el1ess2:::1essn�21ere1 [i1; i2; :::; in�2; in�1; in]i1el i2 ess2 ::: in�2 essn�2 in�1 sre in =) 1el1ess2:::1essn�21sre1 [i1; i2; :::; in�2; in�1; in]c ISO/IEC 2000|All rights reserved 51

ISO/IEC 13568:2000(E) 12 Syntactic transformation rules12.2.9.4 NofixGenNameln i1 ess1 ::: in�1 essn�1 in er =) ln1ess1:::1essn�11er [i1; :::; in�1; in]ln i1 ess1 ::: in�1 essn�1 in sr =) ln1ess1:::1essn�11sr [i1; :::; in�1; in]12.2.10 Relation operator applicationAll relation operator applications are transformed to annotated membership predicates.Each relation NAME should be one for which there is an operator template paragraph in scope (see 12.2.8).The left-hand sides of many of these transformation rules involve ExpSep phrases: they use es metavariables.None of them use ss metavariables: in other words, only the Expression ES case of ExpSep is speci�ed, notthe ExpressionList SS case. Where the latter case occurs in a speci�cation, the ExpressionList shall betransformed by rule 12.2.12 to an expression, and thence a transformation analogous to that speci�ed for theformer case can be performed, di�ering only in that a ss appears in the relation name in place of an es.12.2.10.1 PrefixRel prep e =) e 2 prep1lp e1 es1 ::: en�2 esn�2 en�1 erep en =) (e1; :::; en�2; en�1; en) 2 lp1es1:::1esn�21erep1lp e1 es1 ::: en�2 esn�2 aln�1 srep en =) (e1; :::; en�2; aln�1; en) 2 lp1es1:::1esn�21srep112.2.10.2 PostfixRel e postp =) e 2 1postpe1 elp e2 es2 ::: en�1 esn�1 en erp =) (e1; e2; :::; en�1; en) 2 1elp1es2:::1esn�11erpe1 elp e2 es2 ::: en�1 esn�1 aln srp =) (e1; e2; :::; en�1; aln) 2 1elp1es2:::1esn�11srp12.2.10.3 InfixRele1 ip1 e2 ip2 e3 ::: =) e1 ip1 e2 oo �1 ^ e2 oo �1 ip2 e3 oo �2 :::The chained relation e1 ip1 e2 ip2 e3 ::: is semantically equivalent to a conjunction of relational predicates, withthe constraint that duplicated expressions be of the same type.e1 = e2 =) e1 2 fe2ge1 ip e2 =) (e1; e2) 2 1ip1ip in the above transformation is excluded from being 2 or =, whereas ip1; ip2; ::: can be 2 or =.e1 elp e2 es2 ::: en�2 esn�2 en�1 erep en =) (e1; e2; :::; en�2; en�1; en) 2 1elp1es2:::1esn�21erep1e1 elp e2 es2 ::: en�2 esn�2 aln�1 srep en =) (e1; e2; :::; en�2; aln�1; en) 2 1elp1es2:::1esn�21srep152 c ISO/IEC 2000|All rights reserved

12 Syntactic transformation rules ISO/IEC 13568:2000(E)12.2.10.4 NofixRellp e1 es1 ::: en�1 esn�1 en erp =) (e1; :::; en�1; en) 2 lp1es1:::1esn�11erplp e1 es1 ::: en�1 esn�1 aln srp =) (e1; :::; en�1; aln) 2 lp1es1:::1esn�11srp12.2.11 Function and generic operator applicationAll function operator applications are transformed to annotated application expressions.All generic operator applications are transformed to annotated generic instantiation expressions.Each resulting NAME should be one for which there is an operator template paragraph in scope (see 12.2.8).The left-hand sides of many of these transformation rules involve ExpSep phrases: they use es metavariables.None of them use ss metavariables: in other words, only the Expression ES case of ExpSep is speci�ed, notthe ExpressionList SS case. Where the latter case occurs in a speci�cation, the ExpressionList shall betransformed by rule 12.2.12 to an expression, and thence a transformation analogous to that speci�ed for theformer case can be performed, di�ering only in that a ss appears in the function or generic name in place of anes.12.2.11.1 PrefixApp pre e =) pre1 eln e1 es1 ::: en�2 esn�2 en�1 ere en =) ln1es1:::1esn�21ere1 (e1; :::; en�2; en�1; en)ln e1 es1 ::: en�2 esn�2 aln�1 sre en =) ln1es1:::1esn�21sre1 (e1; :::; en�2; aln�1; en)pre e =) pre1 [e]ln e1 es1 ::: en�2 esn�2 en�1 ere en =) ln1es1:::1esn�21ere1 [e1; :::; en�2; en�1; en]ln e1 es1 ::: en�2 esn�2 aln�1 sre en =) ln1es1:::1esn�21sre1 [e1; :::; en�2; aln�1; en]12.2.11.2 PostfixApp e post =) 1post ee1 el e2 es2 ::: en�1 esn�1 en er =) 1el1es2:::1esn�11er (e1; e2; :::; en�1; en)e1 el e2 es2 ::: en�1 esn�1 aln sr =) 1el1es2:::1esn�11sr (e1; e2; :::; en�1; aln)e post =) 1post [e]e1 el e2 es2 ::: en�1 esn�1 en er =) 1el1es2:::1esn�11er [e1; e2; :::; en�1; en]e1 el e2 es2 ::: en�1 esn�1 aln sr =) 1el1es2:::1esn�11sr [e1; e2; :::; en�1; aln]c ISO/IEC 2000|All rights reserved 53

ISO/IEC 13568:2000(E) 13 Type inference rules12.2.11.3 InfixApp e1 in e2 =) 1in1 (e1; e2)e1 el e2 es2 ::: en�2 esn�2 en�1 ere en =) 1el1es2:::1esn�21ere1 (e1; e2; :::; en�2; en�1; en)e1 el e2 es2 ::: en�2 esn�2 aln�1 sre en =) 1el1es2:::1esn�21sre1 (e1; e2; :::; en�2; aln�1; en)e1 in e2 =) 1in1 [e1; e2]e1 el e2 es2 ::: en�2 esn�2 en�1 ere en =) 1el1es2:::1esn�21ere1 [e1; e2; :::; en�2; en�1; en]e1 el e2 es2 ::: en�2 esn�2 aln�1 sre en =) 1el1es2:::1esn�21sre1 [e1; e2; :::; en�2; aln�1; en]12.2.11.4 NofixAppln e1 es1 ::: en�1 esn�1 en er =) ln1es1:::1esn�11er (e1; :::; en�1; en)ln e1 es1 ::: en�1 esn�1 aln sr =) ln1es1:::1esn�11sr (e1; :::; en�1; aln)ln e1 es1 ::: en�1 esn�1 en er =) ln1es1:::1esn�11er [e1; :::; en�1; en]ln e1 es1 ::: en�1 esn�1 aln sr =) ln1es1:::1esn�11sr [e1; :::; en�1; aln]12.2.12 Expression list e1; :::; en =) f(1; e1); :::; (n; en)gWithin an operator application, each expression list is syntactically transformed to the equivalent explicit repre-sentation of a sequence, which is a set of pairs of position and corresponding component expression.13 Type inference rules13.1 IntroductionAll expressions in Z are typed, allowing some of the logical anomalies that can arise when sets are de�ned interms of their properties to be avoided. An example of a Z phrase that is not well-typed is the predicate 2 2 3,because the second expression of a membership predicate is required to be a set of values, each of the same typeas the �rst expression. The check for well-typedness of a Z speci�cation can be automated, by conforming to thespeci�cation given in this clause.The type constraints that shall be satis�ed between the various parts of a Z phrase are speci�ed by type inferencerules, of which there is one corresponding to each annotated syntax production. The type inference rules togethercan be viewed as a partial function that maps a parse tree of an annotated syntax sentence to a fully annotatedparse tree of an annotated syntax sentence.Initially, all annotations are set to variables, and these are all distinct except as set by the syntactic transformationrules (12.2.7 and 12.2.10). A type inference rule's type sequent is a pattern that when matched against a phrase54 c ISO/IEC 2000|All rights reserved

13 Type inference rules ISO/IEC 13568:2000(E)produces substitutions for its metavariables. Starting with a type sequent for a whole Z speci�cation, that ismatched against the pattern in the type inference rule for a sectioned speci�cation. The resulting substitutionsfor metavariables are used to produce instantiations of the rule's type subsequents and side-conditions. Theinstantiated side-conditions include constraints that determine the environments to be used in typechecking thetype subsequents. There is no need to solve the constraints yet. Instead, type inference rules can be applied tothe generated type subsequents, each application producing zero or more new type subsequents, until no moretype subsequents remain. This produces a tree of deductions, whose leaves correspond to the atomic phrases ofthe sentence, namely given types paragraphs, truth predicates, and reference expressions.There remains a collection of constraints to be solved. There are dependencies between constraints: for example,a constraint that checks that a name is declared in an environment cannot be solved until that environment hasbeen determined by other constraints. Uni�cation is a suitable mechanism for solving constraints. A typecheckershall not impose any additional constraints, such as on the order in which constraints are expected to be solved[15].For a well-typed speci�cation, there shall be no contradictions amongst the constraints, and the solution to theconstraints shall provide values for all of the variables. If there is a contradiction amongst the constraints, therecan be no consistent assignment of annotations, and the speci�cation is not well-typed. If the solution to theconstraints does not provide a value for a variable, there is more than one possible assignment of annotations,and the speci�cation is not well-typed.EXAMPLE 1empty == fgIn this declaration, the type of empty , P�, involves an unconstrained variable.13.2 Formal de�nition of type inference rules13.2.1 Speci�cation13.2.1.1 Sectioned speci�cationfg S sprelude oo �0 �1 S s1 oo �1 ::: �n S sn oo �nZ s1 oo �1 ::: sn oo �n 0B@ �1 = fprelude 7! �0g...�n = �n�1 [ fin�1 7! �n�1g 1CAwhere in�1 is the name of section sn�1, and none of the sections s1 ... sn are named prelude.Each section is typechecked in an environment formed from preceding sections, and is annotated with an envi-ronment that it establishes.NOTE The environment established by the prelude section is as follows.�0 = (A ; (prelude;P(GIVEN A )));(N; (prelude;P(GIVEN A )));(number literal 0; (prelude; (GIVEN A )));(number literal 1; (prelude; (GIVEN A )));(1+1; (prelude;P(((GIVEN A ) � (GIVEN A )) � (GIVEN A ))))If one of the sections s1 ... sn is named prelude, then the same type inference rule applies except that the typesubsequent for the prelude section is omitted.c ISO/IEC 2000|All rights reserved 55

ISO/IEC 13568:2000(E) 13 Type inference rules13.2.2 Section13.2.2.1 Inheriting section�0 D d1 oo �1 ::: �n�1 D dn oo �n� S section i parents i1; :::; im ENDd1 oo �1 ::: dn oo �n oo �

0BBBBBBBBBBBBBBBBB@i 62 dom �fi1; :::; img � dom � �1 = if i = prelude then fg else � prelude 0 = �1 [ � i1 [ ::: [ � im�0 = 0 o9 seconddisjoint hdom �1; :::; dom �ni� 2 ( 7! )� = 0 [ fj : NAME; � : Type j j 7! � 2 �1 [ ::: [ �n � j 7! (i; �)g�1 = �0 [ �1...�n�1 = �n�2 [ �n�1

1CCCCCCCCCCCCCCCCCATaking the side-conditions in order, this type inference rule ensures that:a) the name of the section, i, is di�erent from that of any previous section;b) the names in the parents list are names of known sections;c) the section environment of the prelude is included if the section is not itself the prelude;d) the section environment 0 is formed from those of the parents;e) the type environment �0 is determined from the section environment 0;f) there is no global rede�nition between any pair of paragraphs of the section (the sets of names in theirsignatures are disjoint);g) a name which is common to the environments of multiple parents shall have originated in a common ancestralsection, and a name introduced by a paragraph of this section shall not also be introduced by anotherparagraph or parent section (all ensured by the combined environment being a function);h) the annotation of the section is an environment formed from those of its parents extended according to thesignatures of its paragraphs;i) and the type environment in which a paragraph is typechecked is formed from that of the parent sectionsextended with the signatures of the preceding paragraphs of this section.NOTE 1 Ancestors need not be immediate parents, and a section cannot be amongst its own ancestors (no cyclesin the parent relation).NOTE 2 The name of a section can be the same as the name of a variable introduced in a declaration|the two arenot confused.13.2.3 Generic instantiationGeneric declarations can appear only at the paragraph level. The types of generic declarations shall be determinedbefore the constraints arising from the side-conditions of the type inference rules for references to generics (13.2.6.1and 13.2.6.2) can be solved. This implies solving the constraints in per-paragraph batches. Having determinedthe types of references to generic declarations, instantiations that were left implicit are made explicit, ready forsubsequent semantic relation.NOTE This is why generic instantiation is de�ned here, immediately before the type inference rules for paragraphs.56 c ISO/IEC 2000|All rights reserved

13 Type inference rules ISO/IEC 13568:2000(E)13.2.3.1 Generic type instantiationThe constraints that cannot be solved until the type of a generic declaration is determined are those that involvethe operation of generic type instantiation. The generic type instantiation meta-function relates a known generictype and a list of argument types to the type in which each reference to a generic parameter has been substi-tuted with the corresponding argument type. Applications of the generic type instantiation meta-function areformulated here as the juxtaposition of a generic type (parenthesized) with a square-bracketed list of argumenttypes. ([i1; :::; in] GIVEN i) [�1; :::; �n] = GIVEN i([i1; :::; in] GENTYPE ik) [�1; :::; �n] = �k([i1; :::; in] P �) [�1; :::; �n] = P(([i1; :::; in] �) [�1; :::; �n])([i1; :::; in] � 01 � :::� � 0m) [�1; :::; �n] = ([i1; :::; in] � 01) [�1; :::; �n]� :::� ([i1; :::; in] � 0m) [�1; :::; �n]([i1; :::; in] [i01 : � 01; :::; i0m : � 0m]) [�1; :::; �n]= [i01 : [i1; :::; in] � 01 [�1; :::; �n]; :::; i0m : [i1; :::; in] � 0m [�1; :::; �n]]NOTE There is no equation for variable type because that is the case of the type of the generic declaration beingunknown. In a well-typed speci�cation, all variable types within a generic type will have been uni�ed with othertypes.13.2.3.2 Carrier setThe meta-function carrier relates a type phrase to an expression phrase denoting the carrier set of that type. Itis used for the calculation of implicit generic actuals, and also later in semantic transformation rules.carrier (GIVEN i) = i oo P(GIVEN i)carrier (GENTYPE i) = i oo P(GENTYPE i)carrier (P �) = P(carrier �) oo PP �carrier (�1 � :::� �n) = (carrier �1 � :::� carrier �n) oo P(�1 � :::� �n)carrier ([in : �n; :::; in : �n]) = [in : carrier �n; :::; in : carrier �n] oo P[in : �n; :::; in : �n]NOTE 1 The expressions are generated with type annotations, to avoid needing to apply type inference again, andso avoid the potential problem of type names being captured by local declarations.NOTE 2 But for the GIVEN/GENTYPE distinction and the generation of type annotations, each of these equationsgenerates an expression that has the same textual appearance as the type.NOTE 3 There is no equation for variable type because in a well-typed speci�cation all variable types have beenuni�ed with other types. There is no equation for generic types because they appear in only the type annotation ofgeneric axiomatic paragraphs, and carrier is never applied there.13.2.3.3 Implicit instantiationThe value of a reference expression that refers to a generic de�nition is an inferred instantiation of that genericde�nition. i oo [i1; :::; in]�; � 0 � 0=([i1; :::; in]�) [�1; :::; �n ]=) i [carrier �1; :::; carrier �n ] oo � 0It is semantically equivalent to the generic instantiation expression whose generic actuals are the carrier sets ofthe types inferred for the generic parameters. The type � 0 is an instantiation of the generic type �. The typesinferred for the generic parameters are �1; :::; �n . They shall all be determinable by comparison of � with � 0 assuggested by the condition on the transformation. Cases where these types cannot be so determined, because thegeneric type is independent of some of the generic parameters, are not well-typed.EXAMPLE 1 The paragrapha[X ] == 1c ISO/IEC 2000|All rights reserved 57

ISO/IEC 13568:2000(E) 13 Type inference rulesde�nes a with type [X ]GIVEN A . The paragraphb == atypechecks, giving the annotated expression a oo [X ]GIVEN A ; GIVEN A . Comparison of the generic type with theinstantiated type does not determine a type for the generic parameter X , and so this speci�cation is not well-typed.Cases where these types are not unique (contain unconstrained variables) are not well-typed.EXAMPLE 2 The paragraphempty == ?will contain the annotated expression ? oo [X ]PX ;P�, in which the type determined for the generic parameter X isunconstrained, and so this speci�cation is not well-typed.13.2.4 Paragraph13.2.4.1 Given types paragraph� D [i1; :::; in] END oo �� # fi1; :::; ing = n� = i1 : P(GIVEN i1); :::; in : P(GIVEN in) �In a given types paragraph, there shall be no duplication of names. The annotation of the paragraph is a signatureassociating the given type names with powerset types.13.2.4.2 Axiomatic description paragraph� E e oo �� D AX e oo � END oo � (� = P[�])In an axiomatic description paragraph AX e END, the expression e shall be a schema. The annotation of theparagraph is the signature of that schema.13.2.4.3 Generic axiomatic description paragraph� � fi1 7! P(GENTYPE i1); :::; in 7! P(GENTYPE in)g E e oo �� D GENAX [i1; :::; in] e oo � END oo � 0@ # fi1; :::; ing = n� = P[�]� = � j : dom � � [i1; :::; in] (� j) 1AIn a generic axiomatic description paragraph GENAX [i1; :::; in] e END, there shall be no duplication of names withinthe generic parameters. The expression e is typechecked, in an environment overridden by the generic parameters,and shall be a schema. The annotation of the paragraph is formed from the signature of that schema, having thesame names but associated with types that are generic.

58 c ISO/IEC 2000|All rights reserved

13 Type inference rules ISO/IEC 13568:2000(E)13.2.4.4 Free types paragraph� E e1 1 oo �1 1 ::: � E e1n1 oo �1 n1...� E er 1 oo �r 1 ::: � E er nr oo �r nr� D f1 ::= h1 1 j ::: j h1m1 jg1 1hhe1 1 oo �1 1ii j... jg1n1hhe1 n1 oo �1n1ii &... &fr ::= hr 1 j ::: j hrmr jgr 1hher 1 oo �r 1ii j... jgr nr hher nr oo �r nrii END oo �

0BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB@

# ff1; h1 1; :::; h1m1 ; g1 1; :::; g1n1 ;...; fr; hr 1; :::; hrmr ; gr 1; :::; gr nrg= r +m1 + :::+mr + n1 + :::+ nr� = � � ff1 7! P(GIVEN f1); :::; fr 7! P(GIVEN fr)g�1 1 = P�1 1 ::: �1 n1 = P�1n1...�r 1 = P�r 1 ::: �r nr = P�r nr� = f1 : P(GIVEN f1);h1 1 : GIVEN f1; :::; h1m1 : GIVEN f1;g1 1 : P(�1 1 � GIVEN f1);...;g1n1 : P(�1 n1 � GIVEN f1);...;fr : P(GIVEN fr);hr 1 : GIVEN fr; :::; hrmr : GIVEN fr;gr 1 : P(�r 1 � GIVEN fr);...;gr nr : P(�r nr � GIVEN fr)

1CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCAIn a free types paragraph, the names of the free types, elements and injections shall all be di�erent. The expressionsrepresenting the domains of the injections are typechecked in an environment overridden by the names of the freetypes, and shall all be sets. The annotation of the paragraph is the signature whose names are those of all thefree types, the elements, and the injections, each associated with the corresponding type.13.2.4.5 Conjecture paragraph� P p� D `? p END oo � (� = �)In a conjecture paragraph `? p END, the predicate p shall be well-typed. The annotation of the paragraph is theempty signature.13.2.4.6 Generic conjecture paragraph� � fi1 7! P(GENTYPE i1); :::; in 7! P(GENTYPE in)g P p� D [i1; :::; in] `? p END oo � � # fi1; :::; ing = n� = � �In a generic conjecture paragraph [i1; :::; in] `? p END, there shall be no duplication of names within the genericparameters. The predicate p shall be well-typed in an environment overridden by the generic parameters. Theannotation of the paragraph is the empty signature.13.2.5 Predicate13.2.5.1 Membership predicate� E e1 oo �1 � E e2 oo �2� P (e1 oo �1) 2 (e2 oo �2) � �2 = P �1 �In a membership predicate e1 2 e2, expression e2 shall be a set, and expression e1 shall be of the same type asthe members of set e2.c ISO/IEC 2000|All rights reserved 59

ISO/IEC 13568:2000(E) 13 Type inference rules13.2.5.2 Truth predicate� P trueA truth predicate is always well-typed.13.2.5.3 Negation predicate� P p� P : pA negation predicate : p is well-typed if and only if predicate p is well-typed.13.2.5.4 Conjunction predicate� P p1 � P p2� P p1 ^ p2A conjunction predicate p1 ^ p2 is well-typed if and only if predicates p1 and p2 are well-typed.13.2.5.5 Universal quanti�cation predicate� E e oo � � � � P p� P 8 (e oo �) � p (� = P[�])In a universal quanti�cation predicate 8 e � p, expression e shall be a schema, and predicate p shall be well-typedin the environment overridden by the signature of schema e.13.2.5.6 Unique existential quanti�cation predicate� E e oo � � � � P p� P 91 (e oo �) � p (� = P[�])In a unique existential quanti�cation predicate 91 e � p, expression e shall be a schema, and predicate p shall bewell-typed in the environment overridden by the signature of schema e.13.2.6 Expression13.2.6.1 Reference expressionIn a reference expression, if the name is of the form �i and no declaration of this name yet appears in theenvironment, then the following syntactic transformation is applied.�i �i 62dom �=) [i; i 0]This syntactic transformation makes the otherwise unde�ned name be equivalent to the corresponding schemaconstruction expression, which is then typechecked.Similarly, if the name is of the form �i and no declaration of this name yet appears in the environment, then thefollowing syntactic transformation is applied.�i �i 62dom �=) [i; i 0 j � i = � i 0]NOTE 1 The � notation is deliberately not de�ned in terms of the � notation.NOTE 2 Type inference could be done without these syntactic transformations, but they are necessary steps inde�ning the formal semantics.NOTE 3 Only occurrences of � and � that are in such reference expressions are so transformed, not others such asthose in the names of declarations.60 c ISO/IEC 2000|All rights reserved

13 Type inference rules ISO/IEC 13568:2000(E)� E i oo �� i 2 dom �� = if � i = [{1; :::; {n ] � then � i; (� i) [�1; :::; �n ] else � i �In any other reference expression i, the name i shall be associated with a type in the environment. If that typeis generic, the annotation of the whole expression is a pair of both the uninstantiated type (for the Instantiationclause to determine that this is a reference to a generic de�nition) and the type instantiated with new distinctvariable types (which the context should constrain to non-generic types). Otherwise (if the type in the environmentis non-generic), that is the type of the whole expression.NOTE 4 If the type is generic, the reference expression will be transformed to a generic instantiation expression bythe rule in 13.2.3.3. That shall be done only when the implicit instantiations have been determined via constraintson the new variable types �1; :::; �n .13.2.6.2 Generic instantiation expression� E e1 oo �1 ::: � E en oo �n� E i[(e1 oo �1); :::; (en oo �n)] oo � 0BBBBBBB@ i 2 dom �� i = [{1; :::; {n ] ��1 = P�1...�n = P�n� = (� i) [�1; :::; �n ]1CCCCCCCAIn a generic instantiation expression i [e1; :::; en], the name i shall be associated with a generic type in theenvironment, and the expressions e1; :::; en shall be sets. That generic type shall have the same number ofparameters as there are sets. The type of the whole expression is the instantiation of that generic type by thetypes of those sets' components.NOTE The operation of generic type instantiation is de�ned in 13.2.3.1.13.2.6.3 Set extension expression� E e1 oo �1 ::: � E en oo �n� E f(e1 oo �1); :::; (en oo �n)g oo � 0BBBBBBB@ if n > 0 then(�1 = �n...�n�1 = �n� = P �1)else � = P�

1CCCCCCCAIn a set extension expression, every component expression shall be of the same type. The type of the wholeexpression is a powerset of the components' type, or a powerset of a variable type if there are no components. Inthe latter case, the variable shall be constrained by the context, otherwise the speci�cation is not well-typed.13.2.6.4 Set comprehension expression� E e1 oo �1 � � � E e2 oo �2� E f(e1 oo �1) � (e2 oo �2)g oo �3 � �1 = P[�]�3 = P �2 �In a set comprehension expression fe1 � e2g, expression e1 shall be a schema. The type of the whole expression isa powerset of the type of expression e2, as determined in an environment overridden by the signature of schemae1.13.2.6.5 Powerset expression� E e oo �1� E P(e oo �1) oo �2� �1 = P��2 = P �1 �In a powerset expression P e, expression e shall be a set. The type of the whole expression is then a powerset ofthe type of expression e.c ISO/IEC 2000|All rights reserved 61

ISO/IEC 13568:2000(E) 13 Type inference rules13.2.6.6 Tuple extension expression� E e1 oo �1 ::: � E en oo �n� E ((e1 oo �1); :::; (en oo �n)) oo � � � = �1 � :::� �n �In a tuple extension expression (e1; :::; en), the type of the whole expression is the Cartesian product of the typesof the individual component expressions.13.2.6.7 Tuple selection expression� E e oo �1� E (e oo �1) : b oo �2 ((b; �2) 2 �1)In a tuple selection expression e : b, the type of expression e shall be a Cartesian product, and number b shallselect one of its components. The type of the whole expression is the type of the selected component.13.2.6.8 Binding extension expression� E e1 oo �1 ::: � E en oo �n� E hj i1 == (e1 oo �1); :::; in == (en oo �n) ji oo �� # fi1; :::; ing = n� = [i1 : �1; :::; in : �n] �In a binding extension expression hj i1 == e1; :::; in == en ji, there shall be no duplication amongst the boundnames. The type of the whole expression is that of a binding whose signature associates the names with the typesof the corresponding expressions.13.2.6.9 Binding construction expression� E e oo �1� E � (e oo �1) � oo �20@ �1 = P[�]8 i : NAME j (i; �1) 2 � � (i decor �; �1) 2 � ^ : �1 = [{1; :::; {n ] �2�2 = [�] 1AIn a binding construction expression � e �, the expression e shall be a schema. Every name and type pair in itssignature, with the optional decoration added, should be present in the environment with a non-generic type.The type of the whole expression is that of a binding whose signature is that of the schema.NOTE If the type in the environment were generic, semantic transformation 14.2.5.2 would produce a referenceexpression whose implicit instantiation is not determined by this International Standard.13.2.6.10 Binding selection expression� E e oo �1� E (e oo �1) : i oo �2� �1 = [�](i; �2) 2 � �In a binding selection expression e : i, expression e shall be a binding, and name i shall select one of itscomponents. The type of the whole expression is the type of the selected component.13.2.6.11 Application expression� E e1 oo �1 � E e2 oo �2� E (e1 oo �1) (e2 oo �2) oo �3 � �1 = P(�2 � �3) �In an application expression e1 e2, the expression e1 shall be a set of pairs, and expression e2 shall be of thesame type as the �rst components of those pairs. The type of the whole expression is the type of the secondcomponents of those pairs.13.2.6.12 De�nite description expression� E e1 oo �1 � � � E e2 oo �2� E � (e1 oo �1) � (e2 oo �2) oo �3 � �1 = P[�]�3 = �2 �In a de�nite description expression � e1 � e2, expression e1 shall be a schema. The type of the whole expressionis the type of expression e2, as determined in an environment overridden by the signature of schema e1.62 c ISO/IEC 2000|All rights reserved

13 Type inference rules ISO/IEC 13568:2000(E)13.2.6.13 Variable construction expression� E e oo �1� E [i : (e oo �1)] oo �2� �1 = P��2 = P[i : �] �In a variable construction expression [i : e], expression e shall be a set. The type of the whole expression is thatof a schema whose signature associates the name i with the type of a member of the set e.13.2.6.14 Schema construction expression� E e oo �1 � � � P p� E [(e oo �1) j p] oo �2 � �1 = P[�]�2 = �1 �In a schema construction expression [e j p], expression e shall be a schema, and predicate p shall be well-typedin an environment overridden by the signature of schema e. The type of the whole expression is the same as thetype of expression e.13.2.6.15 Schema negation expression� E e oo �1� E : (e oo �1) oo �2� �1 = P[�]�2 = �1 �In a schema negation expression : e, expression e shall be a schema. The type of the whole expression is thesame as the type of expression e.13.2.6.16 Schema conjunction expression� E e1 oo �1 � E e2 oo �2� E (e1 oo �1) ^ (e2 oo �2) oo �30BB@ �1 = P[�1]�2 = P[�2]�1 � �2�3 = P[�1 [ �2] 1CCAIn a schema conjunction expression e1 ^ e2, expressions e1 and e2 shall be schemas, and their signatures shallbe compatible. The type of the whole expression is that of the schema whose signature is the union of those ofexpressions e1 and e2.13.2.6.17 Schema hiding expression� E e oo �1� E (e oo �1) n (i1; :::; in) oo �20@ �1 = P[�]fi1; :::; ing � dom ��2 = P[fi1; :::; ing �C �] 1AIn a schema hiding expression e n (i1; :::; in), expression e shall be a schema, and the names to be hidden shallall be in the signature of that schema. The type of the whole expression is that of a schema whose signature iscomputed by subtracting from the signature of expression e those pairs whose names are hidden.13.2.6.18 Schema universal quanti�cation expression� E e1 oo �1 � � �1 E e2 oo �2� E 8 (e1 oo �1) � (e2 oo �2) oo �3 0BB@ �1 = P[�1]�2 = P[�2]�1 � �2�3 = P[dom �1 �C �2] 1CCAIn a schema universal quanti�cation expression 8 e1 � e2, expression e1 shall be a schema, and expression e2, inan environment overridden by the signature of schema e1, shall also be a schema, and the signatures of these twoschemas shall be compatible. The type of the whole expression is that of a schema whose signature is computedby subtracting from the signature of e2 those pairs whose names are in the signature of e1.c ISO/IEC 2000|All rights reserved 63

ISO/IEC 13568:2000(E) 13 Type inference rules13.2.6.19 Schema unique existential quanti�cation expression� E e1 oo �1 � � �1 E e2 oo �2� E 91 (e1 oo �1) � (e2 oo �2) oo �3 0BB@ �1 = P[�1]�2 = P[�2]�1 � �2�3 = P[dom �1 �C �2] 1CCAIn a schema unique existential quanti�cation expression 91 e1 � e2, expression e1 shall be a schema, and expressione2, in an environment overridden by the signature of schema e1, shall also be a schema, and the signatures ofthese two schemas shall be compatible. The type of the whole expression is that of a schema whose signature iscomputed by subtracting from the signature of e2 those pairs whose names are in the signature of e1.13.2.6.20 Schema renaming expression� E e oo �1� E (e oo �1)[j1 = i1; :::; jn = in] oo �20BBBB@ # fi1; :::; ing = n�1 = P[�1]�2 = fj1 7! i1; :::; jn 7! ing o9 �1 [ fi1; :::; ing �C �1�2 = P[�2]�2 2 ( 7! ) 1CCCCAIn a schema renaming expression e [j1 = i1; :::; jn = in], there shall be no duplicates amongst the old namesi1; :::; in. Expression e shall be a schema. The type of the whole expression is that of a schema whose signatureis like that of expression e but with the new names in place of corresponding old names. Declarations that aremerged by the renaming shall have the same type.NOTE Old names need not be in the signature of the schema. This is so as to permit renaming to distribute overother notations such as disjunction.13.2.6.21 Schema precondition expression� E e oo �1� E pre (e oo �1) oo �2� �1 = P[�]�2 = P[fi; j : NAME j j 2 dom � ^ (j = i decor 0 _ j = i decor !) � jg �C �] �In a schema precondition expression pre e, expression e shall be a schema. The type of the whole expression isthat of a schema whose signature is computed by subtracting from the signature of e those pairs whose nameshave primed or shrieked decorations.13.2.6.22 Schema composition expression� E e1 oo �1 � E e2 oo �2� E (e1 oo �1) o9 (e2 oo �2) oo �30BBBBBBBBBB@�1 = P[�1]�2 = P[�2]match = fi : dom �2 j i decor 0 2 dom �1 � ig�3 = fi : match � i decor 0g �C �1�4 = match �C �2�3 � �4fi : match � i 7! �1(i decor 0)g � fi : match � i 7! �2 ig�3 = P[�3 [ �4]

1CCCCCCCCCCAIn a schema composition expression e1 o9 e2, expressions e1 and e2 shall be schemas. Let match be the set ofnames in schema e2 for which there are matching primed names in schema e1. Let �3 be the signature formedfrom the components of e1 excluding the matched primed components. Let �4 be the signature formed from thecomponents of e2 excluding the matched unprimed components. Signatures �3 and �4 shall be compatible. Thetypes of the excluded matched pairs of components shall be the same. The type of the whole expression is thatof a schema whose signature is the union of �3 and �4.64 c ISO/IEC 2000|All rights reserved

13 Type inference rules ISO/IEC 13568:2000(E)13.2.6.23 Schema piping expression� E e1 oo �1 � E e2 oo �2� E (e1 oo �1)>> (e2 oo �2) oo �30BBBBBBBBBB@�1 = P[�1]�2 = P[�2]match = fi : NAME j i decor ! 2 dom �1 ^ i decor ? 2 dom �2 � ig�3 = fi : match � i decor !g �C �1�4 = fi : match � i decor ?g �C �2�3 � �4fi : match � i 7! �1(i decor !)g � fi : match � i 7! �2 (i decor ?)g�3 = P[�3 [ �4]

1CCCCCCCCCCAIn a schema piping expression e1>>e2, expressions e1 and e2 shall be schemas. Let match be the set of names forwhich there are matching shrieked names in schema e1 and queried names in schema e2. Let �3 be the signatureformed from the components of e1 excluding the matched shrieked components. Let �4 be the signature formedfrom the components of e2 excluding the matched queried components. Signatures �3 and �4 shall be compatible.The types of the excluded matched pairs of components shall be the same. The type of the whole expression isthat of a schema whose signature is the union of �3 and �4.13.2.6.24 Schema decoration expression� E e oo �1� E (e oo �1) + oo �2� �1 = P[�]�2 = P[fi : dom � � i decor + 7! � ig] �In a schema decoration expression e +, expression e shall be a schema. The type of the whole expression is thatof a schema whose signature is like that of e but with the stroke appended to each of its names.13.3 Summary of scope rulesNOTE Here is an informal explanation of the scope rules implied by the type inference rules of 13.2.A scope is static: it depends on only the structure of the text, not on the value of any predicate or expression.A declaration can be either: a given type, a free type, a formal generic parameter, or an instance of Declarationusually within a DeclPart.The scopes of given types and free types (which occur only at paragraph level), and Declarations at paragraph level(such as those of schema de�nitions and those of the outermost DeclPart in axiomatic descriptions), are the wholeof the rest of the section and any sections of which that is an ancestor.Redeclaration at paragraph level of any name already declared at paragraph level is prohibited. Redeclaration at aninner level of any name already declared with larger scope makes a hole in the scope of the outer declaration.In a free types paragraph, the scopes of the declarations of the free types include the right-hand sides of the free typedeclarations, whereas the scopes of the declarations of the elements and injections of the free types do not includethe free types paragraph itself.The scope of a formal generic parameter is the rest of the paragraph in which it appears.A DeclPart is not in the scope of its declarations.The declarations of a schema inclusion declaration are distinct from those in the signature of the schema itself, andso have separate scopes.A name may be declared more than once within a DeclPart provided the types of the several declarations are identical.In this case, the declarations are merged, so that they share the same scope, and the corresponding properties areconjoined.The scope of the declarations in the DeclPart of a quanti�cation, set comprehension, function construction, de�nitec ISO/IEC 2000|All rights reserved 65

ISO/IEC 13568:2000(E) 14 Semantic transformation rulesdescription or schema construction expression is the j part of the SchemaText and any � part of that construct.14 Semantic transformation rules14.1 IntroductionThe semantic transformation rules de�ne some annotated notations as being equivalent to other annotated no-tations. The only sentences of concern here are ones that are already known to be well-formed syntacticallyand well-typed. These semantic transformations are transformations that could not appear earlier as syntactictransformations because they depend on type annotations or generic instantiations or are applicable only to parsetrees of phrases that are not in the concrete syntax.Some semantic transformation rules generate other transformable notation, though exhaustive application of theserules always terminates. They introduce no type errors. It is not intended that type inference be repeated on thegenerated notation, though type annotations are needed on that notation for the semantic relations. Nevertheless,the manipulation of type annotations is not made explicit throughout these rules, as that would be obfuscatoryand can easily be derived by the reader. Indeed, some rules exploit concrete notation for brevity and clarity.The semantic transformation rules are listed in the same order as the corresponding productions of the annotatedsyntax.All applications of transformation rules that generate new declarations shall choose the names of those declarationsto be such that they do not capture references.14.2 Formal de�nition of semantic transformation rules14.2.1 Speci�cationThere are no semantic transformation rules for speci�cations.14.2.2 SectionThere are no semantic transformation rules for sections.14.2.3 Paragraph14.2.3.1 Free types paragraphA free types paragraph is semantically equivalent to the sequence of given type paragraph and axiomatic de�nitionparagraph de�ned here.NOTE 1 This exploits notation that is not present in the annotated syntax for the purpose of abbreviation.f1 ::= h1 1 j ::: j h1m1 j g1 1hhe1 1ii j ::: j g1n1hhe1 n1ii& ::: &fr ::= hr 1 j ::: j hrmr j gr 1hher 1ii j ::: j gr nrhher nrii=)[f1; :::; fr]END66 c ISO/IEC 2000|All rights reserved

14 Semantic transformation rules ISO/IEC 13568:2000(E)AXh1 1; :::; h1m1 : f1...hr 1; :::; hrmr : frg11 : P(e1 1 � f1); :::; g1n1 : P(e1 n1 � f1)...gr 1 : P(er 1 � fr); :::; gr nr : P(er nr � fr)j(8 u : e1 1 � 91 x : g1 1 � x : 1 = u) ^ ::: ^ (8 u : e1n1 � 91 x : g1n1 � x : 1 = u)... ^(8 u : er 1 � 91 x : gr 1 � x : 1 = u) ^ ::: ^ (8 u : er nr � 91 x : gr nr � x : 1 = u)(8 u; v : e1 1 j g1 1u = g1 1v � u = v) ^ ::: ^ (8 u; v : e1n1 j g1n1u = g1n1v � u = v)... ^(8 u; v : er 1 j gr 1u = gr 1v � u = v) ^ ::: ^ (8 u; v : er nr j gr nru = gr nrv � u = v)8 b1; b2 : N �(8 w : f1 j(b1 = 1 ^ w = h1 1 _ ::: _ b1 = m1 ^ w = h1m1 _b1 = m1 + 1 ^ w 2 fx : g11 � x : 2g _ ::: _ b1 = m1 + n1 ^ w 2 fx : g1n1 � x : 2g)^ (b2 = 1 ^ w = h1 1 _ ::: _ b2 = m1 ^ w = h1m1 _b2 = m1 + 1 ^ w 2 fx : g11 � x : 2g _ ::: _ b2 = m1 + n1 ^ w 2 fx : g1n1 � x : 2g) �b1 = b2) ^... ^(8 w : fr j(b1 = 1 ^ w = hr 1 _ ::: _ b1 = mr ^ w = hrmr _b1 = mr + 1 ^ w 2 fx : gr 1 � x : 2g _ ::: _ b1 = mr + nr ^ w 2 fx : gr nr � x : 2g)^ (b2 = 1 ^ w = hr 1 _ ::: _ b2 = mr ^ w = hrmr _b2 = mr + 1 ^ w 2 fx : gr 1 � x : 2g _ ::: _ b2 = mr + nr ^ w 2 fx : gr nr � x : 2g) �b1 = b2)8 w1 : Pf1; :::; wr : Pfr jh1 1 2 w1 ^ ::: ^ h1m1 2 w1 ^... ^hr 1 2 wr ^ ::: ^ hrmr 2 wr ^(8 y : (� f1 == w1; :::; fr == wr � e1 1) � g1 1y 2 w1) ^::: ^ (8 y : (� f1 == w1; :::; fr == wr � e1n1) � g1n1y 2 w1) ^... ^(8 y : (� f1 == w1; :::; fr == wr � er 1) � gr 1y 2 wr) ^::: ^ (8 y : (� f1 == w1; :::; fr == wr � er nr ) � gr nry 2 wr) �w1 = f1 ^ ::: ^ wr = frENDThe type names are introduced by the given types paragraph. The elements are declared as members of their cor-responding free types. The injections are declared as functions from values in their domains to their correspondingfree type.The �rst of the four blank-line separated predicates is the total functionality property. It ensures that for everyinjection, the injection is functional at every value in its domain.c ISO/IEC 2000|All rights reserved 67

ISO/IEC 13568:2000(E) 14 Semantic transformation rulesThe second of the four blank-line separated predicates is the injectivity property. It ensures that for everyinjection, any pair of values in its domain for which the injection returns the same value shall be a pair of equalvalues (hence the name injection).The third of the four blank-line separated predicates is the disjointness property. It ensures that for every freetype, every pair of values of the free type are equal only if they are the same element or are returned by applicationof the same injection to equal values.The fourth of the four blank-line separated predicates is the induction property. It ensures that for every freetype, its members are its elements, the values returned by its injections, and nothing else.The generated � expressions in the induction property are intended to e�ect substitutions of all references to thefree type names, including any such references within generic instantiation lists in the e expressions.NOTE 2 That is why this is a semantic transformation not a syntactic one: all implicit generic instantiations shallhave been made explicit before it is applied.NOTE 3 The right-hand side of this transformation could have been expressed using the following notation fromthe mathematical toolkit, but for the desire to de�ne the core language separately from the mathematical toolkit.[f1; :::; fr]ENDAXh1 1; :::; h1m1 : f1...hr 1; :::; hr mr : frg1 1 : e1 1� f1; :::; g1n1 : e1n1 � f1...gr 1 : er 1� fr; :::; gr nr : er nr � frjdisjointhfh1 1g; :::; fh1m1g; ran g1 1; :::; ran g1n1i...disjointhfhr 1g; :::; fhr mrg; ran gr 1; :::; ran gr nr i8 w1 : Pf1; :::; wr : Pfr jfh1 1; :::; h1m1g [ g1 1(j � f1 == w1; :::; fr == wr � e1 1 j)[::: [ g1n1(j � f1 == w1; :::; fr == wr � e1n1 j) � w1 ^... ^fhr 1; :::; hrmrg [ gr 1(j � f1 == w1; :::; fr == wr � er 1 j)[::: [ gr nr (j � f1 == w1; :::; fr == wr � er nr j) � wr �w1 = f1 ^ ::: ^ wr = frEND14.2.4 Predicate14.2.4.1 Unique existential predicateThe unique existential quanti�cation predicate 91 e � p is true if and only if there is exactly one value for e forwhich p is true. 91 e � p =) : (8 e � : (p ^ (8 [e j p]1 � � e = � e 1 )))68 c ISO/IEC 2000|All rights reserved

14 Semantic transformation rules ISO/IEC 13568:2000(E)NOTE Exploiting notation that is not present in the annotated syntax, this abbreviates to the following.91 e � p =) 9 e � p ^ (8 [e j p]1 � � e = � e 1)It is semantically equivalent to there existing at least one value for e for which p is true and all those values forwhich it is true being the same.14.2.5 Expression14.2.5.1 Tuple selection expressionThe value of the tuple selection expression e : b is the b'th component of the tuple that is the value of e.(e oo �1 � :::� �n) : b =) fi : carrier (�1 � :::� �n) �(i; � i1 : carrier �1; :::; in : carrier �n j i = (i1; :::; in) � ib)g eNOTE Exploiting notation that is not present in the annotated syntax, this abbreviates to the following.(e oo �1 � :::� �n) : b =) (� i : carrier (�1 � :::� �n) �� i1 : carrier �1; :::; in : carrier �n j i = (i1; :::; in) � ib) eIt is semantically equivalent to the function construction, from tuples of the Cartesian product type to the selectedcomponent of the tuple b, applied to the particular tuple e.14.2.5.2 Binding construction expressionThe value of the binding construction expression � e � is the binding whose names are those in the signature ofschema e and whose values are those of the same names with the optional decoration appended.� e � oo [i1 : �1; :::; in : �n] =) hj i1 == i1 decor �; :::; in == in decor � jiIt is semantically equivalent to the binding extension expression whose value is that binding.14.2.5.3 Binding selection expressionThe value of the binding selection expression e : i is that value associated with i in the binding that is the valueof e. (e oo [�]) : i =) fcarrier [�] � (chartuple (carrier [�]); i)g eNOTE Exploiting notation that is not present in the annotated syntax, this abbreviates to the following.(e oo [�]) : i =) (� carrier [�] � i) eIt is semantically equivalent to the function construction expression, from bindings of the schema type of e, tothe value of the selected name i, applied to the particular binding e.14.2.5.4 Application expressionThe value of the application expression e1 e2 is the sole value associated with e2 in the relation e1.e1 e2 oo � =) (� i : carrier � j (e2; i) 2 e1 � i)It is semantically equivalent to that sole range value i such that the pair (e2; i) is in the set of pairs that is thevalue of e1. If there is no value or more than one value associated with e2, then the application expression has avalue but what it is is not speci�ed.c ISO/IEC 2000|All rights reserved 69

ISO/IEC 13568:2000(E) 14 Semantic transformation rules14.2.5.5 Schema hiding expressionThe value of the schema hiding expression e n (i1; :::; in) is that schema whose signature is that of schema eminus the hidden names, and whose bindings have the same values as those in schema e.(e oo P[�]) n (i1; :::; in) =) : (8 i1 : carrier (� i1); :::; in : carrier (� in) � : e)NOTE Exploiting notation that is not present in the annotated syntax, this abbreviates to the following.(e oo P[�]) n (i1; :::; in) =) 9 i1 : carrier (� i1); :::; in : carrier (� in) � eIt is semantically equivalent to the schema existential quanti�cation of the hidden names i1; :::; in from the schemae.14.2.5.6 Schema unique existential quanti�cation expressionThe value of the schema unique existential quanti�cation expression 91 e1 � e2 is the set of bindings of schemae2 restricted to exclude names that are in the signature of e1, for at least one binding of the schema e1.91 e1 � e2 =) : (8 e1 � : (e2 ^ (8 [e1 j e2]1 � � e1 = � e1 1)))NOTE Exploiting notation that is not present in the annotated syntax, this abbreviates to the following.91 e1 � e2 =) 9 e1 � e2 ^ (8 [e1 j e2]1 � � e1 = � e1 1)It is semantically equivalent to a schema existential quanti�cation expression, analogous to the unique existentialquanti�cation predicate transformation.14.2.5.7 Schema precondition expressionThe value of the schema precondition expression pre e is that schema which is like schema e but without itsprimed and shrieked components.pre(e oo P[�1]) oo P[�2] =) : (8 carrier [�1 n �2] � : e)NOTE Exploiting notation that is not present in the annotated syntax, this abbreviates to the following.pre(e oo P[�1]) oo P[�2] =) 9 carrier [�1 n �2] � eIt is semantically equivalent to the existential quanti�cation of the primed and shrieked components from theschema e.14.2.5.8 Schema composition expressionThe value of the schema composition expression e1 o9 e2 is that schema representing the operation of doing theoperations represented by schemas e1 and e2 in sequence.(e1 oo P[�1]) o9 (e2 oo P[�2]) oo P[�]=): (8 e1 � : (: (8 e3 � : [e1; e1 j � e3 = � e1])^ : (8 e4 � : [e2; e1 j � e4 = � e1])))where e3 == carrier [fi : NAME; � : Type j i decor 0 7! � 2 �1 � i decor 0 7! �g]and e4 == carrier [fi : NAME; � : Type j i 7! � 2 �2 � i 7! �g]and e1 == (e4)170 c ISO/IEC 2000|All rights reserved

15 Semantic relations ISO/IEC 13568:2000(E)NOTE Exploiting notation that is not present in the annotated syntax, this abbreviates to the following.(e1 oo P[�1]) o9 (e2 oo P[�2]) oo P[�]=)9 e1 � (9 e3 � [e1; e1 j � e3 = � e1])^ (9 e4 � [e2; e1 j � e4 = � e1])where e3 == carrier [fi : NAME; � : Type j i decor 0 7! � 2 �1 � i decor 0 7! �g]and e4 == carrier [fi : NAME; � : Type j i 7! � 2 �2 � i 7! �g]and e1 == (e4)1It is semantically equivalent to the existential quanti�cation of the matched pairs of primed components of e1and unprimed components of e2, with those matched pairs being equated.14.2.5.9 Schema piping expressionThe value of the schema piping expression e1 >> e2 is that schema representing the operation formed from thetwo operations represented by schemas e1 and e2 with the outputs of e1 identi�ed with the inputs of e2.(e1 oo P[�1])>> (e2 oo P[�2]) oo P[�]=): (8 e1 � : (: (8 e3 � : [e1; e1 j � e3 = � e1])^ : (8 e4 � : [e2; e1 j � e4 = � e1])))where e3 == carrier [fi : NAME; � : Type j i decor ! 7! � 2 �1 � i decor ! 7! �g]and e4 == carrier [fi : NAME; � : Type j i decor ? 7! � 2 �2 � i decor ? 7! �g]and e1 == (e4)1NOTE Exploiting notation that is not present in the annotated syntax, this abbreviates to the following.(e1 oo P[�1])>> (e2 oo P[�2]) oo P[�]=)9 e1 � (9 e3 � [e1; e1 j � e3 = � e1])^ (9 e4 � [e2; e1 j � e4 = � e1])where e3 == carrier [fi : NAME; � : Type j i decor ! 7! � 2 �1 � i decor ! 7! �g]and e4 == carrier [fi : NAME; � : Type j i decor ? 7! � 2 �2 � i decor ? 7! �g]and e1 == (e4)1It is semantically equivalent to the existential quanti�cation of the matched pairs of shrieked components of e1and queried components of e2, with those matched pairs being equated.14.2.5.10 Schema decoration expressionThe value of the schema decoration expression e + is that schema whose bindings are like those of the schema eexcept that their names have the addition stroke +.(e oo P[i1 : �1; :::; in : �n])+ =) e [i1 decor + = i1; :::; in decor + = in]It is semantically equivalent to the schema renaming where decorated names rename the original names.15 Semantic relations15.1 IntroductionThe semantic relations de�ne the meaning of the remaining annotated notation (that not de�ned by semantictransformation rules) by relation to sets of models in ZF set theory. The only sentences of concern here are onesthat are already known to be well-formed syntactically and well-typed.This clause de�nes the meaning of a Z speci�cation in terms of the semantic values that its global variables maytake consistent with the constraints imposed on them by the speci�cation.This de�nition is loose: it leaves the values of ill-formed de�nite description expressions unde�ned. It is otherwisetight: it speci�es the values of all expressions that do not depend on values of ill-formed de�nite descriptions,c ISO/IEC 2000|All rights reserved 71

ISO/IEC 13568:2000(E) 15 Semantic relationsevery predicate is either true or false, and every expression denotes a value. The looseness leaves the valuesof unde�ned expressions unspeci�ed. Any particular semantics conforms to this International Standard if it isconsistent with this loose de�nition.EXAMPLE The predicate (� x : f g) 2 T could be either true or false depending on the treatment of unde�nedness.NOTE 1 Typical speci�cations contain expressions that in some circumstances have unde�ned values. In thosecircumstances, those expressions ought not to a�ect the meaning of the speci�cation. This de�nition is then su�cientlytight.NOTE 2 Alternative treatments of unde�ned expressions include one or more bottoms outside of the carrier sets,or undetermined values from within the carrier sets.15.2 Formal de�nition of semantic relations15.2.1 Speci�cation15.2.1.1 Sectioned speci�cation[[ s1 ::: sn ]]Z = ([[ section prelude::: ]]S o9 [[ s1 ]]S o9 ::: o9 [[ sn ]]S) ?The meaning of the Z speci�cation s1 ::: sn is the function from sections' names to their sets of models formedby starting with the empty function and extending that with a maplet from a section's name to its set of modelsfor each section in the speci�cation, starting with the prelude.To determine [[ section prelude::: ]]Z another prelude shall not be pre�xed onto it.NOTE The meaning of a speci�cation is not the meaning of its last section, so as to permit several meaningful unitswithin a single document.15.2.2 Section15.2.2.1 Inheriting sectionThe prelude section, as de�ned in clause 11, is treated specially, as it is the only one that does not have preludeas an implicit parent. [[ section prelude parents END d1 ::: dn ]]S=� T : SectionModels � fprelude 7! ([[ d1 ]]D o9 ::: o9 [[ dn ]]D) (j f?g j)gThe meaning of the prelude section is given by that constant function which, whatever function from sections'names and their sets of models it is given, returns the singleton set mapping the name prelude to its set of models.The set of models is that to which the set containing an empty model is related by the composition of the relationsbetween models that denote the meanings of each of the prelude's paragraphs|see clause 11 for details of thoseparagraphs.NOTE One model of the prelude section can be written as follows.fA 7! A ;N 7! N;number literal 0 7! 0;number literal 1 7! 1;+ 7! f((0; 0); 0); ((0; 1); 1); ((1; 0); 1); ((1; 1); 2); :::ggThe behaviour of ( + ) on non-natural numbers, e.g. reals, has not been de�ned at this point, so the set of modelsfor the prelude section includes alternatives for every possible extended behaviour of addition.72 c ISO/IEC 2000|All rights reserved

15 Semantic relations ISO/IEC 13568:2000(E)[[ section i parents i1; :::; im END d1 ::: dn ]]S=� T : SectionModels � T [ fi 7!([[ d1 ]]D o9 ::: o9 [[ dn ]]D) (j fM0 : T prelude; M1 : T i1; :::; Mm : T im; M : Model j M =M0[M1[ :::[Mm � Mg j)gThe meaning of a section other than the prelude is the extension of a function from sections' names to their setsof models with a maplet from the given section's name to its set of models. The given section's set of modelsis that to which the union of the models of the section's parents is related by the composition of the relationsbetween models that denote the meanings of each of the section's paragraphs.15.2.3 Paragraph15.2.3.1 Given types paragraphThe given types paragraph [i1; :::; in] END introduces unconstrained global names.[[ [i1; :::; in] END ]]D = fM : Model ; w1; :::; wn : W�M 7! M [ fi1 7! w1; :::; in 7! wng[ fi1 decor ~ 7! w1; :::; in decor ~ 7! wnggIt relates a model M to that model extended with associations between the names of the given types and semanticvalues chosen to represent their carrier sets. Associations for names decorated with the reserved stroke ~ are alsointroduced, so that references to them from given types (15.2.6.1) can avoid being captured.15.2.3.2 Axiomatic description paragraphThe axiomatic description paragraph AX e END introduces global names and constraints on their values.[[ AX e END ]]D = fM : Model ; t : W j t 2 [[ e ]]EM � M 7! M [ tgIt relates a model M to that model extended with a binding t of the schema that is the value of e in model M.15.2.3.3 Generic axiomatic description paragraphThe generic axiomatic description paragraph GENAX [i1; :::; in] e END introduces global names and constraints ontheir values, with generic parameters that have to be instantiated (by sets) whenever those names are referenced.[[ GENAX [i1; :::; in] (e oo P[j1 : �1; :::; jm : �m]) END ]]D =fM : Model ; u : W " n ! Wj 8 w1; :::; wn : W � 9 w : W �u (w1; :::; wn ) 2 w^ (M � fi1 7! w1; :::; in 7! wng [ fi1 decor � 7! w1; :::; in decor � 7! wng) 7! w 2 [[ e ]]E�M 7! M [ � y : fj1; :::; jmg � � x : W " n � u x ygGiven a model M and generic argument sets w1; :::; wn , the semantic value of the schema e in that modeloverridden by the association of the generic parameter names with those sets is w . All combinations of genericargument sets are considered. The function u maps the generic argument sets to a binding in the schema w .The paragraph relates the model M to that model extended with the binding that associates the names of theschema e (namely j1; :::; jm) with the corresponding value in the binding resulting from application of u toarbitrary instantiating sets x . Associations for names decorated with the reserved stroke � are also introducedwhilst determining the semantic value of e, so that references to them from generic types (15.2.6.2) can avoidbeing captured.15.2.3.4 Conjecture paragraphThe conjecture paragraph `? p END expresses a property that may logically follow from the speci�cation. It maybe a starting point for a proof. [[ `? p END ]]D = id Modelc ISO/IEC 2000|All rights reserved 73

ISO/IEC 13568:2000(E) 15 Semantic relationsIt relates a model to itself: the truth of p in a model does not a�ect the meaning of the speci�cation.15.2.3.5 Generic conjecture paragraphThe generic conjecture paragraph [i1; :::; in] `? p END expresses a generic property that may logically follow fromthe speci�cation. It may be a starting point for a proof.[[ [i1; :::; in] `? p END ]]D = id ModelIt relates a model to itself: the truth of p in a model does not a�ect the meaning of the speci�cation.15.2.4 PredicateThe set of models de�ning the meaning of a predicate is determined from the values of its constituent expressions.The set therefore depends on the particular treatment of unde�nedness.15.2.4.1 Membership predicateThe membership predicate e1 2 e2 is true if and only if the value of e1 is in the set that is the value of e2.[[ e1 2 e2 ]]P = fM : Model j [[ e1 ]]EM 2 [[ e2 ]]EM �MgIn terms of the semantic universe, it is true in those models in which the semantic value of e1 is in the semanticvalue of e2, and is false otherwise.15.2.4.2 Truth predicateA truth predicate is always true. [[ true ]]P = ModelIn terms of the semantic universe, it is true in all models.15.2.4.3 Negation predicateThe negation predicate : p is true if and only if p is false.[[ : p ]]P = Model n [[ p ]]PIn terms of the semantic universe, it is true in all models except those in which p is true.15.2.4.4 Conjunction predicateThe conjunction predicate p1 ^ p2 is true if and only if p1 and p2 are true.[[ p1 ^ p2 ]]P = [[ p1 ]]P \ [[ p2 ]]PIn terms of the semantic universe, it is true in those models in which both p1 and p2 are true, and is falseotherwise.15.2.4.5 Universal quanti�cation predicateThe universal quanti�cation predicate 8 e � p is true if and only if predicate p is true for all bindings of theschema e. [[ 8 e � p ]]P = fM : Model j 8 t : [[ e ]]EM �M � t 2 [[ p ]]P � MgIn terms of the semantic universe, it is true in those models for which p is true in that model overridden by allbindings in the semantic value of e, and is false otherwise.15.2.5 ExpressionEvery expression has a semantic value, speci�ed by the following semantic relations. The value of an unde�nedde�nite description expression is left loose, and hence the values of larger expressions containing unde�ned valuesare also loosely speci�ed.74 c ISO/IEC 2000|All rights reserved

15 Semantic relations ISO/IEC 13568:2000(E)15.2.5.1 Reference expressionThe value of the reference expression that refers to a non-generic de�nition i is the value of the declaration towhich it refers. [[ i ]]E = � M : Model � M iIn terms of the semantic universe, its semantic value, given a model M, is that associated with the name i in M.15.2.5.2 Generic instantiation expressionThe value of the generic instantiation expression i [e1; :::; en] is a particular instance of the generic referred to byname i

ISO/IEC 13568:2000(E) 15 Semantic relations15.2.5.8 De�nite description expressionThe value of the de�nite description expression � e1 � e2 is the sole value of e2 that arises whichever binding ischosen from the set that is the value of schema e1.fM : Model ; t1 : Wj t1 2 [[ e1 ]]EM^ (8 t3 : [[ e1 ]]EM � [[ e2 ]]E (M � t3) = [[ e2 ]]E (M � t1))� M 7! [[ e2 ]]E (M � t1)g � [[ � e1 � e2 ]]EIn terms of the semantic universe, its semantic value, given a model M in which the value of e2 in that modeloverridden by a binding of the schema e1 is the same regardless of which binding is chosen, is that value of e2.In other models, it has a semantic value, but this loose de�nition of the semantics does not say what it is.15.2.5.9 Variable construction expressionThe value of the variable construction expression [i : e] is the set of all bindings whose sole name is i and whoseassociated value is in the set that is the value of e.[[ [i : e] ]]E = � M : Model � fw : [[ e ]]EM � fi 7! wggIn terms of the semantic universe, its semantic value, given a model M, is the set of all singleton bindings (setsof pairs) of the name i associated with a value from the set that is the semantic value of e in M.15.2.5.10 Schema construction expressionThe value of the schema construction expression [e j p] is the set of all bindings of schema e that satisfy theconstraints of predicate p.[[ [e j p] ]]E = � M : Model � ft : [[ e ]]EM j M � t 2 [[ p ]]P � tgIn terms of the semantic universe, its semantic value, given a model M, is the set of the bindings (sets of pairs)that are members of the semantic value of schema e in M such that p is true in the model M overridden withthat binding.15.2.5.11 Schema negation expressionThe value of the schema negation expression : e is that set of bindings that are of the same type as those inschema e but that are not in schema e.[[ : e oo P � ]]E = � M : Model � ft : [[ � ]]TM j : t 2 [[ e ]]EM � tgIn terms of the semantic universe, its semantic value, given a model M, is the set of the bindings (sets of pairs)that are members of the semantic value of the carrier set of schema e in M such that those bindings are notmembers of the semantic value of schema e in M.15.2.5.12 Schema conjunction expressionThe value of the schema conjunction expression e1 ^ e2 is the schema resulting from merging the signatures ofschemas e1 and e2 and conjoining their constraints.[[ e1 ^ e2 oo P � ]]E = � M : Model � ft : [[ � ]]TM; t1 : [[ e1 ]]EM; t2 : [[ e2 ]]EM j t1 [ t2 = t � tgIn terms of the semantic universe, its semantic value, given a model M, is the set of the unions of the bindings(sets of pairs) in the semantic values of e1 and e2 in M.15.2.5.13 Schema universal quanti�cation expressionThe value of the schema universal quanti�cation expression 8 e1 � e2 is the set of bindings of schema e2 restrictedto exclude names that are in the signature of e1, for all bindings of the schema e1.[[ 8 e1 � e2 oo P � ]]E = � M : Model � ft2 : [[ � ]]TM j 8 t1 : [[ e1 ]]EM � t1 [ t2 2 [[ e2 ]]E (M � t1) � t2g76 c ISO/IEC 2000|All rights reserved

15 Semantic relations ISO/IEC 13568:2000(E)In terms of the semantic universe, its semantic value, given a model M, is the set of the bindings (sets of pairs)in the semantic values of the carrier set of the type of the entire schema universal quanti�cation expression inM, for which the union of the bindings (sets of pairs) in e1 and in the whole expression is in the set that is thesemantic value of e2 in the model M overridden with the binding in e1.15.2.5.14 Schema renaming expressionThe value of the schema renaming expression e [j1 = i1; :::; jn = in] is that schema whose bindings are like thoseof schema e except that some of its names have been replaced by new names, possibly merging components.[[ e [j1 = i1; :::; jn = in] ]]E = � M : Model �ft1 : [[ e ]]EM; t2 : W jt2 = fj1 7! i1; :::; jn 7! ing o9 t1 [ fi1; :::; ing �C t1^ t2 2 ( 7! )� t2gIn terms of the semantic universe, its semantic value, given a model M, is the set of the bindings (sets of pairs)in the semantic value of e in M with the new names replacing corresponding old names. Where components aremerged by the renaming, those components shall have the same value.15.2.6 TypeThe value of a type is its carrier set.NOTE 1 For an expression e with a de�ned value, [[ e oo � ]]E 2 [[ � ]]T .NOTE 2 Variable types do not appear in the type annotations of well-typed speci�cations, so do not need to begiven semantics here.NOTE 3 The value of a generic type, [[ [i1; :::; in] � ]]T , is never needed, and so is not de�ned.NOTE 4 [[ � ]]TM di�ers from carrier � in that the former application returns a semantic value whereas the latterapplication returns an annotated parse tree.15.2.6.1 Given type [[ GIVEN i ]]T = � M : Model � M (i decor ~)The semantic value of the given type GIVEN i, given a model M, is the semantic value associated with the giventype name i in M.15.2.6.2 Generic parameter type[[ GENTYPE i ]]T = � M : Model �M (i decor �)The semantic value of the generic type GENTYPE i, given a model M, is the semantic value associated with genericparameter name i in M.15.2.6.3 Powerset type [[ P � ]]T = � M : Model � P ([[ � ]]TM)The semantic value of the set type P �, given a model M, is the powerset of the semantic value of type � in M.c ISO/IEC 2000|All rights reserved 77

ISO/IEC 13568:2000(E) 15 Semantic relations15.2.6.4 Cartesian product type[[ �1 � :::� �n ]]T = � M : Model � ([[ �1 ]]TM)� :::� ([[ �n ]]TM)The semantic value of the Cartesian product type �1 � :::� �n, given a model M, is the Cartesian product of thesemantic values of types �1::: �n in M.15.2.6.5 Schema type[[ [i1 : �1; :::; in : �n] ]]T = � M : Model� ft : fi1; :::; ing ! W j t i1 2 [[ �1 ]]TM ^ ::: ^ t in 2 [[ �n ]]TM � tgThe semantic value of the schema type [i1 : �1; :::; in : �n], given a model M, is the set of bindings, representedby sets of pairs of names and values, for which the names are those of the schema type and the associated valuesare the semantic values of the corresponding types in M.

78 c ISO/IEC 2000|All rights reserved

A Mark-ups ISO/IEC 13568:2000(E)Annex A(normative)Mark-upsA.1 IntroductionA mark-up is a mapping to (or from) the ISO/IEC 10646 representation. The ISO/IEC 10646 representation maybe used directly|the identity function is an acceptable mapping. However, not all systems support ISO/IEC10646, the de�nitive representation of Z characters (clause 6). This annex de�nes two mark-ups based on 7-bitASCII [4]:� a LATEX [9] mark-up, suitable for processing by that tool to render Z characters in their mathematical form;� an email, or lightweight ASCII, mark-up, suitable for rendering Z characters on a low resolution device, suchas an ASCII-character-based terminal, or in email correspondence.The mark-ups described in this annex show how to translate between a `mark-up token' (string of ASCII mark-upcharacters) into the corresponding string of Z characters. Remaining individual mark-up characters that do notform a special mark-up token (such as digits, Latin letters, and much punctuation) are converted directly to thecorresponding Z character, e.g. from ASCII-xy to 0000 00xy in ISO/IEC 10646. Use of di�erent sequences ofmark-up characters that correspond to the same Z characters are permitted by this International Standard, asthe same tokens will result. Tools may require tokens to be marked-up consistently.A chosen mark-up language may also be used to specify a particular rendering for the characters, for example,bold or italic.The semantics of a speci�cation are speci�ed by the normative clauses of this International Standard on theassumption that its sections are in a de�nition before use order. This restriction need not be imposed on theorder in which sections are presented to a human reader or to a tool. If the mark-up of a speci�cation is scannedrecognising only section headers, then a de�nition before use order for the sections can be determined (unlessthere are erroneous cycles in the parents relation), and the contents of the sections can then be scanned in thatorder.A.2 LATEX mark-upA LATEX command is a backslash `\' followed by a string of alphabetic characters (up to the �rst non-alphabeticcharacter), or by a single non-alphabetic character.A.2.1 Letter charactersA.2.1.1 Greek alphabet charactersOnly the minimal subset of Greek alphabet de�ned in 6.2 need be supported by an implementation. LATEXdoes not support upper case Greek letters that look like Roman counterparts. Those Greek characters that aresupported shall use the mark-up given here.LATEX command Z character string\Delta �\Xi �\theta �\lambda �\mu �c ISO/IEC 2000|All rights reserved 79

ISO/IEC 13568:2000(E) A Mark-upsA.2.1.2 Other Z core language letter charactersLATEX command Z character string\arithmos A\nat N\power PA.2.2 Special charactersA.2.2.1 Special characters except Box charactersLATEX command Z character string\_\{ f\} g\ldata hh\rdata ii\lblot hj\rblot jiSubscripts and superscripts shall be marked up as follows:LATEX command Z character string^ hsingle LATEX tokeni %h Z string i .^{ hLATEX tokensi } %h Z string i ._ hsingle LATEX tokeni &h Z string i -_{ hLATEX tokensi } &h Z string i -EXAMPLE LATEX mark-up x^1 corresponds to Z character string `x % 1.', which may be rendered `x 1'LATEX mark-up x^{1} corresponds to Z character string `x % 1.', which may be rendered `x 1'LATEX mark-up x^{\Delta S} corresponds to Z character string `x % �S .', which may be rendered `x�S 'LATEX mark-up \exists_1 corresponds to Z character string `9 & 1-', which may be rendered `91'LATEX mark-up \exists_{1} corresponds to Z character string `9 & 1-', which may be rendered `91'LATEX mark-up \exists_{\Delta S} corresponds to Z character string `9 & �S -', which may be rendered `9�S 'LATEX mark-up x_a^b corresponds to Z character string `x & a -% b .', which may be rendered `xa b 'LATEX mark-up x_{a^b} corresponds to Z character string `x & a % b .-', which may be rendered `xab 'A.2.2.2 Box charactersThe ENDCHAR character is used to mark the end of a Paragraph. The NLCHAR character is used to mark a hardnewline (see 7.5). Di�erent implementations may represent these characters in di�erent ways.The box characters are described in A.2.7, on paragraph mark-up.

80 c ISO/IEC 2000|All rights reserved

A Mark-ups ISO/IEC 13568:2000(E)A.2.3 Symbol characters (except mathematical toolkit characters)LATEX command Z character string\vdash `\land ^\lor _\implies )\iff ,\lnot :\forall 8\exists 9\cross �\in 2@ �\hide n\project �\semi o9\pipe >>A.2.4 Core tokensThe Roman typeface used for core tokens in this International Standard is obtained using the mark-up de�nedin A.2.10, with the following exceptions where there would otherwise be clashes with LATEX keywords.LATEX command Z character string\IF if\THEN then\ELSE else\LET let\SECTION sectionA.2.5 Mathematical toolkit characters and tokensThe mathematical toolkit need not be supported by an implementation. If any of its tokens are supported, theyshall use the mark-up given here.

c ISO/IEC 2000|All rights reserved 81

ISO/IEC 13568:2000(E) A Mark-upsLATEX command Z character string\rel $\fun !\neq 6=\notin 62\emptyset ?\subseteq �\subset �\cup [\cap \\setminus n\symdiff \bigcup S\bigcap T\finset F\mapsto 7!\comp o9\circ �\dres C\rres B\ndres �C\nrres �B\inv �\limg (j\rimg j)\oplus �\plus % +.\star % � .\pfun 7!\pinj 7�\inj �\psurj 7!!\surj !!\bij �!\ffun 7 7!\finj 7 7�\num Z\negate -- �\leq �< <\geq �> >\upto : :\# #\langle h\rangle i\cat a\extract �\filter �\dcat a=82 c ISO/IEC 2000|All rights reserved

A Mark-ups ISO/IEC 13568:2000(E)A.2.6 Section header mark-upSection headers are enclosed in a LATEX zsection environment. The \begin{zsection} is converted to SPACE.The \end{zsection} is converted to ENDCHAR.\begin{zsection}\SECTION NAME \parents ...\end{zsection}A.2.7 Paragraph mark-upEach formal Z paragraph appears between a pair of \begin{xxx} and \end{xxx} LATEX commands. Text notappearing between such commands is informal accompanying text.For boxed paragraphs, the \begin{xxx} command indicates some box character, while for other paragraphs the\begin{xxx} command is Z whitespace. Any middle line in a boxed paragraph is marked-up using the \whereLATEX command, which corresponds to the Z j character. The \end{xxx} command represents the Z ENDCHARcharacter.A.2.7.1 Axiomatic description paragraph mark-up\begin{axdef}DeclPart\wherePredicate\end{axdef}The mark-up \begin{axdef} is translated to an AXCHAR character. The mark-up \where is translated to a jcharacter. The mark-up \end{axdef} is translated to an ENDCHAR character.A.2.7.2 Schema de�nition paragraph mark-up\begin{schema}{NAME}DeclPart\wherePredicate\end{schema}The mark-up \begin{schema}{ } is translated to a SCHCHAR character. The mark-up \where is translated toa j character. The mark-up \end{schema} is translated to an ENDCHAR character.A.2.7.3 Generic axiomatic description paragraph mark-up\begin{gendef}[Formals]DeclPart\wherePredicate\end{gendef}The mark-up \begin{gendef} is translated to an AXCHAR and a GENCHAR character. The mark-up \where istranslated to a j character. The mark-up \end{gendef} is translated to an ENDCHAR character.A.2.7.4 Generic schema de�nition paragraph mark-up\begin{schema}{NAME}[Formals]DeclPart\wherePredicate\end{schema}c ISO/IEC 2000|All rights reserved 83

ISO/IEC 13568:2000(E) A Mark-upsThe mark-up \begin{schema}{ } is translated to a SCHCHAR and a GENCHAR character. The mark-up \whereis translated to a j character. The mark-up \end{schema} is translated to an ENDCHAR character.A.2.7.5 Free types paragraph mark-up\begin{zed}Freetype, { \& , Freetype }\end{zed}A.2.7.6 Other paragraph mark-upAll other paragraphs are enclosed in a pair of \begin{zed} and \end{zed} commands. \begin{zed} is convertedto white space and \end{zed} is converted to ENDCHAR.A.2.8 LATEX whitespace mark-upLATEX has `hard' white space (explicit LATEX mark-up) and `soft' white space (ASCII white space characters suchas space, tab, and new line that are converted to the Z character SPACE).The hard white space is converted as follows:LATEX command Z character string{ (empty)} (empty)~ SPACE\, SPACE\! SPACE\(space) SPACE\; SPACE\: SPACE\t1 SPACE\t2 SPACE\t3 SPACE\t4 SPACE\t5 SPACE\t6 SPACE\t7 SPACE\t8 SPACE\t9 SPACE\\ NLCHAR\also NLCHARThe conversion of LATEX Greek characters shall consume any immediately following soft white space. The con-version of LATEX symbol characters shall preserve any following soft white space. Any remaining soft white spaceshall be converted to the SPACE character.EXAMPLE 1 The LATEX command `\Delta S' converts to the Z string `�S '.EXAMPLE 2 The LATEX command `\Delta~S' converts to the Z string `� S '.EXAMPLE 3 The LATEX command `\power S' converts to the Z string `P S '.A.2.9 Introducing new Z charactersA new Z character is introduced by the following one-line directive.%%Zchar \LaTeXcommand U+nnnnSubsequent occurrences of this \LaTeXcommand shall be converted to the corresponding character in plane 1 ofISO/IEC 10646.84 c ISO/IEC 2000|All rights reserved

A Mark-ups ISO/IEC 13568:2000(E)NOTE 1 There may be an accompanying LATEX \DeclareMathSymbol for the same \LaTeXcommand, giving a corre-sponding character code as its expansion. The two characters thus de�ned are not required to be the same, but ifthey di�er, confusion may ensue.A LATEX command to abbreviate the LATEX mark-up of a sequence of Z characters is introduced by the followingone-line directive.%%Zstring \LaTeXcommand ZstringThe Zstring excludes any leading spaces.NOTE 2 There will typically be an accompanying LATEX \newcommand for the same \LaTeXcommand, giving the sameZstring as its expansion. The two expansions are not required to be the same, but if they di�er, confusion mayensue.Subsequent occurrences of this \LaTeXcommand shall be replaced by the corresponding Zstring and that mark-upshall be converted.The scope of one of these directives is the rest of the section in which it appears and any sections of which it isan ancestor, excluding the headers of those sections.NOTE 3 This is the same as the scope of a global de�nition.EXAMPLE %%Zchar \sqsubseteq U+2291%%Zstring \nattwo \nat_2A.2.10 Remaining LATEX mark-upAny remaining LATEX command names enclosed in braces, `{\aToken}', shall be converted to the equivalent Zcharacter string with the braces and leading backslash removed, as `aToken'.Any remaining LATEX command names shall be converted to the equivalent Z character string with the leadingbackslash removed, and with a SPACE character added at the beginning and end, as ` aToken '.EXAMPLE 1 LATEX mark-up: `{\dom}s', Z character string: `doms'.LATEX mark-up: `\dom s', Z character string: ` dom s'.EXAMPLE 2 LATEX mark-up: \IF \disjoint a \THEN x = y \mod z \ELSE x = y \div zZ character string: if disjoint a then x = y mod z else x = y div zA possible rendering: if disjoint a then x = y mod z else x = y div zA.3 Email mark-upThis email mark-up is designed primarily as a human-readable lightweight mark-up, but may also be processedby tools. The character `%' delimits an ASCII string used to represent a Z character string, for example `�' as`%x%'. This disambiguates it from, for example, the name `x'.Where there is no danger of ambiguity (for the human reader) the trailing `%' character, or both `%' characters,may be omitted to reduce clutter.A literal `%' character may be introduced into the text as `%%'.A.3.1 Letter charactersIn the following, the email string is to be used surrounded by a leading and trailing `%' character.Names that use only ASCII characters, or that are composed out of previously de�ned Z characters, are not listedhere.A.3.1.1 Greek alphabet charactersOnly the minimal subset of Greek alphabet de�ned in 6.2 need be supported by an implementation. Those Greekcharacters that are supported shall use the mark-up given here.c ISO/IEC 2000|All rights reserved 85

ISO/IEC 13568:2000(E) A Mark-upsEmail string Z character stringDelta �Xi �theta �lambda �mu �A.3.1.2 Other Z core language letter charactersEmail string Z character stringarithmos AN NP PA.3.2 Special charactersA.3.2.1 Special characters except Box charactersEmail string Z character string/^ %v/ .\v &^\ -<< hh>> ii<| hj|> jiA.3.2.2 Box charactersThe ENDCHAR character is used to mark the end of a Paragraph. There are several di�erent mark-ups for theENDCHAR character, depending on the kind of paragraph. They are described in A.3.5, on paragraph mark-up.The NLCHAR character is used to mark a hard newline (see 7.5).The email form of the box characters mimicks the mathematical form, as various boxes drawn around the text.They are described in A.3.5, on paragraph mark-up.

86 c ISO/IEC 2000|All rights reserved

A Mark-ups ISO/IEC 13568:2000(E)A.3.3 Symbol characters (except mathematical toolkit characters)Email string Z character string| j|- `/\ ^\/ _==> )<=> ,not :A 8E 9x �e 2@ �S\ nS|\ �S; o9S>> >>A.3.4 Mathematical toolkit characters and tokensThe mathematical toolkit need not be supported by an implementation. If any of its tokens are supported, theyshall use the mark-up given here.

c ISO/IEC 2000|All rights reserved 87

ISO/IEC 13568:2000(E) A Mark-upsEmail string Z character string<--> $--> !/= 6=/e 62(/) ?c_ �c �u [n \(-) uu Snn TF F|--> 7!; o9o �<: C:> B<-: �C:-> �B(| (j|) j)(+) �+ +* �-|-> 7!>-|-> 7�>--> �-|->> 7!!-->> !!>-->> �!-||-> 7 7!>-||-> 7 7�Z Z- - (unary negation)<= �>= �< h> i^ a/| �|\ �A.3.5 Paragraph mark-upA.3.5.1 Axiomatic description paragraph mark-up+..DeclPart|--Predicate88 c ISO/IEC 2000|All rights reserved

A Mark-ups ISO/IEC 13568:2000(E)-..The mark-up +.. is translated to an AXCHAR character. The mark-up |-- is translated to a j character. Themark-up -.. is translated to an ENDCHAR character.A.3.5.2 Schema de�nition paragraph mark-up+-- NAME ---DeclPart|--Predicate---The mark-up +-- --- is translated to a SCHCHAR character. The mark-up |-- is translated to a j character.The mark-up --- is translated to an ENDCHAR character.A.3.5.3 Generic axiomatic description paragraph mark-up+== [Formals] ===DeclPart|--Predicate-==The mark-up +== === is translated to an AXCHAR and a GENCHAR character. The mark-up |-- is translated toa j character. The mark-up -== is translated to an ENDCHAR character.A.3.5.4 Generic schema de�nition paragraph mark-up+-- NAME[Formals] ---DeclPart|--Predicate---The mark-up +-- --- is translated to a SCHCHAR and a GENCHAR character. The mark-up |-- is translated toa j character. The mark-up --- is translated to an ENDCHAR character.A.3.5.5 Other paragraph mark-upUnboxed formal paragraphs (and informal paragraphs where necessary) end with a `%%' on a line by itself, whichmark-up is translated to an ENDCHAR character.

c ISO/IEC 2000|All rights reserved 89

ISO/IEC 13568:2000(E) B Mathematical toolkitAnnex B(normative)Mathematical toolkitB.1 IntroductionThe mathematical toolkit is an optional extension to the compulsory core language. It comprises a hierarchy ofrelated sections, each de�ning operators that are widely used in common application domains.Figure B.1 { Parent relation between sections of the mathematical toolkitset toolkit6relation toolkit6function toolkit number toolkit@@I ���sequence toolkit6standard toolkitThe division of the mathematical toolkit into separate sections allows use of certain subsets of the toolkit ratherthan its entirety. For example, if sequences are not used in a particular speci�cation, then using function toolkitand number toolkit as parents avoids bringing the notation of sequence toolkit into scope. Notations that are notreused can be given di�erent de�nitions.A speci�cation without a section header has section standard toolkit as an implicit parent.B.2 Preliminary de�nitionssection set toolkitB.2.1 Relationsgeneric 5 rightassoc ( $ )X $ Y == P(X �Y )X $ Y is the set of relations between X and Y , that is, the set of all sets of ordered pairs whose �rst membersare members of X and whose second members are members of Y .B.2.2 Total functionsgeneric 5 rightassoc ( ! )X ! Y == f f : X $ Y j 8 x : X � 91 y : Y � (x ; y) 2 f gX ! Y is the set of all total functions from X to Y , that is, the set of all relations between X and Y such thateach x in X is related to exactly one y in Y .90 c ISO/IEC 2000|All rights reserved

B Mathematical toolkit ISO/IEC 13568:2000(E)B.3 SetsB.3.1 Inequality relationrelation ( 6= )[X ]6= : X $ X8 x ; y : X � x 6= y , : x = yInequality is the relation between those values of the same type that are not equal to each other.B.3.2 Non-membershiprelation ( 62 )[X ]62 : X $ PX8 x : X ; a : PX � x 62 a , : x 2 aNon-membership is the relation between those values of a type, x , and sets of values of that type, a, for which xis not a member of a.B.3.3 Empty set?[X ] == f x : X j false gThe empty set of any type is the set of that type that has no members.B.3.4 Subset relationrelation ( � )[X ]� : PX $ PX8 a; b : PX � a � b , (8 x : a � x 2 b)Subset is the relation between two sets of the same type, a and b, such that every member of a is a member of b.B.3.5 Proper subset relationrelation ( � )[X ]� : PX $ PX8 a; b : PX � a � b , a � b ^ a 6= bProper subset is the relation between two sets of the same type, a and b, such that a is a subset of b, and a andb are not equal.c ISO/IEC 2000|All rights reserved 91

ISO/IEC 13568:2000(E) B Mathematical toolkitB.3.6 Non-empty subsetsP1X == f a : PX j a 6= ? gIf X is a set, then P1X is the set of all non-empty subsets of X .NOTE The word P is established as a generic operator by the prelude.B.3.7 Set unionfunction 30 leftassoc ( [ )[X ][ : PX � PX ! PX8 a; b : PX � a [ b = f x : X j x 2 a _ x 2 b gThe union of two sets of the same type is the set of values that are members of either set.B.3.8 Set intersectionfunction 40 leftassoc ( \ )[X ]\ : PX � PX ! PX8 a; b : PX � a \ b = f x : X j x 2 a ^ x 2 b gThe intersection of two sets of the same type is the set of values that are members of both sets.B.3.9 Set di�erencefunction 30 leftassoc ( n )[X ]n : PX � PX ! PX8 a; b : PX � a n b = f x : X j x 2 a ^ x 62 b gThe di�erence of two sets of the same type is the set of values that are members of the �rst set but not membersof the second set.B.3.10 Set symmetric di�erencefunction 25 leftassoc ( )[X ] : PX � PX ! PX8 a; b : PX � a b = f x : X j : (x 2 a , x 2 b) gThe symmetric set di�erence of two sets of the same type is the set of values that are members of one set, or theother, but not members of both.92 c ISO/IEC 2000|All rights reserved

B Mathematical toolkit ISO/IEC 13568:2000(E)B.3.11 Generalized union[X ]S : PPX ! PX8A : PPX � SA = f x : X j 9 a : A � x 2 a gThe generalized union of a set of sets of the same type is the set of values of that type that are members of atleast one of the sets.B.3.12 Generalized intersection[X ]T : PPX ! PX8A : PPX � TA = f x : X j 8 a : A � x 2 a gThe generalized intersection of a set of sets of values of the same type is the set of values of that type that aremembers of every one of the sets.B.4 Finite setsB.4.1 Finite subsetsgeneric 80 ( F )F X == Tf A : PPX j ? 2 A ^ (8 a : A; x : X � a [ fxg 2 A) gIf X is a set, then F X is the set of all �nite subsets of X . The set of �nite subsets of X is the smallest set thatcontains the empty set and is closed under the action of adding single elements of X .B.4.2 Non-empty �nite subsetsF1X == F X n f?gIf X is a set, then F1X is the set of all non-empty �nite subsets of X . The set of non-empty �nite subsets of Xis the smallest set that contains the singleton sets of X and is closed under the action of adding single elementsof X .B.5 More notations for relationssection relation toolkit parents set toolkitB.5.1 First component projection[X ;Y ]�rst : X �Y ! X8 p : X �Y � �rst p = p:1For any ordered pair p, �rst p is the �rst component of the pair.B.5.2 Second component projection[X ;Y ]second : X �Y ! Y8 p : X �Y � second p = p:2For any ordered pair p, second p is the second component of the pair.c ISO/IEC 2000|All rights reserved 93

ISO/IEC 13568:2000(E) B Mathematical toolkitB.5.3 Mapletfunction 10 leftassoc ( 7! )[X ;Y ]7! : X �Y ! X �Y8 x : X ; y : Y � x 7! y = (x ; y)The maplet forms an ordered pair from two values; x 7! y is just another notation for (x ; y).B.5.4 Domain[X ;Y ]dom : (X $ Y )! PX8 r : X $ Y � dom r = f p : r � p:1 gThe domain of a relation r is the set of �rst components of the ordered pairs in r .B.5.5 Range[X ;Y ]ran : (X $ Y )! PY8 r : X $ Y � ran r = f p : r � p:2 gThe range of a relation r is the set of second components of the ordered pairs in r .B.5.6 Identity relationgeneric 80 ( id )id X == f x : X � x 7! x gThe identity relation on a set X is the relation that relates every member of X to itself.B.5.7 Relational compositionfunction 40 leftassoc ( o9 )[X ;Y ;Z ]o9 : (X $ Y )� (Y $ Z )! (X $ Z )8 r : X $ Y ; s : Y $ Z � r o9 s = f p : r ; q : s j p:2 = q :1 � p:1 7! q :2 gThe relational composition of a relation r : X $ Y and s : Y $ Z is a relation of type X $ Z formed by takingall the pairs p of r and q of s , where the second component of p is equal to the �rst component of q , and relatingthe �rst component of p with the second component of q .B.5.8 Functional compositionfunction 40 leftassoc ( � )[X ;Y ;Z ]� : (Y $ Z )� (X $ Y )! (X $ Z )8 r : X $ Y ; s : Y $ Z � s � r = r o9 sThe functional composition of s and r is the same as the relational composition of r and s .94 c ISO/IEC 2000|All rights reserved

B Mathematical toolkit ISO/IEC 13568:2000(E)B.5.9 Domain restrictionfunction 65 rightassoc ( C )[X ;Y ]C : PX � (X $ Y )! (X $ Y )8 a : PX ; r : X $ Y � a C r = f p : r j p:1 2 a gThe domain restriction of a relation r : X $ Y by a set a : PX is the set of pairs in r whose �rst componentsare in a.B.5.10 Range restrictionfunction 60 leftassoc ( B )[X ;Y ]B : (X $ Y )� PY ! (X $ Y )8 r : X $ Y ; b : PY � r B b = f p : r j p:2 2 b gThe range restriction of a relation r : X $ Y by a set b : PY is the set of pairs in r whose second componentsare in b.B.5.11 Domain subtractionfunction 65 rightassoc ( �C )[X ;Y ]�C : PX � (X $ Y )! (X $ Y )8 a : PX ; r : X $ Y � a �C r = f p : r j p:1 62 a gThe domain subtraction of a relation r : X $ Y by a set a : PX is the set of pairs in r whose �rst componentsare not in a.B.5.12 Range subtractionfunction 60 leftassoc ( �B )[X ;Y ]�B : (X $ Y )� PY ! (X $ Y )8 r : X $ Y ; b : PY � r �B b = f p : r j p:2 62 b gThe range subtraction of a relation r : X $ Y by a set b : PY is the set of pairs in r whose second componentsare not in b.B.5.13 Relational inversionfunction 90 ( � )[X ;Y ]� : (X $ Y )! (Y $ X )8 r : X $ Y � r� = f p : r � p:2 7! p:1 gThe inverse of a relation is the relation obtained by reversing every ordered pair in the relation.c ISO/IEC 2000|All rights reserved 95

ISO/IEC 13568:2000(E) B Mathematical toolkitB.5.14 Relational imagefunction 90 ( (j j) )[X ;Y ](j j) : (X $ Y )� PX ! PY8 r : X $ Y ; a : PX � r(j a j) = f p : r j p:1 2 a � p:2 gThe relational image of a set a : PX through a relation r : X $ Y is the set of values of type Y that are relatedunder r to a value in a.B.5.15 Overridingfunction 50 leftassoc ( � )[X ;Y ]� : (X $ Y )� (X $ Y )! (X $ Y )8 r ; s : X $ Y � r � s = ((dom s)�C r) [ sIf r and s are both relations between X and Y , the overriding of r by s is the whole of s together with thosemembers of r that have no �rst components that are in the domain of s .B.5.16 Transitive closurefunction 90 ( + )[X ]+ : (X $ X )! (X $ X )8 r : X $ X � r + = Tf s : X $ X j r � s ^ r o9 s � s gThe transitive closure of a relation r : X $ X is the smallest set that contains r and is closed under the actionof composing r with its members.B.5.17 Re exive transitive closurefunction 90 ( � )[X ]� : (X $ X )! (X $ X )8 r : X $ X � r � = r + [ id XThe re exive transitive closure of a relation r : X $ X is the relation formed by extending the transitive closureof r by the identity relation on X .B.6 Functionssection function toolkit parents relation toolkit96 c ISO/IEC 2000|All rights reserved

B Mathematical toolkit ISO/IEC 13568:2000(E)B.6.1 Partial functionsgeneric 5 rightassoc ( 7! )X 7! Y == f f : X $ Y j 8 p; q : f j p:1 = q :1 � p:2 = q :2 gX 7! Y is the set of all partial functions from X to Y , that is, the set of all relations between X and Y suchthat each x in X is related to at most one y in Y . The terms \function" and \partial function" are synonymous.B.6.2 Partial injectionsgeneric 5 rightassoc ( 7� )X 7� Y == f f : X $ Y j 8 p; q : f � p:1 = q :1, p:2 = q :2 gX 7� Y is the set of partial injections from X to Y , that is, the set of all relations between X and Y such thateach x in X is related to no more than one y in Y , and each y in Y is related to no more than one x in X . Theterms \injection" and \partial injection" are synonymous.B.6.3 Total injectionsgeneric 5 rightassoc ( � )X � Y == (X 7� Y ) \ (X ! Y )X � Y is the set of total injections from X to Y , that is, the set of injections from X to Y that are also totalfunctions from X to Y .B.6.4 Partial surjectionsgeneric 5 rightassoc ( 7!! )X 7!! Y == f f : X 7! Y j ran f = Y gX 7!! Y is the set of partial surjections from X to Y , that is, the set of functions from X to Y whose range isequal to Y . The terms \surjection" and \partial surjection" are synonymous.B.6.5 Total surjectionsgeneric 5 rightassoc ( !! )X !! Y == (X 7!! Y ) \ (X ! Y )X !! Y is the set of total surjections from X to Y , that is, the set of surjections from X to Y that are also totalfunctions from X to Y .B.6.6 Bijectionsgeneric 5 rightassoc ( �! )X �! Y == (X !! Y ) \ (X � Y )X �! Y is the set of bijections from X to Y , that is, the set of total surjections from X to Y that are also totalinjections from X to Y .c ISO/IEC 2000|All rights reserved 97

ISO/IEC 13568:2000(E) B Mathematical toolkitB.6.7 Finite functionsgeneric 5 rightassoc ( 7 7! )X 7 7! Y == (X 7! Y ) \ F(X �Y )The �nite functions from X to Y are the functions from X to Y that are also �nite sets.B.6.8 Finite injectionsgeneric 5 rightassoc ( 7 7� )X 7 7� Y == (X 7 7! Y ) \ (X 7� Y )The �nite injections from X to Y are the injections from X to Y that are also �nite functions from X to Y .B.6.9 Disjointnessrelation ( disjoint )[L;X ]disjoint : P(L$ PX )8 f : L$ PX � disjoint f , (8 p; q : f j p 6= q � p:2 \ q :2 = ?)A labelled family of sets is disjoint precisely when any distinct pair yields sets with no members in common.B.6.10 Partitionsrelation ( partition )[L;X ]partition : (L$ PX )$ PX8 f : L$ PX ; a : PX � f partition a , disjoint f ^ S(ran f ) = aA labelled family of sets f partitions a set a precisely when f is disjoint and the union of all the sets in f is a.B.7 Numberssectionnumber toolkitB.7.1 Successorfunction 80 ( succ )succ : P(N � N)(succ ) = � n : N � n + 1The successor of a natural number n is equal to n + 1.98 c ISO/IEC 2000|All rights reserved

B Mathematical toolkit ISO/IEC 13568:2000(E)B.7.2 IntegersZ : PAZ is the set of integers, that is, positive and negative whole numbers and zero. The set Z is characterised byaxioms for its additive structure given in the prelude (clause 11) together with the next formal paragraph below.Number systems that extend the integers may be speci�ed as supersets of Z.B.7.3 Addition of integers, arithmetic negationfunction 80 ( - )- : P(A � A )8 x ; y : Z � 91 z : Z � ((x ; y); z ) 2 ( + )8 x : Z � 91 y : Z � (x ; y) 2 (- )8 i ; j ; k : Z �(i + j ) + k = i + (j + k)^ i + j = j + i^ i + -i = 0^ i + 0 = iZ= fz : A j 9 x : N � z = x _ z = -xgThe binary addition operator ( + ) is de�ned in the prelude (clause 11). The de�nition here introduces additionalproperties for integers. The addition and negation operations on integers are total functions that take integervalues. The integers form a commutative group under ( + ) with (- ) as the inverse operation and 0 as theidentity element.NOTE If function toolkit notation were exploited, the negation operator could be de�ned as follows.- : A 7! A(Z�Z)C ( + ) 2 Z�Z! ZZC (- ) 2 Z! Z8 i ; j ; k : Z �(i + j ) + k = i + (j + k)^ i + j = j + i^ i + -i = 0^ i + 0 = i8 h : PZ �1 2 h ^ (8 i ; j : h � i + j 2 h ^ -i 2 h)) h = ZB.7.4 Subtractionfunction 30 leftassoc ( � )� : P((A � A ) � A )8 x ; y : Z � 91 z : Z � ((x ; y); z ) 2 ( � )8 i ; j : Z � i � j = i + -jSubtraction is a function whose domain includes all pairs of integers. For all integers i and j , i � j is equal toi + -j .c ISO/IEC 2000|All rights reserved 99

ISO/IEC 13568:2000(E) B Mathematical toolkitNOTE If function toolkit notation were exploited, the subtraction operator could be de�ned as follows.� : A � A 7! A(Z�Z)C ( � ) 2 Z�Z! Z8 i ; j : Z � i � j = i + -jB.7.5 Less-than-or-equalrelation ( � )� : P(A � A )8 i ; j : Z � i � j , j � i 2 NFor all integers i and j , i � j if and only if their di�erence j � i is a natural number.B.7.6 Less-thanrelation ( < )< : P(A � A )8 i ; j : Z � i < j , i + 1 � jFor all integers i and j , i < j if and only if i + 1 � j .B.7.7 Greater-than-or-equalrelation ( � )� : P(A � A )8 i ; j : Z � i � j , j � iFor all integers i and j , i � j if and only if j � i .B.7.8 Greater-thanrelation ( > )> : P(A � A )8 i ; j : Z � i > j , j < iFor all integers i and j , i > j if and only if j < i .B.7.9 Strictly positive natural numbersN1 == fx : N j : x = 0gThe strictly positive natural numbers N1 are the natural numbers except zero.100 c ISO/IEC 2000|All rights reserved

B Mathematical toolkit ISO/IEC 13568:2000(E)B.7.10 Non-zero integersZ1 == fx : Z j : x = 0gThe non-zero integers Z1 are the integers except zero.B.7.11 Multiplication of integersfunction 40 leftassoc ( � )� : P((A � A ) � A )8 x ; y : Z � 91 z : Z � ((x ; y); z ) 2 ( � )8 i ; j ; k : Z �(i � j ) � k = i � (j � k)^ i � j = j � i^ i � (j + k) = i � j + i � k^ 0 � i = 0^ 1 � i = iThe binary multiplication operator ( � ) is de�ned for integers. The multiplication operation on integers is atotal function and has integer values. Multiplication on integers is characterised by the unique operation underwhich the integers become a commutative ring with identity element 1.NOTE If function toolkit notation were exploited, the multiplication operator could be de�ned as follows.� : (A � A ) 7! A(Z�Z)C ( � ) 2 Z�Z! Z8 i ; j ; k : Z �(i � j ) � k = i � (j � k)^ i � j = j � i^ i � (j + k) = i � j + i � k^ 0 � i = 0^ 1 � i = iB.7.12 Division, modulusfunction 40 leftassoc ( div )function 40 leftassoc ( mod )div ; mod : P((A � A ) � A )8 x : Z; y : Z1 � 91 z : Z � ((x ; y); z ) 2 ( div )8 x : Z; y : Z1 � 91 z : Z � ((x ; y); z ) 2 ( mod )8 i : Z; j : Z1 �i = (i div j ) � j + i mod j^ (0 � i mod j < j _ j < i mod j � 0)For all integers i and non-zero integers j , the pair (i ; j ) is in the domain of div and of mod , and i div j andi mod j have integer values.When not zero, i mod j has the same sign as j . This means that i div j is the largest integer no greater than therational number i=j .c ISO/IEC 2000|All rights reserved 101

ISO/IEC 13568:2000(E) B Mathematical toolkitNOTE If function toolkit notation were exploited, the division and modulus operators could be de�ned as follows.div ; mod : A � A 7! A(Z�Z1)C ( div ) 2 Z�Z1! Z(Z�Z1)C ( mod ) 2 Z�Z1! Z8 i : Z; j : Z1 �i = (i div j ) � j + i mod j^ (0 � i mod j < j _ j < i mod j � 0)B.8 Sequencessection sequence toolkit parents function toolkit ;number toolkitB.8.1 Number rangefunction 20 leftassoc ( : : ): : : A � A 7! PA(Z�Z)C ( : : ) 2 Z�Z! PZ8 i ; j : Z � i : : j = f k : Z j i � k � j gThe number range from i to j is the set of all integers greater than or equal to i , which are also less than or equalto j .B.8.2 Iteration[X ]iter : Z! (X $ X )! (X $ X )8 r : X $ X � iter 0 r = id X8 r : X $ X ; n : N � iter (n + 1) r = r o9 (iter n r)8 r : X $ X ; n : N � iter (-n) r = iter n (r�)iter is the iteration function for a relation. The iteration of a relation r : X $ X for zero times is the identityrelation on X . The iteration of a relation r : X $ X for n + 1 times is the composition of the relation with itsiteration n times. The iteration of a relation r : X $ X for -n times is the iteration for n times of the inverse ofthe relation.function 90 ( )[X ] : (X $ X )�Z! (X $ X )8 r : X $ X ; n : N � rn = iter n riter n r may be written as rn .102 c ISO/IEC 2000|All rights reserved

B Mathematical toolkit ISO/IEC 13568:2000(E)B.8.3 Number of members of a setfunction 80 ( # )[X ]# : F X ! N8 a : F X � #a = (�n : N j (9 f : 1 : : n � a � ran f = a))The number of members of a �nite set is the upper limit of the number range starting at 1 that can be put intobijection with the set.B.8.4 Minimumfunction 80 ( min )min : PA 7! APZC (min ) = f a : PZ; m : Z j m 2 a ^ (8n : a � m � n) � a 7! m gIf a set of integers has a member that is less than or equal to all members of that set, that member is its minimum.B.8.5 Maximumfunction 80 ( max )max : PA 7! APZC (max ) = f a : PZ; m : Z j m 2 a ^ (8n : a � n � m) � a 7! m gIf a set of integers has a member that is greater than or equal to all members of that set, that member is itsmaximum.B.8.6 Finite sequencesgeneric 80 ( seq )seq X == f f : N 7 7! X j dom f = 1 : :#f gA �nite sequence is a �nite indexed set of values of the same type, whose domain is a contiguous set of positiveintegers starting at 1.seq X is the set of all �nite sequences of values of X , that is, of �nite functions from the set 1 : : n, for some n,to elements of X .B.8.7 Non-empty �nite sequencesseq1X == seq X n f?gseq1X is the set of all non-empty �nite sequences of values of X .B.8.8 Injective sequencesgeneric 80 ( iseq )iseq X == seq X \ (N 7� X )iseq X is the set of all injective �nite sequences of values of X , that is, of �nite sequences over X that are alsoinjections.c ISO/IEC 2000|All rights reserved 103

ISO/IEC 13568:2000(E) B Mathematical toolkitB.8.9 Sequence bracketsfunction ( h ; ; i )h i[X ] == � s : seq X � sThe brackets h and i can be used for enumerated sequences.B.8.10 Concatenationfunction 30 leftassoc ( a )[X ]a : seq X � seq X ! seq X8 s ; t : seq X � s a t = s [ f n : dom t � n +#s 7! t n gConcatenation is a function of a pair of �nite sequences of values of the same type whose result is a sequence thatbegins with all elements of the �rst sequence and continues with all elements of the second sequence.B.8.11 Reverse[X ]rev : seq X ! seq X8 s : seq X � rev s = �n : dom s � s(#s � n + 1)The reverse of a sequence is the sequence obtained by taking its elements in the opposite order.B.8.12 Head of a sequence[X ]head : seq1X ! X8 s : seq1X � head s = s 1If s is a non-empty sequence of values, then head s is the value that is �rst in the sequence.B.8.13 Last of a sequence[X ]last : seq1X ! X8 s : seq1X � last s = s(#s)If s is a non-empty sequence of values, then last s is the value that is last in the sequence.B.8.14 Tail of a sequence[X ]tail : seq1X ! seq X8 s : seq1X � tail s = �n : 1 : : (#s � 1) � s(n + 1)If s is a non-empty sequence of values, then tail s is the sequence of values that is obtained from s by discardingthe �rst element and renumbering the remainder.104 c ISO/IEC 2000|All rights reserved

B Mathematical toolkit ISO/IEC 13568:2000(E)B.8.15 Front of a sequence[X ]front : seq1X ! seq X8 s : seq1X � front s = f#sg �C sIf s is a non-empty sequence of values, then front s is the sequence of values that is obtained from s by discardingthe last element.B.8.16 Squashing[X ]squash : (Z 7 7! X )! seq X8 f : Z 7 7! X � squash f = f p : f � #f i : dom f j i � p:1 g 7! p:2 gsquash takes a �nite function f : Z 7 7! X and renumbers its domain to produce a �nite sequence.B.8.17 Extractionfunction 45 rightassoc ( � )[X ]� : PZ� seq X ! seq X8 a : PZ; s : seq X � a � s = squash(a C s)The extraction of a set a of indices from a sequence is the sequence obtained from the original by discarding anyindices that are not in the set a, then renumbering the remainder.B.8.18 Filteringfunction 40 leftassoc ( � )[X ]� : seq X � PX ! seq X8 s : seq X ; a : PX � s � a = squash(s B a)The �lter of a sequence by a set a is the sequence obtained from the original by discarding any members that arenot in the set a, then renumbering the remainder.B.8.19 Pre�x relationrelation ( pre�x )[X ]pre�x : seq X $ seq X8 s ; t : seq X � s pre�x t , s � tA sequence s is a pre�x of another sequence t if it forms the front portion of t .c ISO/IEC 2000|All rights reserved 105

ISO/IEC 13568:2000(E) B Mathematical toolkitB.8.20 Su�x relationrelation ( su�x )[X ]su�x : seq X $ seq X8 s ; t : seq X � s su�x t , (9 u : seq X � u a s = t)A sequence s is a su�x of another sequence t if it forms the end portion of t .B.8.21 In�x relationrelation ( in�x )[X ]in�x : seq X $ seq X8 s ; t : seq X � s in�x t , (9 u; v : seq X � u a s a v = t)A sequence s is an in�x of another sequence t if it forms a mid portion of t .B.8.22 Distributed concatenation[X ]a= : seq seq X ! seq Xa= h i = h i8 s : seq X � a= hsi = s8 q ; r : seq seq X � a=(q a r) = (a= q)a (a= r)The distributed concatenation of a sequence t of sequences of values of type X is the sequence of values of typeX that is obtained by concatenating the members of t in order.B.9 Standard toolkitsection standard toolkit parents sequence toolkitThe standard toolkit contains the de�nitions of section sequence toolkit (and implicitly those of its ancestralsections).

106 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)Annex C(normative)Organisation by concrete syntax productionC.1 IntroductionThis annex duplicates some of the de�nitions presented in the normative clauses, but re-organised by concretesyntax production. This re-organisation provides no suitable place to accommodate the material listed in the restof this introduction. That material is consequently omitted from this annex.a) From Concrete syntax, the rules de�ning:1) Formals, used in Generic axiomatic description paragraph, Generic schema paragraph, Generic horizon-tal de�nition paragraph, and Generic conjecture paragraph;2) DeclName, used in Branch, Schema hiding expression, Schema renaming expression, Colon declarationand Equal declaration;3) RefName, used in Reference expression, Generic instantiation expression, and Binding selection expres-sion;4) OpName and its auxiliaries, used in RefName and DeclName;5) ExpSep and ExpressionList, used in auxiliaries of Relation operator application predicates and Func-tion and generic operator application expressions;6) and also the operator precedences and associativities and additional syntactic restrictions.b) From Characterisation rules:1) Characteristic tuple.c) From Prelude:1) its text is relevant not just to number literal expressions but also to the list arguments in Relationoperator application predicates and Function and generic operator application expressions.d) From Syntactic transformation rules:1) Name and ExpressionList.e) From Type inference rules:1) Carrier set and Generic type instantiation.2) Summary of scope rules.f) From Semantic relations:1) all of the relations for Type are omitted.c ISO/IEC 2000|All rights reserved 107

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionAlso, the description of the overall e�ect of a phase, or how the phase operates, is generally omitted from thisannex.Moreover, some of the phases and representations are entirely omitted here, namely Mark-ups, Z characters, Lexisand Annotated syntax.C.2 Speci�cationC.2.1 IntroductionSpecification is the start symbol of the syntax. A Specification can be either a sectioned speci�cation oran anonymous speci�cation. A sectioned speci�cation comprises a sequence of named sections. An anonymousspeci�cation comprises a single anonymous section.C.2.2 Sectioned speci�cationC.2.2.1 SyntaxSpecification = { Section }| ...;C.2.2.2 Typefg S sprelude oo �0 �1 S s1 oo �1 ::: �n S sn oo �nZ s1 oo �1 ::: sn oo �n 0B@ �1 = fprelude 7! �0g...�n = �n�1 [ fin�1 7! �n�1g 1CAwhere in�1 is the name of section sn�1, and none of the sections s1 ... sn are named prelude.Each section is typechecked in an environment formed from preceding sections, and is annotated with an envi-ronment that it establishes.NOTE The environment established by the prelude section is as follows.�0 = (A ; (prelude;P(GIVEN A )));(N; (prelude;P(GIVEN A )));(number literal 0; (prelude; (GIVEN A )));(number literal 1; (prelude; (GIVEN A )));(1+1; (prelude;P(((GIVEN A ) � (GIVEN A )) � (GIVEN A ))))If one of the sections s1 ... sn is named prelude, then the same type inference rule applies except that the typesubsequent for the prelude section is omitted.C.2.2.3 Semantics[[ s1 ::: sn ]]Z = ([[ section prelude::: ]]S o9 [[ s1 ]]S o9 ::: o9 [[ sn ]]S) ?The meaning of the Z speci�cation s1 ::: sn is the function from sections' names to their sets of models formedby starting with the empty function and extending that with a maplet from a section's name to its set of modelsfor each section in the speci�cation, starting with the prelude.To determine [[ section prelude::: ]]Z another prelude shall not be pre�xed onto it.NOTE The meaning of a speci�cation is not the meaning of its last section, so as to permit several meaningful unitswithin a single document.108

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)C.2.3 Anonymous speci�cationC.2.3.1 SyntaxSpecification = ...| { Paragraph };C.2.3.2 TransformationThe anonymous speci�cation d1 ::: dn is semantically equivalent to the sectioned speci�cation comprising a singlesection containing those paragraphs with the mathematical toolkit of annex B as its parent.d1 ::: dn =) Mathematical toolkit section Speci�cation parents standard toolkit END d1 ::: dnIn this transformation, Mathematical toolkit denotes the entire text of annex B. The name given to the sectionis not important: it need not be Speci�cation, though it may not be prelude or that of any section of themathematical toolkit.C.3 SectionC.3.1 IntroductionA Section can be either an inheriting section or a base section. An inheriting section gathers together theparagraphs of parent sections with new paragraphs. A base section is like an inheriting section but has noparents.C.3.2 Inheriting sectionC.3.2.1 SyntaxSection = section , NAME , parents , [ NAME , { ;-tok , NAME } ] , END ,{ Paragraph }| ...;C.3.2.2 Type�0 D d1 oo �1 ::: �n�1 D dn oo �n� S section i parents i1; :::; im ENDd1 oo �1 ::: dn oo �n oo �

0BBBBBBBBBBBBBBBBB@i 62 dom �fi1; :::; img � dom � �1 = if i = prelude then fg else � prelude 0 = �1 [ � i1 [ ::: [ � im�0 = 0 o9 seconddisjoint hdom �1; :::; dom �ni� 2 ( 7! )� = 0 [ fj : NAME; � : Type j j 7! � 2 �1 [ ::: [ �n � j 7! (i; �)g�1 = �0 [ �1...�n�1 = �n�2 [ �n�1

1CCCCCCCCCCCCCCCCCATaking the side-conditions in order, this type inference rule ensures that:a) the name of the section, i, is di�erent from that of any previous section;c ISO/IEC 2000|All rights reserved 109

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionb) the names in the parents list are names of known sections;c) the section environment of the prelude is included if the section is not itself the prelude;d) the section environment 0 is formed from those of the parents;e) the type environment �0 is determined from the section environment 0;f) there is no global rede�nition between any pair of paragraphs of the section (the sets of names in theirsignatures are disjoint);g) a name which is common to the environments of multiple parents shall have originated in a common ancestralsection, and a name introduced by a paragraph of this section shall not also be introduced by anotherparagraph or parent section (all ensured by the combined environment being a function);h) the annotation of the section is an environment formed from those of its parents extended according to thesignatures of its paragraphs;i) and the type environment in which a paragraph is typechecked is formed from that of the parent sectionsextended with the signatures of the preceding paragraphs of this section.NOTE 1 Ancestors need not be immediate parents, and a section cannot be amongst its own ancestors (no cyclesin the parent relation).NOTE 2 The name of a section can be the same as the name of a variable introduced in a declaration|the two arenot confused.C.3.2.3 SemanticsThe prelude section, as de�ned in clause 11, is treated specially, as it is the only one that does not have preludeas an implicit parent. [[ section prelude parents END d1 ::: dn ]]S=� T : SectionModels � fprelude 7! ([[ d1 ]]D o9 ::: o9 [[ dn ]]D) (j f?g j)gThe meaning of the prelude section is given by that constant function which, whatever function from sections'names and their sets of models it is given, returns the singleton set mapping the name prelude to its set of models.The set of models is that to which the set containing an empty model is related by the composition of the relationsbetween models that denote the meanings of each of the prelude's paragraphs|see clause 11 for details of thoseparagraphs.NOTE One model of the prelude section can be written as follows.fA 7! A ;N 7! N;number literal 0 7! 0;number literal 1 7! 1;+ 7! f((0; 0); 0); ((0; 1); 1); ((1; 0); 1); ((1; 1); 2); :::ggThe behaviour of ( + ) on non-natural numbers, e.g. reals, has not been de�ned at this point, so the set of modelsfor the prelude section includes alternatives for every possible extended behaviour of addition.[[ section i parents i1; :::; im END d1 ::: dn ]]S=� T : SectionModels � T [ fi 7!([[ d1 ]]D o9 ::: o9 [[ dn ]]D) (j fM0 : T prelude; M1 : T i1; :::; Mm : T im; M : Model j M =M0[M1[ :::[Mm � Mg j)g110 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)The meaning of a section other than the prelude is the extension of a function from sections' names to their setsof models with a maplet from the given section's name to its set of models. The given section's set of modelsis that to which the union of the models of the section's parents is related by the composition of the relationsbetween models that denote the meanings of each of the section's paragraphs.C.3.3 Base sectionC.3.3.1 SyntaxSection = ...| section , NAME , END , { Paragraph };C.3.3.2 TransformationThe base section section i END d1 ::: dn is semantically equivalent to the inheriting section that inherits from noparents (bar prelude). section i END d1 ::: dn =) section i parents END d1 ::: dnC.4 ParagraphC.4.1 IntroductionA Paragraph can introduce new names into the models, and can constrain the values associated with names. AParagraph can be any of given types, axiomatic description, schema de�nition, generic axiomatic description,generic schema de�nition, horizontal de�nition, generic horizontal de�nition, generic operator de�nition, freetypes, conjecture, generic conjecture, or operator template.C.4.2 Given typesC.4.2.1 SyntaxParagraph = [-tok , NAME , { ;-tok , NAME } , ]-tok , END| ...;C.4.2.2 Type� D [i1; :::; in] END oo �� # fi1; :::; ing = n� = i1 : P(GIVEN i1); :::; in : P(GIVEN in) �In a given types paragraph, there shall be no duplication of names. The annotation of the paragraph is a signatureassociating the given type names with powerset types.C.4.2.3 SemanticsThe given types paragraph [i1; :::; in] END introduces unconstrained global names.[[ [i1; :::; in] END ]]D = fM : Model ; w1; :::; wn : W�M 7! M [ fi1 7! w1; :::; in 7! wng[ fi1 decor ~ 7! w1; :::; in decor ~ 7! wnggc ISO/IEC 2000|All rights reserved 111

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionIt relates a model M to that model extended with associations between the names of the given types and semanticvalues chosen to represent their carrier sets. Associations for names decorated with the reserved stroke ~ are alsointroduced, so that references to them from given types (15.2.6.1) can avoid being captured.C.4.3 Axiomatic descriptionC.4.3.1 SyntaxParagraph = ...| AX , SchemaText , END| ...;C.4.3.2 Type� E e oo �� D AX e oo � END oo � (� = P[�])In an axiomatic description paragraph AX e END, the expression e shall be a schema. The annotation of theparagraph is the signature of that schema.C.4.3.3 SemanticsThe axiomatic description paragraph AX e END introduces global names and constraints on their values.[[ AX e END ]]D = fM : Model ; t : W j t 2 [[ e ]]EM � M 7! M [ tgIt relates a model M to that model extended with a binding t of the schema that is the value of e in model M.C.4.4 Schema de�nitionC.4.4.1 SyntaxParagraph = ...| SCH , NAME , SchemaText , END| ...;C.4.4.2 TransformationThe schema de�nition paragraph SCH i t END introduces the global name i, associating it with the schema thatis the value of t. SCH i t END =) AX [i == t] ENDThe paragraph is semantically equivalent to the axiomatic description paragraph whose sole declaration associatesthe schema's name with the expression resulting from syntactic transformation of the schema text.112 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)C.4.5 Generic axiomatic descriptionC.4.5.1 SyntaxParagraph = ...| GENAX , [-tok , Formals , ]-tok , SchemaText , END| ...;C.4.5.2 Type� � fi1 7! P(GENTYPE i1); :::; in 7! P(GENTYPE in)g E e oo �� D GENAX [i1; :::; in] e oo � END oo � 0@ # fi1; :::; ing = n� = P[�]� = � j : dom � � [i1; :::; in] (� j) 1AIn a generic axiomatic description paragraph GENAX [i1; :::; in] e END, there shall be no duplication of names withinthe generic parameters. The expression e is typechecked, in an environment overridden by the generic parameters,and shall be a schema. The annotation of the paragraph is formed from the signature of that schema, having thesame names but associated with types that are generic.C.4.5.3 SemanticsThe generic axiomatic description paragraph GENAX [i1; :::; in] e END introduces global names and constraints ontheir values, with generic parameters that have to be instantiated (by sets) whenever those names are referenced.[[ GENAX [i1; :::; in] (e oo P[j1 : �1; :::; jm : �m]) END ]]D =fM : Model ; u : W " n ! Wj 8 w1; :::; wn : W � 9 w : W �u (w1; :::; wn ) 2 w^ (M � fi1 7! w1; :::; in 7! wng [ fi1 decor � 7! w1; :::; in decor � 7! wng) 7! w 2 [[ e ]]E�M 7! M [ � y : fj1; :::; jmg � � x : W " n � u x ygGiven a model M and generic argument sets w1; :::; wn , the semantic value of the schema e in that modeloverridden by the association of the generic parameter names with those sets is w . All combinations of genericargument sets are considered. The function u maps the generic argument sets to a binding in the schema w .The paragraph relates the model M to that model extended with the binding that associates the names of theschema e (namely j1; :::; jm) with the corresponding value in the binding resulting from application of u toarbitrary instantiating sets x . Associations for names decorated with the reserved stroke � are also introducedwhilst determining the semantic value of e, so that references to them from generic types (15.2.6.2) can avoidbeing captured.C.4.6 Generic schema de�nitionC.4.6.1 SyntaxParagraph = ...| GENSCH , NAME , [-tok , Formals , ]-tok , SchemaText , END| ...;c ISO/IEC 2000|All rights reserved 113

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionC.4.6.2 TransformationThe generic schema de�nition paragraph GENSCH i [i1; :::; in] t END can be instantiated to produce a schemade�nition paragraph. GENSCH i [i1; :::; in] t END =) GENAX [i1; :::; in] [i == t] ENDIt is semantically equivalent to the generic axiomatic description paragraph with the same generic parameters andwhose sole declaration associates the schema's name with the expression resulting from syntactic transformationof the schema text.C.4.7 Horizontal de�nitionC.4.7.1 SyntaxParagraph = ...| DeclName , == , Expression , END| ...;C.4.7.2 TransformationThe horizontal de�nition paragraph i == e END introduces the global name i, associating with it the value of e.i == e END =) AX [i == e] ENDIt is semantically equivalent to the axiomatic description paragraph that introduces the same single declaration.C.4.8 Generic horizontal de�nitionC.4.8.1 SyntaxParagraph = ...| NAME , [-tok , Formals , ]-tok , == , Expression , END| ...;C.4.8.2 TransformationThe generic horizontal de�nition paragraph i [i1; :::; in] == e END can be instantiated to produce a horizontalde�nition paragraph. i [i1; :::; in] == e END =) GENAX [i1; :::; in] [i == e] ENDIt is semantically equivalent to the generic axiomatic description paragraph with the same generic parametersand that introduces the same single declaration.114 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)C.4.9 Generic operator de�nitionC.4.9.1 SyntaxParagraph = ...| GenName , == , Expression , END| ...;GenName = PrefixGenName| PostfixGenName| InfixGenName| NofixGenName;PrefixGenName = PRE , NAME| L , { NAME , ( ES | SS ) } , NAME , ( ERE | SRE ) , NAME;PostfixGenName = NAME , POST| NAME , EL , { NAME , ( ES | SS ) } , NAME , ( ER | SR );InfixGenName = NAME , I , NAME| NAME , EL , { NAME , ( ES | SS ) } , NAME , ( ERE | SRE ) , NAME;NofixGenName = L , { NAME , ( ES | SS ) } , NAME , ( ER | SR ) ;C.4.9.2 TransformationAll generic names are transformed to juxtapositions of NAMEs and generic parameter lists. This causes the genericoperator de�nition paragraphs in which they appear to become generic horizontal de�nition paragraphs, and thusbe amenable to further syntactic transformation.Each resulting NAME should be one for which there is an operator template paragraph in scope (see 12.2.8).C.4.9.3 PrefixGenName pre i =) pre1 [i]ln i1 ess1 ::: in�2 essn�2 in�1 ere in =) ln1ess1:::1essn�21ere1 [i1; :::; in�2; in�1; in]ln i1 ess1 ::: in�2 essn�2 in�1 sre in =) ln1ess1:::1essn�21sre1 [i1; :::; in�2; in�1; in]C.4.9.4 PostfixGenName i post =) 1post [i]i1el i2 ess2 ::: in�1 essn�1 in er =) 1el1ess2:::1essn�11er [i1; i2; :::; in�1; in]i1el i2 ess2 ::: in�1 essn�1 in sr =) 1el1ess2:::1essn�11sr [i1; i2; :::; in�1; in]C.4.9.5 InfixGenName i1in i2 =) 1in1 [i1; i2]c ISO/IEC 2000|All rights reserved 115

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productioni1el i2 ess2 ::: in�2 essn�2 in�1 ere in =) 1el1ess2:::1essn�21ere1 [i1; i2; :::; in�2; in�1; in]i1el i2 ess2 ::: in�2 essn�2 in�1 sre in =) 1el1ess2:::1essn�21sre1 [i1; i2; :::; in�2; in�1; in]C.4.9.6 NofixGenNameln i1 ess1 ::: in�1 essn�1 in er =) ln1ess1:::1essn�11er [i1; :::; in�1; in]ln i1 ess1 ::: in�1 essn�1 in sr =) ln1ess1:::1essn�11sr [i1; :::; in�1; in]C.4.10 Free typesC.4.10.1 SyntaxParagraph = ...| Freetype , { & , Freetype } , END| ...;Freetype = NAME , ::= , Branch , { j-tok , Branch } ;Branch = DeclName , [ hh , Expression , ii ] ;C.4.10.2 TransformationThe transformation of free types paragraphs is done in two stages. First, the branches are permuted to bringelements to the front and injections to the rear.::: j ghheii j h j ::: =) ::: j h j ghheii j :::Exhaustive application of this syntactic transformation rule e�ects a sort.The second stage requires implicit generic instantiations to have been �lled in, which is done during typechecking(section 13.2.3.3). Hence that second stage is delayed until after typechecking, where it appears in the form of asemantic transformation rule (section 14.2.3.1).

116 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)C.4.10.3 Type� E e1 1 oo �1 1 ::: � E e1n1 oo �1 n1...� E er 1 oo �r 1 ::: � E er nr oo �r nr� D f1 ::= h1 1 j ::: j h1m1 jg1 1hhe1 1 oo �1 1ii j... jg1n1hhe1 n1 oo �1n1ii &... &fr ::= hr 1 j ::: j hrmr jgr 1hher 1 oo �r 1ii j... jgr nr hher nr oo �r nrii END oo �

0BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB@

# ff1; h1 1; :::; h1m1 ; g1 1; :::; g1n1 ;...; fr; hr 1; :::; hrmr ; gr 1; :::; gr nrg= r +m1 + :::+mr + n1 + :::+ nr� = � � ff1 7! P(GIVEN f1); :::; fr 7! P(GIVEN fr)g�1 1 = P�1 1 ::: �1 n1 = P�1n1...�r 1 = P�r 1 ::: �r nr = P�r nr� = f1 : P(GIVEN f1);h1 1 : GIVEN f1; :::; h1m1 : GIVEN f1;g1 1 : P(�1 1 � GIVEN f1);...;g1n1 : P(�1 n1 � GIVEN f1);...;fr : P(GIVEN fr);hr 1 : GIVEN fr; :::; hrmr : GIVEN fr;gr 1 : P(�r 1 � GIVEN fr);...;gr nr : P(�r nr � GIVEN fr)

1CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCAIn a free types paragraph, the names of the free types, elements and injections shall all be di�erent. The expressionsrepresenting the domains of the injections are typechecked in an environment overridden by the names of the freetypes, and shall all be sets. The annotation of the paragraph is the signature whose names are those of all thefree types, the elements, and the injections, each associated with the corresponding type.C.4.10.4 SemanticsA free types paragraph is semantically equivalent to the sequence of given type paragraph and axiomatic de�nitionparagraph de�ned here.NOTE 1 This exploits notation that is not present in the annotated syntax for the purpose of abbreviation.f1 ::= h1 1 j ::: j h1m1 j g1 1hhe1 1ii j ::: j g1n1hhe1 n1ii& ::: &fr ::= hr 1 j ::: j hrmr j gr 1hher 1ii j ::: j gr nrhher nrii=)[f1; :::; fr]END

c ISO/IEC 2000|All rights reserved 117

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionAXh1 1; :::; h1m1 : f1...hr 1; :::; hrmr : frg11 : P(e1 1 � f1); :::; g1n1 : P(e1 n1 � f1)...gr 1 : P(er 1 � fr); :::; gr nr : P(er nr � fr)j(8 u : e1 1 � 91 x : g1 1 � x : 1 = u) ^ ::: ^ (8 u : e1n1 � 91 x : g1n1 � x : 1 = u)... ^(8 u : er 1 � 91 x : gr 1 � x : 1 = u) ^ ::: ^ (8 u : er nr � 91 x : gr nr � x : 1 = u)(8 u; v : e1 1 j g1 1u = g1 1v � u = v) ^ ::: ^ (8 u; v : e1n1 j g1n1u = g1n1v � u = v)... ^(8 u; v : er 1 j gr 1u = gr 1v � u = v) ^ ::: ^ (8 u; v : er nr j gr nru = gr nrv � u = v)8 b1; b2 : N �(8 w : f1 j(b1 = 1 ^ w = h1 1 _ ::: _ b1 = m1 ^ w = h1m1 _b1 = m1 + 1 ^ w 2 fx : g11 � x : 2g _ ::: _ b1 = m1 + n1 ^ w 2 fx : g1n1 � x : 2g)^ (b2 = 1 ^ w = h1 1 _ ::: _ b2 = m1 ^ w = h1m1 _b2 = m1 + 1 ^ w 2 fx : g11 � x : 2g _ ::: _ b2 = m1 + n1 ^ w 2 fx : g1n1 � x : 2g) �b1 = b2) ^... ^(8 w : fr j(b1 = 1 ^ w = hr 1 _ ::: _ b1 = mr ^ w = hrmr _b1 = mr + 1 ^ w 2 fx : gr 1 � x : 2g _ ::: _ b1 = mr + nr ^ w 2 fx : gr nr � x : 2g)^ (b2 = 1 ^ w = hr 1 _ ::: _ b2 = mr ^ w = hrmr _b2 = mr + 1 ^ w 2 fx : gr 1 � x : 2g _ ::: _ b2 = mr + nr ^ w 2 fx : gr nr � x : 2g) �b1 = b2)8 w1 : Pf1; :::; wr : Pfr jh1 1 2 w1 ^ ::: ^ h1m1 2 w1 ^... ^hr 1 2 wr ^ ::: ^ hrmr 2 wr ^(8 y : (� f1 == w1; :::; fr == wr � e1 1) � g1 1y 2 w1) ^::: ^ (8 y : (� f1 == w1; :::; fr == wr � e1n1) � g1n1y 2 w1) ^... ^(8 y : (� f1 == w1; :::; fr == wr � er 1) � gr 1y 2 wr) ^::: ^ (8 y : (� f1 == w1; :::; fr == wr � er nr ) � gr nry 2 wr) �w1 = f1 ^ ::: ^ wr = frENDThe type names are introduced by the given types paragraph. The elements are declared as members of their cor-responding free types. The injections are declared as functions from values in their domains to their correspondingfree type.The �rst of the four blank-line separated predicates is the total functionality property. It ensures that for everyinjection, the injection is functional at every value in its domain.118 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)The second of the four blank-line separated predicates is the injectivity property. It ensures that for everyinjection, any pair of values in its domain for which the injection returns the same value shall be a pair of equalvalues (hence the name injection).The third of the four blank-line separated predicates is the disjointness property. It ensures that for every freetype, every pair of values of the free type are equal only if they are the same element or are returned by applicationof the same injection to equal values.The fourth of the four blank-line separated predicates is the induction property. It ensures that for every freetype, its members are its elements, the values returned by its injections, and nothing else.The generated � expressions in the induction property are intended to e�ect substitutions of all references to thefree type names, including any such references within generic instantiation lists in the e expressions.NOTE 2 That is why this is a semantic transformation not a syntactic one: all implicit generic instantiations shallhave been made explicit before it is applied.NOTE 3 The right-hand side of this transformation could have been expressed using the following notation fromthe mathematical toolkit, but for the desire to de�ne the core language separately from the mathematical toolkit.[f1; :::; fr]ENDAXh1 1; :::; h1m1 : f1...hr 1; :::; hr mr : frg1 1 : e1 1� f1; :::; g1n1 : e1n1 � f1...gr 1 : er 1� fr; :::; gr nr : er nr � frjdisjointhfh1 1g; :::; fh1m1g; ran g1 1; :::; ran g1n1i...disjointhfhr 1g; :::; fhr mrg; ran gr 1; :::; ran gr nr i8 w1 : Pf1; :::; wr : Pfr jfh1 1; :::; h1m1g [ g1 1(j � f1 == w1; :::; fr == wr � e1 1 j)[::: [ g1n1(j � f1 == w1; :::; fr == wr � e1n1 j) � w1 ^... ^fhr 1; :::; hrmrg [ gr 1(j � f1 == w1; :::; fr == wr � er 1 j)[::: [ gr nr (j � f1 == w1; :::; fr == wr � er nr j) � wr �w1 = f1 ^ ::: ^ wr = frENDC.4.11 ConjectureC.4.11.1 SyntaxParagraph = ...| `? , Predicate , END| ...;c ISO/IEC 2000|All rights reserved 119

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionC.4.11.2 Type� P p� D `? p END oo � (� = �)In a conjecture paragraph `? p END, the predicate p shall be well-typed. The annotation of the paragraph is theempty signature.C.4.11.3 SemanticsThe conjecture paragraph `? p END expresses a property that may logically follow from the speci�cation. It maybe a starting point for a proof. [[ `? p END ]]D = id ModelIt relates a model to itself: the truth of p in a model does not a�ect the meaning of the speci�cation.C.4.12 Generic conjectureC.4.12.1 SyntaxParagraph = ...| [-tok , Formals , ]-tok , `? , Predicate , END| ...;C.4.12.2 Type� � fi1 7! P(GENTYPE i1); :::; in 7! P(GENTYPE in)g P p� D [i1; :::; in] `? p END oo � � # fi1; :::; ing = n� = � �In a generic conjecture paragraph [i1; :::; in] `? p END, there shall be no duplication of names within the genericparameters. The predicate p shall be well-typed in an environment overridden by the generic parameters. Theannotation of the paragraph is the empty signature.C.4.12.3 SemanticsThe generic conjecture paragraph [i1; :::; in] `? p END expresses a generic property that may logically follow fromthe speci�cation. It may be a starting point for a proof.[[ [i1; :::; in] `? p END ]]D = id ModelIt relates a model to itself: the truth of p in a model does not a�ect the meaning of the speci�cation.C.4.13 Operator templateAn operator template has only syntactic signi�cance: it noti�es the reader to treat all occurrences in this sectionof the words in the template, with whatever strokes they are decorated, as particular pre�x, in�x, post�x orno�x names. The category of the operator|relation, function, or generic|determines how applications of theoperator are interpreted| as relational predicates, application expressions, or generic instantiation expressionsrespectively.120 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)C.4.13.1 SyntaxParagraph = ...| OperatorTemplate , END;OperatorTemplate = relation , Template| function , CategoryTemplate| generic , CategoryTemplate;CategoryTemplate = Prec , PrefixTemplate| Prec , PostfixTemplate| Prec , Assoc , InfixTemplate| NofixTemplate;Prec = NUMERAL ;Assoc = leftassoc| rightassoc;Template = PrefixTemplate| PostfixTemplate| InfixTemplate| NofixTemplate;PrefixTemplate = (-tok , PrefixName , )-tok ;PostfixTemplate = (-tok , PostfixName , )-tok ;InfixTemplate = (-tok , InfixName , )-tok ;NofixTemplate = (-tok , NofixName , )-tok ;C.5 PredicateC.5.1 IntroductionA Predicate expresses constraints between the values associated with names. A Predicate can be any of uni-versal quanti�cation, existential quanti�cation, unique existential quanti�cation, newline conjunction, semicolonconjunction, equivalence, implication, disjunction, conjunction, negation, relation operator application, member-ship, schema predicate, truth, falsity, or parenthesized predicate.C.5.2 Universal quanti�cationC.5.2.1 SyntaxPredicate = 8 , SchemaText , � , Predicate| ...;c ISO/IEC 2000|All rights reserved 121

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionC.5.2.2 Type� E e oo � � � � P p� P 8 (e oo �) � p (� = P[�])In a universal quanti�cation predicate 8 e � p, expression e shall be a schema, and predicate p shall be well-typedin the environment overridden by the signature of schema e.C.5.2.3 SemanticsThe universal quanti�cation predicate 8 e � p is true if and only if predicate p is true for all bindings of theschema e. [[ 8 e � p ]]P = fM : Model j 8 t : [[ e ]]EM �M � t 2 [[ p ]]P � MgIn terms of the semantic universe, it is true in those models for which p is true in that model overridden by allbindings in the semantic value of e, and is false otherwise.C.5.3 Existential quanti�cationC.5.3.1 SyntaxPredicate = ...| 9 , SchemaText , � , Predicate| ...;C.5.3.2 TransformationThe existential quanti�cation predicate 9 t � p is true if and only if p is true for at least one value of t.9 t � p =) : 8 t � : pIt is semantically equivalent to p being false for not all values of t.C.5.4 Unique existential quanti�cationC.5.4.1 SyntaxPredicate = ...| 91 , SchemaText , � , Predicate| ...;C.5.4.2 Type� E e oo � � � � P p� P 91 (e oo �) � p (� = P[�])In a unique existential quanti�cation predicate 91 e � p, expression e shall be a schema, and predicate p shall bewell-typed in the environment overridden by the signature of schema e.C.5.4.3 SemanticsThe unique existential quanti�cation predicate 91 e � p is true if and only if there is exactly one value for e forwhich p is true. 91 e � p =) : (8 e � : (p ^ (8 [e j p]1 � � e = � e 1 )))122 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)NOTE Exploiting notation that is not present in the annotated syntax, this abbreviates to the following.91 e � p =) 9 e � p ^ (8 [e j p]1 � � e = � e 1)It is semantically equivalent to there existing at least one value for e for which p is true and all those values forwhich it is true being the same.C.5.5 Newline conjunctionC.5.5.1 SyntaxPredicate = ...| Predicate , NL , Predicate| ...;C.5.5.2 TransformationThe newline conjunction predicate p1 NL p2 is true if and only if both its predicates are true.p1 NL p2 =) p1 ^ p2It is semantically equivalent to the conjunction predicate p1 ^ p2.C.5.6 Semicolon conjunctionC.5.6.1 SyntaxPredicate = ...| Predicate , ; -tok , Predicate| ...;C.5.6.2 TransformationThe semicolon conjunction predicate p1; p2 is true if and only if both its predicates are true.p1; p2 =) p1 ^ p2It is semantically equivalent to the conjunction predicate p1 ^ p2.C.5.7 EquivalenceC.5.7.1 SyntaxPredicate = ...| Predicate , , , Predicate| ...;c ISO/IEC 2000|All rights reserved 123

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionC.5.7.2 TransformationThe equivalence predicate p1 , p2 is true if and only if both p1 and p2 are true or neither is true.p1 , p2 =) (p1 ) p2) ^ (p2 ) p1)It is semantically equivalent to each of p1 and p2 being true if the other is true.C.5.8 ImplicationC.5.8.1 SyntaxPredicate = ...| Predicate , ) , Predicate| ...;C.5.8.2 TransformationThe implication predicate p1 ) p2 is true if and only if p2 is true if p1 is true.p1 ) p2 =) : p1 _ p2It is semantically equivalent to p1 being false disjoined with p2 being true.C.5.9 DisjunctionC.5.9.1 SyntaxPredicate = ...| Predicate , _ , Predicate| ...;C.5.9.2 TransformationThe disjunction predicate p1 _ p2 is true if and only if at least one of p1 and p2 is true.p1 _ p2 =) : (: p1 ^ : p2)It is semantically equivalent to not both of p1 and p2 being false.C.5.10 ConjunctionC.5.10.1 SyntaxPredicate = ...| Predicate , ^ , Predicate| ...;124 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)C.5.10.2 Type� P p1 � P p2� P p1 ^ p2A conjunction predicate p1 ^ p2 is well-typed if and only if predicates p1 and p2 are well-typed.C.5.10.3 SemanticsThe conjunction predicate p1 ^ p2 is true if and only if p1 and p2 are true.[[ p1 ^ p2 ]]P = [[ p1 ]]P \ [[ p2 ]]PIn terms of the semantic universe, it is true in those models in which both p1 and p2 are true, and is falseotherwise.C.5.11 NegationC.5.11.1 SyntaxPredicate = ...| : , Predicate| ...;C.5.11.2 Type� P p� P : pA negation predicate : p is well-typed if and only if predicate p is well-typed.C.5.11.3 SemanticsThe negation predicate : p is true if and only if p is false.[[ : p ]]P = Model n [[ p ]]PIn terms of the semantic universe, it is true in all models except those in which p is true.C.5.12 Relation operator applicationC.5.12.1 SyntaxPredicate = ...| Relation| ...;Relation = PrefixRel| PostfixRel| InfixRel| NofixRel;c ISO/IEC 2000|All rights reserved 125

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionPrefixRel = PREP , Expression| LP , ExpSep , ( Expression , EREP | ExpressionList , SREP ) , Expression;PostfixRel = Expression , POSTP| Expression , ELP , ExpSep , ( Expression , ERP | ExpressionList , SRP );InfixRel = Expression , ( 2 | =-tok | IP ) , Expression{ ( 2 | =-tok | IP ) , Expression }| Expression , ELP , ExpSep ,( Expression , EREP | ExpressionList , SREP ) , Expression;NofixRel = LP , ExpSep , ( Expression , ERP | ExpressionList , SRP ) ;C.5.12.2 TransformationAll relation operator applications are transformed to annotated membership predicates.Each relation NAME should be one for which there is an operator template paragraph in scope (see 12.2.8).The left-hand sides of many of these transformation rules involve ExpSep phrases: they use es metavariables.None of them use ss metavariables: in other words, only the Expression ES case of ExpSep is speci�ed, notthe ExpressionList SS case. Where the latter case occurs in a speci�cation, the ExpressionList shall betransformed by rule 12.2.12 to an expression, and thence a transformation analogous to that speci�ed for theformer case can be performed, di�ering only in that a ss appears in the relation name in place of an es.C.5.12.3 PrefixRel prep e =) e 2 prep1lp e1 es1 ::: en�2 esn�2 en�1 erep en =) (e1; :::; en�2; en�1; en) 2 lp1es1:::1esn�21erep1lp e1 es1 ::: en�2 esn�2 aln�1 srep en =) (e1; :::; en�2; aln�1; en) 2 lp1es1:::1esn�21srep1C.5.12.4 PostfixRel e postp =) e 2 1postpe1 elp e2 es2 ::: en�1 esn�1 en erp =) (e1; e2; :::; en�1; en) 2 1elp1es2:::1esn�11erpe1 elp e2 es2 ::: en�1 esn�1 aln srp =) (e1; e2; :::; en�1; aln) 2 1elp1es2:::1esn�11srpC.5.12.5 InfixRele1 ip1 e2 ip2 e3 ::: =) e1 ip1 e2 oo �1 ^ e2 oo �1 ip2 e3 oo �2 :::The chained relation e1 ip1 e2 ip2 e3 ::: is semantically equivalent to a conjunction of relational predicates, withthe constraint that duplicated expressions be of the same type.e1 = e2 =) e1 2 fe2ge1 ip e2 =) (e1; e2) 2 1ip1126 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)ip in the above transformation is excluded from being 2 or =, whereas ip1; ip2; ::: can be 2 or =.e1 elp e2 es2 ::: en�2 esn�2 en�1 erep en =) (e1; e2; :::; en�2; en�1; en) 2 1elp1es2:::1esn�21erep1e1 elp e2 es2 ::: en�2 esn�2 aln�1 srep en =) (e1; e2; :::; en�2; aln�1; en) 2 1elp1es2:::1esn�21srep1C.5.12.6 NofixRellp e1 es1 ::: en�1 esn�1 en erp =) (e1; :::; en�1; en) 2 lp1es1:::1esn�11erplp e1 es1 ::: en�1 esn�1 aln srp =) (e1; :::; en�1; aln) 2 lp1es1:::1esn�11srpC.5.12.7 Type� E e1 oo �1 � E e2 oo �2� P (e1 oo �1) 2 (e2 oo �2) � �2 = P �1 �In a membership predicate e1 2 e2, expression e2 shall be a set, and expression e1 shall be of the same type asthe members of set e2.C.5.12.8 SemanticsThe membership predicate e1 2 e2 is true if and only if the value of e1 is in the set that is the value of e2.[[ e1 2 e2 ]]P = fM : Model j [[ e1 ]]EM 2 [[ e2 ]]EM �MgIn terms of the semantic universe, it is true in those models in which the semantic value of e1 is in the semanticvalue of e2, and is false otherwise.C.5.13 SchemaC.5.13.1 SyntaxPredicate = ...| Expression| ...;C.5.13.2 TransformationThe schema predicate e is true if and only if the binding of the names in the signature of schema e satis�es theconstraints of that schema. e =) � e 2 eIt is semantically equivalent to the binding constructed by � e being a member of the set denoted by schema e.c ISO/IEC 2000|All rights reserved 127

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionC.5.14 TruthC.5.14.1 SyntaxPredicate = ...| true| ...;C.5.14.2 Type� P trueA truth predicate is always well-typed.C.5.14.3 SemanticsA truth predicate is always true. [[ true ]]P = ModelIn terms of the semantic universe, it is true in all models.C.5.15 FalsityC.5.15.1 SyntaxPredicate = ...| false| ...;C.5.15.2 TransformationThe falsity predicate false is never true. false =) : trueIt is semantically equivalent to the negation of true.C.5.16 Parenthesized predicateC.5.16.1 SyntaxPredicate = ...| (-tok , Predicate , )-tok;C.5.16.2 TransformationThe parenthesized predicate (p) is true if and only if p is true.(p) =) pIt is semantically equivalent to p.128 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)C.6 ExpressionC.6.1 IntroductionAn Expression denotes a value in terms of the names with which values are associated by a model. AnExpression can be any of schema universal quanti�cation, schema existential quanti�cation, schema unique ex-istential quanti�cation, function construction, de�nite description, substitution expression, schema equivalence,schema implication, schema disjunction, schema conjunction, schema negation, conditional, schema composition,schema piping, schema hiding, schema projection, schema precondition, Cartesian product, powerset, functionand generic operator application, application, schema decoration, schema renaming, binding selection, tuple se-lection, binding construction, reference, generic instantiation, number literal, set extension, set comprehension,characteristic set comprehension, schema construction, binding extension, tuple extension, characteristic de�nitedescription, or parenthesized expression.C.6.2 Schema universal quanti�cationC.6.2.1 SyntaxExpression = 8 , SchemaText , � , Expression| ...;C.6.2.2 Type� E e1 oo �1 � � �1 E e2 oo �2� E 8 (e1 oo �1) � (e2 oo �2) oo �3 0BB@ �1 = P[�1]�2 = P[�2]�1 � �2�3 = P[dom �1 �C �2] 1CCAIn a schema universal quanti�cation expression 8 e1 � e2, expression e1 shall be a schema, and expression e2, inan environment overridden by the signature of schema e1, shall also be a schema, and the signatures of these twoschemas shall be compatible. The type of the whole expression is that of a schema whose signature is computedby subtracting from the signature of e2 those pairs whose names are in the signature of e1.C.6.2.3 SemanticsThe value of the schema universal quanti�cation expression 8 e1 � e2 is the set of bindings of schema e2 restrictedto exclude names that are in the signature of e1, for all bindings of the schema e1.[[ 8 e1 � e2 oo P � ]]E = � M : Model � ft2 : [[ � ]]TM j 8 t1 : [[ e1 ]]EM � t1 [ t2 2 [[ e2 ]]E (M � t1) � t2gIn terms of the semantic universe, its semantic value, given a model M, is the set of the bindings (sets of pairs)in the semantic values of the carrier set of the type of the entire schema universal quanti�cation expression inM, for which the union of the bindings (sets of pairs) in e1 and in the whole expression is in the set that is thesemantic value of e2 in the model M overridden with the binding in e1.C.6.3 Schema existential quanti�cationC.6.3.1 SyntaxExpression = ...| 9 , SchemaText , � , Expression| ...;c ISO/IEC 2000|All rights reserved 129

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionC.6.3.2 TransformationThe value of the schema existential quanti�cation expression 9 t � e is the set of bindings of schema e restrictedto exclude names that are in the signature of t, for at least one binding of the schema t.9 t � e =) : 8 t � : eIt is semantically equivalent to the result of applying de Morgan's law.C.6.4 Schema unique existential quanti�cationC.6.4.1 SyntaxExpression = ...| 91 , SchemaText , � , Expression| ...;C.6.4.2 Type� E e1 oo �1 � � �1 E e2 oo �2� E 91 (e1 oo �1) � (e2 oo �2) oo �3 0BB@ �1 = P[�1]�2 = P[�2]�1 � �2�3 = P[dom �1 �C �2] 1CCAIn a schema unique existential quanti�cation expression 91 e1 � e2, expression e1 shall be a schema, and expressione2, in an environment overridden by the signature of schema e1, shall also be a schema, and the signatures ofthese two schemas shall be compatible. The type of the whole expression is that of a schema whose signature iscomputed by subtracting from the signature of e2 those pairs whose names are in the signature of e1.C.6.4.3 SemanticsThe value of the schema unique existential quanti�cation expression 91 e1 � e2 is the set of bindings of schemae2 restricted to exclude names that are in the signature of e1, for at least one binding of the schema e1.91 e1 � e2 =) : (8 e1 � : (e2 ^ (8 [e1 j e2]1 � � e1 = � e1 1)))NOTE Exploiting notation that is not present in the annotated syntax, this abbreviates to the following.91 e1 � e2 =) 9 e1 � e2 ^ (8 [e1 j e2]1 � � e1 = � e1 1)It is semantically equivalent to a schema existential quanti�cation expression, analogous to the unique existentialquanti�cation predicate transformation.C.6.5 Function constructionC.6.5.1 SyntaxExpression = ...| � , SchemaText , � , Expression| ...;130 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)C.6.5.2 TransformationThe value of the function construction expression � t � e is the function associating values of the characteristictuple of t with corresponding values of e.� t � e =) ft � (chartuple t; e)gIt is semantically equivalent to the set of pairs representation of that function.C.6.6 De�nite descriptionC.6.6.1 SyntaxExpression = ...| � , SchemaText , � , Expression| ...;C.6.6.2 Type� E e1 oo �1 � � � E e2 oo �2� E � (e1 oo �1) � (e2 oo �2) oo �3 � �1 = P[�]�3 = �2 �In a de�nite description expression � e1 � e2, expression e1 shall be a schema. The type of the whole expressionis the type of expression e2, as determined in an environment overridden by the signature of schema e1.C.6.6.3 SemanticsThe value of the de�nite description expression � e1 � e2 is the sole value of e2 that arises whichever binding ischosen from the set that is the value of schema e1.fM : Model ; t1 : Wj t1 2 [[ e1 ]]EM^ (8 t3 : [[ e1 ]]EM � [[ e2 ]]E (M � t3) = [[ e2 ]]E (M � t1))� M 7! [[ e2 ]]E (M � t1)g � [[ � e1 � e2 ]]EIn terms of the semantic universe, its semantic value, given a model M in which the value of e2 in that modeloverridden by a binding of the schema e1 is the same regardless of which binding is chosen, is that value of e2.In other models, it has a semantic value, but this loose de�nition of the semantics does not say what it is.C.6.7 Substitution expressionC.6.7.1 SyntaxExpression = ...| let , DeclName , == , Expression{ ; -tok , DeclName , == , Expression }, � , Expression| ...;c ISO/IEC 2000|All rights reserved 131

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionC.6.7.2 TransformationThe value of the substitution expression let i1 == e1; :::; in == en � e is the value of e when all of its referencesto the names have been substituted by the values of the corresponding expressions.let i1 == e1; :::; in == en � e =) � i1 == e1; :::; in == in � eIt is semantically equivalent to the similar de�nite description expression.C.6.8 Schema equivalenceC.6.8.1 SyntaxExpression = ...| Expression , , , Expression| ...;C.6.8.2 TransformationThe value of the schema equivalence expression e1 , e2 is that schema whose signature is the union of those ofschemas e1 and e2, and whose bindings are those whose relevant restrictions are either both or neither in e1 ande2. e1 , e2 =) (e1 ) e2) ^ (e2 ) e1)It is semantically equivalent to the schema conjunction shown above.C.6.9 Schema implicationC.6.9.1 SyntaxExpression = ...| Expression , ) , Expression| ...;C.6.9.2 TransformationThe value of the schema implication expression e1 ) e2 is that schema whose signature is the union of those ofschemas e1 and e2, and whose bindings are those whose restriction to the signature of e2 is in the value of e2 ifits restriction to the signature of e1 is in the value of e1.e1 ) e2 =) : e1 _ e2It is semantically equivalent to the schema disjunction shown above.132 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)C.6.10 Schema disjunctionC.6.10.1 SyntaxExpression = ...| Expression , _ , Expression| ...;C.6.10.2 TransformationThe value of the schema disjunction expression e1 _ e2 is that schema whose signature is the union of those ofschemas e1 and e2, and whose bindings are those whose restriction to the signature of e1 is in the value of e1 orits restriction to the signature of e2 is in the value of e2.e1 _ e2 =) : (: e1 ^ : e2)It is semantically equivalent to the schema negation shown above.C.6.11 Schema conjunctionC.6.11.1 SyntaxExpression = ...| Expression , ^ , Expression| ...;C.6.11.2 Type� E e1 oo �1 � E e2 oo �2� E (e1 oo �1) ^ (e2 oo �2) oo �30BB@ �1 = P[�1]�2 = P[�2]�1 � �2�3 = P[�1 [ �2] 1CCAIn a schema conjunction expression e1 ^ e2, expressions e1 and e2 shall be schemas, and their signatures shallbe compatible. The type of the whole expression is that of the schema whose signature is the union of those ofexpressions e1 and e2.C.6.11.3 SemanticsThe value of the schema conjunction expression e1 ^ e2 is the schema resulting from merging the signatures ofschemas e1 and e2 and conjoining their constraints.[[ e1 ^ e2 oo P � ]]E = � M : Model � ft : [[ � ]]TM; t1 : [[ e1 ]]EM; t2 : [[ e2 ]]EM j t1 [ t2 = t � tgIn terms of the semantic universe, its semantic value, given a model M, is the set of the unions of the bindings(sets of pairs) in the semantic values of e1 and e2 in M.C.6.12 Schema negationC.6.12.1 SyntaxExpression = ...| : , Expression| ...;c ISO/IEC 2000|All rights reserved 133

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionC.6.12.2 Type� E e oo �1� E : (e oo �1) oo �2� �1 = P[�]�2 = �1 �In a schema negation expression : e, expression e shall be a schema. The type of the whole expression is thesame as the type of expression e.C.6.12.3 SemanticsThe value of the schema negation expression : e is that set of bindings that are of the same type as those inschema e but that are not in schema e.[[ : e oo P � ]]E = � M : Model � ft : [[ � ]]TM j : t 2 [[ e ]]EM � tgIn terms of the semantic universe, its semantic value, given a model M, is the set of the bindings (sets of pairs)that are members of the semantic value of the carrier set of schema e in M such that those bindings are notmembers of the semantic value of schema e in M.C.6.13 ConditionalC.6.13.1 SyntaxExpression = ...| if , Predicate , then , Expression , else , Expression| ...;C.6.13.2 TransformationThe value of the conditional expression if p then e1 else e2 is the value of e1 if p is true, and is the value of e2 ifp is false. if p then e1 else e2 =) � i : fe1; e2g j p ^ i = e1 _ : p ^ i = e2 � iIt is semantically equivalent to the de�nite description expression whose value is either that of e1 or that of e2such that if p is true then it is e1 or if p is false then it is e2.C.6.14 Schema compositionC.6.14.1 SyntaxExpression = ...| Expression , o9 , Expression| ...;134 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)C.6.14.2 Type� E e1 oo �1 � E e2 oo �2� E (e1 oo �1) o9 (e2 oo �2) oo �30BBBBBBBBBB@�1 = P[�1]�2 = P[�2]match = fi : dom �2 j i decor 0 2 dom �1 � ig�3 = fi : match � i decor 0g �C �1�4 = match �C �2�3 � �4fi : match � i 7! �1(i decor 0)g � fi : match � i 7! �2 ig�3 = P[�3 [ �4]

1CCCCCCCCCCAIn a schema composition expression e1 o9 e2, expressions e1 and e2 shall be schemas. Let match be the set ofnames in schema e2 for which there are matching primed names in schema e1. Let �3 be the signature formedfrom the components of e1 excluding the matched primed components. Let �4 be the signature formed from thecomponents of e2 excluding the matched unprimed components. Signatures �3 and �4 shall be compatible. Thetypes of the excluded matched pairs of components shall be the same. The type of the whole expression is thatof a schema whose signature is the union of �3 and �4.C.6.14.3 SemanticsThe value of the schema composition expression e1 o9 e2 is that schema representing the operation of doing theoperations represented by schemas e1 and e2 in sequence.(e1 oo P[�1]) o9 (e2 oo P[�2]) oo P[�]=): (8 e1 � : (: (8 e3 � : [e1; e1 j � e3 = � e1])^ : (8 e4 � : [e2; e1 j � e4 = � e1])))where e3 == carrier [fi : NAME; � : Type j i decor 0 7! � 2 �1 � i decor 0 7! �g]and e4 == carrier [fi : NAME; � : Type j i 7! � 2 �2 � i 7! �g]and e1 == (e4)1NOTE Exploiting notation that is not present in the annotated syntax, this abbreviates to the following.(e1 oo P[�1]) o9 (e2 oo P[�2]) oo P[�]=)9 e1 � (9 e3 � [e1; e1 j � e3 = � e1])^ (9 e4 � [e2; e1 j � e4 = � e1])where e3 == carrier [fi : NAME; � : Type j i decor 0 7! � 2 �1 � i decor 0 7! �g]and e4 == carrier [fi : NAME; � : Type j i 7! � 2 �2 � i 7! �g]and e1 == (e4)1It is semantically equivalent to the existential quanti�cation of the matched pairs of primed components of e1and unprimed components of e2, with those matched pairs being equated.C.6.15 Schema pipingC.6.15.1 SyntaxExpression = ...| Expression , >> , Expression| ...;c ISO/IEC 2000|All rights reserved 135

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionC.6.15.2 Type� E e1 oo �1 � E e2 oo �2� E (e1 oo �1)>> (e2 oo �2) oo �30BBBBBBBBBB@�1 = P[�1]�2 = P[�2]match = fi : NAME j i decor ! 2 dom �1 ^ i decor ? 2 dom �2 � ig�3 = fi : match � i decor !g �C �1�4 = fi : match � i decor ?g �C �2�3 � �4fi : match � i 7! �1(i decor !)g � fi : match � i 7! �2 (i decor ?)g�3 = P[�3 [ �4]

1CCCCCCCCCCAIn a schema piping expression e1>>e2, expressions e1 and e2 shall be schemas. Let match be the set of names forwhich there are matching shrieked names in schema e1 and queried names in schema e2. Let �3 be the signatureformed from the components of e1 excluding the matched shrieked components. Let �4 be the signature formedfrom the components of e2 excluding the matched queried components. Signatures �3 and �4 shall be compatible.The types of the excluded matched pairs of components shall be the same. The type of the whole expression isthat of a schema whose signature is the union of �3 and �4.C.6.15.3 SemanticsThe value of the schema piping expression e1 >> e2 is that schema representing the operation formed from thetwo operations represented by schemas e1 and e2 with the outputs of e1 identi�ed with the inputs of e2.(e1 oo P[�1])>> (e2 oo P[�2]) oo P[�]=): (8 e1 � : (: (8 e3 � : [e1; e1 j � e3 = � e1])^ : (8 e4 � : [e2; e1 j � e4 = � e1])))where e3 == carrier [fi : NAME; � : Type j i decor ! 7! � 2 �1 � i decor ! 7! �g]and e4 == carrier [fi : NAME; � : Type j i decor ? 7! � 2 �2 � i decor ? 7! �g]and e1 == (e4)1NOTE Exploiting notation that is not present in the annotated syntax, this abbreviates to the following.(e1 oo P[�1])>> (e2 oo P[�2]) oo P[�]=)9 e1 � (9 e3 � [e1; e1 j � e3 = � e1])^ (9 e4 � [e2; e1 j � e4 = � e1])where e3 == carrier [fi : NAME; � : Type j i decor ! 7! � 2 �1 � i decor ! 7! �g]and e4 == carrier [fi : NAME; � : Type j i decor ? 7! � 2 �2 � i decor ? 7! �g]and e1 == (e4)1It is semantically equivalent to the existential quanti�cation of the matched pairs of shrieked components of e1and queried components of e2, with those matched pairs being equated.C.6.16 Schema hidingC.6.16.1 SyntaxExpression = ...| Expression , n , (-tok , DeclName , { ;-tok , DeclName } , )-tok| ...;136 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)C.6.16.2 Type� E e oo �1� E (e oo �1) n (i1; :::; in) oo �20@ �1 = P[�]fi1; :::; ing � dom ��2 = P[fi1; :::; ing �C �] 1AIn a schema hiding expression e n (i1; :::; in), expression e shall be a schema, and the names to be hidden shallall be in the signature of that schema. The type of the whole expression is that of a schema whose signature iscomputed by subtracting from the signature of expression e those pairs whose names are hidden.C.6.16.3 SemanticsThe value of the schema hiding expression e n (i1; :::; in) is that schema whose signature is that of schema eminus the hidden names, and whose bindings have the same values as those in schema e.(e oo P[�]) n (i1; :::; in) =) : (8 i1 : carrier (� i1); :::; in : carrier (� in) � : e)NOTE Exploiting notation that is not present in the annotated syntax, this abbreviates to the following.(e oo P[�]) n (i1; :::; in) =) 9 i1 : carrier (� i1); :::; in : carrier (� in) � eIt is semantically equivalent to the schema existential quanti�cation of the hidden names i1; :::; in from the schemae.C.6.17 Schema projectionC.6.17.1 SyntaxExpression = ...| Expression , � , Expression| ...;C.6.17.2 TransformationThe value of the schema projection expression e1 � e2 is the schema that is like the conjunction e1 ^ e2 but whosesignature is restricted to just that of schema e2.e1 � e2 =) fe1; e2 � � e2gIt is semantically equivalent to that set of bindings of names in the signature of e2 to values that satisfy theconstraints of both e1 and e2.C.6.18 Schema preconditionC.6.18.1 SyntaxExpression = ...| pre , Expression| ...;c ISO/IEC 2000|All rights reserved 137

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionC.6.18.2 Type� E e oo �1� E pre (e oo �1) oo �2� �1 = P[�]�2 = P[fi; j : NAME j j 2 dom � ^ (j = i decor 0 _ j = i decor !) � jg �C �] �In a schema precondition expression pre e, expression e shall be a schema. The type of the whole expression isthat of a schema whose signature is computed by subtracting from the signature of e those pairs whose nameshave primed or shrieked decorations.C.6.18.3 SemanticsThe value of the schema precondition expression pre e is that schema which is like schema e but without itsprimed and shrieked components.pre(e oo P[�1]) oo P[�2] =) : (8 carrier [�1 n �2] � : e)NOTE Exploiting notation that is not present in the annotated syntax, this abbreviates to the following.pre(e oo P[�1]) oo P[�2] =) 9 carrier [�1 n �2] � eIt is semantically equivalent to the existential quanti�cation of the primed and shrieked components from theschema e.C.6.19 Cartesian productC.6.19.1 SyntaxExpression = ...| Expression , � , Expression , { � , Expression }| ...;C.6.19.2 TransformationThe value of the Cartesian product expression e1� :::� en is the set of all tuples whose components are membersof the corresponding sets that are the values of its expressions.e1 � :::� en =) fi1 : e1; :::; in : en � (i1; :::; in)gIt is semantically equivalent to the set comprehension expression that declares members of the sets and assemblesthose members into tuples.C.6.20 PowersetC.6.20.1 SyntaxExpression = ...| P , Expression| ...;138 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)C.6.20.2 Type� E e oo �1� E P(e oo �1) oo �2� �1 = P��2 = P �1 �In a powerset expression P e, expression e shall be a set. The type of the whole expression is then a powerset ofthe type of expression e.C.6.20.3 SemanticsThe value of the powerset expression P e is the set of all subsets of the set that is the value of e.[[ P e ]]E = � M : Model � P ([[ e ]]EM)In terms of the semantic universe, its semantic value, given a model M, is the powerset of values of e in M.C.6.21 Function and generic operator applicationC.6.21.1 SyntaxExpression = ...| Application| ...;Application = PrefixApp| PostfixApp| InfixApp| NofixApp;PrefixApp = PRE , Expression| L , ExpSep , ( Expression , ERE | ExpressionList , SRE ) , Expression;PostfixApp = Expression , POST| Expression , EL , ExpSep , ( Expression , ER | ExpressionList , SR );InfixApp = Expression , I , Expression| Expression , EL , ExpSep ,( Expression , ERE | ExpressionList , SRE ) , Expression;NofixApp = L , ExpSep , ( Expression , ER | ExpressionList , SR ) ;C.6.21.2 TransformationAll function operator applications are transformed to annotated application expressions.All generic operator applications are transformed to annotated generic instantiation expressions.Each resulting NAME should be one for which there is an operator template paragraph in scope (see 12.2.8).The left-hand sides of many of these transformation rules involve ExpSep phrases: they use es metavariables.None of them use ss metavariables: in other words, only the Expression ES case of ExpSep is speci�ed, notthe ExpressionList SS case. Where the latter case occurs in a speci�cation, the ExpressionList shall bec ISO/IEC 2000|All rights reserved 139

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productiontransformed by rule 12.2.12 to an expression, and thence a transformation analogous to that speci�ed for theformer case can be performed, di�ering only in that a ss appears in the function or generic name in place of anes.C.6.21.3 PrefixApp pre e =) pre1 eln e1 es1 ::: en�2 esn�2 en�1 ere en =) ln1es1:::1esn�21ere1 (e1; :::; en�2; en�1; en)ln e1 es1 ::: en�2 esn�2 aln�1 sre en =) ln1es1:::1esn�21sre1 (e1; :::; en�2; aln�1; en)pre e =) pre1 [e]ln e1 es1 ::: en�2 esn�2 en�1 ere en =) ln1es1:::1esn�21ere1 [e1; :::; en�2; en�1; en]ln e1 es1 ::: en�2 esn�2 aln�1 sre en =) ln1es1:::1esn�21sre1 [e1; :::; en�2; aln�1; en]C.6.21.4 PostfixApp e post =) 1post ee1 el e2 es2 ::: en�1 esn�1 en er =) 1el1es2:::1esn�11er (e1; e2; :::; en�1; en)e1 el e2 es2 ::: en�1 esn�1 aln sr =) 1el1es2:::1esn�11sr (e1; e2; :::; en�1; aln)e post =) 1post [e]e1 el e2 es2 ::: en�1 esn�1 en er =) 1el1es2:::1esn�11er [e1; e2; :::; en�1; en]e1 el e2 es2 ::: en�1 esn�1 aln sr =) 1el1es2:::1esn�11sr [e1; e2; :::; en�1; aln]C.6.21.5 InfixApp e1 in e2 =) 1in1 (e1; e2)e1 el e2 es2 ::: en�2 esn�2 en�1 ere en =) 1el1es2:::1esn�21ere1 (e1; e2; :::; en�2; en�1; en)e1 el e2 es2 ::: en�2 esn�2 aln�1 sre en =) 1el1es2:::1esn�21sre1 (e1; e2; :::; en�2; aln�1; en)e1 in e2 =) 1in1 [e1; e2]e1 el e2 es2 ::: en�2 esn�2 en�1 ere en =) 1el1es2:::1esn�21ere1 [e1; e2; :::; en�2; en�1; en]e1 el e2 es2 ::: en�2 esn�2 aln�1 sre en =) 1el1es2:::1esn�21sre1 [e1; e2; :::; en�2; aln�1; en]C.6.21.6 NofixAppln e1 es1 ::: en�1 esn�1 en er =) ln1es1:::1esn�11er (e1; :::; en�1; en)ln e1 es1 ::: en�1 esn�1 aln sr =) ln1es1:::1esn�11sr (e1; :::; en�1; aln)140 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)ln e1 es1 ::: en�1 esn�1 en er =) ln1es1:::1esn�11er [e1; :::; en�1; en]ln e1 es1 ::: en�1 esn�1 aln sr =) ln1es1:::1esn�11sr [e1; :::; en�1; aln]C.6.21.7 Type� E e oo �1� E P(e oo �1) oo �2� �1 = P��2 = P �1 �In a powerset expression P e, expression e shall be a set. The type of the whole expression is then a powerset ofthe type of expression e.C.6.21.8 SemanticsThe value of the powerset expression P e is the set of all subsets of the set that is the value of e.[[ P e ]]E = � M : Model � P ([[ e ]]EM)In terms of the semantic universe, its semantic value, given a model M, is the powerset of values of e in M.C.6.22 ApplicationC.6.22.1 SyntaxExpression = ...| Expression , Expression| ...;C.6.22.2 Type� E e1 oo �1 � E e2 oo �2� E (e1 oo �1) (e2 oo �2) oo �3 � �1 = P(�2 � �3) �In an application expression e1 e2, the expression e1 shall be a set of pairs, and expression e2 shall be of thesame type as the �rst components of those pairs. The type of the whole expression is the type of the secondcomponents of those pairs.C.6.22.3 SemanticsThe value of the application expression e1 e2 is the sole value associated with e2 in the relation e1.e1 e2 oo � =) (� i : carrier � j (e2; i) 2 e1 � i)It is semantically equivalent to that sole range value i such that the pair (e2; i) is in the set of pairs that is thevalue of e1. If there is no value or more than one value associated with e2, then the application expression has avalue but what it is is not speci�ed.C.6.23 Schema decorationC.6.23.1 SyntaxExpression = ...| Expression , STROKE| ...;c ISO/IEC 2000|All rights reserved 141

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionC.6.23.2 Type� E e oo �1� E (e oo �1) + oo �2� �1 = P[�]�2 = P[fi : dom � � i decor + 7! � ig] �In a schema decoration expression e +, expression e shall be a schema. The type of the whole expression is thatof a schema whose signature is like that of e but with the stroke appended to each of its names.C.6.23.3 SemanticsThe value of the schema decoration expression e + is that schema whose bindings are like those of the schema eexcept that their names have the addition stroke +.(e oo P[i1 : �1; :::; in : �n])+ =) e [i1 decor + = i1; :::; in decor + = in]It is semantically equivalent to the schema renaming where decorated names rename the original names.C.6.24 Schema renamingC.6.24.1 SyntaxExpression = ...| Expression , [-tok , DeclName , = , DeclName ,{ ;-tok , DeclName , = , DeclName } , ]-tok| ...;C.6.24.2 Type� E e oo �1� E (e oo �1)[j1 = i1; :::; jn = in] oo �20BBBB@ # fi1; :::; ing = n�1 = P[�1]�2 = fj1 7! i1; :::; jn 7! ing o9 �1 [ fi1; :::; ing �C �1�2 = P[�2]�2 2 ( 7! ) 1CCCCAIn a schema renaming expression e [j1 = i1; :::; jn = in], there shall be no duplicates amongst the old namesi1; :::; in. Expression e shall be a schema. The type of the whole expression is that of a schema whose signatureis like that of expression e but with the new names in place of corresponding old names. Declarations that aremerged by the renaming shall have the same type.NOTE Old names need not be in the signature of the schema. This is so as to permit renaming to distribute overother notations such as disjunction.C.6.24.3 SemanticsThe value of the schema renaming expression e [j1 = i1; :::; jn = in] is that schema whose bindings are like thoseof schema e except that some of its names have been replaced by new names, possibly merging components.[[ e [j1 = i1; :::; jn = in] ]]E = � M : Model �ft1 : [[ e ]]EM; t2 : W jt2 = fj1 7! i1; :::; jn 7! ing o9 t1 [ fi1; :::; ing �C t1^ t2 2 ( 7! )� t2gIn terms of the semantic universe, its semantic value, given a model M, is the set of the bindings (sets of pairs)in the semantic value of e in M with the new names replacing corresponding old names. Where components aremerged by the renaming, those components shall have the same value.142 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)C.6.25 Binding selectionC.6.25.1 SyntaxExpression = ...| Expression , : , RefName| ...;C.6.25.2 Type� E e oo �1� E (e oo �1) : i oo �2� �1 = [�](i; �2) 2 � �In a binding selection expression e : i, expression e shall be a binding, and name i shall select one of itscomponents. The type of the whole expression is the type of the selected component.C.6.25.3 SemanticsThe value of the binding selection expression e : i is that value associated with i in the binding that is the valueof e. (e oo [�]) : i =) fcarrier [�] � (chartuple (carrier [�]); i)g eNOTE Exploiting notation that is not present in the annotated syntax, this abbreviates to the following.(e oo [�]) : i =) (� carrier [�] � i) eIt is semantically equivalent to the function construction expression, from bindings of the schema type of e, tothe value of the selected name i, applied to the particular binding e.C.6.26 Tuple selectionC.6.26.1 SyntaxExpression = ...| Expression , : , NUMERAL| ...;C.6.26.2 Type� E e oo �1� E (e oo �1) : b oo �2 ((b; �2) 2 �1)In a tuple selection expression e : b, the type of expression e shall be a Cartesian product, and number b shallselect one of its components. The type of the whole expression is the type of the selected component.C.6.26.3 SemanticsThe value of the tuple selection expression e : b is the b'th component of the tuple that is the value of e.(e oo �1 � :::� �n) : b =) fi : carrier (�1 � :::� �n) �(i; � i1 : carrier �1; :::; in : carrier �n j i = (i1; :::; in) � ib)g ec ISO/IEC 2000|All rights reserved 143

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionNOTE Exploiting notation that is not present in the annotated syntax, this abbreviates to the following.(e oo �1 � :::� �n) : b =) (� i : carrier (�1 � :::� �n) �� i1 : carrier �1; :::; in : carrier �n j i = (i1; :::; in) � ib) eIt is semantically equivalent to the function construction, from tuples of the Cartesian product type to the selectedcomponent of the tuple b, applied to the particular tuple e.C.6.27 Binding constructionC.6.27.1 SyntaxExpression = ...| � , Expression , { STROKE }| ...;C.6.27.2 Type� E e oo �1� E � (e oo �1) � oo �20@ �1 = P[�]8 i : NAME j (i; �1) 2 � � (i decor �; �1) 2 � ^ : �1 = [{1; :::; {n ] �2�2 = [�] 1AIn a binding construction expression � e �, the expression e shall be a schema. Every name and type pair in itssignature, with the optional decoration added, should be present in the environment with a non-generic type.The type of the whole expression is that of a binding whose signature is that of the schema.NOTE If the type in the environment were generic, semantic transformation 14.2.5.2 would produce a referenceexpression whose implicit instantiation is not determined by this International Standard.C.6.27.3 SemanticsThe value of the binding construction expression � e � is the binding whose names are those in the signature ofschema e and whose values are those of the same names with the optional decoration appended.� e � oo [i1 : �1; :::; in : �n] =) hj i1 == i1 decor �; :::; in == in decor � jiIt is semantically equivalent to the binding extension expression whose value is that binding.C.6.28 ReferenceC.6.28.1 SyntaxExpression = ...| RefName| ...;C.6.28.2 TypeIn a reference expression, if the name is of the form �i and no declaration of this name yet appears in theenvironment, then the following syntactic transformation is applied.�i �i 62dom �=) [i; i 0]144 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)This syntactic transformation makes the otherwise unde�ned name be equivalent to the corresponding schemaconstruction expression, which is then typechecked.Similarly, if the name is of the form �i and no declaration of this name yet appears in the environment, then thefollowing syntactic transformation is applied.�i �i 62

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionThe value of the reference expression that refers to a non-generic de�nition i is the value of the declaration towhich it refers. [[ i ]]E = � M : Model � M iIn terms of the semantic universe, its semantic value, given a model M, is that associated with the name i in M.C.6.29 Generic instantiationC.6.29.1 SyntaxExpression = ...| RefName , [-tok , Expression , { ;-tok , Expression } , ]-tok| ...;C.6.29.2 Type� E e1 oo �1 ::: � E en oo �n� E i[(e1 oo �1); :::; (en oo �n)] oo � 0BBBBBBB@ i 2 dom �� i = [{1; :::; {n ] ��1 = P�1...�n = P�n� = (� i) [�1; :::; �n ]1CCCCCCCAIn a generic instantiation expression i [e1; :::; en], the name i shall be associated with a generic type in theenvironment, and the expressions e1; :::; en shall be sets. That generic type shall have the same number ofparameters as there are sets. The type of the whole expression is the instantiation of that generic type by thetypes of those sets' components.NOTE The operation of generic type instantiation is de�ned in 13.2.3.1.C.6.29.3 SemanticsThe value of the generic instantiation expression i [e1; :::; en] is a particular instance of the generic referred to byname i. [[ i [e1; :::; en] ]]E = � M : Model � M i ([[ e1 ]]EM; :::; [[ en ]]EM)In terms of the semantic universe, its semantic value, given a model M, is the generic value associated with thename i in M instantiated with the semantic values of the instantiation expressions in M.C.6.30 Number literalC.6.30.1 IntroductionZ accepts the ordinary notation for writing number literals that represent natural numbers, and imposes the usualmeaning on those literals. The method of doing this is as follows.The lexis de�nes the notion of a numeric string. The prelude de�nes the notions of natural number, zero, oneand addition (of natural numbers). The syntactic transformation rules prescribe how numeric strings are to beunderstood as natural numbers, using the ideas de�ned in the prelude.The extension to integers, and the introduction of other numeric operations on integers, is de�ned in the mathe-matical toolkit (annex B).146 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)The extension to other number systems is left to user de�nition.C.6.30.2 SyntaxExpression = ...| NUMERAL| ...;Numeric literals are concrete expressions.C.6.30.3 TransformationThe value of the multiple-digit number literal expression bc is the number that it denotes.bc =) b + b + b + b + b +b + b + b + b + b + cIt is semantically equivalent to the sum of ten repetitions of the number literal expression b formed from all butthe last digit, added to that last digit. 0 =) number literal 01 =) number literal 12 =) 1 + 13 =) 2 + 14 =) 3 + 15 =) 4 + 16 =) 5 + 17 =) 6 + 18 =) 7 + 19 =) 8 + 1The number literal expressions 0 and 1 are semantically equivalent to number literal 0 and number literal 1 re-spectively as de�ned in section prelude. The remaining digits are de�ned as being successors of their predecessors,using the function + as de�ned in section prelude.NOTE These syntactic transformations are applied only to NUMERAL tokens that form number literal expressions,not to other NUMERAL tokens (those in tuple selection expressions and operator template paragraphs), as those otheroccurrences of NUMERAL do not have semantic values associated with them.C.6.31 Set extensionC.6.31.1 SyntaxExpression = ...| f-tok , [ Expression , { ;-tok , Expression } ] , g-tok| ...;c ISO/IEC 2000|All rights reserved 147

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionC.6.31.2 Type� E e1 oo �1 ::: � E en oo �n� E f(e1 oo �1); :::; (en oo �n)g oo � 0BBBBBBB@ if n > 0 then(�1 = �n...�n�1 = �n� = P �1)else � = P�1CCCCCCCAIn a set extension expression, every component expression shall be of the same type. The type of the wholeexpression is a powerset of the components' type, or a powerset of a variable type if there are no components. Inthe latter case, the variable shall be constrained by the context, otherwise the speci�cation is not well-typed.C.6.31.3 SemanticsThe value of the set extension expression f e1; :::; eng is the set containing the values of its expressions.[[ f e1; :::; eng ]]E = � M : Model � f[[ e1 ]]EM; :::; [[ en ]]EMgIn terms of the semantic universe, its semantic value, given a model M, is the set whose members are the semanticvalues of the member expressions in M.C.6.32 Set comprehensionC.6.32.1 SyntaxExpression = ...| f-tok , SchemaText , � , Expression , g-tok| ...;C.6.32.2 Type� E e1 oo �1 � � � E e2 oo �2� E f(e1 oo �1) � (e2 oo �2)g oo �3 � �1 = P[�]�3 = P �2 �In a set comprehension expression fe1 � e2g, expression e1 shall be a schema. The type of the whole expression isa powerset of the type of expression e2, as determined in an environment overridden by the signature of schemae1.C.6.32.3 SemanticsThe value of the set comprehension expression f e1 � e2g is the set of values of e2 for all bindings of the schemae1. [[ f e1 � e2g ]]E = � M : Model � ft1 : [[ e1 ]]EM � [[ e2 ]]E (M � t1)gIn terms of the semantic universe, its semantic value, given a model M, is the set of values of e2 in M overriddenwith a binding value of e1 in M.

148 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)C.6.33 Characteristic set comprehensionC.6.33.1 SyntaxExpression = ...| ( ( f-tok , SchemaText , g-tok ) | ( f-tok , g-tok ) )| ( f-tok , Expression , g-tok )| ...;C.6.33.2 TransformationThe value of the characteristic set comprehension expression ftg is the set of the values of the characteristic tupleof t. ftg =) ft � chartuple tgIt is semantically equivalent to the corresponding set comprehension expression in which the characteristic tupleis made explicit.C.6.34 Schema constructionC.6.34.1 SyntaxExpression = ...| ( [-tok , SchemaText , ]-tok ) | ( [-tok , Expression , ]-tok )| ...;C.6.34.2 TransformationThe value of the schema construction expression [t] is that schema whose signature is the names declared by theschema text t, and whose bindings are those that satisfy the constraints in t.[t] =) tIt is semantically equivalent to the schema resulting from syntactic transformation of the schema text t.C.6.34.3 Type� E e oo �1� E [i : (e oo �1)] oo �2� �1 = P��2 = P[i : �] �In a variable construction expression [i : e], expression e shall be a set. The type of the whole expression is thatof a schema whose signature associates the name i with the type of a member of the set e.� E e oo �1 � � � P p� E [(e oo �1) j p] oo �2 � �1 = P[�]�2 = �1 �In a schema construction expression [e j p], expression e shall be a schema, and predicate p shall be well-typedin an environment overridden by the signature of schema e. The type of the whole expression is the same as thetype of expression e.C.6.34.4 SemanticsThe value of the variable construction expression [i : e] is the set of all bindings whose sole name is i and whoseassociated value is in the set that is the value of e.[[ [i : e] ]]E = � M : Model � fw : [[ e ]]EM � fi 7! wggc ISO/IEC 2000|All rights reserved 149

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionIn terms of the semantic universe, its semantic value, given a model M, is the set of all singleton bindings (setsof pairs) of the name i associated with a value from the set that is the semantic value of e in M.The value of the schema construction expression [e j p] is the set of all bindings of schema e that satisfy theconstraints of predicate p.[[ [e j p] ]]E = � M : Model � ft : [[ e ]]EM j M � t 2 [[ p ]]P � tgIn terms of the semantic universe, its semantic value, given a model M, is the set of the bindings (sets of pairs)that are members of the semantic value of schema e in M such that p is true in the model M overridden withthat binding.C.6.35 Binding extensionC.6.35.1 SyntaxExpression = ...| hj , [ DeclName , == , Expression ,{ ;-tok , DeclName , == , Expression } ] , ji| ...;C.6.35.2 Type� E e1 oo �1 ::: � E en oo �n� E hj i1 == (e1 oo �1); :::; in == (en oo �n) ji oo �� # fi1; :::; ing = n� = [i1 : �1; :::; in : �n] �In a binding extension expression hj i1 == e1; :::; in == en ji, there shall be no duplication amongst the boundnames. The type of the whole expression is that of a binding whose signature associates the names with the typesof the corresponding expressions.C.6.35.3 SemanticsThe value of the binding extension expression hj i1 == e1; :::; in == en ji is the binding whose names are asenumerated and whose values are those of the associated expressions.[[ hj i1 == e1; :::; in == en ji ]]E = � M : Model � fi1 7! [[ e1 ]]EM; :::; in 7! [[ en ]]EMgIn terms of the semantic universe, its semantic value, given a model M, is the set of pairs enumerated by itsnames each associated with the semantic value of the associated expression in M.C.6.36 Tuple extensionC.6.36.1 SyntaxExpression = ...| (-tok , Expression , ;-tok , Expression , { ;-tok , Expression } , )-tok| ...;C.6.36.2 Type� E e1 oo �1 ::: � E en oo �n� E ((e1 oo �1); :::; (en oo �n)) oo � � � = �1 � :::� �n �150 c ISO/IEC 2000|All rights reserved

C Organisation by concrete syntax production ISO/IEC 13568:2000(E)In a tuple extension expression (e1; :::; en), the type of the whole expression is the Cartesian product of the typesof the individual component expressions.C.6.36.3 SemanticsThe value of the tuple extension expression (e1; :::; en) is the tuple containing the values of its expressions inorder. [[ (e1; :::; en) ]]E = � M : Model � ([[ e1 ]]EM; :::; [[ en ]]EM)In terms of the semantic universe, its semantic value, given a model M, is the tuple whose components are thesemantic values of the component expressions in M.C.6.37 Characteristic de�nite descriptionC.6.37.1 SyntaxExpression = ...| (-tok , � , SchemaText , )-tok| ...;C.6.37.2 TransformationThe value of the characteristic de�nite description expression (� t) is the sole value of the characteristic tuple ofschema text t. (� t) =) � t � chartuple tIt is semantically equivalent to the corresponding de�nite description expression in which the characteristic tupleis made explicit.C.6.38 Parenthesized expressionC.6.38.1 SyntaxExpression = ...| (-tok , Expression , )-tok| ...;C.6.38.2 TransformationThe value of the parenthesized expression (e) is the value of expression e.(e) =) eIt is semantically equivalent to e.C.7 Schema textC.7.1 IntroductionA SchemaText introduces local variables, with constraints on their values.c ISO/IEC 2000|All rights reserved 151

ISO/IEC 13568:2000(E) C Organisation by concrete syntax productionC.7.2 SyntaxSchemaText = [ DeclPart ] , [ j-tok , Predicate ] ;DeclPart = Declaration , { ( ; -tok | NL ) , Declaration } ;Declaration = DeclName , { ;-tok , DeclName } , : , Expression| DeclName , == , Expression| Expression;C.7.3 TransformationThere is no separate schema text class in the annotated syntax: all concrete schema texts are transformed toexpressions.C.7.3.1 DeclarationEach declaration is transformed to an equivalent expression.A constant declaration is equivalent to a variable declaration in which the variable ranges over a singleton set.i == e =) i : fegA comma-separated multiple declaration is equivalent to the conjunction of variable construction expressions inwhich all variables are constrained to be of the same type.i1; :::; in : e =) [i1 : e oo �1] ^ ::: ^ [in : e oo �1]C.7.3.2 DeclPartEach declaration part is transformed to an equivalent expression.de1; :::; den =) de1 ^ ::: ^ denIf NL tokens have been used in place of any ; s, the same transformation to ^ applies.C.7.3.3 SchemaTextGiven the above transformations of Declaration and DeclPart, any DeclPart in a SchemaText can be assumedto be a single expression.A SchemaText with non-empty DeclPart and Predicate is equivalent to the schema construction expressioncontaining that schema text. e j p =) [e j p]If both DeclPart and Predicate are omitted, the schema text is equivalent to the set containing the emptybinding. =) fhj jigIf just the DeclPart is omitted, the schema text is equivalent to the schema construction expression in whichthere is a set containing the empty binding. j p =) [fhj jig j p]152 c ISO/IEC 2000|All rights reserved

D Tutorial ISO/IEC 13568:2000(E)Annex D(informative)TutorialD.1 IntroductionThe aim of this tutorial is to show, by examples, how this International Standard can be used to determinewhether a speci�cation is a well-formed Z sentence, and if it is, to determine its semantics. The examples coversome of the more di�cult parts of Z, and some of the recent innovations in the Z notation.D.2 Semantics as modelsThe semantics of a speci�cation is determined by sets of models, each model being a function from names de�nedby the speci�cation to values that those names are permitted to have by the constraints imposed on them in thespeci�cation. For example, consider the following speci�cation.n : Nn 2 f1; 2; 3; 4gThis speci�cation introduces one name with four possible values (ignoring the prelude section for the moment).The set of models de�ning the meaning of the speci�cation contains four models, as follows.ffn 7! 1g; fn 7! 2g; fn 7! 3g; fn 7! 4ggOne model of the prelude section can be written as follows.fA 7! A ;N 7! N;number literal 0 7! 0;number literal 1 7! 1;+ 7! f((0; 0); 0); ((0; 1); 1); ((1; 0); 1); ((1; 1); 2); :::ggThe behaviour of ( + ) on non-natural numbers, e.g. reals, has not been de�ned at this point, so the set ofmodels for the prelude section includes alternatives for every possible extended behaviour of addition. The set ofmodels for the whole speci�cation arises from extending models of the prelude section with associations for n inall combinations.This International Standard speci�es the relation between Z speci�cations and their semantics in terms of sets ofmodels. That relation is speci�ed as a composition of relations, each implementing a phase within the standard.Those phases are as identi�ed in Figure 1 in the conformance clause, namely mark-up, lexing, parsing, character-ising, syntactic transformation, type inference, semantic transformation and semantic relation. The rest of thistutorial illustrates the e�ects of those phases on example Z phrases.D.3 Given types and schema de�nition paragraphsThe following two paragraphs are taken from the birthday book speci�cation [12].[NAME ;DATE ]BirthdayBookknown : PNAMEbirthday : NAME 7! DATEknown = dom birthdayThe mark-up, lexing, parsing and syntactic transformation phases are illustrated using this example.c ISO/IEC 2000|All rights reserved 153

ISO/IEC 13568:2000(E) D TutorialD.3.1 Mark-upsThe mathematical representation of Z is what one would write with pen, pencil, chalk, etc. Instructing a computerto produce the same appearance currently requires the use of a mark-up language. There are many di�erent mark-up languages, each tailored to di�erent circumstances, such as particular typesetting software. This InternationalStandard de�nes some mark-ups in annex A, by relating substrings of the mark-up language to strings of Zcharacters. Source text for the birthday-book paragraphs written in the mark-ups de�ned in annex A follow. Thetranslation of these into sequences of Z characters is not explained here { annex A provides su�cient information.D.3.1.1 LATEX mark-up\begin{zed}[NAME, DATE]\end{zed}\begin{schema}{BirthdayBook}known : \power NAME\\birthday : NAME \pfun DATE\whereknown = \dom~birthday\end{schema}D.3.1.2 Email mark-up[NAME, DATE]+-- BirthdayBook ---known : %P NAMEbirthday : NAME -+-> DATE|--known = dom birthday---D.3.2 LexingLexing is the translation of a speci�cation's sequence of Z characters to a corresponding sequence of tokens. Thetranslation is de�ned by the lexis in clause 7. Associated with the tokens NAME and NUMERAL are the originalnames and numerals. Here on the left is the sequence of tokens corresponding to the extract from the birthdaybook (with -tok su�ces omitted), and on the right is the same sequence but revealing the underlying spelling ofthe name tokens.[NAME; NAME] END [NAME ;DATE ] ENDSCH NAME SCH BirthdayBookNAME : P NAME NL known : PNAME NLNAME : NAME I NAME birthday : NAME 7! DATEj jNAME = NAME NAME known = dom birthdayEND ENDThe layout here is of no signi�cance: there are NL and END tokens where ones are needed. The paragraph outlinehas been replaced by a SCH box token, to satisfy the linear syntax requirement of the syntactic metalanguage.NAME and I are name tokens: this abstraction allows the �xed size grammar of the concrete syntax to cope withthe extensible Z notation.This speci�cation's sequence of Z characters does conform to the lexis. If it had not, then subsequent phaseswould not be applicable, and this International Standard would not de�ne a meaning for the speci�cation.154 c ISO/IEC 2000|All rights reserved

D Tutorial ISO/IEC 13568:2000(E)D.3.3 ParsingParsing is the translation of the sequence of tokens produced by lexing to a tree structure, grouping the tokensinto grammatical phrases. The grammar is de�ned by the concrete syntax in clause 8. The parse tree for thebirthday-book speci�cation is shown in Figure D.1.The sequence of tokens produced by lexing can be seen in this tree by reading just the leaf nodes in order fromleft to right. To save space elsewhere in this International Standard, parse trees are presented as just their textualfringes, with parentheses added where necessary to override precedences.This speci�cation's sequence of tokens does conform to the concrete syntax. If it had not, then subsequent phaseswould not be applicable, and this International Standard would not de�ne a meaning for the speci�cation.D.3.4 Syntactic transformationThe meaning of a Z speci�cation is established by relating it to an interpretation in a semantic universe. Thatrelation is expressed using ZF set theory, which is not itself formally de�ned. It is therefore bene�cial to de�neas much Z notation as possible by transformations to other Z notation, so that only a relatively small kernel needbe related using ZF set theory. Conveniently, that Z kernel contains largely notation that has direct counterpartsin traditional ZF set theory, the novel Z notation having been largely transformed away. A further bene�t is thatthe transformations reveal relationships between di�erent Z notations. The syntactic transformation stage is oneof several phases of such transformation.The syntactic transformation rules (clause 12) are applied to a parsed sentence of the concrete syntax (clause 8).The notation that results is a sentence of the annotated syntax (clause 10).Consider the e�ect of the syntactic transformation rules on the birthday book extract. There is no syntacticFigure D.1 { Parse tree of birthday book exampleAnonymous specification

Given types paragraph Schema definition paragraph

[ NAME , NAME ] END SCH NAME SchemaText END

NAME DATE BirthdayBook DeclPar t | Relation predicate

Declaration NL Declaration InfixRel

DeclName : Application DeclName : Application RefName = application

NAME powerset NAME InfixApp NAME RefName RefName

known P RefName birthday RefName I RefName known NAME NAME

NAME NAME I NAME dom birthday

NAME NAME DATE

c ISO/IEC 2000|All rights reserved 155

ISO/IEC 13568:2000(E) D Tutorialtransformation rule for given types; given types are in the annotated syntax. So the �rst paragraph is leftunchanged.[NAME;NAME] END [NAME ;DATE ] ENDThe schema paragraph requires several syntactic transformations before it becomes a sentence of the annotatedsyntax. The order in which these syntactic transformations are applied does not matter, as the same result isobtained.Transform NL by �rst rule in 12.2.7.SCH NAME SCH BirthdayBookNAME : P NAME; known : PNAME ;NAME : NAME I NAME birthday : NAME 7! DATEj jNAME = NAME NAME known = dom birthdayEND ENDTransform generic application NAME 7! DATE by sixth InfixApp rule in 12.2.11.SCH NAME SCH BirthdayBookNAME : PNAME; known : PNAME ;NAME : NAME [NAME; NAME] birthday : 1 7!1 [NAME ;DATE ]j jNAME = NAME NAME known = dom birthdayEND ENDTransform equality by third InfixRel rule in 12.2.10.SCH NAME SCH BirthdayBookNAME : PNAME; known : PNAME ;NAME : NAME [NAME; NAME] birthday : 1 7!1 [NAME ;DATE ]j jNAME 2 fNAME NAMEg known 2 fdom birthdaygEND ENDTransform basicdecls by sixth rule in 12.2.7.SCH NAME SCH BirthdayBook[NAME : PNAME]; [known : PNAME ];[NAME : NAME [NAME; NAME]] [birthday : 1 7!1 [NAME ;DATE ]]j jNAME 2 fNAME NAMEg known 2 fdom birthdaygEND ENDTransform schema text by second rule in 12.2.7.SCH NAME SCH BirthdayBook[[NAME : PNAME] ^ [[known : PNAME ] ^[NAME : NAME [NAME; NAME]] [birthday : 1 7!1 [NAME ;DATE ]]j jNAME 2 fNAME NAMEg] known 2 fdom birthdayg]END ENDTransform paragraph by �rst rule in 12.2.3.156 c ISO/IEC 2000|All rights reserved

D Tutorial ISO/IEC 13568:2000(E)AX AX[NAME == [BirthdayBook ==[[NAME : PNAME] ^ [[known : PNAME ] ^[NAME : NAME [NAME; NAME]] [birthday : 1 7!1 [NAME ;DATE ]]j jNAME 2 fNAME NAMEg]] known 2 fdom birthdayg]END ENDThe two paragraphs now form a sentence of the annotated syntax. These syntactic transformations do not changethe meaning: the meaning of the annotated representation is the same as that of the original schema paragraph.This is ensured, despite transformations to notations of di�erent precedences, by transforming trees not text {the trees are presented as text above solely to save space.Do not be surprised that the result of syntactic transformation looks \more complicated" than the originalformulation { if it did not, there would not have been much point in having the notation that has been transformedaway. The bene�ts are that fewer notations remain to be de�ned, and those that have been de�ned have beende�ned entirely within Z.D.4 Axiomatic description paragraphsHere is a very simple axiomatic description paragraph, preceded by an auxiliary given types paragraph.[X ]i : XD.4.1 Lexing and parsingLexing generates the following sequence of tokens, with corresponding spellings of name tokens.[NAME] END [X ] ENDAX NAME : NAME END AX i : X ENDParsing proceeds as for the birthday book, so is not explained in detail again.D.4.2 Syntactic transformationThe schema text is transformed to an expression.AX [NAME : NAME] END AX [i : X ] ENDThis is now a sentence of the annotated syntax.D.4.3 Type inferenceThe type inference phase adds annotations to each expression and each paragraph in the parse tree. Withoutgoing into too much detail, the signature of the given types paragraph is determined by rule 13.2.4.1 to beX : P(GIVEN X ).[X ] END oo X : P(GIVEN X )Rule 13.2.2.1 adds the name of the given type X to the type environment, associated with type P(GIVEN X ). Theannotation for the reference expression referring to X is determined by rule 13.2.6.1 using that type environmentto be P(GIVEN X ). Hence the type of the variable construction expression is found by rule 13.2.6.13 to beP[i : GIVEN X ]. Hence the signature of the axiomatic description paragraph is determined. The resultingannotated tree is shown in Figure D.2, and as linear text as follows.AX ([i : (X oo P(GIVEN X ))] oo P[i : GIVEN X ]) END oo i : GIVEN XThis speci�cation's parse tree is well-typed. If it were not, then subsequent phases would not be applicable, andthis International Standard would not de�ne a meaning for the speci�cation.c ISO/IEC 2000|All rights reserved 157

ISO/IEC 13568:2000(E) D TutorialD.4.4 Semantic relationThe semantic relation phase takes a sentence of the annotated syntax and relates it to its meaning in terms ofsets of models. The meaning of a paragraph d is given by the semantic relation [[ d ]]D, which relates a model tothat same model extended with associations between its names and their semantic values in the given model. Forthe example given types paragraph, the semantic relation in 15.2.3.1 relates any model to that model extendedwith an association of the given type name X with an arbitrarily chosen set w . (A further association is madebetween a distinctly decorated version of the given type name X~ and that same semantic value, for use inavoiding variable capture.)fX 7! w ;X~ 7! wgThis is one model of the pre�x of the speci�cation up to the given types paragraph (ignoring the prelude). Theset of models de�ning the meaning of this pre�x includes other models, each with a di�erent set w .The meaning of an expression e is given by the semantic function [[ e ]]E , which maps the expression to its semanticvalue in a given model. Within the axiomatic description paragraph, the reference to the given type X has asemantic value determined by relation 15.2.5.1 as being the semantic value w already associated with the giventype name X in the model. The variable construction expression [i : X ] has a semantic value determined byrelation 15.2.5.9 that represents a set of bindings of the name i to members of the semantic value of the referenceto X , i.e. the set w . The meaning of the example axiomatic description paragraph, as given by semantic relation15.2.3.2, is to relate any model to that model extended with a binding that is in the set that is the semantic valueof the variable construction expression. So, if the members of w are w1;w2; :::, then the set of models de�ningthe meaning of the speci�cation includes the following.ffX 7! w ;X~ 7! w ; i 7! w1g; fX 7! w ;X~ 7! w ; i 7! w2g; :::gIf w is chosen to be the empty set, then the set of models is empty.D.5 Generic axiomatic description paragraphsHere is a generic axiomatic description paragraph. Although it looks simple, it has the complication of being aloose generic de�nition.Figure D.2 { Annotated parse tree of part of axiomatic exampleanonymous specification

given typesoo [X : P (GIVEN X)]

axiomatic descriptionoo [i : GIVEN X]

[ NAME ] END AX variable constructionoo P [i : GIVEN X] END

X [ NAME : referenceoo P (GIVEN X) ]

i NAME

X158 c ISO/IEC 2000|All rights reserved

D Tutorial ISO/IEC 13568:2000(E)[X ]i : PXD.5.1 Lexing and parsingLexing generates the following sequence of tokens, with corresponding spellings of name tokens.GENAX [NAME] NAME : PNAME END GENAX [X ] i : PX ENDParsing proceeds as for the birthday book, so is not explained in detail again.D.5.2 Syntactic transformationThe schema text is transformed to an expression.GENAX [NAME] [NAME : PNAME] END GENAX [X ] [i : PX ] ENDThis is now a sentence of the annotated syntax.D.5.3 Type inferenceWithout going into too much detail, rule 13.2.4.3 adds the name of the generic parameter X to the type en-vironment, associated with type P(GENTYPE X ). The annotation for the reference expression referring to X isdetermined by rule 13.2.6.1 using that type environment to be P(GENTYPE X ). Hence the type of the powersetexpression is found by rule 13.2.6.5 to be PP(GENTYPE X ). Hence the type of the variable construction expressionis found by rule 13.2.6.13 to be P[i : P(GENTYPE X )]. Hence the signature of the generic axiomatic descriptionparagraph is determined.GENAX [X ] ([i : (P(X oo P(GENTYPE X )) oo PP(GENTYPE X ))] oo P[i : P(GENTYPE X )]) END oo i : P(GENTYPE X )D.5.4 Semantic relationEvery use of a generic de�nition instantiates the generic parameters with particular sets. A suitable semanticvalue for a generic de�nition is therefore a function from the semantic values of the sets instantiating the genericparameters to the semantic value of the de�nition given those values for the parameters. In the case of a loosegeneric de�nition, several models are needed to express its semantics, each giving a di�erent function. Each modelde�ning the meaning of the example generic axiomatic description paragraph has the following form.fi 7! fs1 7! subset of s1; s2 7! subset of s2; :::ggThe model associates the name i with a function from sets s1; s2; ::: instantiating the generic parameter X tothe semantic value of i resulting from the corresponding instantiation. Di�erent models for this paragraph havedi�erent subsets of s1; s2; :::. The way this is de�ned by the semantic relations is roughly as follows.The semantic relation in 15.2.3.3 speci�es that w is a binding in the semantic value of schema e in the givenmodel extended with an association of the generic parameter X with the set instantiating it w1. (The model isalso extended with a further association between a distinctly decorated version of the generic parameter X� andthat same semantic value w1, for use in avoiding variable capture). This is speci�ed in a way that is cautiousof e being unde�ned in the extended model. The determination of the value of e is done in the same way asfor the preceding example, using semantic relations 15.2.5.5, 15.2.5.1 and 15.2.5.9. The semantic relation for theparagraph is then able to extend its given model with the association illustrated above.D.6 Operator templates and genericsThe de�nition of relations in the toolkit provides an example of an operator template and the de�nition of ageneric operator.generic 5 rightassoc ( $ )X $ Y == P(X �Y )c ISO/IEC 2000|All rights reserved 159

ISO/IEC 13568:2000(E) D TutorialD.6.1 Lexing and parsingAn operator template paragraph a�ects the lexing and parsing of subsequent paragraphs. In this example, it causessubsequent appearances of names using the word $ to be lexed as I tokens, and hence its in�x applications areparsed as operator names (illustrated in the example) or as generic operator application expressions. An operatortemplate paragraph does not have any further e�ect on the meaning of a speci�cation, so a parsed representationis needed of only the generic operator de�nition paragraph, for which lexing generates the following sequence oftokens and corresponding spellings of name tokens.NAME I NAME == P(NAME� NAME) END X $ Y == P(X �Y ) ENDParsing proceeds as for the birthday-book example, so is not explained in detail again.D.6.2 Syntactic transformationThe generic operator name is transformed by the �rst InfixGenName rule in 12.2.9.I [NAME; NAME] == P(NAME� NAME) END $ [X ;Y ] == P(X �Y ) ENDThis generic horizontal de�nition paragraph is then transformed by 12.2.3.4 to a generic axiomatic descriptionparagraph, which is the sole form of generic de�nition for which there is a semantic relation.GENAX [NAME; NAME] GENAX [X ;Y ]I == P(NAME� NAME) $ == P(X �Y )END ENDTransform Cartesian product expression by the rule in 12.2.6.8 to a set of pairs.GENAX [NAME; NAME] GENAX [X ;Y ]I == PfNAME : NAME; NAME : NAME � (NAME; NAME)g $ == Pfx : X ; y : Y � (x ; y)gEND ENDTransform the operator name by the �rst InfixName rule in 12.2.8.3.GENAX [NAME; NAME] GENAX [X ;Y ]NAME == PfNAME : NAME; NAME : NAME � (NAME; NAME)g 1$1 == Pfx : X ; y : Y � (x ; y)gEND ENDTransform the schema texts to expressions.GENAX [NAME; NAME] GENAX [X ;Y ][NAME : fPf[NAME : NAME] ^ [NAME : NAME] � (NAME; NAME)gg] [1$1 : fPf[x : X ] ^ [y : Y ] � (x ; y)gg]END ENDThis is now a sentence of the annotated syntax.D.6.3 Type inferenceThe type inference phase adds annotations to the parse tree. For this example, the resulting subtree for the setextension expression (to the right of the colon) is shown in Figure D.3.Informally, the way the annotations are determined is as follows. The type inference rule for generic axiomaticdescription paragraph (13.2.4.3) overrides the type environment with types for the generic parameters X andY . The type inference rule for reference expression (13.2.6.1) retrieves these types for the references to X andY . The type inference rule for variable construction expression (13.2.6.13) builds the schema types. The typeinference rule for schema conjunction expression (13.2.6.16) merges those schema types. The type inference rulefor set comprehension expression (13.2.6.4) overrides the type environment with types for the local declarationsx and y . The type inference rule for reference expression (13.2.6.1) retrieves these types for the references to xand y . The type inference rule for tuple extension expression (13.2.6.6) builds the Cartesian product type. Thetype of the set comprehension is thus determined, and hence that of the powerset by rule 13.2.6.5 and that of theset extension by rule 13.2.6.3.160 c ISO/IEC 2000|All rights reserved

D Tutorial ISO/IEC 13568:2000(E)D.6.4 Semantic relationFor the example generic axiomatic description paragraph, the semantic relation in 15.2.3.3 associates name $with a function from the semantic values of the sets instantiating the generic parameters X and Y to thesemantic value of the powerset expression given those values for X and Y . The semantic value of the example'spowerset expression is given by semantic relations 15.2.5.4, 15.2.5.5 and 15.2.5.6 as sets of tuples in ZF set theory.Hence the example generic axiomatic description paragraph adds the following association to the meaning of thespeci�cation.( $ ) 7! f(set for X ; set for Y ) 7! value of powerset expression given that X and Y ;and so on for all combinations of sets for X and Y gSyntactic transformation 12.2.3.4 moved the name of the generic operator to after the generic parameters. Inconstructing this association, the name had to be lifted back out again. This has sometimes been called thegeneric lifting operation.D.7 List argumentsAn operator that forms an indexed-from-zero sequence can be introduced and de�ned as follows. The de�nitionuses several toolkit notations.function (h0 ; ; i0)h0 ; ; i0[X ] == � s : seq X � fb : dom s ; r : ran s � b � 1 7! rgThe semantics of an application of this operator, for example h01; 2; 1i0, are de�ned as follows.Figure D.3 { Annotated parse tree of part of generic exampleset extension

oo P ( P ( P (GENTYPE X 0 GENTYPE Y)))

{ powersetoo P (P (GENTYPE X 0 GENTYPE Y)) }

P set comprehensionoo P (GENTYPE X 0 GENTYPE Y)

{ conjunctionoo P [x : GENTYPE X; y : GENTYPE Y] + tuple extension

oo GENTYPE X 0 GENTYPE Y }

variable constructionoo P [x : GENTYPE X] * variable construction

oo P [y : GENTYPE Y] ( RefName

oo GENTYPE X , RefName

oo GENTYPE Y )

[ NAME : RefNameoo P (GENTYPE X) ] [ NAME : RefName

oo P (GENTYPE Y) ] NAME NAME

x NAME y NAME x y

X Y

c ISO/IEC 2000|All rights reserved 161

ISO/IEC 13568:2000(E) D TutorialD.7.1 Lexing and parsingThe application is recognised as being an instance of the NofixApp rule in the concrete syntax, the word h0 beinglexed as a L token and the word i0 being lexed as a SR token. Between those brackets, 1; 2; 1 is recognised as anExpressionList.L NUMERAL; NUMERAL; NUMERAL SR h01; 2; 1i0D.7.2 Syntactic transformationThe ExpressionList is transformed to an expression by rule 12.2.12.L f(NUMERAL; NUMERAL); h0f(1; 1); (2; 2); (3; 1)gi0(NUMERAL; NUMERAL);(NUMERAL; NUMERAL)g SRThe NofixApp is transformed to an application expression.NAME f(NUMERAL; NUMERAL); h01i0 f(1; 1); (2; 2); (3; 1)g(NUMERAL; NUMERAL);(NUMERAL; NUMERAL)gThe operator notation has now been eliminated, and so the semantic de�nition proceeds as usual for the remainingnotation. All applications of operator notation are eliminated by such syntactic transformations.D.8 Mutually recursive free typesThe standard notation for free types is an extension of the traditional notation, to allow the speci�cation ofmutually recursive free types, such as the following example.exp ::= NodehhN1 iij Condhhpred � exp � expii&pred ::= Comparehhexp � expiiThis speci�es a tiny language, in which an expression exp can be a conditional involving a predicate pred , and apred compares expressions. A more realistic example would have more kinds of expressions and predicates, andmaybe other auxiliary types perhaps in mutual recursion with these two, but this small example su�ces here.Like the previous examples, the source text for this one has to be taken through the phases of mark-up, lexing,parsing, syntactic transformation and type inference. (There are no applicable characterisations or instantiations.)The focus here is on the semantic transformation of free types. (Strictly, the Cartesian products should besyntactically transformed �rst, but keeping them makes the following more concise.)D.8.1 Semantic transformationTransforming the above free types paragraph by rule 12.2.3.5 generates the following Z notation. The semantictransformation rules are de�ned in terms of concrete notation for clarity, which should itself be subjected tofurther transformations, though that is not done here.D.8.1.1 Type declarations[exp; pred ]D.8.1.2 Membership constraintsNode : P(N1 � exp)Cond : P((pred � exp � exp)� exp)Compare : P((exp � exp) � exp)162 c ISO/IEC 2000|All rights reserved

D Tutorial ISO/IEC 13568:2000(E)D.8.1.3 Total functionality constraints8u : N1 � 91 x : Node � x :1 = u8u : pred � exp � exp � 91 x : Cond � x :1 = u8u : exp � exp � 91 x : Compare � x :1 = uD.8.1.4 Injectivity constraints8u; v : nat1 j Node u = Node v � u = v8u; v : pred � exp � exp j Cond u = Cond v � u = v8u; v : exp � exp j Compare u = Compare v � u = vD.8.1.5 Portmanteau disjointness constraintThere are no disjointness constraints from the pred type as it has only one injection and no element values.8 b1; b2 : N �8w : exp j(b1 = 1 ^ w 2 fx : Node � x :2g _b1 = 2 ^ w 2 fx : Cond � x :2g)^ (B2 = 1 ^ w 2 fx : Node � x :2g _b2 = 2 ^ w 2 fx : Cond � x :2g) �b1 = b2D.8.1.6 Induction constraint8w1 : P exp; w2 : Ppred j(8 y : (� exp == w1; pred == w2 � N1 ) �Node y 2 w1) ^(8 y : (� exp == w1; pred == w2 � pred � exp � exp) �Cond y 2 w1) ^(8 y : (� exp == w1; pred == w2 � exp � exp) �Compare y 2 w2) �w1 = exp ^ w2 = predD.9 Chained relations and implicit generic instantiationThe semantics of chained relations is de�ned to give a meaning to this example,f1g 6= ? � f2; 3gin which ? refers to the generic de�nition of empty set and so is implicitly instantiated, whilst rejecting thefollowing example as being not well-typed,f(1; 2)g 6= ? � Abecause the single ? expression in the second example needs to be instantiated di�erently for the two relations.To demonstrate how this is done, the former example is taken through syntactic transformation and type inference,including the �lling in of the implicit instantiations.c ISO/IEC 2000|All rights reserved 163

ISO/IEC 13568:2000(E) D TutorialD.9.1 Syntactic transformationThe chaining is transformed by the �rst InfixRel rule in 12.2.10 to a conjunction of relations in which theduplicates of the common expression are constrained to be of the same type by giving them the same annotation.f1g 6= (? oo �) ^ (? oo �) � f2; 3gThe third InfixRel rule in 12.2.10 transforms these two relations to membership predicates.(f1g; (? oo �)) 2 ( 6= ) ^ ((? oo �); f2; 3g) 2 ( � )The two operator names are transformed by the second rule in 12.2.8.3.(f1g; (? oo �)) 2 16=1 ^ ((? oo �); f2; 3g) 2 1�1This is now a phrase of the annotated syntax.D.9.2 Type inferenceType inference on this example generates the annotations illustrated in Figure D.4. (The tool used to draw that�gure has no 1 symbol, so 1 is used instead.)Those reference expressions that refer to generic de�nitions have to be transformed to generic instantiationexpressions for their meaning to be determined. This is done by the instantiation rule (13.2.3.3). It determinesthe generic instantiations by comparison of the generic type with the inferred type. For example, the referencesto ? have been given the type annotation P(GIVEN A ), which is the instance of [X ]P(GENTYPE X ) in whichGENTYPE X is GIVEN A . The desired instantiating expression is the carrier set of that type, which is A . It isgenerated by the instantiation rule, which e�ects the following transformation.Figure D.4 { Annotated parse tree of chained relation exampleconjunction

membership * membership

tuple extension

ooP (GIVEN A) 0 P (GIVEN A)

/

reference

oo [X] P (GENTYPE X 0 GENTYPE X),

P (P (GIVEN A) 0 P (GIVEN A))

tuple extension

ooP (GIVEN A) 0 P (GIVEN A)

/

reference

oo [X] P (P (GENTYPE X) 0 P (GENTYPE X)),

P (P (GIVEN A) 0 P (GIVEN A))

(set extension

ooP (GIVEN A)

,

reference

oo [X] P (GENTYPE X),

P (GIVEN A)

) NAME (

reference

oo [X] P (GENTYPE X),

P (GIVEN A)

,set extension

P (GIVEN A)) NAME

{number literal

oo GIVEN A

} NAME ∞6∞ NAME {number literal

oo GIVEN A

,number literal

oo GIVEN A

} ∞9∞

1 8 8 NUMERAL NUMERAL

2 3164 c ISO/IEC 2000|All rights reserved

D Tutorial ISO/IEC 13568:2000(E)? oo [X ]PX ;P(GIVEN A ) =) ?[A oo P(GIVEN A )] oo P(GIVEN A )Similarly, the reference to 16=1 has type P(P(GIVEN A )�P(GIVEN A )) which is the instance of [X ]P(GENTYPE X�GENTYPE X ) in which GENTYPE X is P(GIVEN A ). The instantiating expression is the carrier set of that type, whichis PA .Similarly again, the reference to 1�1 has type P(P(GIVEN A ) � P(GIVEN A )) which is the instance of[X ]P(P(GENTYPE X ) � P(GENTYPE X )) in which GENTYPE X is GIVEN A . The instantiating expression is thecarrier set of that type, which is A .D.10 Logical inference rulesThis document does not attempt to standardise any particular deductive system for Z. However, the soundnessof potential logical inference rules can be shown relative to the sets of models de�ned by the semantics. Someexamples are given here.The predicate true can be used as an axiom. The proof of this is trivial: an axiom p is sound if and onlyif [[ p ]]P = Model (as given by the de�nition of soundness in 5.2.3), and from the semantic relation for truthpredicates (15.2.4.2), [[ true ]]P = Model .The inference rule with premise : : p and consequent p is sound if and only if[[ : : p ]]P � [[ p ]]P(again as given by the de�nition of soundness in 5.2.3). By two applications of the semantic relation for negationpredicate (15.2.4.3), this becomesModel n (Model n [[ p ]]P) � [[ p ]]Pwhich by properties of set di�erence becomes[[ p ]]P � [[ p ]]Pwhich is a property of set inclusion.The transformation rules of clauses 12 and 14 inspire corresponding logical inference rules: any logical infer-ence rule whose sole premise matches the left-hand side of a transformation rule and whose consequent is thecorresponding instantiation of that transformation rule's right-hand side is sound.

c ISO/IEC 2000|All rights reserved 165

ISO/IEC 13568:2000(E) E Conventions for state-based descriptionsAnnex E(informative)Conventions for state-based descriptionsE.1 IntroductionThis annex records some of the conventions of notation that are often used when state-based descriptions ofsystems are written in Z. Conventions for identifying before and after states (x and x 0) and input and outputvariables (i? and o!) are given.E.2 StatesWhen giving a model-based description of a system, the state of the system and the operations on the state arespeci�ed. Each operation is described as a relation between states. It is therefore necessary to distinguish betweenthe values of state variables before the operation and their values afterwards. The convention in Z described hereis to use dashes (primes) to make this distinction: if the state variables are x and y , then a predicate describingan operation is written using the variables x ; y ; x 0; y 0, where x and y denote the values before the operation, andx 0 and y 0 denote the values afterwards. (The predicate can also refer to any global constants.) For instance,if x and y are both integer variables, then an operation which incremented both variables could be speci�ed asfollows.x 0 = x + 1 ^ y 0 = y + 1In order to use predicates like this to describe operations, all of the variables have to be in scope. If the statehas been described in a schema S , then including S in the declaration part of the operation schema brings thestate variables|x and y in the example above| into scope. The after-state variables are similarly introducedby including S 0: this is a schema obtained from S by adding a dash to all the variables in the signature of S ,and replacing every occurrence of such a variable in the predicate part of S by its dashed counterpart. Noticethat the variables from the signature of S are the only ones which are dashed|global constants, types etc remainundashed. If S contains a variable which has already been decorated in some way, then an extra dash is addedto the existing decoration.Thus operations can be described in Z by a schema of the formOpSS 0...Since the inclusion of undashed and dashed copies of the state schema is so common, an abbreviation is used:�S == [S ; S 0]The operation schema above now becomesOp�S...166 c ISO/IEC 2000|All rights reserved

E Conventions for state-based descriptions ISO/IEC 13568:2000(E)It should be stressed that � is not an `operator on schemas', merely a character in the schema name. One reasonfor this is that some authors like to include additional invariants in their �-schemas. For instance, if S containedan additional component z , but none of the operations ever changed z , then �S could be de�ned by�S == [S ; S 0 j z 0 = z ] ;thus making it unnecessary to include z 0 = z in each operation description. If a name �S is referred to without adeclaration of it having appeared previously, the reference is equivalent to [S ; S 0] as de�ned formally in 13.2.6.1.It should be noted that strange results can occur if this implicit de�nition of �S is used on a schema S thatcontains variables which are not intended to be state components, perhaps inputs or outputs (see below). Thesequence of strokes after a variable name might then become di�cult to interpret.There is one further piece of notation for describing state transitions: when enquiry operations are being described,it is often necessary to specify that the state should not change. For this the abbreviation �S is used. Unless ithas been explicitly de�ned to mean something else, references to �S are equivalent to [S ; S 0 j �S = �S 0]. Notethat �S is not de�ned in terms of �S , in case �S has been given an explicit unconventional de�nition.E.3 Inputs and outputsFor many systems, it is convenient to be able to describe operations not just in terms of relations between states,but with inputs and outputs as well. The input values of an operation are provided by `the environment', andthe outputs are returned to the environment.In order to distinguish a variable intended as either an input or an output in an operation schema from a state-before variable (which has no decoration), an additional su�x is used: ? for input variables and ! for outputvariables. Thus name? denotes an input, and result ! denotes an output.E.4 Schema operatorsThe schema operators pre, o9 and >> make use of this decoration convention.

c ISO/IEC 2000|All rights reserved 167

ISO/IEC 13568:2000(E) BibliographyBibliography[1] Enderton, H.B., Elements of Set Theory Academic Press, 1977[2] Hayes, I. (editor) Speci�cation Case Studies Prentice-Hall, �rst edition, 1987[3] Hayes, I. (editor) Speci�cation Case Studies Prentice-Hall, second edition, 1993[4] ISO/IEC 646:1991 Information technology|ISO 7-bit coded character set for information interchange 3rdedition[5] The Unicode Consortium The Unicode Standard Version 2.0, second edition, Addison Wesley, 1997[6] ISO/IEC 14977:1996 Information Technology|Syntactic Metalanguage|Extended BNF[7] King, S., S�rensen, I.H. and Woodcock, J.C.P. Z: Grammar and Concrete and Abstract Syntaxes PRG-68,Programming Research Group, Oxford University, July 1988[8] Lalonde, W.R. and des Rivieres, J. Handling Operator Precedence in Arithmetic Expressions with Tree Trans-formations ACM Transactions on Programming Languages and Systems, 3(1) January 1981[9] Lamport, L. LATEX: A Document Preparation System|User's Guide and Reference Manual Addison-Wesley,second edition, 1994[10] Spivey, J.M., Understanding Z Cambridge University Press, 1988[11] Spivey, J.M., The Z Notation|A Reference Manual Prentice-Hall, �rst edition, 1989[12] Spivey, J.M., The Z Notation|A Reference Manual Prentice-Hall, second edition, 1992, out-of-print, avail-able from http://spivey.oriel.ox.ac.uk/~mike/zrm/index.html[13] Sufrin, B. (editor) Z Handbook Programming Research Group, Oxford University, March 1986[14] Toyn, I. Innovations in the Notation of Standard Z ZUM'98: The Z Formal Speci�cation Notation, Springer-Verlag Lecture Notes in Computer Science 1493, pp193-213, 1998[15] Toyn, I, Valentine, S.H, Stepney, S. and King, S. Typechecking Z ZB2000: The International Conference ofB and Z Users, Springer-Verlag Lecture Notes in Computer Science, 2000

168 c ISO/IEC 2000|All rights reserved

Index ISO/IEC 13568:2000(E)Index+ (addition)in mathematical metalanguage, 7in prelude, 43- (arithmetic negation)in mathematical toolkit, 99�! (bijections)in mathematical metalanguage, 8in mathematical toolkit, 97� (binding construction)expression, see binding construction expressionhj; ; ji (binding extension)expression, see binding extension expression: (binding selection)expression, see binding selection expression# (cardinality)in mathematical metalanguage, 7in mathematical toolkit, 103� (Cartesian product)expression, see Cartesian product expressionin mathematical metalanguage, 7type, see Cartesian product type(� j ) (characteristic de�nite description)expression, see characteristic de�nite descriptionexpressionf j g (characteristic set comprehension)expression, see characteristic set comprehension ex-pression� (compatible relations)in mathematical metalanguage, 8a (concatenation)in mathematical toolkit, 104in metalanguage, 39`? (conjecture)paragraph, see conjecture paragraph^ (conjunction)expression, see schema conjunction expressionin mathematical metalanguage, 4predicate, see conjunction predicate� j � (de�nite description)expression, see de�nite description expression_ (disjunction)expression, see schema disjunction expressionin mathematical metalanguage, 4predicate, see disjunction predicatea= (distributed concatenation)in mathematical toolkit, 106C (domain restriction)in mathematical metalanguage, 8in mathematical toolkit, 95�C (domain subtraction)in mathematical metalanguage, 8

in mathematical toolkit, 95? (empty set)in mathematical metalanguage, 6in mathematical toolkit, 91= (equality)in mathematical metalanguage, 6predicate, see relation operator application predi-cate, (equivalence)expression, see schema equivalence expressionpredicate, see equivalence predicate9 j � (existential quanti�cation)expression, see schema existential quanti�cation ex-pressionin mathematical metalanguage, 5predicate, see existential quanti�cation predicate� (extraction)in mathematical toolkit, 105� (�ltering)in mathematical toolkit, 1057 7! (�nite functions)in mathematical metalanguage, 8in mathematical toolkit, 987 7� (�nite injections)in mathematical toolkit, 98::= (free type)paragraph, see free types paragraph� j � (function construction)expression, see function construction expressionin mathematical metalanguage, 8� (functional composition)in mathematical toolkit, 947! (functions)in mathematical metalanguage, 8T (generalized intersection)in mathematical toolkit, 93S (generalized union)in mathematical toolkit, 93� (generic type name stroke), 40~ (given type name stroke), 40> (greater than)in mathematical toolkit, 100� (greater than or equal)in mathematical toolkit, 100) (implication)expression, see schema implication expressionpredicate, see implication predicate6= (inequality)in mathematical toolkit, 91" (iterated product)in mathematical metalanguage, 7(iteration)in mathematical toolkit, 102c ISO/IEC 2000|All rights reserved 169

ISO/IEC 13568:2000(E) Index(juxtaposition)expression, see application expressionin mathematical metalanguage, 9� � (lambda)expression, see function construction expression< (less than)in mathematical toolkit, 100� (less than or equal)in mathematical toolkit, 1007! (maplet)in mathematical metalanguage, 7in mathematical toolkit, 942 (membership)in mathematical metalanguage, 6predicate, see membership predicate� � (mu)expression, see de�nite description expression� (multiplication)in mathematical toolkit, 101: (negation)expression, see schema negation expressionin mathematical metalanguage, 4predicate, see negation predicateNL (newline conjunction)in mathematical metalanguage, 4predicate, see newline conjunction predicate62 (non-membership)in mathematical metalanguage, 6in mathematical toolkit, 91: : (numeric range)in mathematical metalanguage, 7in mathematical toolkit, 102( ) (parentheses)expression, see parenthesized expressionin mathematical metalanguage, 4predicate, see parenthesized predicate7! (partial functions)in mathematical toolkit, 977� (partial injections)in mathematical toolkit, 977!! (partial surjections)in mathematical toolkit, 97� (proper subset)in mathematical toolkit, 91B (range restriction)in mathematical toolkit, 95�B (range subtraction)in mathematical toolkit, 95� (re exive transitive closure)in mathematical toolkit, 96o9 (relational composition)in mathematical metalanguage, 8in mathematical toolkit, 94

(j j) (relational image)in mathematical metalanguage, 8in mathematical toolkit, 96� (relational inversion)in mathematical metalanguage, 8in mathematical toolkit, 95� (relational overriding)in mathematical metalanguage, 8in mathematical toolkit, 96$ (relations)in mathematical toolkit, 90o9 (schema composition)expression, see schema composition expression, (schema equivalence)expression, see schema equivalence expressionn (schema hiding)expression, see schema hiding expression) (schema implication)expression, see schema implication expression>> (schema piping)expression, see schema piping expression� (schema projection)expression, see schema projection expression= (schema renaming)expression, see schema renaming expressionh; ; i (sequence brackets)in mathematical metalanguage, 9in mathematical toolkit, 104f j � g (set comprehension)expression, see set comprehension expressionin mathematical metalanguage, 6n (set di�erence)in mathematical metalanguage, 6in mathematical toolkit, 92f; ; g (set extension)expression, see set extension expressionin mathematical metalanguage, 6\ (set intersection)in mathematical metalanguage, 6in mathematical toolkit, 92 (set symmetric di�erence)in mathematical toolkit, 92[ (set union)in mathematical metalanguage, 6in mathematical toolkit, 92� (subset)in mathematical metalanguage, 6in mathematical toolkit, 91� (subtraction)in mathematical toolkit, 99! (total functions)in mathematical metalanguage, 8in mathematical toolkit, 90170 c ISO/IEC 2000|All rights reserved

Index ISO/IEC 13568:2000(E)� (total injections)in mathematical toolkit, 97!! (total surjections)in mathematical toolkit, 97+ (transitive closure)in mathematical toolkit, 96( ,, ) (tuple extension)expression, see tuple extension expressionin mathematical metalanguage, 791 j � (unique existential quanti�cation)expression, see schema unique existential quanti�-cation expressionin mathematical metalanguage, 5predicate, see unique existential quanti�cation pred-icate8 j � (universal quanti�cation)expression, see schema universal quanti�cation ex-pressionin mathematical metalanguage, 5predicate, see universal quanti�cation predicateALPHASTR, 24Annotated syntax, 40anonymous speci�cationconcrete syntax, 31, 109syntactic transformation, 44, 109application expressionannotated syntax, 42concrete syntax, 32, 141semantic transformation, 69, 141type inference rule, 62, 141A (arithmos)in prelude, 43associativity of operators, 35AX, 25AXCHAR, 21axiomatic description paragraphannotated syntax, 40concrete syntax, 31, 112semantic relation, 73, 112type inference rule, 58, 112base sectionconcrete syntax, 31, 111syntactic transformation, 45, 111Bibliography, 168binding, 1binding construction expressionannotated syntax, 42concrete syntax, 32, 144semantic transformation, 69, 144type inference rule, 62, 144binding extension expression

annotated syntax, 42concrete syntax, 32, 150semantic relation, 75, 150type inference rule, 62, 150binding selection expressionannotated syntax, 42concrete syntax, 32, 143semantic transformation, 69, 143type inference rule, 62, 143BOXCHAR, 18BRACKET, 18capture, 2carrier , 57carrier set, 2Cartesian product expressionconcrete syntax, 32, 138syntactic transformation, 48, 138Cartesian product typeannotated syntax, 43semantic relation, 78charac , 39Characterisation rules, 38characteristic de�nite description expressioncharacterisation, 39, 151concrete syntax, 32, 151characteristic set comprehension expressioncharacterisation, 39, 149concrete syntax, 32, 149characteristic tuple, 38chartuple , 39Concrete syntax, 30conditional expressionconcrete syntax, 32, 134syntactic transformation, 48, 134Conformance, 14conjecture paragraphannotated syntax, 40concrete syntax, 31, 119semantic relation, 73, 120type inference rule, 59, 120conjunction predicateannotated syntax, 41concrete syntax, 31, 124semantic relation, 13, 74, 125type inference rule, 60, 125constraint, 2Conventions for state-based descriptions, 166decorin mathematical metalanguage, 7DECORWORD, 24de�nite description expressionc ISO/IEC 2000|All rights reserved 171

ISO/IEC 13568:2000(E) Indexannotated syntax, 42concrete syntax, 32, 131semantic relation, 76, 131type inference rule, 62, 131DIGIT, 18disjointin mathematical metalanguage, 9in mathematical toolkit, 98disjunction predicateconcrete syntax, 31, 124syntactic transformation, 46, 124div in mathematical toolkit, 101dom in mathematical metalanguage, 8in mathematical toolkit, 94EL, 29ELP, 29empty signatureannotated syntax, 43END, 25ENDCHAR, 21environment, 2equivalence predicateconcrete syntax, 31, 123syntactic transformation, 46, 124ER, 29ERE, 29EREP, 29ERP, 29ES, 29existential quanti�cation predicateconcrete syntax, 31, 122syntactic transformation, 46, 122Expressionannotated syntax, 42characterisation rules, 39concrete syntax, 32semantic relations, 74semantic transformation rules, 69syntactic transformation rules, 47type inference rules, 60expression listconcrete syntax, 35syntactic transformation, 54F (�nite subsets)in mathematical metalanguage, 7in mathematical toolkit, 93F1 (non-empty �nite subsets)in mathematical toolkit, 93falsity predicate

concrete syntax, 31, 128syntactic transformation, 47, 128�rst in mathematical metalanguage, 7in mathematical toolkit, 93Foreword, ivfree types paragraphannotated syntax, 40concrete syntax, 31, 116semantic transformation, 66, 117syntactic transformation, 45, 116type inference rule, 59, 117frontin mathematical toolkit, 105function and generic operator application expressionconcrete syntax, 32, 139syntactic transformation, 53, 140function construction expressioncharacterisation, 39, 131concrete syntax, 32, 130function toolkit , 96GENAX, 25GENCHAR, 21generic axiomatic description paragraphannotated syntax, 40concrete syntax, 31, 113semantic relation, 73, 113type inference rule, 58, 113generic conjecture paragraphannotated syntax, 40concrete syntax, 31, 120semantic relation, 74, 120type inference rule, 59, 120generic horizontal de�nition paragraphconcrete syntax, 31, 114syntactic transformation, 45, 114generic instantiation, 56generic instantiation expressionannotated syntax, 42concrete syntax, 32, 146semantic relation, 75, 146type inference rule, 61, 146generic nameconcrete syntax, 34, 115syntactic transformation, 51, 115generic operator de�nition paragraphconcrete syntax, 31, 115syntactic transformation, 51, 115generic parameter typeannotated syntax, 43semantic relation, 77generic schema de�nition paragraph172 c ISO/IEC 2000|All rights reserved

Index ISO/IEC 13568:2000(E)concrete syntax, 31, 113syntactic transformation, 45, 114generic typeannotated syntax, 43generic type instantiation, 57GENSCH, 25given typeannotated syntax, 43semantic relation, 77given types paragraphannotated syntax, 40concrete syntax, 31, 111semantic relation, 73, 111type inference rule, 58, 111GREEK, 18head in mathematical toolkit, 104horizontal de�nition paragraphconcrete syntax, 31, 114syntactic transformation, 45, 114I, 29id in mathematical metalanguage, 8in mathematical toolkit, 94if then else (conditional)in mathematical metalanguage, 5implication predicateconcrete syntax, 31, 124syntactic transformation, 46, 124in�xin mathematical toolkit, 106in�x function and generic operator applicationconcrete syntax, 35, 139syntactic transformation, 54, 140in�x generic nameconcrete syntax, 34, 115syntactic transformation, 51, 115in�x operator nameconcrete syntax, 34syntactic transformation, 50in�x relation operator applicationconcrete syntax, 34, 125syntactic transformation, 52, 126inheriting sectionannotated syntax, 40concrete syntax, 31, 109semantic relationnon-prelude, 72, 110prelude, 72, 110type inference rule, 56, 109interpretation, 2

Introduction, vIP, 29iseq (injective sequences)in mathematical toolkit, 103iter (iteration)in mathematical toolkit, 102L, 29lambda expression, see function construction expressionlast in mathematical toolkit, 104LATIN, 18let � (substitution)expression, see substitution expressionLETTER, 18Lexis, 24LP, 29Mark-ups, 79Mathematical toolkit, 90max in mathematical toolkit, 103membership predicateannotated syntax, 41semantic relation, 74, 127type inference rule, 59, 127metalanguage, 2metavariable, 2min in mathematical toolkit, 103mktuple , 39modin mathematical toolkit, 101Model , 13model, 2mu expression, see de�nite description expressionN1 (strictly positive naturals)in mathematical toolkit, 100N (naturals)in prelude, 43negation predicateannotated syntax, 41concrete syntax, 31, 125semantic relation, 74, 125type inference rule, 60, 125newline conjunction predicateconcrete syntax, 31, 123syntactic transformation, 46, 123NL, 25NLCHAR, 21no�x function and generic operator applicationconcrete syntax, 35, 139syntactic transformation, 54, 140c ISO/IEC 2000|All rights reserved 173

ISO/IEC 13568:2000(E) Indexno�x generic nameconcrete syntax, 34, 115syntactic transformation, 52, 116no�x operator nameconcrete syntax, 34syntactic transformation, 51no�x relation operator applicationconcrete syntax, 34, 125syntactic transformation, 53, 127Normative references, 1number literal expressionconcrete syntax, 32, 147syntactic transformation, 48, 147number toolkit , 98number literal 0in prelude, 43number literal 1in prelude, 43NUMERAL, 24operator associativity, 35operator nameconcrete syntax, 33syntactic transformation, 50operator precedence, 35operator template paragraphconcrete syntax, 31, 121Organisation by concrete syntax production, 107OTHERLETTER, 18P (powerset)in mathematical metalanguage, 7P1 (non-empty subsets)in mathematical toolkit, 92Paragraphannotated syntax, 40concrete syntax, 31semantic relations, 73semantic transformation rules, 66syntactic transformation rules, 45type inference rules, 58parenthesized expressionconcrete syntax, 32, 151syntactic transformation, 49, 151parenthesized predicateconcrete syntax, 31, 128syntactic transformation, 47, 128partitionin mathematical toolkit, 98POST, 29post�x function and generic operator applicationconcrete syntax, 35, 139syntactic transformation, 53, 140

post�x generic nameconcrete syntax, 34, 115syntactic transformation, 51, 115post�x operator nameconcrete syntax, 34syntactic transformation, 50post�x relation operator applicationconcrete syntax, 34, 125syntactic transformation, 52, 126POSTP, 29P (powerset)in prelude, 43powerset expressionannotated syntax, 42concrete syntax, 32, 138semantic relation, 75, 139, 141type inference rule, 61, 139, 141powerset typeannotated syntax, 43semantic relation, 77PRE, 29precedence of operators, 35Predicateannotated syntax, 41concrete syntax, 31semantic relations, 74semantic transformation rules, 68syntactic transformation rules, 46type inference rules, 59pre�xin mathematical toolkit, 105pre�x function and generic operator applicationconcrete syntax, 35, 139syntactic transformation, 53, 140pre�x generic nameconcrete syntax, 34, 115syntactic transformation, 51, 115pre�x operator nameconcrete syntax, 33syntactic transformation, 50pre�x relation operator applicationconcrete syntax, 34, 125syntactic transformation, 52, 126Prelude, 43PREP, 29ran in mathematical toolkit, 94reference expressionannotated syntax, 42concrete syntax, 32, 144semantic relation, 75, 146type inference rule, 61, 145174 c ISO/IEC 2000|All rights reserved

Index ISO/IEC 13568:2000(E)relation operator application predicateconcrete syntax, 31, 125syntactic transformation, 52, 126relation toolkit , 93rev (reverse)in mathematical toolkit, 104SCH, 25SCHCHAR, 21schema, 2schema composition expressionannotated syntax, 42concrete syntax, 32, 134semantic transformation, 70, 135type inference rule, 64, 135schema conjunction expressionannotated syntax, 42concrete syntax, 32, 133semantic relation, 76, 133type inference rule, 12, 63, 133schema construction expressionannotated syntax, 42concrete syntax, 32, 149semantic relation, 76, 150syntactic transformation, 49, 149type inference rule, 63, 149schema decoration expressionannotated syntax, 42concrete syntax, 32, 141semantic transformation, 71, 142type inference rule, 65, 142schema de�nition paragraphconcrete syntax, 31, 112syntactic transformation, 9, 45, 112schema disjunction expressionconcrete syntax, 32, 133syntactic transformation, 47, 133schema equivalence expressionconcrete syntax, 32, 132syntactic transformation, 47, 132schema existential quanti�cation expressionconcrete syntax, 32, 129syntactic transformation, 47, 130schema hiding expressionannotated syntax, 42concrete syntax, 32, 136semantic transformation, 70, 137type inference rule, 63, 137schema implication expressionconcrete syntax, 32, 132syntactic transformation, 47, 132schema negation expressionannotated syntax, 42

concrete syntax, 32, 133semantic relation, 76, 134type inference rule, 63, 134schema piping expressionannotated syntax, 42concrete syntax, 32, 135semantic transformation, 71, 136type inference rule, 65, 136schema precondition expressionannotated syntax, 42concrete syntax, 32, 137semantic transformation, 70, 138type inference rule, 64, 138schema predicateconcrete syntax, 31, 127syntactic transformation, 46, 127schema projection expressionconcrete syntax, 32, 137syntactic transformation, 48, 137schema renaming expressionannotated syntax, 42concrete syntax, 32, 142semantic relation, 77, 142type inference rule, 64, 142schema textconcrete syntax, 32, 152syntactic transformation, 49, 152schema typeannotated syntax, 43semantic relation, 78schema unique existential quanti�cation expressionannotated syntax, 42concrete syntax, 32, 130semantic transformation, 70, 130type inference rule, 64, 130schema universal quanti�cation expressionannotated syntax, 42concrete syntax, 32, 129semantic relation, 76, 129type inference rule, 63, 129Scope, 1scope of a declaration, 2scope rules, 2secondin mathematical metalanguage, 7in mathematical toolkit, 93Sectionannotated syntax, 40concrete syntax, 31semantic relations, 72syntactic transformation rules, 45type inference rules, 56section type environmentc ISO/IEC 2000|All rights reserved 175

ISO/IEC 13568:2000(E) Indexannotated syntax, 43sectioned speci�cationannotated syntax, 40concrete syntax, 31, 108semantic relation, 72, 108type inference rule, 55, 108SectionModels , 13Semantic relations, 71Semantic transformation rules, 66semantic universe, 2semicolon conjunction predicateconcrete syntax, 31, 123syntactic transformation, 46, 123seq (�nite sequences)in mathematical toolkit, 103seq1 (non-empty �nite sequences)in mathematical toolkit, 103sequence toolkit , 102set comprehension expressionannotated syntax, 42concrete syntax, 32, 148semantic relation, 75, 148type inference rule, 61, 148set extension expressionannotated syntax, 42concrete syntax, 32, 147semantic relation, 75, 148type inference rule, 61, 148set toolkit , 90signature, 2annotated syntax, 43signature variable, see variable signatureSPACE, 21SPECIAL, 18Speci�cationannotated syntax, 40concrete syntax, 31semantic relations, 72syntactic transformation rules, 44type inference rules, 55squashin mathematical toolkit, 105SR, 29SRE, 29SREP, 29SRP, 29SS, 29standard toolkit , 106STROKE, 24STROKECHAR, 18substitution expressionconcrete syntax, 32, 131syntactic transformation, 47, 132

succ in mathematical toolkit, 98su�xin mathematical toolkit, 106SYMBOL, 18Symbols and de�nitions, 3SYMBOLSTR, 24Syntactic transformation rules, 44tail in mathematical toolkit, 104Terms and de�nitions, 1TOKEN, 24TOKENSTREAM, 24toolkit, see mathematical toolkittruth predicateannotated syntax, 41concrete syntax, 31, 128semantic relation, 74, 128type inference rule, 60, 128tuple extension expressionannotated syntax, 42concrete syntax, 32, 150semantic relation, 75, 151type inference rule, 62, 150tuple selection expressionannotated syntax, 42concrete syntax, 32, 143semantic transformation, 69, 143type inference rule, 62, 143Tutorial, 153Type inference rules, 54type universe, 2type variable, see variable typeU (semantic universe), 13unique existential quanti�cation predicateannotated syntax, 41concrete syntax, 31, 122semantic transformation, 68, 122type inference rule, 60, 122universal quanti�cation predicateannotated syntax, 41concrete syntax, 31, 121semantic relation, 74, 122type inference rule, 60, 122variable construction expressionannotated syntax, 42semantic relation, 76, 149type inference rule, 63, 149variable signatureannotated syntax, 43variable type176 c ISO/IEC 2000|All rights reserved

Index ISO/IEC 13568:2000(E)annotated syntax, 43WORD, 24WORDGLUE, 18WORDPART, 24Z (integers)in mathematical toolkit, 99Z characters, 18Z1 (non-zero integers)in mathematical toolkit, 101ZCHAR, 18ZF set theory, 2

c ISO/IEC 2000|All rights reserved 177