A Set-Based Calculus and its Implementation
vorgelegt von Diplom-Informatiker
Wolfgang Grieskamp
aus Essen
Am Fachbereich 13, Informatik,
der Technischen Universit¨
at Berlin
zur Erlangung des akademischen Grades
Doktor der Ingenieurwissenschaften
– Dr.-Ing. –
genehmigte Dissertation
Promotionsausschuß:
Vorsitzender : Prof. Dr. G¨
unter Hommel
Berichter : Prof. Dr. Peter Pepper
Berichter : Prof. Dr. Stefan J¨
ahnichen
Tag der wissenschaftlichen Aussprache: 26.11.1999
Berlin 1999
D 83
Meinen Eltern
Zusammenfassung
Diese Arbeit untersucht die Fundierung und Implementierung eines Berechnungsmodells
f¨ur mengenbasierte Computersprachen. Es wird das
Z-Kalk¨ul eingef¨uhrt, eine mini-
male mengenbasierte Ausdruckssprache, verwandt mit dem
-Kalk¨ul, das Anwendungs-
sprachen wie die Spezifikationssprache Z oder funktional-logische Programmiersprachen
komplett und nat¨urlich einbetten kann. Syntax,Semantik und Gleichungstheorie von
Z
werden definiert. Mehrere Berechnungsmodelle werden entwickelt. Durch gezielte An-
wendung der Gleichungstheorie ergibt sich eine Narrowingsemantik, die durch lokale
Modifikation der Redexauswahl nicht-strikt oder strikt ausf¨allt, und insbesondere interes-
sant f¨ur interpretative “on-line” Auswertung ist, da sie auf symbolischer Termersetzung
basiert. Das zentrale Berechnungsmodell aber basiert auf einer nat¨
urlichen Semantik, die
durch ihren operationalen Charakter das Design kompilierter “off-line” Auswertung vor-
bereitet, und das Berechnungsreferenzmodell von
Zfestlegt. Dieses Modell kombiniert
funktionale Reduktion und nebenl¨aufige Resolution, und definiert eine klare Trennung
zwischen der (deterministischen, funktionalen) Konstruktion von Mengen und der (nicht-
deterministischem, logischen) Dekonstruktion. Da Mengen sowohl extensional als auch
intensional dargestellt werden k¨onnen, ist das Modell von h¨oherer Ordnung.
Die Implementierung erfolgt in Form einer abstrakten Maschine, der ZAM, welche
auf der Technik nebenl¨aufiger Resolutionsagenten basiert. Die Maschine realisiert eine
effiziente Tiefensuche ¨uber die Verwaltung von Auswahlpunkten und Modifikationspro-
tokollen. Durch ein Priorit¨atenmodell in der nebenl¨aufigen Ausf¨uhrung werden nichtde-
terministische Berechnungen dynamisch verz¨ogert und deterministische propagiert. Die
ZAM ist als Stackmaschine vollst¨andig in Z spezifiert, und wird in der Implementierung
in C++ zu einer Registermaschine verfeinert, welche persistente Register verwendet, um
den Aufwand der Protokollierung von Modifikation zu minimieren.
Die Anwendung der vorgestellten Konzepte erfolgt im Rahmen des ZeTa Systems,
im BMBF Projekt ESPRESS entwickelt, das verschiedenartige Notationen und Werkzeuge
auf der semantischen Grundlage von Z integriert. Der ZaP ¨
Ubersetzer, Bestandteil des
ZeTa Systems, realisiert mit Hilfe des
Z-Kalk¨uls die Ausf¨uhrung von Z Modellen, und
wurde beispielsweise in ESPRESS f¨ur die Automatisierung von Softwaretests eingesetzt.
Die Definition von
Z, der Berechnungsmodelle, der abstrakten Maschine und der
¨
Ubersetzung von
Zin Maschinencode ist vollst¨andig in der Spezifikationssprache Z ge-
geben (mit kleineren syntaktischen Erweiterungen), und daher syntax- und typgepr¨uft.
Insofern ist diese Arbeit auch eine Fallstudie der Anwendbarkeit von Z f¨ur anspruchsvol-
le Probleme der Metamodellierung.
Preface
In response to those who thought that Cantor’s theory of sets might be destroyed by the
well-known paradoxes discovered at the beginning of this century, Hilbert once spoke
about the “paradise created by Cantor from which nobody shall ever expel us” (quoted
in Vaught [1995]). On the level of non-constructive calculi, the beauty of the set-based
approach has been recognized in computer science in the formal notation Z [Spivey, 1992;
Toyn, 1998], developed in the eighties and semantically based on Zermelo-Fraenkli set
theory, which solves the paradoxes of classical set theory. In recent years, a growing
number of authors haveadvocated the useof sets in declarativeprogramming and program
analysis.
In this thesis, I use the set-based approach as the basis for a novel, small intermediate
calculus, which allows to naturally embed concepts from higher-order functional, logic
and concurrent constraint programming, as well as set-based specification languages such
as Z. I define the syntax and semanticsof the calculus, analyze its equational theory, inves-
tigate several computation models, provide an abstract machine that implements a model,
and define a compilation from the calculus to the machine. The power of the calculus
and its implementation allows an unorthodox approach to the integration of higher-order
functional and constraint logic programming.
The present thesis, written between January and September 1999, grew out of my ac-
tivities in the application oriented research project ESPRESS (1995-1998), which was con-
cerned with methods and tools for the specification of safety-critical embedded systems
[B¨ussow et al., 1996; B¨ussow and Grieskamp, 1997; B¨ussow et al., 1997a; Grieskamp
et al., 1998; B¨ussow et al., 1998; B¨ussowand Grieskamp, 1999]. One goal in the ESPRESS
context was to provide a tool to execute Z specifications, for the purpose of evaluating
test data and animating requirements specification of embedded systems based on Z. The
development of a compiler for Z was influenced by my earlier experiences with the im-
plementation of the algebraic-functional language Opal [Schulte and Grieskamp, 1992;
Hartel et al., 1996; Didrich et al., 1994; Frauenstein et al., 1996a,b; Didrich et al., 1998],
which strongly suggested basing such a compiler on a small intermediate language in
the style of the
-calculus. This led to a first design of the calculus presented in this
thesis, called
Zbecause of its original purpose for abstracting from the diversity of the
Z notation. This first version was used as an intermediate language in the experimental
compiler ZaP, which is part of the Z-based tool-integration environment ZeTa [B¨ussow
and Grieskamp, 1999], developed under the supervision of the author in ESPRESS.ZaP
has proved to be a feasible tool, in particular for the evaluation of test data, and it is being
used for this purpose in several projects conducted in cooperation with Daimler-Chrysler,
FT3/SM, Berlin. The work presented here consolidates and refines the technology of ZaP
on the basis of these experiences. On the one hand, it closes the gap between the exper-
imental prototype ZaP and its theoretical foundation, and on the other it extends ZaP’s
model by indeterministic computation, which proved to be desirable in the course of the
case studies.
Acknowledgments
I would like to thank Prof. Dr. Peter Pepper for his continuous support on both a personal
and professional level over the past years. Peter’s tolerance combined with brilliance has
been a major yardstick for me. I would also like to thank Prof. Dr. Stefan J¨ahnichen and
Prof. Dr. Hartmut Ehrig for their encouragement and confidence in my ESPRESS work.
Numerous colleagues at Peters group, ¨
UBB, have indirectly contributed to this thesis,
among them Klaus Didrich, Michael Cebulla and Christian Maeder, not at least by taking
over some of my daily obligations during the time of the writing. In ESPRESS, the col-
laboration with Robert B¨ussow on the ZeTa system and other topics was very fruitful and
pleasuring. The exchange of ideas on Z, among other things, with Andreas Fett, Thomas
Santen and other colleagues of the ESPRESS context helped me to gain insights to aspects
of this work. The discussions I had from time to time with Markus Lepper were highly
stimulating. My special thanks go to Erich Mikk for his invaluable feedback on early
prototypes of the ZaP compiler and to Jacob Wieland for the fruitful discussion of the
Z
calculus and its use for program analysis in his diploma thesis [Wieland, 1999].
Contents
1 Introduction 17
2 Meta Notation 23
2.1 A Sketch of Z . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.1 Types and Sematic Universe . . . . . . . . . . . . . . . . . . . . 25
2.1.2 Schema Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.3 Genericity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.4 Undefinedness . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2 Notational Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.1 Where Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.2 If-Exists Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.3 Inference Rule Systems . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.4 Recursive Partial Functions . . . . . . . . . . . . . . . . . . . . 29
2.2.5 Local Variables in Schema Boxes . . . . . . . . . . . . . . . . . 29
2.2.6 Case Distinction in Predicates . . . . . . . . . . . . . . . . . . . 30
2.2.7 Selective
............................. 30
2.2.8 Overloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.9 Further Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3 Mathematical Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.1 Sets and Relations . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.2 Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.3 Booleans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.4 Order and Lattices . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 The
ZCalculus 37
3.1 Introduction to
Z.............................. 38
3.1.1 Syntax and Informal Meaning . . . . . . . . . . . . . . . . . . . 38
3.1.2 Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 Semantic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.1 Set Representation . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.2 Types................................ 44
3.2.3 Universe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.4 Free Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.5 Standard Types and Constructors . . . . . . . . . . . . . . . . . . 47
3.2.6 Order and Fixed-Points . . . . . . . . . . . . . . . . . . . . . . . 48
3.3 Expression Syntax and Meaning . . . . . . . . . . . . . . . . . . . . . . 50
3.3.1 Variable, Expression and Pattern Type . . . . . . . . . . . . . . . 50
3.3.2 Typing Relation . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.3 Meaning Function . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.4 Basic Forms: Typing and Meaning . . . . . . . . . . . . . . . . . 52
3.3.5 Expression Abbreviation Forms . . . . . . . . . . . . . . . . . . 56
3.4 Equational Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4.1 Syntactic Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4.2 Equivalence Relation . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4.3 Boolean Laws . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.4.4 Singleton Set Laws . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.4.5 Translation Laws . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.4.6 Schema Laws . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4.7 Fixed-Point Unrolling Law . . . . . . . . . . . . . . . . . . . . . 66
3.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4 Computation in
Z71
4.1 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.2 Normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.2.1 Property Normalization . . . . . . . . . . . . . . . . . . . . . . . 75
4.2.2 Normalization Rules . . . . . . . . . . . . . . . . . . . . . . . . 76
4.2.3 Properties of Normalization . . . . . . . . . . . . . . . . . . . . 79
4.3 Narrowing Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.3.1 General Narrowing . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.3.2 Outermost-in Narrowing . . . . . . . . . . . . . . . . . . . . . . 84
4.3.3 Strict Narrowing . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.4 The Reference Computation Model . . . . . . . . . . . . . . . . . . . . . 86
4.4.1 Values and Constraints . . . . . . . . . . . . . . . . . . . . . . . 87
4.4.2 Computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5 Abstract Machine 97
5.1 Basic Model of the ZAM .......................... 98
5.1.1 Values................................ 98
5.1.2 Intensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.1.3 Threads and Goals . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.1.4 Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.1.5 Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.2 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.2.1 Axiomatic Definitions . . . . . . . . . . . . . . . . . . . . . . . 105
5.2.2 Auxiliary Instructions . . . . . . . . . . . . . . . . . . . . . . . 107
5.2.3 Execution Step and Selection . . . . . . . . . . . . . . . . . . . . 109
5.2.4 Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.3 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.3.1 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.3.2 Compilation Functions . . . . . . . . . . . . . . . . . . . . . . . 125
5.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
5.4.1 Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
5.4.2 Instruction Set . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.4.3 Memory Management . . . . . . . . . . . . . . . . . . . . . . . 133
5.4.4 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
5.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
6 The ZeTa System 139
6.1 Three Dimensions of Integration . . . . . . . . . . . . . . . . . . . . . . 139
6.1.1 Semantic Integration . . . . . . . . . . . . . . . . . . . . . . . . 140
6.1.2 Document Integration . . . . . . . . . . . . . . . . . . . . . . . 141
6.1.3 Tool Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.1.4 Graphical User Interfaces . . . . . . . . . . . . . . . . . . . . . 143
6.2 The ZaP Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.2.1 The Basic Specification of the Birthday Book . . . . . . . . . . . 146
6.2.2 Refining the Birthday Book for Execution . . . . . . . . . . . . . 147
6.2.3 Refining the Birthday Book for Testing . . . . . . . . . . . . . . 150
6.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
7 Conclusion 157
7.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
List of Figures
3.1 Type Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2 Type Language: Syntactic Tools . . . . . . . . . . . . . . . . . . . . . . 45
3.3 Semantic Universe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4 Free Types: Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5 Free Types: Meaning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.6 Free Type of Booleans . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.7 Free Type of Natural Numbers . . . . . . . . . . . . . . . . . . . . . . . 47
3.8 The Order on Partial Sets . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.9 Expressions and Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.10 Typing Relation: Declarations . . . . . . . . . . . . . . . . . . . . . . . 51
3.11 Meaning Function: Declarations . . . . . . . . . . . . . . . . . . . . . . 51
3.12 Value Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.13 Syntax and Meaning: Constructor Application . . . . . . . . . . . . . . . 52
3.14 Syntax and Meaning: Singleton Set Display and Selection . . . . . . . . 52
3.15 Syntax and Meaning: Set Algebra . . . . . . . . . . . . . . . . . . . . . 53
3.16 Syntax and Meaning: Set Translation . . . . . . . . . . . . . . . . . . . . 54
3.17 Syntax and Meaning: Schema, Fixed-Point, and Variable . . . . . . . . . 55
3.18 Expression Abbreviation Forms . . . . . . . . . . . . . . . . . . . . . . 56
3.19 Syntactic Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.20 Equivalence Relation: Declaration . . . . . . . . . . . . . . . . . . . . . 58
3.21 Boolean Laws . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.22 Excluded Middle Laws . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.23 Selection Elimination Law . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.24 Constructor Decomposition Laws . . . . . . . . . . . . . . . . . . . . . 60
3.25 Translation Composition and Identity Laws . . . . . . . . . . . . . . . . 60
3.26 Translation Distributivity Laws . . . . . . . . . . . . . . . . . . . . . . . 61
3.27 Translation Product Law . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.28 Translation Lifting Law . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.29 Translation Splitting Law . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.30 Translation Intersection Elimination Law . . . . . . . . . . . . . . . . . 63
3.31 Schema Elimination and Distributivity Laws . . . . . . . . . . . . . . . . 64
3.32 Schema Complement Lifting Law . . . . . . . . . . . . . . . . . . . . . 65
3.33 Schema Translation Elimination Laws . . . . . . . . . . . . . . . . . . . 65
3.34 Schema Membership Lifting Law . . . . . . . . . . . . . . . . . . . . . 65
3.35 Schema Property Substitution Law . . . . . . . . . . . . . . . . . . . . . 66
3.36 Fixed-Point Unrolling Law . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.1 Extensional Equality and Unequality . . . . . . . . . . . . . . . . . . . . 72
4.2 Matching Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.3 Normalized Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.4 Singleton Set Normalization . . . . . . . . . . . . . . . . . . . . . . . . 76
4.5 Constructor Normalization . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.6 Union Normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.7 Intersection Normalization . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.8 Complement Normalization . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.9 Translation Normalization . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.10 Schema Normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.11 Narrowing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.12 Values and Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.13 Strict Context Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.14 Variable, Schema, and Fixed-Point Reduction . . . . . . . . . . . . . . . 89
4.15 Translation and Complement Reduction . . . . . . . . . . . . . . . . . . 89
4.16 Set Value Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.17 Mu-Value Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.18 Compound Constraint Resolution . . . . . . . . . . . . . . . . . . . . . . 91
4.19 Expression Reduction in Constraints . . . . . . . . . . . . . . . . . . . . 91
4.20 Membership and Equality Resolution . . . . . . . . . . . . . . . . . . . 92
4.21 Test-Emptiness Resolution . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.1 ZAM Values................................. 98
5.2 ZAM Intensions............................... 99
5.3 ZAM Threads and Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.4 ZAM Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.5 ZAM Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.6 Shifting Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.7 Freezing Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.8 Getting the Variables of a Value . . . . . . . . . . . . . . . . . . . . . . 106
5.9 Equality...................................107
5.10 Unification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.11 Merging and Joining Value Sequences . . . . . . . . . . . . . . . . . . . 108
5.12 Adding Information to Choices . . . . . . . . . . . . . . . . . . . . . . . 109
5.13 Ordering Index Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.14 ZAM Auxiliary Instructions . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.15 ZAM Execution Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.16 ZAM Dispatching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.17 The LOAD Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.18 The WAIT Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.19 The LOADENV Instruction . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.20 The UNIFY Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.21 The STORE Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.22 The MEMBER Instruction . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.23 The TRYNEXT Auxiliary Instruction: The Empty Case . . . . . . . . . . 114
5.24 The TRYNEXT Auxiliary Instruction: The Extensional Case . . . . . . . 115
5.25 The TRYNEXT Auxiliary Instruction: The Intensional Case . . . . . . . . 115
5.26 The MKEMPTY and MKSINGLE Instructions . . . . . . . . . . . . . . . 116
5.27 The MKTERM Instruction . . . . . . . . . . . . . . . . . . . . . . . . . 116
5.28 The MKINTEN Instruction . . . . . . . . . . . . . . . . . . . . . . . . . 116
5.29 The UNION Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.30 The ISECT Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.31 The SUCCESS Instruction . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.32 The MU Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.33 The TEST and TESTNATIVE Instructions . . . . . . . . . . . . . . . . . 119
5.34 The SEARCH Auxiliary Instruction: Dispatching . . . . . . . . . . . . . 120
5.35 The SEARCH Auxiliary Instruction: Select, More Intensions . . . . . . . 120
5.36 The SEARCH Auxiliary Instruction: Select: No More Intensions . . . . . 121
5.37 The SEARCH Auxiliary Instruction: Resume: Subgoal Success . . . . . . 122
5.38 The SEARCH Auxiliary Instruction: Resume: Subgoal Failure . . . . . . 123
5.39 The SEARCH Auxiliary Instruction: Backtracking . . . . . . . . . . . . . 123
5.40 Compilation Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.41 Declaration of Compilation Functions . . . . . . . . . . . . . . . . . . . 125
5.42 Compiling General Expressions . . . . . . . . . . . . . . . . . . . . . . 125
5.43 Compiling Disjunctions and Conjunctions . . . . . . . . . . . . . . . . . 126
5.44 Compiling Literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.45 Compiling Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.46 Value Types of the ZAM in C++ ......................130
5.47 Control Types of the ZAM in C++ .....................130
5.48 Register Transfer Instruction Set of the ZAM ................131
6.1 Semantic Integration in ZeTa ........................140
6.2 Document Integration in ZeTa .......................141
6.3 Chains of Content Queries . . . . . . . . . . . . . . . . . . . . . . . . . 143
6.4 The XEmacs GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.5 The Swing GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Chapter 1
Introduction
Ich ging im Walde
So f¨
ur mich hin,
Und nichts zu suchen,
Das war mein Sinn.
(Goethe)
1
The automatic evaluation of test data for safety-critical embedded systems is an interest-
ing application that can help to put declarative language implementation techniques into
industrial practice. Some studies report that more than 50% of development costs in this
application area go into testing. A setting for test-case evaluation that can improve this
situation is as follows: given a requirements specification by an executable prototype,
some input data describing a test case, and the output data from a run of the system’s
implementation on the given input, we check by executing the specification whether the
implementation meets its requirements. At the first sight, this goal would seem to be
simple, since input and output data are fixed. However, a real-world specification of a
complex system may contain a lot of “hidden” data, which is used to describe the observ-
able behavior. Thus, the problem scales up to finding the solution(s) to (a sequence of)
partial data bindings.
In the application-oriented research project ESPRESS2, which is concerned with meth-
ods and tools for the development of embedded systems, the set-based specification lan-
guage Z [Spivey, 1992] is used for requirements specification in combination with other
notations such as Statecharts which are incorporated by a shallow encoding in Z [B¨ussow
and Grieskamp, 1999]. Performing test-case evaluation in this setting requires a compu-
tation model for Z.
In this thesis, the underlying theory and implementation of a computation model for
Z are investigated. In fact, the work is not restricted to Z, since it is based on a small
intermediate calculus, called
Z, that can embed Z as well as other declarative notations.
The major contributions are the introduction of the novel calculus
Z, the definition of
the calculus’ computation model (operational semantics) and the definition of an abstract
machine for implementing the calculus. In this initiatory Chapter, an outline of these
topics is given.
1Im Goethejahr 1999 haben wir uns vorgenommen, (fast) alle Kapitelwahlspr¨uche beim großen deut-
schen Dichter auszuleihen.
2ESPRESS is a joint project involving industrial partners (Daimler-Benz AG and Robert Bosch AG) and
academic research institutes (GMD-First, FhG-ISST, and TU-Berlin), funded by the German “Bundesmin-
isterium f¨ur Bildung, Wissenschaft, Forschung und Technologie”.
18 Introduction
The
ZCalculus
The
Zcalculus is a pure expression language in the spirit of the
-calculus. Since it can
embed the full Z language – the simple-typed
-calculus, set calculus, predicate calculus,
and schema calculus – computation in
Zcan not be complete. However, a computa-
tion model and implementation by an abstract machine can be provided that is compa-
rable with that of higher-order functional logic paradigms [Smolka, 1998; Hanus, 1999;
Chakravarty et al., 1997].
The
Zcalculus is based upon a small number of constructs, which are tentatively
summarized below (e
EXP being expressions and p
PAT patterns):
e
EXP
x
e
e
e
e
e
e
e
e
e
p
p
"!#$
p
e
%'&)(
p
*
e
p
PAT
+
EXP
The calculus employs constructor terms,
e
, and the basic operations of set algebra, set
union, intersection and complement. Patterns, p
PAT, are the subset of expressions
built from constructor terms and variables. In addition, the following expression forms
are provided:
,
The form
eselects the element of a singleton set e.
,
The form e
p
-
p
"!
describes the translation of the set e. The result consists of all
elements that match p
, such that there exists an element in ethat matches the pat-
ternp
under the same substitution. For example,
./103254678/1032:9;7<=>
x
2
y
-
x
!)?@A0B
(where numbers are special
C
-ary constructor symbols).
,
The form
p
e
describes a schema (set comprehension). The property eis a set
expression of Boolean type – truth being the set containing a dedicated singleton
element and falsity the empty set.
,
The form
&)(
p
*
edescribes a fixed-point of a set (or tuple of sets) e.
The calculus is able to represent all concepts of Z in a remarkably consistent way. For
example, a Cartesian product e
ED
e
is expressed as e
F
x
x
2 G!6
e
H
y
2
y
G!I2
with
2
, the constructor symbol for pairs, used in mixfix notation, and a pattern “joker”
(or anonymous variable). Relational application, Re, is encoded as
R
8
e
J5 KA!I2
where
K
is the
C
-ary constructor for the unit in Boolean sets. Function application, e
e
,
is given as
"
e
L8
e
7
x
x
2 G!M=N 2
y
E
y
!MPO
As these examples indicate, the heart
of the
Zcalculus is its novel construct for set translation, which provides a means for
the constructive description of morphisms in the category of
Zsets.
In Chapter 3, we develop the exact syntax and semantics of the calculus and provide
an equational theory for it. The semantic model of
Zis based on a hierarchical typed
universe, where sets are represented as partial characteristic (Boolean) functions in a set-
theoretical sense, which can be founded by Zitself or by ZF set theory. This representation
of sets is a generalization of partial three-valued logics [Owe, 1997] to the case of set
algebra. The equational theory of
Zis powerful enough to induce a narrowing semantics
by a pure expression transformation, as will be shown in Chapter 4.
Introduction 19
Computation in
Z
Several notions of computation are investigated in Chapter 4. We start with a normaliza-
tion of expressions to a disjunctive normal form, which, combined with simplification, is
a prerequisite for all further investigations (including compilation). From the normaliza-
tion, we can easily deduce a general narrowing semantics which is suited for symbolic
“on-line” computation. By restricting the redex selection order of narrowing, several sub-
models are derived.
The reference computation model of
Z, however, is given in the style of natural se-
mantics, constituting a trade-off between computation power and efficient implementabil-
ity, preparing a straight transition to the abstract machine given in Chapter 5 for “off-line”
computation. This model draws a clear borderline between the functional (deterministic)
construction of sets and the logic (indeterministic) deconstruction. For example, in an
expression such as
x
Q
x
e
=-8
x
R
x
S
e
7
(where
is syntactic sugar), the
expressions e
and e
are concurrently reduced in a deterministic functional style. Once
an expression eihas reached a value form, a resolution step is performed, thereby binding
the variable xi.
The reference computation model of
Zis comparable with that of higher-order func-
tional logic languages with concurrent constraint resolution, though it goes beyond this,
supporting disjunction and negation. It supports the free combination of sets (relations
and functions) by set union, intersection and complement, thereby abstracting from in-
tensional and extensional representations. The widely used set-based Z specification style
can thus be fully supported. We give some examples in Z. Given the function f, the execu-
tion of its domain restriction,
e
=2TOTOTOU2
en
WV
f, causes no problems. We can also execute
the properties x
YX6ZJ[
for x
]\_^6`
f. We may execute f
a
, which might become a rela-
tion, if fis not injective. If gis a further function, then f
gand f
gare executable.
Similar possibilities carry over to the schema calculus, which can be fully executed as
well.
The limitations of the computation model are found in the executability of universal
quantification and of complement. The universal quantification,
b
x
,
e, is encoded in
Zas
c.
x
d
e
L
x
KA!M
. The problem of executing this construct is conspicuously
apparent in the equational theory of
Z: set complement cannot be distributed over hiding
translation. Thus, we cannot expect complements to be pushed down completely to the
expression leafs during the construction of the disjunctive normal form. We deal with this
problem by computing independent “subgoals” for expressions nested inside of comple-
ments. These computations do not contribute to resolution in their enclosing context, and
are bound to the context by residuation. For the universal quantifier, this entails that it can
be computed provided the quantified range is finitely enumeratable.
The Abstract Machine ZAM
An abstract machine – called ZAM – which implements the reference computation model
of
Zis developed in Chapter 5. In the ZAM, concurrent threads collaboratively work on
a resolution task. The threads synchronize via variables: accessing an unbound variable
suspends a thread and binding a variable resumes threads waiting for it (residuation). The
machine maintains a stack of choice points which is shared by the threads jointly acting
on a resolution. When a thread executes a property such as x
e
e
e
, it continues
20 Introduction
with x
e
and creates a choice point for x
e
. A simple but powerful optimization
is achieved by an instance of the “Andorra Principle” [Warren, 1990], dynamically low-
ering the priority of threads that try to create choice points, thereby giving deterministic
computation preference.
The compilation of
Zto ZAM instructions is based on the disjunctive normal form
defined in Chapter 4. The instruction set of the ZAM is at a higher level than, for ex-
ample, of the Warren Abstract Machine [Warren, 1983], making compilation easy and
retraceable.
In Chapter 5, we give a comprehensive specification of the ZAM in Z’s sequential
specification style. This specification is intended to be executable using the concepts
presented in this thesis. A prototype of the ZAM has been implemented in C++, and will
be also outlined.
The ZeTa System and Conclusion
In Chapter 6, we give a short overview of the design of the ZeTa system [B¨ussow et al.,
1998; B¨ussow and Grieskamp, 1999], and the role of the ZAP compiler as integrated into
ZeTa. The goal of the ZeTa system is to offer an open environment for editing, browsing
and analyzing integrated specifications assembled from heterogeneous formalisms – such
as Statecharts, Z, temporal logic, message sequence charts, and other. The formalisms are
semantically integrated by a shallow encoding in Z, using the
df<g
conventions [B¨ussow
et al., 1997a]. The ZeTa system is designed to systematically support such encodings
by three dimensions of integration: semantic integration, document integration and tool
integration. The ZAP compiler, part of the ZeTa system, can thus be used not only to
execute Z specifications, but also other formalisms that are mapped to Z and thereby to
Z.Chapter 7 concludes with a summary of the contributions of this work and of future
lines of research. A discussion of related work can be found at the end of each of the
relevant chapters.
Reading Advices
Since this thesis aims at a comprehensive formalization of the concepts it introduces, it
contains a lot of detailed formal material, most of which as been put into figures that are
interleaved with the text. For layout technical reasons, figures occasionally occur before
their contents is explained. It is recommended to read (at least) until the first reference to
a figure in the text until its content is read.
Not all parts of this thesis need to be thoroughly read to get an idea of the main con-
cepts. Chapter 2 may be skipped by readers which are firm to Z and which do not want
to know how we explain certain Z extensions that have common roots in well-known no-
tational concepts (such as inference rules). In Chapter 3, it might be sufficient to read
the introduction to the
Zcalculus, Section 3.1 (on page 38), then the equational theory,
Section 3.4 (on page 57), skipping the proofs in there, and finally the discussion. In Chap-
ter 4, the definition of the distributive normal form in the introduction of Section 4.2 (on
page 74) and the entire Section 4.4 (on page 86) is essential, and, of course, the discus-
sion. In Chapter 5, the reader might find it sufficient to read Section 5.1 (on page 98),
Introduction 21
Section 5.4 (on page 129) and the discussion. Chapter 6 may be skipped by readers not
interested in the application.
Chapter 2
Meta Notation
Seh’ ich die Werke der Meister an,
So seh’ ich das, was sie getan.
(Goethe)
The meta notation used throughout this work is strictly based on the Z language [Spivey,
1992]. A brief introduction to Z is given in Section 2.1 (on page 25). In general, the
reader is expected to be familiar with Z.
One obvious advantage of using Z is that it is standardized1. Since Z is also a formal
language, another important advantage is that it is amenable to machine support. Thus,
most of the mathematical material in this thesis is verified by a parser and type-checker2.
Exceptions to the use of type-checked Z may appear in mathematical phrases inlined in
text and where template notations such as f
x
=2TOTOTOh2
xn
provide a better way of arguing
than conventional Z. This is seldom the case, and is only applied when properties of
objects are described, not for their declaration.
Using a formal notation such as Z does not necessarily imply using a formal method
in the sense of formal reasoning and proof with machine support. The degree of detail of
description required to this end would be enormous. A significant amount of description
is therefore kept loose – informal assertions are made that are clear to a human reader but
unamenable to a machine. An important example of such usage is when we informally
select the “smallest” solution to some axioms. Though Z is powerful enough to express
such constraints, it would be cumbersome to write them down, and would thereby distract
from the real concern.
The Z language, though a general specification notation, is tailored to the description
of stated-based sequential systems. A typical instance of this usage is the specification of
the abstract machine, ZAM, developed in Chapter 5. However, in other parts of this the-
sis, description techniques such as inference rules and recursive partial functions over free
term algebras (abstract syntax) are required, which are not directly supported by Z’s syn-
tax. Some extensions are therefore made to the language (Section 2.2 (on page 28)), which
are explained as syntactic sugar, which is implemented using the macro-preprocessor of
the E
f<g
type checker. The printed output of the extensions looks natural, and all are
actually type-checked and have a well-defined meaning in Z.
1An ISO standardization of Z is currently in progress. We follow the the draft proposals for the Z
standard, [Z-ISO]. A good text book on Z is written by Spivey [1992]; the innovations in the forthcoming
standard relative to this source are described by Toyn [1998].
2The E
i7j
type-checker (written by the author), which is part of the ZeTa system, is used. See also
Chapter 6.
24 Meta Notation
Z provides a powerful mathematical toolkit for defining basic notions such as num-
bers, relations, and functions. It is assumed that the reader is familiar with Z’s toolkit,
which is a fairly standard account of basic set theory (see Spivey [1992] for a specifi-
cation). Some extensions to the toolkit are nevertheless required: they are defined in
Section 2.3 (on page 32).
2.1 A Sketch of Z 25
2.1 A Sketch of Z
The basic model of Z is reviewed below, without the intention of providing a complete
picture. For a comprehensive description of Z, see [Spivey, 1992; Toyn, 1998].
2.1.1 Types and Sematic Universe
The model of Z is based on typed set theory. Given a collection of so-called given types,
Z types are freely constructed by power set construction,
k
A,cartesian product,A
D
O7OTOD
An, and binding set construction,
x
l
A
nmOTOTOUm
xn
An
!
. Binding sets denote
products with named components. A semantic universe for Z is large enough to contain
meanings for these types, where given types may have assigned arbitrary (not necessarily
countable) domains. Because of the type hierarchy, Z avoids Russel’s Antinomy: sets are
well-founded, and no set contains itself.
A distinguishing feature of Z is that types are “first-order citizens” of the language. A
type is represented by an expression which denotes a set. As a set, it just has the property
of being the largest set containing elements of the same type.
Z has a static typing discipline which forbids terms which are not well-typed. A
declaration such as x
Ehas two effects in Z: the variable xranges over the set denoted
by the expression E(x
E), and x is declared to be of some type, which is the largest
superset of E. For example, the constant
o
represents the given type of integer numbers,
and the constant
plqro
a subset of it. Then, declaring x
;p
lets xrange over
p
and assigns
the type
o
to it for type checking.
2.1.2 Schema Text
A central notion of Z is that of schema text, which denotes a set of bindings (tuples with
named components). A schema text, D
P, is built from a set of declarations Dand a set
of properties P. The declarations spawn a binding set, which is constrained by P. The
property is built of first-order predicative formulas over variables representing the binding
components.
For instance, the expression
x
2
y
Aps
x
t
y
!
represents the set of bindings where both
components xand yare constrained to be natural numbers by the declaration, and where
xis constrained to be less than or equal to yby the property.
In Z, it is always possible to shift constraints induced by declarations to the property
part. For example, the above schema can be transformed into
x
2
y
Jou
x
lpwv
y
lpwv
x
t
y
!
.
Schema text is used in manifold ways in Z:
,
Schema text is used to directly denote sets of bindings in expressions, as in
x
2
y
ps
x
t
y
!
, which denotes the set of bindings where component xis less or equal to
component y. (We already used this notation above).
,
Schema text is used in quantifiers. For example, the universal quantifier is written
as
b
D
P
,
Q, where D
Pspawns the range of quantified values. This notation
is equivalent to
b
D
,
P
x
Q. Similarly,
y
D
P
,
Q, which is equivalent to
y
D
,
P
v
Q.
26 Meta Notation
,
Schema text is used in function abstractions,
D
P
,
E, where D
Pdenotes the
domain of the function. The binding set D
Pis converted into a set of tuples by
removing the names of the components. For instance, the domain of the abstraction
x
)pzm
y
)p{
y
|}C
,
x
~
yis the set of pairs (xrepresenting the first and ythe
second component) with the specified property (y
|{C
). The graph of the function
described is a subset of
k"GpDwp'Dp'
.
,
Schema text is used in set comprehension,
D
P
, where the tuples of D
P
are the elements of the comprehended set. A further variant of comprehension,
D
P
,
E
, allows us to explicitly construct the result tuples, as e.g. in
x
hp
x
[WZ<X4SC
,
x
2
x
c0H:
, which describes the set of pairs where an even number
is related with its direct successor.
,
Schema text is also used for introducing global constants. Using the notation
D
P
the components of the bindings of D
Pare introduced as global constants. If
D
Pcontains more then one binding, the constants are loosely specified. If D
P
is empty, the specification is inconsistent.
2.1.3 Genericity
Z supports genericity. Global constants of a specification may be generic over a list of
“formal” types. The meaning of a generic constant is a total function from an instantiation
of the formals into a value. The instantiations are not just type “terms” but arbitrary set
values. This distinguishes Z’s polymorphism from the Hindley-Milner polymorphism
found in functional programming languages and specification formalisms [Damas and
Milner, 1982]. For example, if
o
is the given type of integer numbers, then a generic
constant such as
"ne
may be instantiated as
"7eo
,
17
x
<o
x
C<
,
"nLA0B254;
, and so
on.
2.1.4 Undefinedness
The semantics of Standard Z does not prescribe a particular view of undefinedness. The
treatment of undefinedness is left to conventions introduced by specifiers and/or tools.
Throughout this thesis, the following conventions are adopted, which are oriented to de-
sirable properties of a partial logic, as described, e.g., by Owe [1997]:
,
There is a special predicate for testing the definedness of an expression:
M
eiff e
is defined.
,
The undefined value can be denoted by the expression
, which is an abbreviation
for
.
2.1 A Sketch of Z 27
,
Undefinedness strictly propagates in relational application, e e
, and in relational
test, e R e
.
,
A set may have “unknowns”, that is the proposition x
Xmay be undefined for
certain x’s. For schema text, x
X
Px, if the proposition Pc is undefined for some
c, then c
x
X
Px
will be as well. At the same time, for some other c
such
that Pc
is defined, c
L
x
X
Px
is defined.
,
Intersection and union of sets in set algebra or the schema calculus can deal with
unknowns. Briefly, if x
X
is unknown and x
X
is false, then x
X
z
X
is
false. This behavior is commutative and associative. Symmetrically, if x
X
is
unknown and x
X
is true, then x
X
)
X
is true.
,
Logical connectives can be seen as a special case of set-union and set-intersection,
and treat undefinedness in a similar way. Moreover, if Pis undefined, then
P
is as well. The conditional expression,
p
T'A
e
A7
e
, is treated as an
abbreviation for
x
A
p
x
x
e
v
p
x
x
e
, and is therefore non-strict.
,
Quantifiers are treated as the usual expansion to and-chains and or-chains regarding
undefinedness.
Note that the above treatment still is loose as regards the representation of undefinedness
in a model: we have merely stated some properties. The
Zcalculus is more explicit,
adding a
element to the carriers, which can be seen as a refinement of the above.
In Section 2.2.4 (on page 29), syntactic sugar will be introduced which allows a con-
venient notation for recursive partial functions making use of these conventions – in par-
ticular of the
)M
epredicate.
28 Meta Notation
2.2 Notational Extensions
Throughout this thesis, a few purely syntactical extensions of Z will be used, which embed
well-known mathematical notation techniques in the Z framework.
2.2.1 Where Notation
In Z, axioms of the kind
b
D
P
,
Qare commonly used at a top-level position of
a specification, where no outer scope exists. For this kind of “shallow” quantification,
the
b
-prefix notation distracts from the actual specification goal, the predicate Q, which
contains free variables bound by D
P. To enhance readability, we allow the alternative
notation Q
Q'6H
D
P. The binding priorities for Qare lowered to the level of schema
properties, such that newline and “
m
” can be used instead of logical conjunction, “
v
”.
Thus the notation
Q
7m
Q
Q
Fm
Q
Q)AH
D
P
is syntactic sugar for
b
D
P
,
Q
v
Q
-v
Q
-v
Q
.
2.2.2 If-Exists Notation
An often encountered situation in specification is the desire to formulate a “conditional
let”: if a unique binding for some schema text exists, then an expression should be evalu-
ated under this binding, otherwise an alternative expression should be evaluated. In plain
Z, one has to write
#y
D
P
F'A
D
P
,
E
A7
E
to achieve this effect. We
allow the notation
/=¡
D
P
F)A
E
A7
E
as syntactic sugar for the above phrase.
2.2.3 Inference Rule Systems
In computer science, a widely used notation for axioms of the kind
b
D
P
,
Qare
so-called inference rules:P
QD
We allow this notation as syntactic sugar for the universal quantification.
Systems of inference rules are often used in this thesis to inductivelydescribe relations
on syntax. When defining a relation with an inference rule system, in addition to the
axioms described by the rules, a principle of generation is assumed. We say that a relation
is the smallest one which satisfies the rules. Formally, let R
Tbe the relation defined
(with Tits type) and I
T
R
!
upto In
R
!
the rules:
R
£¢}
R
T
I
F
R
!¤mEOTOTOdm
In
R
!¥
In this thesis, a formalization of generation is not usually given. However, it will be
sufficiently treated in the explanatory text.
2.2 Notational Extensions 29
2.2.4 Recursive Partial Functions
A commonly used technique for describing recursive partial functions is to use equations
of the form f E
¦
E
. Here, the value Eis in f’s domain iff E
is defined. If so, the
mapping E
E
is in the functions graph. For example, an interpretation function which
maps terms to semantic values is defined iff the interpretation of subterms is defined. This
technique is indispensable for readability in those situations where the description of the
definedness and mapping cannot be adequately partitioned.
Throughout this thesis, we use the notation
E
§
E
¦
E
BOTOTO¨¦ O7OTO
En
¦
E
n
Q)AH
D
P
as a syntactic abbreviation for the Z form:
b
D
P
,
E
©wX6ZJ[
E
§$ª )M
E
zv
E
«8X6Z<[
E
§©x
E
§
E
¬
E
vuO7OTOAv
En
X6ZJ[
E
§ª M
E
n
zv
En
wX6ZJ[
E
§-x
E
§
En
E
n
In general, with this style of definition, the left-hand sides Eimay be not exhaustive.
Moreover, we may spread equations for one function E
§
over several paragraphs. We
normally choose the smallest solution for a function defined by a system of recursive
partial definitions, given in one or several paragraphs. It is constructed similarly as for
relations (see Section 2.2.3 (on the facing page)).
If patterns of definitions overlap, we treat them to be priorized by textual order. For
example, the following recursive function definition removes each second element in a
sequence:
A]
remove
4®6"n
A
¯ 17
A
remove
4"°
x
2
y
±)²
s
¦ °
x
±²
remove
4J
s
s
¦
s
Q'6H
x
2
y
A
m
s
317
A
The second definition case captures any sequence, but has less priority than the first case,
such that sequences whose length is greater then one are handled by the first case.
2.2.5 Local Variables in Schema Boxes
When specifying sequential systems using schemas in vertical box notation, one often
encounters the necessity of introducing local variables. In Z, this is has to be notated as
shown in the left-hand side below:
30 Meta Notation
S
State
y
Locals
,
P
v
OTOTOAv
Pn
S
State
Locals
.. .. . .. .. . . .
P
O7OTO
Pn
One obvious problem of this notation is that it becomes necessary to separate the proper-
ties Piin the context of the existential quantifier by “
v
” instead of line break or “;” which
would be more readable. We therefore introduce the notation on the right-hand side as a
shortcut for the left-hand side.
2.2.6 Case Distinction in Predicates
Case distinction in predicates must be denoted in Z as on the left-hand side below. We
introduce the notation on the right-hand side as a much more instructive variant:
S
State
x
³´Cx
x
x
µ]0
x
³¶Cx
x
x
r0
S
State
x
³´C
T'A
x
J
x
µ]0
A7
x
x
r0
2.2.7 Selective
·
When specifying state transition operations in Z’s sequential specification style, one uses
the
Soperator to create pre and post state versions of the fields of the schema S. If
certain fields are not going to be changed, equations such as x
x
have to be added to
the operation schema. Apart of notational noise, this diminishes localizability of changes
to S.
We therefore use the notation
¸
x
72TO7OTOh2
xn
!
Sto express that, from the schema S,only
the variables xiare changed, and all other keep their value. This is syntactic sugar for
¹
S
HºJ
S
»R
x
=2TOTOTOU2
xn
1rºJ
S
»R
x
2TOTOTOh2
x
n
1G!
2.2.8 Overloading
In a large Z specification that introduces hundreds of new names, keeping all these names
disjoint decreases the readibility when similar things need to carry different names. For
example, suppose a function which delivers the set of free variables of different types
of terms: naming this function
¼H^¨\¾½P¿IÀ<ÁFÂ
,
¼H^¨\ý"ÄFÅÇÆHÈ"É;Â
and so on, does not contributes to
readibility.
We therefore allow the selective use of ad-hoc overloading. Actually, this overloading
is implemented by using different L
A
TEX markup names for Z symbols which expand to
the same representation.
2.2 Notational Extensions 31
2.2.9 Further Extensions
The E
f<g
type checker, developed in ESPRESS and used for processing the mathemat-
ics used in this thesis, adds some further extensions to the Z notation, which have been
proposed to the Z ISO Panel:
,
The order in which paragraphs appear in a specification is arbitrary. The only re-
quirement is that the definition-use relation of paragraphs is acyclic. (A paragraph
is in definition-use relation to another paragraph if it introduces a name that is re-
ferred to by the other paragraph.)
,
and
Ê
are introduced as expression operators.
,
Mutually recursive free types are allowed. This is (roughly) explained as follows.
A free type definition, T
Ë
variants, introduces two paragraphs: one containing
the definition of the given type
T
!
, and a second containing the free type axioms
derived from the variants. Given the freedom of order of paragraphs, this allows
arbitrary recursive dependencies between free type names and other definitions.
,
Global constants can be declared multiple times, provided all declarations are type-
compatible.
A detailed justification, including the semantic foundation, is givenin [Fett and Grieskamp,
1998].
32 Meta Notation
2.3 Mathematical Tools
Standard Z provides a rich set of “mathematical tools” for working with sets, relations,
and functions. It is assumed that the reader is familiar with Z’s mathematical toolkit (a
specification can be found in [Spivey, 1992]). Some further tools are required in this
thesis, and will be defined below.
2.3.1 Sets and Relations
The Z toolkit is fairly complete as regards basic functions on sets and relations. For our
present purposes, it lacks only one concept: the reduction of a set of values by a binary
function.
Ì
f
edenotes a function that takes a set and reduces its elements using the function fand
the starting element e.fmust be right-commutativew.r.t. the argument set (f
x
n2
f
x
72
y
1z
f
x
72
f
x
n2
y
1
) since the order in which reduction is performed is not determined:
X
2
Y]
Ì
X
D
Y
Í
Y
D
Y
¯ k
X
Í
Y
Ì
f
es
¦
y
Y
s
v
y
e
ξb
x
s
,
y
f
x
2
Ì
f
e
s
Ï
x
3"1"
Q'6H
f
X
D
Y
Í
Y
m
e
Y
m
s
;k
X
This definition makesuse of the syntactic extension fordefining recursive partial functions
(Section 2.2.4 (on page 29)). The domain of the function
Ì
f
eis induced by its defining
expression, which is (for non-trivial s) only defined if fis right-commutative and defined
for all elements.
2.3.2 Sequences
The Z toolkit lacks some typical functions known from functional languages for working
with sequences, which are defined as follows. With x
Ð
s, the element xis prepended
to the sequence s, with s
NÐ
xappended. By
Ñ/ÒÓ©
s
n2
s
n
, the sequence is delivered where
the elements are pairwise combined. The phrase
f
2
e
JÔ
sdenotes the reduction of the
function ffrom right to left on the sequence s, with starting value e; the phrase
f
2
e
JÏ
s
denotes the reduction from left to right.
X]
Ð Õ%
x
X
m
s
6"n
X
,
°
x
±)²
s
Ð Õ%
s
617
X
m
x
X
,
s
²°
x
±
X
2
Y]
Ñ/ÒÓY3"n
X
D¸"7
Y
Í "7d
X
D
Y
Ñ/ÒÓ"°G±n2/°¤±5 ¦ °¤±
Ç
x
ÐÃ
s
2
y
ÐÃ
t
U¦
x
2
y
LÐÖÑ/ÒÓ
s
2
t
Q'6H
x
X
m
s
6"n
X
m
y
Y
m
t
6"n
Y
2.3 Mathematical Tools 33
X
2
Y]
Ô "
X
D
Y
Í
Y
D
Y
D8"n
X
Í
Y
Ô "
f
2
e
:2/°G±5 ¦
e
"
f
2
e
:2
x
Ð
s
U¦
f
x
2F
f
2
e
JÔ
s
Q'6H
f
X
D
Y
Í
Y
m
e
Y
m
x
X
m
s
B"7
X
X
2
Y]
Ï 1
X
D
Y
Í
Y
D
Y
D8"7
X
Í
Y
Ï "
f
2
e
:2/°G±5 ¦
e
"
f
2
e
:2
s
×Ð
x
)¦
f
x
2F
f
2
e
JÏ
s
Q'6H
f
X
D
Y
Í
Y
m
e
Y
m
x
X
m
s
B"7
X
With f
Ø
e
2
s
, the “context mapping” of the function fto the elements in sfrom left
to right is denoted. eis an environment or “state” parameter, which is threaded through
the mapping:
X
2
Y
2
Z]
Ø
X
D
Y
Í
X
D
Z
-D
X
D17
Y
dÍ
X
D17
Z
Ø
f
2F
e
2F°G±5" ¦
e
2/°G±5
f
2F
e
2
x
ÐÃ
s
"U¦ 6
e
_2
e
L
X
m
x
Ù
Z
m
s
L6"7
Z
e
¾2
x
f
e
2
x
:mW
e
Ã2
s
z
f
Ø-
e
Ã2
s
,
e
2
x
ÐÃ
s
Q'6H
f
X
D
Y
Í
X
D
Z
m
e
X
m
x
Y
m
s
6"7
Y
2.3.3 Booleans
In the forthcoming Z ISO Standard, schema expressions and value expressions have been
unified. Moreover, schemas with an empty signature are allowed (for example,
¾
P
!
).
This opens up the possibility of defining the type of Boolean values as the set of schemas
to the empty signature, and use schema reference in a predicate to refer to a Boolean
value. The type
Ú
is defined below following this approach:
ÚÕ£k¬ ! Û
\¥Ü/ÝWÞ_
true
!
ß
^6à ½IÝWÕÞ¾
false
!
á
c
s
;kÚ
,
_¨y
x
s
,
x
! âãÕ£
s
;käÚ
,
¾7b
x
s
,
x
!
With
á
s, the members of the set of booleans sare disjuncted, with
â
s, they are con-
juncted. Note that Booleans are truly two-valued, in contrast to truth values as discussed
in Section 2.1.4 (on page 26).
2.3.4 Order and Lattices
Ordered sets and lattices provide a fundamental theory for computer science and discrete
mathematics. Below, some basic notions that are required later on in this thesis are for-
34 Meta Notation
malized in Z. The definitions and theorems are mostly taken from [Davey and Priestly,
1990].
An ordered set is a set equipped with a (partial) order,
å
, which is reflexive,
antisymmetric and transitive:
X]
å
X
æ
X
x
å
x
m
x
å
y
v
y
å
x
x
x
y
m
x
å
y
v
y
å
z
x
x
å
y
Q'6H
x
2
y
2
z
X
The axiom
å =
A
!Ù
Eis used throughout this thesis to state that “the” partial order of
a given set Aregarding lattice properties is equal to the expression Eof type A
æ
A. For
example, the following axiom states that the partial order of sets of some given element
type FOO is set inclusion:
FOO
! å 5çk
FOO
!Ù{ +
The technique used for this kind of “overloaded” definition of
å
, where meanings
are assigned in dependency of generic instances, is comparable to Haskell’s type classes
[Wadler and Blott, 1989; Hudak et al., 1992]3.
From the order of a set X, its dual order is derived by relational inversion:
X]
è
ÕÞ å =
X
!
a
Given an ordered set S
+
X, the supremum (least upper bound) and the infimum
(greatest lower bound), if existent, are denoted by
é
S(
ê
S):
X]
é27êë;k
X
Í
X
é
S
¦ 6
U
Õì
x
X
Tb
x
L
S
,
x
è
x
¾
,
x
U
7b
x
Ù
U
,
x
å
x
Ã
Q'6H
S
;k
X
ê
S
¦ 6
L
Õí
x
X
7b
x
Ù
S
,
x
å
x
Ã
,
x
L
7b
x
d
L
,
x
è
x
Ë
Q'6H
S
;k
X
To build the supremum (infimum) of two-element sets
x
2
x
S+
X, the notation x
î
x
(x
ï
x
) is used. The former is called the join, the latter the meet:
3Standard Z, [Toyn, 1998], relaxes restrictions found in the Z of [Spivey, 1992] and permits such use
of genericity. Semantically, specifying
ð
generically for all possible instantiations does not cause a
problem: for any set A, there exists at least the empty order,
ñ ð òIó
A
ôAõö
.
2.3 Mathematical Tools 35
X]
î 2 ï
X
D
X
Í
X
î ¬
x
2
x
)¦ é
x
2
x
Q'6H
x
2
x
X
ï ¬
x
2
x
)¦ ê
x
2
x
¾
Q'6H
x
2
x
d
X
Alattice is a set L
+
X, where for all pairs x
2
x
Ù
L,x
î
x
and x
ï
x
are defined. The
set of all subsets Lof Xwhich are a lattice is described by
à>^
Û
X. In a complete lattice, for
each subset L
Ù+
Lthe supremum (infimum) exists.
é
L(
ê
L) are called the top (bottom)
element of a complete lattice L:
X]
à>^
Û
Õí
L
Ak
X
7b
x
2
x
L
,
x
2
x
$8X6ZJ[ î v
x
2
x
8X6ZJ[ ï :
X]
à>^
Û
Ä Õì
L
Çà ^
Û
X
7b
L
;k
L
,
L
X6ZJ[é÷v
L
8X6ZJ[êl
X]
ø
Õ%
L
Jà>^
Û
Ä
X
,
é
L
Õ%
L
Jà>^
Û
Ä
X
,
ê
L
A well-known structure related to a complete lattice is a cpo (complete partial order).
It has a bottom element and behaves like a complete lattice as regards the infimum. For
the dual, it is only demanded that for every directed subset of S, the supremum exists.
Adirected set is one where for any finite subset the upper bound is in the set. Cpos are
commonly used for modeling the semantics of programming languages; however, for our
set-based calculus, the more general notion of lattices is better suited.
For complete lattices (and cpos), theorems exist that can characterize computability.
These will be briefly reviewed below. Let f
L
¯
Lbe a function on a complete lattice
L. The set of fixed-points of fis defined as the set
x
L
x
f x
. The least fixed-point
exists if the infimum of this set exists (the set is not empty) and is a fixed-point (is in the
set). It is known that if fis order-preserving (monotonic), then the least fixed-point exists
for complete lattices. If fis also continuous, then the least fixed-point can be expressed
by the image of funder the supremum of the set of finite elements in the domain of f.
Continuity in this context means that for any subset S
+
L, it holds
é
f
ù
S
ú5E
f
.é
S
.
We denote the set of continuous functions over a base type Xas X
¯¥û
X:
X
2
Y]
¯¥û Õì
f
X
Í
Y
/X6ZJ[
f
là>^
Û
Ä
X
vs\_^6`
f
à>^
Û
Ä
Y
_b
S
;k¥X6ZJ[
f
,
é
f
ù
S
úP)
f
Ié
S
1:
Afinite element of a complete lattice is one where there exists only a finite number of
36 Meta Notation
elements in a chain starting at
and reaching the element. Let F
+üX6ZJ[
fbe the non-
empty set of all finite elements in the domain of f. Then, the central fixed-point theorem
for continuous functions and complete lattices states:
f
X
¯¤û
X
x êl
x
BX6ZJ[
f
x
f x
f
Ié
F
Thus, putting the supremum of maximal finite information into fyields the (possibly,
infinite) least fixed-point. Since (by continuity) fis order preserving, this (indeed “ideal”)
maximal finite information can be incrementally computed by successive application of f
starting at
L. These results are used in Chapter 3 to justify the fixed-point law of
Z.
Chapter 3
The
ý
ZCalculus
So gestaltend, umgestaltend –
Zum Erstaunen bin ich da.
(Goethe)
The
Zcalculus is a set-based expression language which can embed set-oriented nota-
tions such as Z as well as functional and logical programming languages. The calculus
is designed for the automatic analysis and transformation, where it is desirable working
with a small set of language constructs. However,
Zis not “as small as possible”1. The
calculus has redundancy in that it allows extensional as well as intensional description of
the same meaning. For example, the set containing the numbers
0
and
4
can be denoted
in
Zas
A0Bw¨4A
or by the schema
x
x
þ0'
x
ÿ4;
. The support of both inten-
sional and extensional description allows the definition of computation as a source-level
transformation from intensional towards extensional representation, as shown in the next
chapter.
The language constructs of
Zare essentially those of set algebra (set intersection,
union and complement), set comprehension and a novel notation for set translation.
Moreover, singleton sets can be constructed and deconstructed. The calculus entails a
notion of free constructors, which are used to model tuples, Z-style bindings and free
types. As will be seen, the
-calculus, predicate calculus and schema calculus can be
derived from this basic set of operators.
In this chapter,
Zwill be introduced and formally defined. A semantic model is
developed, and the language constructs will be described one-by-one, giving their typing
rules and semantic meanings. An equational theory for
Zis developed. The chapter is
concluded with a discussion of some aspects of the calculus and of related work.
1Higher-order logic [Gordon and Melham, 1993], for instance, has a smaller number of language con-
structs.
38 The
ZCalculus
3.1 Introduction to
Z
We give an introduction to the
Zcalculus and discuss the encoding of Z as well as logic
and functional logic programming languages in
Z.
3.1.1 Syntax and Informal Meaning
Let x
VAR be variable symbols, and let
%
CONS be (term) constructor symbols.
The
Zcalculus provides the syntactic categories of expressions, and a subset of them,
patterns:
e
EXP
x
e
e
e
e
e
e
e
e
e
p
p
"!#$
p
e
%'&)(
p
*
e
p
PAT
+
EXP
The form
e
describes a constructor application, where eis a sequence of expressions.
(We generally use the convention of denoting sequences of terms tby t.) The set of pat-
terns PAT
+
EXP are those expressions that are solely built from constructor application
to patterns,
p
, and variables, x.
The form
e
denotes a singleton set. The form
eis the singleton set selection that
returns the element of a singleton set, and is undefined for each other set. The usual forms
for set algebra are provided: the empty set is denoted by
, set intersection by e
e
, set
union by e
e
and set complement by
e.
The form e
p
p
"!
describes the translation of the set e. The result of the transla-
tion is the set of all elements that match p
such that there exists an element in ewhich
matches the pattern p
under the same substitution. Thereby, both patterns may contain
unbound variables, which may be denoted by wildcards ( ). For example. For exam-
ple,
I/10B254An$/I032P9;nJ=>
x
2
x
!
(where numbers are special
C
-ary constructor
symbols) equals to
A0¨
. The cartesian product of two sets, e
D
e
, can be expressed in
Zas e
F
x
x
2 G!6
e
H
y
2
y
¤!
(
2
being the constructor symbol for pairs used
in mixfix notation). Conversely, the range of a binary relation e(a set of pairs) is de-
noted as e
N 2
y
®
y
!
. We call a translation with
¼H^¨\ý
p
#+ ¼H^¨\¾½
p
an embedding and
with
¼H^¨\¾½
p
@¼H^¨\ý
p
ahiding. Note that there might exist translations which are nei-
ther embeddings nor hidings. In general, translations are capable of expressing all kinds
of specification morphisms induced by signature morphisms as used in algebraic spec-
ification [Ehrig and Mahr, 1985; Wirsing, 1990]2, and thus can be seen as a means for
constructive description of (some) morphisms in the category of
Zsets.
The form
p
e
describes a set comprehension, or a schema in Z terminology3. It
denotes the set of values that match the pattern psuch that the Boolean expression eis true
under the binding of variables resulting from the match. Thereby, a Boolean expression
is just a set expression over the element type of units (a type containing just one element):
let
K
be the 0-ary constructor for this element: then truth is the set
FK
, falsity is the
2It is easy to see that sets of tuples or bindings (tuples with named components) correlate to sets of
models/algebras.
3We prefer the notion “schema” since the structure of the generating pattern, p, is preserved, whereas in
Z’s set comprehension pis reduced to its characteristic tuple.
3.1 Introduction to
Z39
empty set, conjunction is intersection, disjunction union, and negation complement. For
example, the (sugared) schema
;
x
2
y
2
z
w
x
y
y
z
describes the set of triples
where each member is larger than the previous one. The Boolean expression x
yis
syntactic sugar for the form
1
Jw;
x
2
y
"J= KA!
(where
is a binary relation,
a set of pairs). The conclusive translation can be read as: we are not interested in the
actual result of the intersection, we merely want to know if it is empty or not. The entire
schema literally reads as
;
x
2
y
2
z
«;1
J8;
x
2
y
:<= KA! 1
J8;
y
2
z
:<= ¶K;!.ÖO
The form
&'(
p
*
edenotes the smallest member of the set
p
p
e
(where the equal-
ity abbreviates
I
p
-w
e
J= K;!
). The order needed here is discussed in Section 3.2.6
(on page 48). If a smallest member does not exist, the form is undefined.
The
Zcalculus uses a shallow polymorphic type system. To this end, constructors
have associated a (generic) type, and expressions are assumed to have a principal type.
A further condition for well-formedness is that patterns in translations and schemas are
used linearly (no variable is allowed to appear twice).
For commonly used forms of expressions, syntactic sugar is used, the most important
of which is the following:
e
e
x
¶KA!
e
e
I
e
e
e
e
e
s
e
is the “universal set”, the largest set of its according type domain.
eis an abbreviation
for the Boolean expression which is true iff the set eis nonempty. The two other forms
represent membership and equality.
3.1.2 Encodings
Constructs such as function application,
-abstraction, membership-test, equality, exis-
tential and universal quantification can be naturally encoded in the
Zcalculus. We
demonstrate this by sketching the encoding of Z in
Z. A brief comparison with logic
programming languages (horn-clause systems) and with the functional logic language
Curry [Hanus, 1999] is also given, anticipating some basic ideas underlying the compu-
tation model of
Z.
Encoding Z
Lambda Calculus. The operations of the simple-typed
-calculus are encoded as fol-
lows:
p
,
e
;
p
2
y
«
y
e
y
~
varse
ee
1
e
w
e
ÃL
x
x
2 G!M=N 2
y
z
y
!M
This treats functions as sets of pairs. The encoding of the application does in fact also
capture relational application as used in Z: it is sufficient for eto be a binary relation that
is right-unique and defined at the point e
.
40 The
ZCalculus
Predicate Calculus. We have already noted that formulas are a special case of set ex-
pressions over the element type of units, and we have defined abbreviations for the basic
predicates of membership-test and equality. To complete the picture, we give the encoding
of quantifiers:
y
x
,
e
x
e
b
x
,
e
r
x
¨
e
J
The resulting semantics of the encoding of predicate calculus is a partial three-valued
logic (see Section 3.2.1 (on page 43)).
Schema Calculus. In Z, a schema denotes a set of bindings, bindings being tuples
(records) with named components. The set is constrained by the declarations of a schema
as well as by the property. For example, in Z, the schema
a
Lpzm
b
Öor
a
b
!
denotes
the set of bindings
a
Õ
x
2
b
Õ
y
, where x
p
,y
o
, and x
y.
Assuming
Zconstructors for bindings,
a
EÕ 2TOTOTOU2
an
Õ
, where the ai’s are
interpreted as part of the constructor name, the above Z schema can be encoded in
Zby
a
Õ
x
2
b
Õ
y
x
p
x
y
The constraint y
o
vanishes since
o
is a given type. The property x
yis further trans-
lated as described in the previous section. Other possible encodings exist, for example
p¬
x
a
Õ
x
2
b
Õ
I!3w
a
Õ
x
2
b
Õ
y
x
y
The connectivities of the schema calculus directly map to
Z. Schema conjunction in
Z, S
v
S
, is the set of bindings with the joined signature of S
and S
where components
with the same name are identified. This is expressed in
Zas
S
T
S
=
!6
S
F
S
7
!I2
where
is the pattern for the joined signature. For example, the Z schema conjunction
a
A
m
b
B
P
a
2
b
!!hvr
a
A
m
c
C
Q
a
2
c
!!
(where A,Band Care given types) maps
to
a
Õ
x
2
b
Õ
y
P
x
2
y
!¥
a
Õ
x
2
b
Õ
y
¬
a
Õ
x
2
b
Õ
y
2
c
Õ
I!
a
Õ
x
2
c
Õ
y
ä
Q
x
2
y
!¥L
a
x
2
c
Õ
y
¬
a
Õ
x
2
b
Õ 2
c
Õ
y
I!
Existential schema quantification,
y
S
,
S
, is encoded as
S
S
S
G!6
S
=
S
z
S
dÏ
S
G!
where
S
'Ï
S
denotes the removal of the components from Sin S
. Similarly, the
remaining connectivities of the schema calculus are encoded.
Note that
Z’s support of the schema calculus clearly shows that
Zis capable to
express relations between entire specification units, modules, etc.: Z schemas can be
thought of as an algebra on the calculus level.
3.1 Introduction to
Z41
Encoding Logic Languages
A logic program in a language such as Prolog consists of a set of Horn clauses A
B
n27OTOTOU2
Bn, where Ais called the conclusion and the Biare the premises of the clause.
The Aand Biare so-called atoms of the form R
t
, where tis a sequence of terms over
constructor symbols and variables, and Ris a n-ary relation. We can map Horn clause
systems to
Zas follows. Let A
R
t
and Bi
Qi
si
; then the “body” of the clause is
represented as
;
t
WÇ
s
5-
Q
LìOTOTOP
sn
-
Qn
. To define the meaning of the relation
R, we collect the bodies of all clauses in which Ris the head of the premise, as follows:
R
í;
t
:E;
s
¡
Q
¡
{O7OTOP
sn
¡
Qn
¡
OTOTO
;
tm
E;
s
m
Q
m
ìOTOTOP
snm
Qnm
We proceed similarly with the clauses for Qijin the system. If Rand Qijare recursively
dependend, the fixed-point operator will be used. Answering a query R
q
then merely
means computing the intersection R
8;
q
:
.
Encoding Functional Logic Languages
Languages such as Curry [Hanus, 1999] or Goffin [Chakravarty et al., 1997] can, in prin-
ciple, be encoded in
Z. The exact operational semantics will not be the same, since
a strict reduction order for
Zis preferred by design, whereas both Curry and Goffin,
which are extensions of Haskell, use lazy reduction. An illustration of such an encoding
is instructive, anyway.
A function definition in Curry is mapped as follows (fbeing a function symbol, pa
pattern, ca constraint, and ean expression; the fresh variables yimay not appear in the
patterns pi):
f p
c
]
e
=mWOTO7Ohm
f pn
cn
en
&)(
f
*®;
p
n2
y
5E
c
Ù
y
$
e
=-{O7OTOP8;
pn
2
yn
E
c
yn
en
Thus, a constraint cof Curry directly maps to a corresponding constraint in
Z. Con-
junctions of constraints are expressed by intersection. Calling a function that returns a
constraint with a free variable as the argument, such as Cx, amounts to membership test,
x
C. In fact,
Zallows a richer constraint language than Curry (in particular, disjunc-
tion and negation), which, however, will not always be executable.
The computation model of
Z, described later on, executes constraints concurrently,
using both residuation [Ait-Kaci et al., 1987] and backtracking and enumeration to deal
with free variables. An access to a free variable is suspended in a nested context. This
is, for example, the case for arguments of the
-operator (and therefore for function ap-
plication ee
which is defined using
) or for negative constraints. Backtracking takes
place for constraints which map to the membership test of a pattern in a set. For exam-
ple, consider the definition of an “append” relation on lists (below, an abbreviation for
introducing local variables is used:
p
Ï
q
e
is equivalent to
;
p
2
q
«
e
LN
p
2
q
p
!
):
42 The
ZCalculus
&)(
app
*®;"°G±n2
ys
2
zs
e
zs
ys
-
;
x
Ë
xs
2
ys
2
zs
LÏ
t
;
xs
2
ys
2
t
$
app
zs
x
Ë
t
Applying this relation to unbound xs and ys and bound zs will compute the possible par-
titions of the list zs, as usual in logic languages.
Zis higher-order because sets can be stored in constructed values. Similar as Curry
or Goffin, the computation model does not employ higher-order unification. This restric-
tion is, though, not tied to the notion of a type of a value (whether it is a set or not) but
to the representation: sets that are extensionally represented are incorporated by a simple
equality test in unification. An extensional representation is given by applying construc-
tors, singleton sets and set union to extensional values.
3.2 Semantic Model 43
3.2 Semantic Model
The model of
Zis constructed by an interpretation function over terms of a type lan-
guage. We will first discuss the concepts underlying the set representation in the model
and then define the type interpretation.
3.2.1 Set Representation
The model of
Zis based on a hierarchical typed universe, where sets are represented
as partial characteristic (Boolean) functions in a set-theoretical meaning, which can be
founded by Z itself or by Zermelo-Fraenklin set theory. We will use Z to this end.
Let Ube the domain of some type. The representation of an element of the powerset
of this type is a partial function f
U
Í Ú
. The function fcharacterizes the knowledge
about the elements in the set in the following way. A value u
Uis
1. a member of the set, if u
8X6ZJ[
f
v
f u;
2. not a member of the set, if u
X6ZJ[
f
v
f u;
3. unknown to be a member or not, if u
~8X6ZJ[
f.
As an example, consider the (sugared)
Zschema
x
0EXJÒ ¼
x
0B
. For this set,
0
is
known to be member, and all natural numbers greater then
0
are knownnot to be members;
however, for
C
, no information is available, since the expression
0LXJÒ ¼C
is undefined. Thus
this set is represented as the Boolean function
x
;p Ï HC<
,
¾
x
{0n!¤O
The given representation of sets allows for a natural definition of the set-algebraic
operations. Let f
n2
f
be the representations of two sets. The intersection is defined as
f
f
-?
x
¥X6ZJ[
f
¸X6ZJ[
f
nd
f
a
7ùM
ß
^6à ½Iݨ¨úU
f
a
7ùM
ß
^6à ½Iݨ¨ú
,
¾
f
x
v
f
x
!¥2
and the union is defined as
f
f
©?
x
¥X6Z<[
f
¸X6Z<[
f
7d
f
a
7ùG
Û
\¤Ü/ÝB¨úU
f
a
7ùM
Û
\¥Ü/ݨ¨ú
,
_
f
x
Î
f
x
!¤O
Thereby, the conjuction in our meta-language Z,
v
, is defined if one of the operands is
false, and disjunction,
Î
, if one of the operands is true, independent of the definedness
of the other operand. Accordingly, the domains of the resulting characteristic functions
are constructed: we add all those elements to the domain for which the one or the other
operand already determines the result.
As an example for the effect of the set operators, consider the expression
x
A0ÖXJÒ ¼
x
0¨
x
x
|üC<
. The representation of the left set operand was already defined above.
The right set operand is given by the function
x
;p
,
_
x
|£C¨!
. The intersection of both
representations according to the above definition yields the function
x
;p
,
¾;0$XJÒ ¼
x
{0Wv
x
|£C¨!¥O
44 The
ZCalculus
TCONS
2
TVAR
!
^¨\¥Ò
Û
TCONS
¯ p
TYPE
Ë s !M
h/Q
TCONS
m
317
TYPE
H^¨\¥Ò
Û
®
d
k
TYPE
l
TVAR
Figure 3.1: Type Language
Whereas the left-operand is not defined for
C
, the result is (with
C
known not to be member
of the resulting set).
An interesting aspect is the definition of set complement in our set representation. It
is straight-forward:
f
?
x
3X6Z<[
f
,
f x
O
Thus the complement does not alter the domain of the characteristic function. What is
unknown to be member of the set keeps to be unknown. As a consequence, the “principle
of the excluded middle” will not hold in our framework: f
£
f
?
does not hold.
However,
ÿ
f
?
fholds. The valid laws will be discussed in more detail in Section 3.4
(on page 57).
The representation of sets and the definition of the set-operations provides a general-
ization of what is called “three-valued” logic in the literature to the case of set algebra.
We have already discussed that truth-vales are represented as sets over the “unit” type
with one member, denoted by the constructor
K
. The empty set,
, represents falsity, and
the singleton set containing the unit,
FK
, truth. Intersection, union, and complement over
sets of this type behave as conjunction, disjunction, and negation in the three-valued logic
described by Owe [1997].
3.2.2 Types
The model of
Zis constructed by an interpretation function over terms of a type lan-
guage. Terms of the type language,
Þ
TYPE, are built from type construction
L
Ç!
(where
TCONS are type constructors with arity), from power-set types
k
, and from
type variable application,
(
%
TVAR). The definitions are given in Figure 3.1. Note
that the Cartesian product is introduced by certain type constructors, which will be dis-
cussed in Section 3.2.4 (on page 46).
We suppose standard syntactic tools on type terms (Figure 3.2 (on the facing page)).
The set of free type variables in a type is deliveredby
¼H^H\¾½
. The subset of types which are
ground (contain no type variables) is denoted with TYPE
. A type variable substitution is
a partial function
!
TSUBS
TVAR
Í
TYPE, such that
X6ZJ[
"!
W
$#
¼H^¨\¾½¬ùM\_^6`
%!
ú5
.
The application of a substitution to a type is denoted as
½=Ü
'&
/½
(!)
.TSUBS
denotes the set
of ground substitutions. The most general unifier of two types is described by the relation
T-
+*,
n
. These standard concepts are not formalized.
3.2 Semantic Model 45
TYPE
w;k
TYPE TSUBS
Õ
TVAR
Í
TYPE
TSUBS
Õ
TVAR
Í
TYPE
¼H^¨\¾½
TYPE
¯ k
TVAR
½=Ü
'&
/½
TSUBS
¯
TYPE
¯
TYPE
;kz
TYPE
D
TSUBS
D
TYPE
Figure 3.2: Type Language: Syntactic Tools
UNIV
!
Ü6`/X6Ý
ß
UNIV
½1ÝH[
TYPE
¯ k
UNIV
b
,
TYPE
,
Ü6`/X6Ý
ß
8½Iݨ[
-
G
TYPE
,
½Iݨ[
.
Ï 6Ü6`/X6Ý
ß
3$ÓH^¨\
Û
Ò
Û
Ò ZJ`
UNIV
Ï 6Ü6`/X6Ý
ß
/'0
UNIV
Í Ú
21
UNIV
3'0
UNIV
Í
UNIV
Í Ú¬
b
,
TYPE
,
½Iݨ[
4
Í Ú+]X6Z<[
/'0
3'0
/'0
a
½Iݨ[¶¤k
5
L)¦
r
6½Iݨ[
.
Í Ú
,
/'0
r
Q)AH
6
TYPE
Ü6`/X6Ý
ß
/'0
Figure 3.3: Semantic Universe
3.2.3 Universe
The semantic universe is denoted by the Z type UNIV. It contains a special element,
Ü6`/X6Ý
ß
, representing undefinedness. The universe is partitioned by the type interpretation
½Iݨ[
.
over ground types, modulo the element for undefinedness, which is member of each
interpretation. The definitions are given in Figure 3.3.
The following remarks on the semantic interpretation
½1ÝH[
in Figure 3.3:
,
For type construction, the partitioning axiom already states everything required:
a type construction
L
Ç!
delivers a subset of the universe disjoint from any other
type interpretation, except that the element for undefinedness,
Ü6`/X6Ý
ß
, is shared.
More constraints on certain type constructors are added in Section 3.2.4 (on the
next page), letting their interpretation being generated by value constructors.
,
As discussed above, a powerset type,
k
, denotes all the partial Boolean functions
over the domain of the meaning of
,
½Iݨ[
7
®Í Ú
. To map this representation into
UNIV, we define an encoding function
/'0
as a partial injection which is defined for
values which can be generated from a ground type. The inductive definition of the
domain of
/'0
ensures that an encoding exists, and contradictions such as Russel’s
Antinomy are avoided.
The same value for undefinedness is shared since by the interpretation of powerset
46 The
ZCalculus
CONS
!
ß
Û
ÓBÝl
TCONS
Í "n
TVAR
D
CONS
Í "n
TYPE
ß
Û
ÓBÝUR 617
TVAR
m
8
CONS
Í "n
TYPE
lc^¨\¥Ò
Û
®v¾b 6X6ZJ[
98
,
#
¼H^¨\¾½ùM\_^6`;
8
UJ.ú5+%\_^6` ¬:
Q'6H R6X6Z<[
ß
Û
ÓBÝ
G«R6X6ZJ[
ß
Û
ÓBÝ
,
X6Z<[S
ß
Û
ÓBÝUJPO4A$ÓH^¨\
Û
Ò
Û
Ò>ZJ`
CONS
Û
ÓBÝ©2
Û
Ò`/½
Û
CONS
¯ "n
TYPE
D
TYPE
Figure 3.4: Free Types: Syntax
types the totally undefined Boolean function,
¯ Ú
, which is identified with
Ü6`/X6Ý
ß
in a power-set domain, cannot be distinguished. Reusing
Ü6`/X6Ý
ß
over different types causes
no problems, since only typed expressions are considered in the
Zcalculus.
3.2.4 Free Types
The type constructors represent by default abstract, “given” subsets of the universe. For
some type constructors, this set may be generated by a collection of value constructors, a
commonly so-called free-type construction. A value constructor is a total injective map-
ping from a (possibly empty) sequence of values into a given value. A system of value
constructors effectively describes a many-sorted term algebra embedded into the model
of
Z.
The function
ß
Û
ÓBÝ
(Figure 3.4) associates a free type definition with certain type con-
structors, which consists of a sequence of type variables matching the type constructor’s
arity, and a mapping from constructor symbols to argument types which are closed under
the type variables. The given set of constructors, CONS, is partitioned by the constructors
of the free types.
For convenience, we introduce an auxiliary function which delivers the type of a value
constructor,
Û
:
Ó3Ý®
R L )!¬w17
TYPE
D
TYPE. Furthermore, we assume there is a
function
Û
Ò `/½
Û
, which delivers the type of a constructor with “fresh” type variables.
The semantics of a value constructor is described bythe function
½1ÝH[
;!
ÕR817
UNIV
Í
UNIV, which delivers for a ground type substitution and constructor a total injection
w.r.t. the meaning of the constructors argument types into the type constructor’s domain.
Given this function, the domain of a type constructor is partitioned by the range of the
meaning of all its value constructors (Figure 3.5). We have formally stated freeness (con-
structors are injective) and generation (by the partitioning). It is further demanded that
the generated type’s domain,
½Iݨ[½=Ü
'&
/½
!
RL
J!.1
is the smallest which satisfies the above
property. A formalization is left open.
There may be free type configurations which are inconsistent: consider a constructor
with type
°Gk®;±
. There is no solution by the above axioms for such a constructor,
and therefore it is not allowed. In Z one can further restrict the domain of constructor
functions, such that (in the above notation) one gets e.g. a type such as
°
=<
;±
for a
constructor, where
<
Õ
is the set of finite subsets of
. Thus Z’s solution to the problem
is to use partial injective constructor functions regarding the basic type of the arguments
3.2 Semantic Model 47
½1ÝH[
TSUBS
®¯
CONS
Í 17
UNIV
1
UNIV
_bR6X6ZJ[
"8
,
R8X6Z<[S½1ÝH[
;!
'zv
½1ÝH[
;!
Õ]
u
317
UNIV
u
>
8
UJzv
_b
i
6X6ZJ[
u
,
ui
½1ÝH[¥½5Ü
'&
/½
(!
:8
U
i
"""
?
½1ÝH[]½=Ü
'&
/½
(!
QL
Ç!M1"dÏ6Ü6`/X6Ý
ß
3
GW 3X6ZJ[
@8
,
\_^6`;¥½Iݨ[
-!
hJ"$ÓH^¨\
Û
Ò
Û
Ò>Z<`½Iݨ[½=Ü
'&
/½
!
RL
<!.1hÏ 6Ü6`/X6Ý
ß
Q'6H R6X6Z<[
ß
Û
ÓBÝzm
A!
l
TSUBS
Um 6"n
TVAR
6"n
TYPE
m
A8
CONS
Í "7
TYPE
$2
B8
ß
Û
:
Ó3ÝhÖm«\_^6` +]X6ZJ[
@!
zm
R{ dû
Figure 3.5: Free Types: Meaning
°G±ä
TCONS
K
CONS
ß
Û
:
Ó3Ý$°¤±e{
27FK® °G±53
ÚrÕ%k#°G±6m
ÛMÛ
Õ%
u
6½1ÝH[°G±
,
Û
\¤Ü/Ý3m
C
Õ%
u
6½1ÝH[°G±
,
ß
^6à ½IÝ
Figure 3.6: Free Type of Booleans
(the basic type of
<
is
k
). Since a clean equational theory for
Zheavily depends on
the fact that value constructors are total, this approach is not feasible for
Z. Instead,
a solution to the problem is to encode constraints on constructor arguments in special
given types (thus
<
would be a given type), and provide primitive (partial) encoding and
decoding functions which interpret these types. This approach is, however, not detailed
here.
3.2.5 Standard Types and Constructors
Some standard types and associated constructors with sugared notation will be defined
below.
Units and Booleans. The unit type,
°G±
, contains exactly one element, denoted by the
0-ary constructor
K
(Figure 3.6). The type of Booleans is a powerset of the unit type, and
is abbreviated as
Ú
. The semantic values
ÛMÛ
and
C
are the characteristic functions mapping
the unit value to true and false, respectively.
Natural Numbers. The type of natural numbers is available. It is generated by the
countable set of
C
-ary constructors
CÙ270J2TOTO7O
, denoted by the total injection (Figure 3.7).
ps
TCONS
Ap
?
CONS
ß
Û
:
Ó3Ý)pÞ
25«RÇ\¾^A`;
,
°G±5
Figure 3.7: Free Type of Natural Numbers
48 The
ZCalculus
b
+
TYPE
,
b
r
=2
r
«6½1ÝH[
-
Í Ú
,
/'0
r
«å
/'0
r
ª
_b
u
6X6ZJ[
r
)X6Z<[
r
,
r
u
x
r
u
v
_b
u
6X6ZJ[
r
)ÏeX6ZJ[
r
,
r
u
zv
_b
u
6X6ZJ[
r
ÏeX6ZJ[
r
,
r
u
a
ß
^6à ½IÝ32
b
ß
^6à ½Iݨ
6
a
Û
\¤Ü/Ý32
b
Û
\¥Ü/ݨ
b
ß
^Aà ½1ÝH
a
Û
\¤Ü/ÝH
a
ß
^6à ½IÝB2
b
Û
\¥Ü/ÝB
a
Û
\¥Ü/Ý32
b
ß
^6à ½Iݨ
a
ß
^6à ½Iݨ
b
Û
\¥Ü/ÝB
b
+
TYPE
,
½1ÝH[]Gk
Ùà ^
Û
Ä
UNIV
Figure 3.8: The Order on Partial Sets
This forces the interpretation of
p
in the semantic universe to be actually isomorphic to
natural numbers. Requiring the existence of this type ensures that our semantic model is
not trivial.
Bindings and Products. A family of type constructors and value constructors for bind-
ings is available. Bindings are records with named components, called fields. A binding
type constructor is denoted as
°
f
e
D
F=mWOTO7OUm
fn
E
n
±
. This type is generated by exactly one
constructor,
f
eÕ mOTOTOUm
fn
Õ
. The formal definition is omitted here; it matches
the notion of bindings in Z.
Cartesian products and their elements, tuples, are a special case of bindings, with
“anonymous” field names, which will be denoted as 1,2, and so on. A cartesian product
type,
FSDOTOTO)D
F
n, abbreviates the binding type
°
1
G
T7mOTOTOhm
n
H
n
±
, and the tuple
constructor
2TOTOTOh2
the binding constructor
1
Õ m«OTOTOUm
n
Õ
.
3.2.6 Order and Fixed-Points
The fixed-point operator of
Z,
&)(
p
*
e, selects the smallest element from the set
p
p
e
. To this end an order on values needs to be defined, and lattice properties need to
be established (see Section 2.3.4 (on page 33)).
Our model of sets suggests to define the order such that u
å
v
ª
u
u
v, where
3.2 Semantic Model 49
is the definition of intersection on characteristic functions:
f
f
©?
x
¥X6Z<[
f
)X6Z<[
f
nd
f
a
7ùM
ß
^6à ½IÝ/¨ú)l
f
a
7ùM
ß
^6à ½IÝ/¨ú
,
¾
f
x
v
f
x
!
The order confirming to this notion of intersection is defined in Figure 3.8 (on the fac-
ing page). The elements of a set-type can be refined from non-membership to unknown
membership to membership. This follows from that non-membership intersected with un-
known membership yields non-membership. For sets over the domain
a
2
b
the order is
illustrated in Figure 3.8 (on the preceding page). It is clear that with this order power-set
domains are complete lattices: the lattices “join” equals to set intersection and the “meet”
to union. The bottom element is the total function which delivers false for all members
of the element type’s domain,
½Iݨ[
-
, and the top element the total function which deliv-
ers true. Note that the bottom element does not coincide with the completely undefined
characteristic function,
Ü6`/X6Ý
ß
6
, as shown in Figure 3.8 (on the facing page).
We will not attempt to define ordering for the given values of the universe, though this
might be in principle possible for constructed values, allowing to build “infinite terms” by
fixed-points. For the fixed-point operator,
&)(
p
*
e, it is demanded by the type conditions
that the free variables in poverwhich a (simultaneous) fixed-point is constructed represent
set-values, and that pis an exhaustive pattern (like a tuple) which matches each value of
its type domain. The point-wise lifting of set-order to values matching such patterns is
obvious and a formalization is left open.
50 The
ZCalculus
VAR
!
EXPUT
Ë {O7OTO
PATUT
Ak
EXPUT
x
PATUT
x
I
VAR p
817
PATUT
p
E
PATUT
J
I
CONS
p
I KMLON
PATUT
PATEX
Ak
PATUT
m
PATLIN
;k
PATUT
Figure 3.9: Expressions and Patterns
3.3 Expression Syntax and Meaning
This section provides the definitive reference for the exact typing conditions and meaning
of
Zexpressions. For an informal introduction and motivation, we refer to Section 3.1
(on page 38).
The forms of
Zexpressions will be incrementally defined, each one together with
its typing rule and meaning function. There are also a few syntactic abbreviations for
common forms of expressions, which are introduced in Section 3.3.5 (on page 56).
3.3.1 Variable, Expression and Pattern Type
The syntax of (untyped) expressions is defined by the free type EXPUT (Figure 3.9) which
will be extended as we proceed. The set of variables, VAR, is pre-given. Patterns are the
smallest subset of expressions which satisfies the rules in Figure 3.9. A pattern is called
exhaustive, if it matches all values of its type. The property of being exhaustive can be
syntactically checked by analyzing the free types the constructors of the pattern belong
to. A pattern is called linear, if no variable in it appears twice. The set PATEX contains all
exhaustive patterns, the set PATLIN all linear patterns; a formalization is left open.
3.3.2 Typing Relation
The well-typed expressions, EXP
+
EXPUT, are those which are in the typing relation,
P Q
e
Ð
E
(Figure 3.10 (on the next page)). The context for typing,
P
TYPASS, is a
mapping from variables to types. Rules for the typing are supplied with each individual
expression form in Section 3.3.4 (on page 52) below. The well-typed patterns are patterns
which are well-typed expressions.
For well-typed expression it is assumed that there is a type-reconstruction function,
Û
:
Ó3Ý
e, which delivers the type of an expression in its context, as fixed by
Q
Ð
. The
function
Û
:
Ó3Ý
is not strictly consistent with our formal model, since an expression does
not contain information about its usage context. However, it is conceptually possible to
model such a function formally by adding type annotations to expressions.
3.3 Expression Syntax and Meaning 51
TYPASS
Õ
VAR
Í
TYPE
Q
Ð ;k¬
TYPASS
D
EXPUT
D
TYPE
EXP
Õì
e
EXPUT
By
P
TYPASS
m
TYPE
,
PRQ
e
Ð
S
d
PAT
Õ
PATUT
EXP
Û
ÓBÝu
EXP
¯
TYPE
Figure 3.10: Typing Relation: Declarations
SEMCTX
Õ
TSUBS
D
UNIASS
½1ÝH[
SEMCTX
¯
EXP
Í
UNIV
X6ZJ[¥½Iݨ[
;T
Wí
e
EXP
By
P
TYPASS
m
2
TYPE
,
PRQ
e
Ð
U
v
-#
¼H^¨\ý¬ùG\_^6`
P
ú5d¼H^¨\ý
+]X6ZJ[
9T
O0äv
X6ZJ[
P
X6ZJ[
VT
O4v
_b
x
6X6ZJ[
P
,
T
O4
x
w½Iݨ[´¥½5Ü
'&
/½
WT
O03
P
x
1""
Q)AH
XT
r
SEMCTX
Figure 3.11: Meaning Function: Declarations
3.3.3 Meaning Function
With each expression form, the meaning is supplied in subsequent sections, defining a
case for the recursive partial function,
½1ÝH[
YT
, that is declared in Figure 3.11. The context,
T
r
SEMCTX, consists of a ground type substitution and a value assignment forvariables.
The domain of
½Iݨ[
-T
is fixed to those expressions which fit to the context. An expres-
sion fits if its typing,
P Q
e
Ð
, confirms to
T
, which means the following: all types in
P
, as well as the expression’s result type
, are ground under the substitution
T
OË0
4, and
all values in the value assignment are in their type’s domain. In a similar way we could
state that every value delivered by the meaning function is in the according result type’s
domain, which is, however, omitted.
For the definition of the meaning function, we need the notions of value matching
and substitution. A pattern pcan be matched against a value uunder a value assignment
Z
UNIASS
VAR
Í
UNIV, written as p
['\
u. The inverse of value matching is
substitution, written as
½5Ü
'&
/½
Z
p(Figure 3.12). These fairly standard concepts are not
formalized.
4The Z phrase e
]
nselects the n-th element of a tuple.
UNIASS
VAR
Í
UNIV
[
;k
PAT
D
UNIASS
D
UNIV
½5Ü
'&
/½
UNIASS
¯
PAT
Í
UNIV
Figure 3.12: Value Matching
52 The
ZCalculus
EXPUT
Ë {O7OTOd< =
^
CONS
D"n
EXPUT
Û
Ò`/½
Û
S
R
_
dmX6ZJ[
X6ZJ[
<ÇrX6ZJ[
e
b
i
6X6ZJ[
,
PRQ
ei
Ð
J
i
v
<
i
,*
i
PRQ
e
¬ÐF½5Ü
'&
/½
(!)
`
I
TYPASS
a
J
I
CONS
a
e
I KMLON
EXPUT
b
I
TYPE
a
bdc bBe
I KMLON
TYPE
a
*
I
TSUBS
½Iݨ[
;T
e
=)¦¶½1ÝH[
YT
OË0)W"½1ÝH[
;T
Whû
e
Q)AH
XT
r
SEMCTX
m
CONS
m
e
6"n
EXP
Figure 3.13: Syntax and Meaning: Constructor Application
EXPUT
Ë {O7OTOd<I J
f
EXPUT
s
EXPUT
PRQ
e
Ð
S
PgQ
e
ÐHk
$
`
I
TYPASS
e
I
EXPUT
a
b
I
TYPE
PgQ
e
ÐHk
PRQ
e
Ð
S
`
I
TYPASS
e
I
EXPUT
a
b
I
TYPE
½Iݨ[
;T
.
e
JU¦
/'0
¤
u
3½1ÝH[¥½5Ü
'&
/½
WT
OË0$
Û
:
Ó3Ý
e
1
,
_
u
r½Iݨ[
YT
e
!
e
¦ 6
f
Õ
3'0
¥½Iݨ[
-T
e
,
WX6Z<[
f
c½Iݨ[½=Ü
'&
/½
hT
O0$1Gk a)5
Û
ÓBÝ
e
1"zv
f
a¸ÚlÍ
UNIV
F)AY
f
aU
Û
\¤Ü/Ý«A7RÜ6`/X6Ý
ß
Q)AH
XT
r
SEMCTX
m
e
EXP
Figure 3.14: Syntax and Meaning: Singleton Set Display and Selection
3.3.4 Basic Forms: Typing and Meaning
The tools for defining typing conditions and semantic meaning have been introduced in
the previous sections. In the sequel, for each basic expression form its typing and meaning
will be defined.
Constructor Application
A constructor application is denoted as
ikj
e
ldmSnSndn(m
en
o
, with n
prq
. The definitions are
given in Figure 3.13.
In the typing rule, we use the function
sBtvuwxsi
, which delivers the type of a construc-
tor with “fresh” type variables. The meaning is derived from the constructor’s semantic
interpretation,
wzy{-|}i
, for given ground type substitution
|
found in the context.
Singleton Set Display and Selection
A set which contains exactly one element is denoted by the expression
~
e
, called a
singleton set display. The element of a singleton set is selected with the expression
e,
called a singleton set selection. The definitions are given in Figure 3.14.
The type of the display is constructed from the type of the element. The operand of
the selection must denote a set. The type of the result is extracted from the type of this
set.The singleton set display denotes a characteristic function which is exactly true for the
display contents, and false for all other elements of the type. The meaning of singleton
3.3 Expression Syntax and Meaning 53
EXPUT
v
ndnSnhj
of
EXPUT
EXPUT
j
of
EXPUT
EXPUT
E
EXPUT
fresh
g
W
TYPASS
=
TVAR
e
$(
g
e
$
W
TYPASS
e
EXPUT
b
TYPE
R
e
l2$ld
R
e
A5U2l
+
U
op
j
e
lUm
e
o
j:w^'wh|Sl
o
W
TYPASS
e
c
e
EXPUT
b
c b
TYPE
TSUBS
op
¢¡ £ ¤
c
¡ ¥ ¤¦
wzy{;§¨j
o © ª'«
j=¬
u
wzy{j:w^'w(§,n®'jOs¯'°Ey2
o¢o±³²:´¶µ
w¢y
o
j
e
lk
e
oW© ·O¸'¹
f
l
¨º'«
j:w¢y{;§
e
l
o
f
¨º'«
j:w¢y{;§
e
o»±
ª'«
j=¬
u
j¼'½{
f
l¾¿¼'½{
f
o
j
f
À
l
oUÁ
~
²:´¶µ
w¢yÂW.j
f
À
oUÁ
~
²:´¶µ
w¢yÂ
±.Ã
f
l
u
Ä
f
u
Å
o
j
e
lk
e
oW© ·O¸'¹
f
l
¨º'«
j:w¢y{;§
e
l
o
f
¨º'«
j:w¢y{;§
e
o»±
ª'«
j=¬
u
j¼'½{
f
l¾¿¼'½{
f
o
j
f
À
l
oUÁ
~sÇÆÈyÂ%Éj
f
À
odÁ
~sÇÆyÂ
±-Ã
f
l
u
Ê
f
u
Å
o
jÈ
e
o © ·O¸'¹
f
˺'«
j:w¢y{;§
e
o±Xª'«
j=¬
u
¼'½»{
f
±-Ã
Ì
f u
Å
o
ÍÏÎ
¸¶Ð¸
§
SEMCTX
e
m
e
lUm
e
EXP
2
TYPE
Figure 3.15: Syntax and Meaning: Set Algebra
set selection is defined only if the operand denotes a characteristic function over the entire
types domain, which is true for exactly one element. Note that for a partial characteristic
function, the
form is undefined.
Set Algebra
The empty set is denoted by the expression
, the set intersection by the expression
e
lÑ
e
, set union by e
lÑ
e
, and set complement by
e. The definitions are given in
Figure 3.15.
The type of the empty set is a powerset over some fresh type variable
. For set
intersection and union, both operands must denote sets of types which can be unified. For
the set complement, the operand must be a set.
The meaning of the empty set is a total characteristic function which constantly yields
false. The meaning of set intersection, set union, and set complement has been already
discussed in Section 3.2.1 (on page 43). Here, we take care for the encoding details.
Set Translation
The translation of a set, e
Ã
p
l}ÒÓ
p
BÅ
, describes the set of values from ewhich are trans-
formed by the pattern p
l
to p
. The definitions are given in Figure 3.16 (on the next
page).
The patterns must be typeable under a shared environment, and must be linear. The
type of emust be unifiable with the type of p
l
; the resulting type is the substitution of the
unifier in the type of p
.
54 The
ZCalculus
EXPUT
v
ndnSnhj
Ã
ÒÓ Å
of
EXPUT
PATUT
PATUT
)ÔÕ
p
l2SSld
}ÔÖ
p
Sd
p
lØ×
PATLIN
p
Ù×
PATLIN
R
e
(
Sl
R
e
Ã
p
lAÒÓ
p
ÚÅW³jwf'w(|hU
o
c
e
TYPASS
e
EXPUT
p
c
p
PATUT
bBc b
c b
TYPE
TSUBS
ÛÜ
Ý
}
~
u
l
UNIV
p
lUm
p
PAT
u
UNIV
ÞÕ|
TSUBS
ß¾Hà
UNIASS
±
u
lÕ×"w¢y{¨jwf'w(|Ïj:s:¯'°Dy
p
l
oÚo
Ä
u
Õ×@w¢y{j:w^'w(|ÏjOs¯'°Ey
p
oÚo
Ä
p
l2áDâ
u
lGÄ
p
Aá'â
u
d
sÇÆ
¬
p
lUm
p
PAT
±
¬
u
UNIV
±
~
u
Ô
UNIV
up
ÛÜ
p
Ý
u
Ô
wzy{;§¨j
e
Ã
p
lAÒÓ
p
ÚÅ
o%©
·O¸'¹
f
}¨º'«
jwzy{-§
e
o
D
l
w¢y{j:w^'wW§,n®'jOs¯'°Ey
p
l
oÚo
D
w¢y{j:w^'wW§,n®'jOs¯'°Ey
p
oÚo»±
ª'«
jÚj=¬
u
äã
jOsÇÆfj
p
lAÒÓ
p
oUÁ
¼'½»{
f
Â
o+±9å
j
f
Á
sÇÆÇj
p
ÖÒÓ
p
l
o
u
Â
oÚo
j=¬
u
D
çæ
ã
j:sÇÆÇj
p
lÒÓ
p
oUÁ
D
lBÂ
o,±²:´'µ
wzy
oÚo
ÍÏÎ
¸¶Ð¸
§
SEMCTX
e
EXP
p
ldm
p
PAT
Figure 3.16: Syntax and Meaning: Set Translation
For the specification of the meaning of translation, we define an auxiliary relation,
u
l
p
ÛÜ
p
Ý
u
, which relates values which are translated by two patterns. The relation is
described polymorphically, by relating all those values u
lUm
u
which are in an instance of
the pattern’s types under a common ground type substitution
|
and which can be matched
by the patterns using the same value assignment
à
. The auxiliary function
sÇÆ
yields the
set of values which are reached under the translation by a pattern pair.
For the meaning of translation, two cases have to be distinguished: those elements
which are defined in the characteristic function denoted by the set eand which are reached
by p
lÙÒÓ
p
, are in the domain of the resulting characteristic function; their membership
is derived by Boolean disjunction of their image under the reverse of pattern translation.
Those values which can not be reached by the translation are defined to be constantly not
members of the set. This definition reflects that a translation may “filter out” undefined
elements of the translated set. Consider for example a set over lists where the membership
of the empty list, denoted by the constructor nil, is unknown, whereas the membership of
all elements denoted by the constructor cons
j
X
m
XS
o
is known. Translating such a set
by cons
j
X
m
XS
o
ÒÓ
cons
j
X
m
XS
o
results in a set of which nil cannot be member. This is
reflected by the second
¬
in Figure 3.16. The example also shows that a translation by
identical patterns does not necessarily yield an identical set value.
Schema, Fixed-Point, and Variable
A schema is denoted by the expression
~
p
e
, where pis a pattern, and ean expression
of type
è
. A fixed-point is denoted by
é%ê
p
ë
e. A variable application is written as x.
The definitions are given in Figure 3.17 (on the next page).
3.3 Expression Syntax and Meaning 55
EXPUT
v
ndnSnhjz~
o^
PATUT
EXPUT
äj:é%ê ë
o^
PATUT
EXPUT
j
of
VAR
¼'½»{
Ô
¨ì´
Æíw
p
p
×
PATLIN
Ô
p
S(
¨îï
Ô
e
dè
~
p
e
}5
c
e
TYPASS
p
PATUT
e
EXPUT
b
TYPE
x
×9¼'½{
R
x
x
(
TYPASS
x
VAR
¼'½{
}Ô
ì´
Æíw
p
p
×
PATLIN
PATEX
ØÆ
´
u
}ÔÑð
Æ
´
uñ
Ô
p
Sl^
îò Ô
e
SU2l
U
R
éçê
p
ë
e
w^'w|}Sl
c
e
TYPASS
TSUBS
p
PATUT
e
EXPUT
b
c b
TYPE
wzy{;§¨jx~
p
e
o4©
ª'«
~
u
wzy{jwf'w(§,n®'j:s:¯'°Dy
p
o¢o
f
UNIV
ó èA+à
UNIASS
p
á
â
u
ô
ª'«
f
wzy{õj§,n®DmB§,nvö
î
à
o
e
Ä
ª'«
f
÷
'u¼'y
²¾±
u
ÒÓ
Ã
p
á
â
u
Ä
f
søsxÅ
jOéçê
p
ë
e
o%©_·O¸¶¹
wf'wW§,n®Dj:s:¯'°Dy
p
o
f
˺'«
jwzy{Y§+~
p
p
e
o»±
·O¸¶¹
cands
j
f
À
oUÁ
~sÇÆÈyÂ
±
ùOú}û
cands
×
cands
¹
Î
¸äü
û
cands
¸¶·ýU¸
'u¼'y
²
j
x
o ©
§,nvö
x
ÍÏÎ
¸¶Ð¸
§
SEMCTX
p
PAT
e
EXP
x
VAR
Figure 3.17: Syntax and Meaning: Schema, Fixed-Point, and Variable
The pattern of a schema must be typed under a minimal type assignment, and must be
linear. The property must be typed as a Boolean under an extension of the environment
by the type assignment used for the pattern, where variables of the pattern hide variables
in the environment. The resulting type of the schema is a powerset of the pattern’s type.
The pattern of a fixed-point must be typed under a minimal type assignment, must be
linear, and must be exhaustive. Each variable in the pattern must have a set type. The
definition must be typed under an extension of the environment by the type assignment
for the pattern, where variables from the pattern hide variables in the environment, and
must unify with the pattern’s type. The resulting type is this unified type.
The meaning is defined as follows. For schemas, a characteristic function is con-
structed, the domain of which are the elements from the schema’s pattern type such that,
if they match the pattern, then the property evaluates to a defined Boolean value under the
bindings resulted by this match. The schema’s characteristic function yields true for an
element if the pattern has matched and the properties Boolean value is true.
For the fixed-point, we use the meaning of
~
p
p
e
to construct the set of can-
didates. By the typing conditions we know that the variables in prepresent sets, and the
domain of p’s type is ordered by
þ
. Thus, if the infimum of the candidate set is a
candidate, we select it, otherwise
'u¼'y
²
is delivered. A sufficient condition for existence
of the fixed-point is that eis order-preserving, see Section 2.3.4 (on page 33).
56 The
ZCalculus
ÿ
}
}
5
m
EXPUT
EXPUT
e
e
Ã
x
ÒÓ
Å
e
e
ÍÏÎ
¸'и
e
EXPUT
x
VAR
× m
EXPUT
EXPUT
EXPUT
e
×
e
Ô
jz~
e
H
e
Ô
o
e
e
Ô
e
×F~
e
Ô
ÍÏÎ
¸'и
e
m
e
Ô
EXPUT
m
EXPUT
EXPUT
¬
e
l
EXPUT
±
ùOú
e
q
¹
Î
¸¶ü
¸¶·:ýd¸
ùOú
e
®
¹
Î
¸¶ü
heade
¸¶·:ýd¸
head e
j
taile
o
¬
e
l
EXPUT
±
ùOú
e
q
¹
Î
¸¶ü
ÿ
¸¶·:ýd¸
ùOú
e
®
¹
Î
¸¶ü
heade
¸¶·:ýd¸
head e
j
taile
o
Figure 3.18: Expression Abbreviation Forms
3.3.5 Expression Abbreviation Forms
We have already mentioned several syntactic abbreviations for frequent patterns of
Z
expressions. The abbreviations are specified in Figure 3.18 as constants and injective
functions which map into expressions. The functions work on untyped syntax; the typing
conditions are inherited from the basic forms they map to.
The following explanations about the definitions. The universal set,
ÿ
, is the comple-
ment of the empty set. The undefined value,
, is the singleton selection on the empty
set. The Boolean expression
e, which tests whether the given set is non-empty, is an
abbreviation for a translation to the Boolean unit,
. The complementary form
etests
whether the given set is empty. The Boolean membership, e
×
e
Ô
, is mapped to an in-
tersection of a singleton set containing the element with the set to test membership in,
and a subsequent test for emptiness of the result. The equality, e
e
Ô
, is derived from
membership in a singleton set.
In order to work with sequences of unions and intersections, two further abbreviations
are introduced:
edescribes the generalized union, and
ethe generalized intersection
of the sequence of expressions e. For empty expression sequences, the according neutral
element (
resp.
ÿ
) is denoted.
3.4 Equational Theory 57
ì´
Æíw
EXP
VAR
EXPASS
VAR
ó
EXP
ñj
PAT
EXPASS
PAT
o
w^'w
EXPASS
EXP
ó
EXP
{
Uwf'w
PAT
EXP
EXPASS
{
Uwf'w
¬
p
PAT
e
EXP
±
¬
x
Dì´
ÆMw
p
±
³jz~
e
Ã
p
ÒÓ
x
Å
o
PATCTX
PAT
PAT
EXPCTX
EXP
EXP
ì´
Æí½'ÆM¼'yÆ
VAR
VAR
Figure 3.19: Syntactic Tools
3.4 Equational Theory
An equational theory for
Zwill be developed in this section. The laws will be shown to
be consistent with the model of
Zdeveloped in the previous section.
3.4.1 Syntactic Tools
For defining the equivalences, some syntactic tools for working with expressions are re-
quired (Figure 3.19). The variables which occur free in an expression (are not bound
by some schema’s pattern) are delivered with
ì´
Æíw
e. Two patterns are unified using the
notation p
l
p
determining the smallest assignment
×
EXPASS
VAR
ó
EXP
which makes them equal. An expression assignment can be substituted in an expres-
sion by
w^'w
!
e. Substitution is partial because of typing conditions for the substituted
expressions. These fairly standard concepts are not formalized.
Given a pattern pand an expression e, we build a substitution of the variables in the
pattern by sub-components of the expression with
{
Uwf'w¾j
p
m
e
o
. Variables xare substi-
tuted by a “selection” from the expression eexpressed via a translation. Note that the
meaning of this selection may be undefined (
'u¼'y
²
), in case the pattern pdoes not match
the value of e.
A pattern context,
"
×
PATCTX, is a “pattern with a hole”. It is described by an in-
jective function from a pattern to a pattern. Similar, an expression context
#
õ×
EXPCTX
is defined. The context functions are partial because of typing conditions.
For variables a total order is assumed, such that we can convert a finite set of variables
into a sequence of variables by the function
ì´
ÆM½¶ÆM¼'yÆ
.
3.4.2 Equivalence Relation
The equivalences are described by a relation over well-typed expressions of the same
type. This relation has the equivalence properties and is a congruence (is closed under
contexts). The declarations are given in Figure 3.20. The equivalence relation will be
incrementally refined below:
$
is supposed to be the smallest relation satisfying the
laws in Figure 3.20 and the laws added later on.
58 The
ZCalculus
$
ñ~
e
m
e
Ô
EXP
s¯'°Ey
e
s¯'°Ey
e
Ô
e
$
e
e
$
e
Ô
ô
e
Ô
$
e
e
$
e
Ô
Ä
e
Ô
$
e
Ô Ô
ô
e
$
e
Ô Ô
e
$
e
Ô
ÄF~
e
m
e
Ô
ð
¼'½{
%#
ô
&#
e
$#
e
Ô
ÍÏÎ
¸¶Ð¸
e
m
e
Ô
m
e
Ô Ô
EXP
'#
EXPCTX
Figure 3.20: Equivalence Relation: Declaration
e
e
Ô
$
e
Ô
e
e
Éj
e
Ô
e
Ô Ô
o
$
j
e
e
Ô
o
e
Ô Ô
e
$
e
e
$
e
e
Éj
e
Ô
e
Ô Ô
o
$
j
e
e
Ô
o
@j
e
e
Ô Ô
o
ÍÏÎ
¸¶Ð¸
e
m
e
Ô
m
e
Ô Ô
EXP
e
e
Ô
$
e
Ô
e
e
Éj
e
Ô
e
Ô Ô
o
$
j
e
e
Ô
o
e
Ô Ô
e
ÿ
$
ÿ
e
e
$
e
e
Éj
e
Ô
e
Ô Ô
o
$
j
e
e
Ô
o
Éj
e
e
Ô Ô
o
ÍÏÎ
¸'и
e
m
e
Ô
m
e
Ô Ô
EXP
j
e
e
Ô
o
$
e
>
e
Ô
j
e
e
Ô
o
$
e
>
e
Ô
$
ÿ
jÈ
e
o
$
e
ÍÏÎ
¸¶Ð¸
e
m
e
Ô
m
e
Ô Ô
EXP
Figure 3.21: Boolean Laws
3.4.3 Boolean Laws
The set operations follow almost all of the usual laws for Boolean algebras. Commu-
tativity and distributivity of union and intersection hold, and De Morgan’s laws are sat-
isfied, such that we can build a conjunctive or disjunctive normal form of expressions
(Figure 3.21).
However, the “principle of the excluded middle” does not hold: e
>
e
$
is not
valid for arbitrary e, as well as e
e
$
ÿ
. The reason for this is the partiality of sets:
if econtains unknowns, then in the complement of ethese unknowns keep unknown, and
therefore do not absorb each other. As a consequence, the implication e
ô
e, interpreted
as the usual abbreviation for
j
e
e
o
>
e, does not equal to
ÿ
.
Proof
.We prove one of the distributivity laws and one of the De Morgan laws.
±
Let f
l
,f
,f
(
be characteristic functions. We want to show (ignoring encoding de-
tails) that the pair u
ÒÓ
bis in the characteristic function h
l
f
lkVj
f
f
(
o
iff it is
in the function h
j
f
lk
f
o
Vj
f
lÑ
f
(
o
:
Case u
ÒÓ sÇÆÈy
:According to definition of union and intersection, u
ÒÓ sÇÆÈyÏ×
h
l
iff u
ÒÓ sÇÆy×
f
l+Ä>j
u
ÒÓ sÇÆÈy ×
f
,Ê
u
ÒÓ sÇÆy×
f
(
o
. This is equivalent to
j
u
ÒÓ sÇÆy×
f
lÖÄ
u
ÒÓ sÇÆÈy$×
f
o
ʨj
u
ÒÓ sÇÆÈy×
f
lHÄ
u
ÒÓ sÇÆy×
f
(
o
, which
in turn holds iff u
ÒÓ sÇÆÈy}×
h
.
3.4 Equational Theory 59
~
e
G>~
e
)$
~
e
G>~
e
)$
ÿ
ÍÏÎ
¸¶Ð¸
e
EXP
Figure 3.22: Excluded Middle Laws
~
e
)$
e
ÍÏÎ
¸¶Ð¸
e
EXP
Figure 3.23: Selection Elimination Law
Case u
ÒÓ
²:´¶µ
w¢y
:Then we have u
ÒÓ
²:´'µ
wzyÏ×
h
l
iff u
ÒÓ
²:´¶µ
w¢y ×
f
lÊj
u
ÒÓ
²:´¶µ
w¢y ×
f
Ä
u
ÒÓ
²:´'µ
wzy³×
f
(
o
. This is equivalent to
j
u
ÒÓ
²:´'µ
wzy³×
f
lÊ
u
ÒÓ
²:´¶µ
w¢yX×
f
o
Äïj
u
ÒÓ
²:´¶µ
w¢y×
f
lGÊ
u
ÒÓ
²:´¶µ
w¢y×
f
(
o
, which holds iff u
ÒÓ
²:´'µ
wzy×
h
.
±
Let f
l
and f
be characteristic functions. We show that the pair u
ÒÓ
bis in the
characteristic function h
l
j
f
l
f
o
iff it is in the function h
f
l >
f
.
We thereby use the following fact: let g
Ô
g, then it follows from the definition
of complement: u
ÒÓ
b
×
g
Ô
iff u
ÒÓ Ì
b
×
g, where
Ì
bis (Z-level) negation of
the Boolean value b. (Note the difference to the (wrong) assertion, u
ÒÓ
b
×
g
Ô
+*
Ìïj
u
ÒÓ
b
×
g
o
.)
Case u
ÒÓ sÇÆÈy
:We have u
ÒÓ sÇÆÈy ×
h
l
iff u
ÒÓ
²:´'µ
wzy ×j
f
lÑ
f
o
, iff u
ÒÓ
²:´¶µ
w¢y ×
f
lÕÊ
u
ÒÓ
²:´'µ
wzy5×
f
, iff u
ÒÓ sÇÆy ×Y
f
lÙÊ
u
ÒÓ sÇÆÈy ×Y
f
, iff u
ÒÓ sÇÆÈy ×
h
.
Case u
ÒÓ
²:´¶µ
w¢y
:We have u
ÒÓ
²:´'µ
wzy ×
h
l
iff u
ÒÓ sÇÆÈyÏ×j
f
l
f
o
, iff u
ÒÓ sÇÆÈy ×
f
lÖÄ
u
ÒÓ sÇÆÈy×
f
, iff u
ÒÓ
²:´'µ
wzy×.
f
lØÄ
u
ÒÓ
²:´¶µ
w¢y×-
f
, iff u
ÒÓ
²:´'µ
wzy×
h
.
,
3.4.4 Singleton Set Laws
Excluded Middle
For singleton sets the “excluded middle” holds (Figure 3.22). One can easily see the
validity by considering the characteristic function constructed for a singleton set: it is
total and true exactly for the element e. The complement yields a total characteristic
function which is true for all elements except e.
Selection Elimination
Singleton set selection on a singleton set construction reduces to the singleton sets mem-
ber (Figure 3.23). The validity can be easily seen from the representation of singleton sets
and the meaning of the
-operator.
60 The
ZCalculus
~ikj
e
o
)$
jÚj=¬
i
-
±
~
ei
Ã
j
xi
o
ÒÓ ikj¢j
o
/.
x
o
Å
o
/.
jxt ¼kj¢®ÕnSn
e
oÚo¢o
~ih
$
~
0
W
Ã
ÒÓ_i»Å
ÍÏÎ
¸¶Ð¸
i
CONS
e
EXP
x
VAR
e
x
1
òq
Figure 3.24: Constructor Decomposition Laws
e
Ã
p
lGÒÓ
p
ÚÅ
Ã
p
(
ØÒÓ
p
2
BÅ
3$
e
Ã
wf'w
!
p
lAÒÓ wf'w
p
2
ÇÅ m
ùOú
p
p
(
e
Ã
p
lGÒÓ
p
ÚÅ
Ã
p
(
ØÒÓ
p
2
BÅ
3$
m
ùOú
Ì
p
p
(
e
Ã
p
Ô
ÒÓ
p
Ô
Å
$
e
ÍÏÎ
¸¶Ð¸
e
EXP
p
ldm
p
Um
p
(
Sm
p
2
PAT
p
Ô
PATEX
'
EXPASS
Figure 3.25: Translation Composition and Identity Laws
Constructor Decomposition
A singleton set containing a constructor application with arity greater zero can be decom-
posed into an intersection of projections. A singleton set containing a zero-arity construc-
tor equals to a translation of a truth value (Figure 3.24). The first law is formulated in
“
nSnSn
” notation as follows:
~ikj
e
ldmSnSndnWm
en
o
4$
~
e
l^
Ã
x
lGÒÓ ikj
x
ldmSnSndn(m
o
Å' nSnSnB@~
en
Ã
xn
ÒÓ_ikj mSnSnSnWm
xn
o
Å
It holds since the translation
~
ei
Ã
xi
ÒÓ_ikj¢nSndnWm
xi
mdnSnSn
o
Å
yields the set ofall values
ikjznSnSnWm
ei
mSnSndn
o
,
where the ith argument is fixed by eiand all other are arbitrary. Intersecting the sets re-
sulting from such a translation for each argument of the constructor must thus yield in
~ikj
e
ldmSnSndn(m
en
o
. Thereby, definedness of eiis not significant, since constructors and sin-
gleton sets are not strict.
3.4.5 Translation Laws
Composition and Identity
Consecutive translations are composable, if the intermediate patterns can be unified. If
they cannot be unified, consecutive translation reduces to the empty set. A translation by
an exhaustive pattern has no effect (Figure 3.25).
Proof
.We prove composition of consecutive translation. We want to show that the
pair u
ÒÓ
bis in the characteristic function h
l
f
Ã
p
l5ÒÓ
p
ÚÅ
Ã
p
(
ÒÓ
p
2
BÅ
iff there exists
an assignment
such that p
p
(
and u
ÒÓ
bis in the characteristic function h
f
Ã
wf'w
p
lGÒÓ w^'w
p
2
ÇÅ
.
Case u
ÒÓ sÇÆy
:When u
ÒÓ sÇÆy×
h
l
, according to definition of translation there exist
value assignments
à mfà
Ô
, and values u
Ô
m
u
Ô Ô
, such that p
2
á
â
u,p
(
á
â
u
Ô
,p
Ïá
â
e
u
Ô
,
and p
lØá
â
e
u
Ô Ô
. Since p
(
and p
match the same value u
Ô
, there must exists a small-
est pattern assignment
such that p
p
(
, and
jwf'w
!
p
o
á
â
e e
u
Ô
as well as
jwf'w
p
(
o
á
â
e e e
u
Ô
. The assignment
specializes the patterns compatible to the
value u
Ô
, and hence we also have
jwf'w
!
p
l
o
á
â
e e
u
Ô Ô
and
j:w^'w
p
2
o
á
â
e e e
u, and
therefore u
ÒÓ sÇÆÈy}×
h
.
3.4 Equational Theory 61
j
e
e
Ô
ofÃ
p
lAÒÓ
p
BÅ
5$
e
Ã
p
lGÒÓ
p
ÚÅ'
e
Ô
Ã
p
lAÒÓ
p
ÚÅ
j
e
e
Ô
ofÃ
p
lAÒÓ
p
BÅ
5$
e
Ã
p
lGÒÓ
p
ÚÅ'
e
Ô
Ã
p
lAÒÓ
p
ÚÅ>m
ùOú
ì´
ÆMw
p
l
ð
ì´
Æíw
p
j=
e
o^Ã
p
lAÒÓ
p
ÚÅ
$
j
e
Ã
p
lGÒÓ
p
ÚÅ
o
m
ùOú
ì´
ÆMw
p
l
ð
ì´
Æíw
p
ÖÄ
p
lØ×
PATEX
Ä
p
×
PATEX
ÍÏÎ
¸¶Ð¸
e
m
e
Ô
EXP
p
lUm
p
PAT
Figure 3.26: Translation Distributivity Laws
Case u
ÒÓ
²:´'µ
wzy
:Similar argumentation as above, but with negated propositions.
,
Distributivity over Set-Operators
Any translation distributes over set union. A translation by an embedding distributes
over set intersection. An embedding distributes over set complement if it is exhaustive
(Figure 3.26).
An analogy to predicate logic givesan intuition whyhiding translations (where
ì´
ÆMw
p
l
76
ì´
Æíw
p
) do not distribute over intersection. Hiding in
Zcan be interpreted as an existen-
tial quantifier. In predicate calculus, the following holds:
Þ
x
±
P
Ê
Qiff
j=Þ
x
±
P
o
Ê
jÈÞ
x
±
Q
o
. However, it does not hold
Þ
x
±
P
Ä
Qiff
jÈÞ
x
±
P
o
ÄòjÈÞ
x
±
Q
o
, since in the
later case Pand Qmust be satisfied simultaneously for the same x.
Proof
.We prove distributivity of any translation over union and of embedding transla-
tions over intersection, using the auxiliary relation vp
ÛÜ
p
Ý
u(Section 3.3.4 (on page 54)).
±
We prove that u
ÒÓ
bis in h
l
j
f
f
Ô
o^Ã
p
lYÒÓ
p
BÅ
iff it is in h
f
Ã
p
l;ÒÓ
p
ÚŶ
f
8
p
l
p
.
Case u
ÒÓ sÇÆÈy
:We have u
ÒÓ sÇÆÈy×
h
l
iff
Þ
v
UNIV
±
vp
ÛÜ
p
Ý
u
±
v
ÒÓ_sÇÆÈy×
j
f
f
Ô
o
iff
Þ
v
UNIV
vp
ÛÜ
p
Ý
u
±
v
ÒÓ sÇÆÈy.×
f
Ê
v
ÒÓ sÇÆy.×
f
Ô
iff
j=Þ
v
UNIV
±
vp
ÛÜ
p
Ý
u
±
v
ÒÓ sÇÆÈy}×
f
o
Êòj=Þ
v
UNIV
±
vp
ÛÜ
p
Ý
u
±
v
ÒÓ
sÇÆÈy×
f
Ô
o
iff u
ÒÓ sÇÆÈy×
h
.
Case u
ÒÓ
²:´¶µ
w¢y
:similar.
±
We prove that u
ÒÓ
bis in h
l
j
f
f
Ô
o^Ã
p
lYÒÓ
p
BÅ
iff it is in h
f
Ã
p
l;ÒÓ
p
ÚŶ
f
Ã
p
lHÒÓ
p
ÚÅ
, where
ì´
ÆMw
p
l
ð
ì´
Æíw
p
. Thereby the following property is used:
if
ì´
ÆMw
p
l
ð
ì´
Æíw
p
, then for a given uthere exists not more then one vin the same
type such that vp
ÛÜ
p
Ý
u. This follows from the fact that all variables in p
l
are
bound by a match of p
against u.
Case u
ÒÓ sÇÆÈy
:We have u
ÒÓ_sÇÆÈy×
h
l
iff
Þ
l
v
UNIV
vp
ÛÜ
p
Ý
u
±
v
ÒÓ sÇÆÈy}×
f
Ä
v
ÒÓ sÇÆy×
f
Ô
iff
j=Þ
l
v
UNIV
±
vp
ÛÜ
p
Ý
u
±
v
ÒÓ sÇÆÈy6×
f
o
Ä j=Þ
l
v
UNIV
±
vp
ÛÜ
p
Ý
u
±
v
ÒÓ sÇÆy ×
f
Ô
o
iff u
ÒÓ sÇÆy ×
h
. Since of the unique
existential quantifier, the conjunction could have been pulled out.
62 The
ZCalculus
j
e
Ã
p
lAÒÓ
p
¢Å¶
e
Ô
Ã
p
Ô
l
ÒÓ
p
Ô
Å
o^Ã
p
(
ØÒÓ
p
2
BÅ
9$
e
Ã
p
lGÒÓ
p
ÚÅ
Ã
p
(
HÒÓ
p
2
ÇŶ
e
Ô
Ã
p
Ô
l
ÒÓ
p
Ô
Å
Ã
p
(
HÒÓ
p
2
ÇÅ
ÍÏÎ
¸¶Ð¸
e
m
e
Ô
EXP
p
lUm
p
Sm
p
Ô
l
m
p
Ô
m
p
(
dm
p
2
PAT
'
EXPASS
p
p
Ô
ì´
Æíw jwf'w
p
l
o
ì´
Æíwñj:w^'w
p
Ô
l
o
;:
Figure 3.27: Translation Product Law
Case u
ÒÓ
²:´¶µ
w¢y
:similar.
,
Distributivity of Hiding over Product
A hiding applied to a product can be distributed. A product is an intersection of translated
sets which are independent (Figure 3.27). The independence of the operands is checked
by unifying their target translation patterns, und stating that the source patterns under the
resulting substitution have disjoint variables.
A formal proof is omitted, but an analogy to predicate calculus can serve as an intu-
ition for the validity of the law. In predicate calculus the following holds:
Þ
x
m
y
±
Px
Ê
Qy
*
j=Þ
x
m
y
±
Px
o
Ê j=Þ
x
m
y
±
Qy
o
, provided that yis not free in Px and xis not free in
Qy. A similar situation is described here.
The product law, in combination with the constructor decomposition law (Figure 3.24
(on page 60)), provides a generalization of decomposition in unification. Consider an
equality such as
ikj
a
m
b
oH
ikj
c
m
d
o
. Removing the syntactic sugar yields in
jz~ikj
a
m
b
o
G@~ikj
c
m
d
o
ofÃ
x
ÒÓ
&
¶Å
Applying the constructor decomposition law yields:
jz~
a
Ã
x
ÒÓ ikj
x
m
y
o
Åä9~
b
Ã
y
ÒÓ ikj
x
m
y
o
Å'
~
c
Ã
x
ÒÓ ikj
x
m
y
o
Åä9~
d
Ã
y
ÒÓ ikj
x
m
y
o
Å
o Ã
x
ÒÓ
¶Å
Next we apply associativity of intersection and distributivity of embeddings to get
jÚjx~
a
G@~
c
o^Ã
x
ÒÓ_ikj
x
m
y
o
ŶÉjx~
b
G@~
d
o^Ã
y
ÒÓ ikj
x
m
y
o
Å
ofÃ
x
ÒÓ
&
¶Å
Now, since the outer intersection is a product, we can apply the distributivityof the hiding
x
ÒÓ
. The resulting consecutive translations are immediately contracted such that we
finally get:
jz~
a
G9~
c
ofÃ
x
ÒÓ
&
¶ÅE7jx~
b
G@~
d
o^Ã
y
ÒÓ
&
¶Å
Folding the syntactic sugar for equality, we reach at a
c
b
d.
Lifting of Hiding
A hiding as an operand of an intersection can be lifted out of the intersection (Figure 3.28
(on the next page)). The hidden part is introduced by an embedding for the right operand,
3.4 Equational Theory 63
e
Ã
p
lGÒÓ
p
ÚÅ'
e
Ô
$
j
e
e
Ô
Ã
p
HÒÓ
p
l¢Å
ofÃ
p
lAÒÓ
p
ÚÅ>m
ùOú
ì´
ÆMw
p
=<
ì´
Æíw
p
l
ÍÏÎ
¸¶Ð¸
e
m
e
Ô
EXP
p
lUm
p
PAT
Figure 3.28: Translation Lifting Law
e
Ã
p
lGÒÓ
p
ÚÅ
3$
e
Ã
p
lHÒÓ j j
o
/.
x
o
Å
Ã
j j
o
>.
x
o
ÒÓ
p
ÚÅ
ÍÏÎ
¸¶Ð¸
e
EXP
p
ldm
p
PAT
x
?@
VAR
Ì
ì´
ÆMw
p
l
ð
ì´
Æíw
p
GÌ
ì´
Æíw
p
ð
ì´
ÆMw
p
lUØÆ
´
u
x
ì´
Æíw
p
lç
ì´
Æíw
p
Figure 3.29: Translation Splitting Law
e
Ô
, by just reverting the translation. On the intersection, the hiding is then performed
again.
We do not provide a formal proof, but just point to an analogy in predicate calculus.
jÈÞ
x
±
Px
o
Ä
Qis equivalent to
Þ
x
±
Px
Ä
Q, provided xis not free in Q. Lifting of
hiding is a generalization of this.
Splitting into Embedding and Hiding
A translation which is neither hiding nor embedding can be splitted into an embedding
and a consecutive hiding (Figure 3.29). The correctness of this law follows directly from
the law of composition of translations (Figure 3.25 (on page 60)): unifying
j
x
o
against
itself yield in an empty assignment, henceforth applying the composition law of transla-
tion yields in e
Ã
wf'w
:
p
lÙÒÓ wf'w
:
p
¢Å
, which equals to the left hand side expression in
Figure 3.29.
It should be noted that since embeddings can be distributed and hidings can be lifted
out of intersections, meanwhile other translations can be decomposed into embeddings
and hidings, it is possible to normalize expressions such that embeddings are pushed to
the leafs and hidings are pulled to the top of intersections.
Intersection Elimination
Two translated sets in intersection, with target patterns which cannot be unified, reduce to
the empty set (Figure 3.30).
Note that in combination with the constructor decomposition law (Figure 3.24 (on
page 60)) this law leads to the reduction of intersections
~ikj
e
o
G@~i
Ô
j
e
Ô
o
, with
i;÷
i
Ô
,
to the empty set.
e
Ã
p
lGÒÓ
p
ÚÅ'
e
Ô
Ã
p
Ô
l
ÒÓ
p
Ô
Å
3$
m
ùOú
Ì
p
p
Ô
ÍÏÎ
¸¶Ð¸
e
m
e
Ô
EXP
p
lUm
p
Sm
p
Ô
l
m
p
Ô
PAT
'
EXPASS
Figure 3.30: Translation Intersection Elimination Law
64 The
ZCalculus
~
p
Ñ
$
~
p
ÿ
$
ÿ
Ã
p
ÒÓ
p
Å
~
p
e
e
Ô
)$
~
p
e
H9~
p
e
Ô
~
p
e
e
Ô
)$
~
p
e
H9~
p
e
Ô
~
p
e
$
j=Ë~
p
e
ofÃ
p
ÒÓ
p
Å
ÍÏÎ
¸¶Ð¸
e
m
e
Ô
EXP
p
PAT
Figure 3.31: Schema Elimination and Distributivity Laws
3.4.6 Schema Laws
Elimination and Distributivity
A schema with a false property can be reduced to the empty set, one with a true prop-
erty to a translated universal set preserving the pattern (this is necessary for the case the
pattern is not exhaustive). Schema construction distributes over set union, intersection,
and complement (Figure 3.31). The distributivity over complement requires a translation
of the resulting set with p
ÒÓ
pfor the case that pis not exhaustive. In this case, the
negated schema denotes also those values which do not fit to p. These are filtered out by
the translation.
Proof
.We prove one of the distributivity laws. In order to represent the property eof
a schema,
~
p
e
, functions F
×
UNIASS
wzy{
BADC
ó è
are used: F
à
yields the
characteristic Boolean-valued function of a property in dependency of a value assignment
à
.We want to show that the pair u
ÒÓ
bis in the characteristic function h
l
~
p
F
lk
F
S
iff it is in the function h
~
p
F
l^H9~
p
F
d
. Suppose there is not match
p
á
â
u. Then obviously u
ÒÓ
²:´'µ
wzy}×
h
l
iff u
ÒÓ
²:´¶µ
w¢y}×
h
. Suppose there is a match, and
let it be
à
:
Case u
ÒÓ sÇÆy
:We have u
ÒÓ sÇÆyX×
h
l
iff
"ÒÓ sÇÆy³×>j
F
lÙàG
F
)à
o
(where
repre-
sents the constructor of the unit value), iff
ÒÓ sÇÆÈy}×
F
lÙàÊ
E
ÒÓ sÇÆÈy×
F
,à
, iff
u
ÒÓ_sÇÆÈy×
h
.
Case u
ÒÓ
²:´'µ
wzy
:dual.
The proof for intersection is similar.
,
Complement Lifting
We have described how schema distributes over complement. The opposite of this law is
given in Figure 3.32 (on the facing page). The operand
j
ÿ
Ã
p
ÒÓ
p
Å
o
adds those values
which are in the result set since they do not match the pattern p. For exhaustive patterns
it reduces to
, since a translation by the same exhaustive pattern can be eliminated.
3.4 Equational Theory 65
¨~
p
e
F$
~
p
e
H>Ëj
ÿ
Ã
p
ÒÓ
p
Å
o
ÍÏÎ
¸¶Ð¸
e
EXP
p
PAT
Figure 3.32: Schema Complement Lifting Law
~
p
e
Ã
p
lGÒÓ
p
ÚÅ
5$
m
ù:ú
Ì
p
p
l
~
p
e
Ã
p
lGÒÓ
p
ÚÅ
5$
~wf'w
p
w^'w
!
e
Rm
ù:ú
p
p
lGÄ
ì´
Æíw
p
l
ð
ì´
ÆMw
p
ÍÏÎ
¸¶Ð¸
e
EXP
p
m
p
l^m
p
PAT
'
EXPASS
Figure 3.33: Schema Translation Elimination Laws
Translation Elimination
Any translation of a schema where the schema’s pattern and the translation’s source pat-
tern cannot be unified reduces to the empty set. An embedding translation on a schema
can be eliminated (Figure 3.33).
Membership Lifting
A schema which contains a membership-test, p
×
e, where pis linear and contains only
variables from the schema’s pattern, can be eliminated provided the expression edoes not
contain variables dependent on the schema’s pattern (Figure 3.34).
Note that membership lifting also captures equality:
~
x
x
e
is an abbreviation
for
~
x
x
×ï~
e
, which eventually reduces to
~
e
provided xis not free in e.
Property Substitution
A schema intersected with a translated singleton set is equivalent to an expression where
the singleton set’s element is “imported” by substitution into the schema’s property (Fig-
ure 3.35 (on the next page)). Since we can always add the identity translation, x
ÒÓ
x,
the law captures also the case where no real translation of the singleton set is involved.
Since other laws have ensured that embedding translations applied to schemas can be
eliminated, and hiding translations can be lifted out of intersections, we do not need to
consider the case of the translation of the schema itself.
Proof (informal)
. Recall that
{
Uw^'w¾j
p
m
e
o
is defined as
¬
p
PAT
e
EXP
±
¬
x
Eì´
Æíw
p
±
Xjz~
e
Ã
p
ÒÓ
x
Å
o
n
~
p
p
Ô
×
e
G$
e
Ã
p
Ô
ÒÓ
p
Å
ÍÏÎ
¸¶Ð¸
e
EXP
p
m
p
Ô
PAT
p
Ô
×
PATLIN
ì´
ÆMw
p
ÔÑð
ì´
ÆMw
p
ì´
Æíw
e
ì´
Æíw
p
H:
Figure 3.34: Schema Membership Lifting Law
66 The
ZCalculus
~
p
e
H@~
e
Ô
Ã
p
lGÒÓ
p
ÚÅ
I$
~wf'w
p
wf'wñjx{
Uw^'w¾j:w^'w
p
l^m
e
Ô
o¢o
e
GV~
e
Ô
Ã
p
lGÒÓ
p
ÚÅ
ÍÏÎ
¸¶Ð¸
e
m
e
Ô
EXP
p
m
p
l^m
p
PAT
J
EXPASS
p
K
p
Figure 3.35: Schema Property Substitution Law
é%ê
p
ë
e
$
wf'wñjz{
L
Uw^'w¾j
p
mÚéçê
p
ë
e
oÚo
e
ÍÏÎ
¸¶Ð¸
p
PAT
e
EXP
M
§
SEMCTX
éçê
p
ë
e
×9¼'½{j:w¢y{Y§
o»±
Þ
l
D
wzy{¨j:w^'wh§,n®AjOs¯'°Ey
p
oÚo»±
jȬ
u
D
±É·O¸'¹
à
UNIASS
p
á
â
u
±
wzy{¨j§,n®DmB§,nvö
î
à
o
e
o
×
D
.
D
Figure 3.36: Fixed-Point Unrolling Law
In Figure 3.35, the selection of a component from e
Ô
will simplify if
wf'w
!
p
l
is a simple
variable, name it x: then we have the substitution
{
L
Uw^'w¾j
x
m
e
Ô
o2
~
x
ÒÓ_³jz~
e
Ô
Ã
x
ÒÓ
x
Å
o
¶m
and, after further simplification steps, the replacement of xin the schema’s property e
reduces to e
Ô
. However, if
w^'w
p
l
is a proper pattern, then the selections via the
operator in the substituted expressions may be in principle undefined. Yet, in this case,
though the property
w^'w2jx{
Uwf'w¾jwf'w
p
lUm
e
Ô
oÚo
eof the schema becomes undefined, the
singleton set expression
~
e
Ô
Ã
p
lAÒÓ
p
¢Å
must also reduce to
, such that the undefinedness
of the property does not count.
,
3.4.7 Fixed-Point Unrolling Law
The fixed-point operator,
é%ê
p
ë
e, can be unrolled, provided the expression erepresents
a continuous function on the domain of the pattern’s type (Figure 3.36). This law differs
from all others in that the application condition is semantic. The pragmatics is that the
unrolling law is used in the operational semantics of
Zunder the unproved assumption
of the above condition, and is thus correct only relative to such assumptions.
Proof (informal)
. The correctness of this law follows from the fixed-point theorem for
lattices discussed in Section 2.3.4 (on page 33). By the typing conditions, we know that p
is an exhaustive pattern where the variables represent set types, and thus its type’s domain
is a complete lattice.
,
3.5 Discussion 67
3.5 Discussion
We have presented the
Zcalculus, which provides a way of viewing the
¬
-calculus,
predicate calculus, schema calculus, set algebra, etc., in a unified framework. A set-based
model for the calculus has been defined, syntax, typing conditions and semantics have
been provided, and a set of equational laws has been given. A few further points are
discussed below, including the relation to other work.
Partial Sets and Recursion
Features like sets with unknowns and the explicit representation of undefinedness makes
Z’s model different from the one normally used for Z. However, as discussed in Sec-
tion 2.1.4 (on page 26), the forthcoming ISO Standard does not prescribe a particular
position on undefinedness. The treatment of undefinedness is left to conventions intro-
duced by specifiers and/or tools.
Representing undefinedness in the model of
Zis essential. The need for its repre-
sentation is usually attributed to computation. For example, the reason that VDM [Plat
and Larsen, 1992; Larsen and Pawlowski, 1995] represents undefinedness, unlike Z, is
often explained by its need to deal with computation. For
Z, the more important ar-
gument is that explicit representation of undefinedness is the key to a simple equational
theory, which can be applied without testing guards for definedness (which are, in reality,
intractable). Central laws, such as the distributivity of schema construction over conjunc-
tion,
~
p
e
lk
e
S
N$
~
p
e
lUÖ9~
p
e
S
, would otherwise become more complex. Other
laws affected are property substitution (related to
O
-reduction or unfolding), construc-
tor decomposition and many more. The observation can be compared with the cleaner
equational properties of lazy functional languages as opposed to strict ones.
It is notable that, although we have undefinedness, it is decoupled from fixed-point
construction, which is based on classical lattice theory. In fact, the least element for
fixed-point construction is the empty set, not the undefined set. Building fixed-points
would also work for models without undefinedness.
Since
Z’s approach is not constructive a priori, a fixed-point may be undefined. At
the level of the model semantics, this causes no problems. In the equational theory, how-
ever, we have to place conditions about continuity of the expression ein
éçê
p
ë
eover the
variables from pto allow symbolic computation of fixed-points. The application condition
of this law is indeed intractable, but in practice – when mapping Z to
Zand converting
some recursive equations into the fixed-point form – a pragmatic solution is acceptable,
which adds the unproved assumption that the condition for the fixed expression is obeyed.
Set Algebra
The
Zcalculus is based on set algebra, and its operators are well known, except that
they are interpreted with a partial semantics. A new contribution is the combination of
set-algebraic operators with the translation construct. Translation is used to model micro-
elements, like function application and quantifiers, and at the same time it scales up to
describe morphisms between macro-elements, like entire specifications. Translations are
a way of describing morphisms in the category of sets of the
Zuniverse, and some of
68 The
ZCalculus
the equational laws seem to have a direct correspondence to concepts in category theory
[Barr and Wells, 1990]. However, the relation to category theory needs to be further
investigated.
Sets In Programming Languages
Sets for use in programming were proposed by the designers of SETL back in the eighties
[Kruchten et al., 1984]. Recently, sets in declarative programming have again attracted
interest in the community. Several set-oriented programming languages have been de-
fined. This work usually adds special primitives to functional or logic languages, provid-
ing predicates for membership or subset relation and introducing non-free constructors
for decomposing sets in pattern-based rule definitions. One approach along these lines is
the language
~
log
(pronounced SETLOG), which is an extension of Prolog by special
terms for set expressions, including extensional and intensional representation, and en-
capsulated search [Dovier et al., 1996; Rossi, 1997]. Another interesting approach here is
subset logic programming, described e.g. in [Jana and Jayaraman, 1999; Jayaraman and
Moon, 1999], which allows for recursive subset clauses.
Zdiffers from these approaches in that it embeds functional and logic concepts into
sets and not vice versa, thereby using a pure expression language in the spirit of the
¬
-calculus. This makes
Zsuitable as an intermediate language for the integration of
paradigms. On the other hand, as will be seen in Chapter 4, the computation model for
Z
presented in this thesis is not as ambitious as the one for subset logic programming [Moon,
1997], which (in a first-order setting) employs set unification and fixed-points over sub-
set constraints, quite expensive features [Arenas-Sanchez and Dovier, 1997; Stolzenburg,
1999]. These symbolic computation techniques are, in principle, entailed in
Z’s model,
but no attempt has been made to formulate equational laws which reflect them.
Higher-Order Logic
Zis related to higher-order logic [Gordon and Melham, 1993] in its ambition to re-
duce mechanical reasoning to a small calculus. However,
Zhas more redundancy, since
it contains extensional elements (singleton sets) and set algebra, whereas basic HOL is
purely intensional, and uses only abstraction and application as the kernel expression
forms. In [Santen, 1999], it has been shown that Z can be consistently embedded into
HOL, with the practical effect that tools like Isabelle [Paulson, 1994] can be used for me-
chanical reasoning. Here we propose that the redundancy of
Z, supporting extensional
description and set algebra, is in fact an advantage, because it allows the construction of
kernel machines that are specialized for the basic concept that is of interest in reasoning
– boolean algebras. This is at least indicated for the applications of partial evaluation and
(symbolic) computation, as will be investigated in the next chapter.
Concurrent Constraint, Functional Logic Languages
Most authors presenting implementation techniques for concurrent constraint or func-
tional logic languages base their work on a kernel language which is usually an extension
of a subset of ML or Haskell. Special “choice” constructs (generalizations of the
PQ
ýd¸
construct of functional languages) introduce indeterminism, and logic variables can be
3.5 Discussion 69
declared [Kuchen et al., 1990; Lock, 1992]. In languages that support concurrent con-
straints, collections of constraints can also be used in position of Boolean expressions
[Chakravarty et al., 1997; Hanus, 1999; Mehl, 1999]. These kernel languages are of-
ten tailored to the application in hand. In contrast, the
Zcalculus uses a more general
approach, since it is based on standard notions of set algebra.
An approach similar to that of
Zare the calculi for the Oz language [Smolka, 1998],
described in [Smolka, 1994a,b]. The
-Calculus, Calculus Aand Calculus Buse a lan-
guage overconjunctions and disjunctions of constraints. Basic constraints are declarations
of predicates and functions, as well as equalities and applications of predicates, and com-
mitted choice. The calculi are pure expression languages, similar to
Z. An equational
theory is given which serves to define the operational semantics modulo expression con-
gruences. As will be discussed in Chapter 4, the computation model has some similarities
to that of
Z.
Zdiffers from the Oz calculi in that it uses set algebra instead of predicate logic. It
incorporates extensional representation of disjunctive information, which the Oz calculi
do not support. On the other hand,
Zcurrently has no equivalent of committed choice,
which is important for representing explicit concurrency. Committed choice cannot be
represented as syntactic sugar in
Z. By a way of an attempt, let g
lGÓ
e
l
î
g
ÖÓ
e
be a
choice in
Z, where g
l
and g
are Boolean guards and the meaning is defined as
~
x
g
lÑ
g
x
×
e
lU³ ~
x
g
>
g
lk
x
×
e
dX
~
x
g
h
g
x
×
e
lk
e
S
The problem is the case where both g
l
and g
are true: in a committed choice, we expect
that either e
l
or e
is chosen nondeterministically. This kind of non-determinism is “don’t
care”, which is not supported by
Z: the calculus is, in fact, purely declarative, unfolding
“don’t know” indeterminism into sets. Thus, the property x
×
e
lÑ
e
encounters all
possibilities in the union of e
l
and e
. How choice can be incorporated into
Zrequires
further research. A more general approach than only supporting choice is aimed at, based
on temporal interval logic [B¨ussow and Grieskamp, 1997]. This will be discussed under
future work in the conclusion in Chapter 7.
Chapter 4
Computation in
R
Z
Daß man nicht weiß,
Was man denkt,
Wenn man denkt;
alles ist als wie geschenkt.
(Goethe)
Models for computation in
Zare investigated in this chapter. The principal goal of
computation is seen to be the transformation of a
Zexpression into a “more” extensional
but equivalent form. The process, thereby, is incremental: given a set expression e, one
computes, for example, the equivalent expression
~
e
l^H
e
. Computation may then be
continued with e
l
(in case it is not already completely reduced) or with e
.
In general, the pragmatics of computation differs if it is performed “on-line” or “off-
line”1. On-line computation works by direct symbolic interpretation of expressions,
whereas off-line computation involves compilation steps, targeting at a tailored encoding
of expressions and values at execution time. In this chapter, we will have this distinction
not explicitly: all the computation models we investigate are symbolic, in the sense that
they work on expressions (or slight extensions of them). However, some models are better
suited to off-line computation and compilation, as we shall see.
Underlying every model of computation we investigate is a normalization transforma-
tion which establishes a disjunctive normal form, including simplifications of expressions
(Section 4.2 (on page 74)). The normalization already exploits most of the equational
laws given for
Zin Chapter 3. It is confluent and terminating, which is important to
make it applicable to the partial evaluation and optimization of
Zprograms at compile
time. Indeed, since it terminates, it has to leave out laws such as the fixed-point unrolling
law.We obtain a narrowing semantics of
Zby adding to normalization some further re-
ductions, which are based on the property substitution law, membership lifting law, and
fixed-point unrolling law (Section 4.3 (on page 82)). By constraining the reduction order
of narrowing to outermost-in and strict narrowing, we obtain some interesting submodels.
The narrowing semantics is well suited to on-line computation, however, not to off-
line computation (as will be discussed). Therefore, a further model is developed, using
the style of natural semantics, and constituting
Z’s reference computation model,RCM
(Section 4.4 (on page 86)). This model defines computation by making a distinction
between (strict, functional) deterministic reduction and (logic, concurrent) indeterministic
resolution, and prepares a straight transition to the abstract machine defined in the next
chapter. The chapter concludes with a discussion of the results obtained and of related
work.
1The notions “on-line” and “off-line” are taken from the realm of partial evaluation (e.g., Consel and
Danvy [1993]).
72 Computation in
Z
EXP
S
EXP
M
i
¼'½{
e
l
±
e
l
i
e
i
ikj
e
l
o
Fikj
e
o
T
CONS
e
c
e
UWVYX
EXP
M
i
¼'½{
e
l
±
Þ
j
¼'½»{
e
±
e
l
i
e
j
M
j
¼'½{
e
±
Þ
i
¼'½»{
e
l
±
e
j
e
l
i
jÚjz~
o
/.
e
l
o
jÚjz~
o
/.
e
o
e
c
e
UZVYX
EXP
÷
EXP
S
EXP
iäl}÷
i'ÖÊïjÈÞ
i
¼'½»{
e
l
±
e
l
i
÷
e
i
o
iälUj
e
l
o
÷Yi'j
e
o
T
c
T
CONS
e
c
e
UZVYX
EXP
jÈÞ
i
¼'½{
e
l
±
M
j
¼'½»{
e
±
e
l
i
÷
e
j
o
Êïj=Þ
j
¼'½»{
e
±
M
i
¼'½»{
e
l
±
e
j
÷
e
l
i
o
jÚjz~
o
/.
e
l
o
÷
jÚjz~
o
/.
e
o
e
c
e
UWV[X
EXP
Figure 4.1: Extensional Equality and Unequality
4.1 Preliminaries
Some preliminary definitions are given in this section: extensional equality, extensional
confluence and matching contexts.
Extensional Equality
We introduce the notion of extensional equality of expressions. This (partial) equality
identifies expressions that are built from constructor terms and union of singleton sets; it
cannot identify schemas and translations. Thus, the relation
is an approximation of
expression equivalence, such that e
lk
e
Öô
e
l
5$
e
holds. Since it is approximative, the
negation
Ì
e
lk
e
ô Ì
e
l
L$
e
does not hold. We therefore define a second relation,
extensional inequality, written as e
l÷
e
, which obeys the property e
l2÷
e
Öô Ì
e
l
\$
e
.
Both relations are defined by the rule system in Figure 4.1.
The use of
requires that unions be bracketed to the right (cf. the definition of
,
Section 3.3.5 (on page 56)), and that the empty set be removed in a non-empty union.
Since equality will only be applied to normalized expressions that puts unions into such a
form, this constraint is feasible.
No attempt is made, by the given notion of equality, to identify further expression
forms. It is generally assumed that intersection is resolved before equality is tested. Sets
described by translation, complement and, in particular, by schemas cannot be identified.
Extensional Confluence
On the basis of the equality relation
, the notion of an expression relation Rbeing
extensionally confluent is defined. For such a relation, all terminating derivations that
lead to an expression in the domain of
must yield equal results under
. Thus, if
4.1 Preliminaries 73
Ã
A]
]_^\`ba
2j
?@
A
A
o
UNCTX
~
0c
]_^\`ba
EXP
±
¬
s
EXP
±
j
Yc
s
o
INCTX
~
0c
]_^\`ba
EXP
±
¬
s
EXP
±
j
[c
s
o
Figure 4.2: Matching Contexts
e R
nSnSn
R e
l
and e R
nSnSn
R e
, where e
l^m
e
E8
×¼'½{
R, are terminating derivations, then
e
l×¼'½»{$j
o
Ê
e
³×˼'½»{j
o
ô
e
lk
e
. This notion of confluence reflects the
fact that as long as “symbolic” computation is done, confluence is not asserted; only if a
derivation leads to an extensional form it counts.
Matching Contexts
Asequence matching context serves for the convenient formulation of rewriting rules.
With a sequence matching context, we can match one or more elements out of a sequence
and replace them by new elements or removethem. For example, if
cdA
=öm
feC
matches some
sequence containing
ö
and
e
at arbitrary positions, then
cdA?g
+öm
geC
matches the sequence
where one occurence of
ö
is replaced by
g
,ö
and one occurence of
e
is replaced by
ge
.
chAig
,ö
C
is the sequence where the occurence of
ö
is replace by
g
+ö
, and the occurence
of
e
is removed. Sequence matching context
c
×
]_^\`ba
(
the element type of the
sequence) are declared in Figure 4.2.
For the common case of sequence matching in combination with generalized union
and intersection, in Figure 4.2 we also define union matching contexts
j
×
UNCTX and
intersection matching contexts
j
×
INCTX.
j
eabbreviates
j
j
[c
e
o
for some sequence
matching context
c
(similar for intersection).
74 Computation in
Z
b
×
EXPB
d
ikj
b
o
d
x expressions
d
×
EXPD
c disjunctions
c
×
EXPC
l conjunctions
l
×
EXPL
a
a literals
a
×
EXPA
g
x
6~
p
lk
¾
c
Ã
p
lAÒÓ
p
ÚÅË
atoms
d
éçê
p
ë
d
6~
b
k
"×
EXPP
p
l
p
p
×
c
c
c properties
Figure 4.3: Normalized Expressions
4.2 Normalization
Underlying every model of computation we investigateis a transformation that establishes
a disjunctive normal form, including simplifications of expressions. Normalization is
described by the relation
Ó
«
:
Ó
«
EXP
S
EXP
Applying this relation as a context rewriting establishes a disjunctive normal form as
described by the grammar in Figure 4.3. The DNF is justified by the de-Morgan laws of
the calculus. In addition to the DNF form, some further assertions hold about normalized
expressions:
±
Any translation that is neither hiding nor embedding has been decomposed into
an embedding followed by a hiding. Hidings are pulled, embeddings pushed and
consecutive translations contracted. Complement is pushed as far as possible –
justified by the lifting and distributivity laws of translation
Note that hiding translations cannot be completely pulled out of expressions, since
complement is not distributive w.r.t. hiding; thus, for example, the following ex-
pression is in normal form: c
jÚj
c
lk
c
o^Ã
p
lGÒÓ
p
ÚÅ
o
.
±
Potential for simplification is exploited to a maximum: the only laws not consid-
ered for this purpose are membership lifting, property substitution and fixed-point
unrolling.
±
Schema properties are decomposed into one of the forms: pattern equality, p
l
p
,
pattern membership, p
×
c, or test for emptiness and nonemptiness,
cor
c.
The variables appearing in the patterns p,p
l
, and p
must be directly bound by
the enclosing schema, and the patterns must be linear. In fact, after removing the
syntactic sugar, the forms overlap. However, for the sake of simplicity, it will be
assumed in the sequel that the property forms can be distinguished.
4.2 Normalization 75
4.2.1 Property Normalization
We take a closer look at the normalization of schema properties. The benefit of having a
schema property in the form
~
p
p
Ô
×
c
is that the membership lifting law (Figure 3.34
(on page 65)) can be applied as soon as cdoes not depend on variables from p, yielding
the expression c
Ã
p
Ô
ÒÓ
p
Å
2.
Normalization ensures that any so-called flexible appearances of variables in a prop-
erty are converted into a membership property, p
×
c, together with a sequence of simple
equations of flexible variables, x
x
Ô
. By a flexible appearance, we mean a variable x
used as in
~
Px
C
~
m
x
, where Cis a positive conjunctive context built from intersec-
tions and translations, and
m
a context of constructor applications.
The normalization of flexible variables works as follows. Let
~
p
j
D
l
o
be a
schema with a positive conjunctive property as an intermediate result of normalization,
where constructor decomposition has been performed, hidings have been pulled and ab-
sorbed by the overall hiding of
, and embeddings have been pushed to the leaves.
Henceforth,
j
l
o
must match (modulo associativity and commutativity)
jz~
x
lU
Ã
p
lAÒÓ
q
lzÅ' nSnSnB@~
xn
Ã
pn
ÒÓ
qn
Ŷ
c
o
where the xiare flexible and where cdoes not contain variables in a flexible position.
Next, we unify the patterns qiagainst each other (if this fails, then the property reduces
to
already at normalization time). Let
be the resulting assignment, and let
Ô
~
x
lÒÓ wf'w
p
ldmSnSndn(m
xn
ÒÓ wf'w
!
pn
be an assignment for the flexible variables xi,
and q
w^'w
q
l
the unified translation target. Let x
ì´
Æíw
q
j
ì´
Æíw
Á
Æ
´
u
n
Ô
Â
o
be
the variables in qthat are bound to the flexible variables (qcan contain further variables
introduced by embeddings). Then, we construct the schema
~wf'w
Ô
p
j
x
o
×ïjwf'w
Ô
c
ofÃ
q
ÒÓ j
x
o
Åx n
However, this schema might not be well-formed, since
wf'w
Ô
pmay result in a non-
linear pattern. But in this case, a simple renaming of double occurrences of variables can
be performed, adding aliases like x
x
Ô
for each renamed variable.
By way of an example, consider the schema
~
x
Õj
e
m
x
o
×
e
Ô
. This results in the
normalized schema
~
x
x
×òjx~
e
Ã
x
ÒÓ j
x
m
o
Å'
e
Ô
ofÃ
j m
y
o
ÒÓ
y
Åz n
As a further example, demonstrating aliasing, consider the schema
~äj
x
m
y
m
z
o
Gj
e
m
x
o5
j
y
m
z
o
×
e
Ô
. For the property one literally gets
jx~
x
Ã
x
ÒÓ j m
x
o
Ŷ9~
y
Ã
x
ÒÓ j
x
m
o
Å'@~
z
Ã
x
ÒÓ j m
z
o
Å'9~
e
Ã
x
ÒÓ j
x
m
o
ÅD
e
Ô
o
Unification of
j m
x
o
with
j
y
m
) and
j m
z
o
yields
j
y
m
z
o
. The resulting schema is
~äj
z
m
y
m
z
Ô
o
äj
y
m
z
o
×jx~
e
Ã
x
ÒÓ j
x
m
o
Ŷ
e
Ô
o
z
z
Ô
n
In a subsequent normalization step, this is reduced to a conjunction of schemas, one hold-
ing the pattern membership, the other the alias.
2Membership elimination is not part of normalization – butthe computation models based on normalized
expressions use it as a central simplification step.
76 Computation in
Z
«
l
6~
e
;Ó
«
ee
EXP
Figure 4.4: Singleton Set Normalization
«
~ihFÓ
«
~
0
W
Ã
x
ÒÓ i»Å
T
CONS
x
VAR
«
(
e
x
1
ïq
~ikj
e
o
FÓ
«
j¢j=¬
i
-
ò±
~
ei
Ã
j
xi
o
ÒÓ_ikjÚj
o
/.
x
o
Å
o
/.
t ¼kj¢®ÕnSn
e
o¢o
T
CONS
e
UZVYX
EXP
x
UZVYX
VAR
Figure 4.5: Constructor Normalization
4.2.2 Normalization Rules
The rewriting rules for simplification and normalization are defined in the sequel, using
the notation style of inference rules. Though this kind of notation is particularly suitable
for inductive definitions over the structure of expressions (which does not apply to the
rewriting rules below because they are not recursive in their premises), it is used here be-
cause the application conditions of rules are sometimes complex, and are better readable
when denoted in rule style.
Singleton-Set Elimination
Rule
c
+®
in Figure 4.4 resembles the reduction of singleton-set selection.
Constructor Decomposition
Rules
c
Øö
and
cbe
in Figure 4.5 handle the decomposition of singleton sets containing con-
structor terms (accordingto the lawsin Figure 3.24 (onpage 60)). Even0-ary constructors
are transformed into translations, since incompatible constructions (e.g.
~i Ö9~i
Ô
with
i"÷
i
Ô
) are detected by the intersection of translations (Rule
c
Ù®
0o
).
Union
Rules
c3p
to
c\q
in Figure 4.6 (on the facing page) model the simplification of set union
based on Boolean laws (Figure 3.21 (on page 58)). Unions are rebracketed such that the
generalized union,
, can apply. Tautologies are reduced and duplicate elements are
removed. The “excluded middle” for singleton sets is tackled by rule
cbq
.
Intersection
Rules
cbr
to
c
Ù®
s
in Figure 4.7 (on the facing page) model the simplification and nor-
malization of set intersection based on boolean laws (Figure 3.21 (on page 58)). As for
union, intersections are rebracketed, tautologies are reduced and duplicate elements are
removed. The “excluded middle” for singleton sets is tackled by rule
c
+®
e
. Rule
c
+®
0s
distributes intersection over union.
4.2 Normalization 77
«
2
j
e
lk
e
o
e
(
³Ó
«
e
lÑVj
e
h
e
(
o
e
c
e
c
e
t
EXP
«
vu
j
A
m
e
C
ÏÓ
«
j
A
e
C
e
EXP
j
UNCTX
«
vw
j
A
ÿ
m
e
C
Ó
«
ÿ
e
EXP
j
UNCTX
«
x
e
lk
e
j
A
e
l^m
e
yC
Ó
«
j
A
e
l
zC
e
c
e
EXP
j
UNCTX
«
{
e
lk
e
j
A
z~
e
l^ mf~
e
S
C
Ó
«
ÿ
e
c
e
EXP
j
UNCTX
Figure 4.6: Union Normalization
«
|
j
e
l
e
o
e
(
XÓ
«
e
lkVj
e
e
(
o
e
c
e
c
e
t
EXP
«
l
~}
jA
Èm
e
C
Ó
«
e
EXP
j
INCTX
«
løl
j;A
ÿ
m
e
C
Ó
«
j;A
e
C
e
EXP
j
INCTX
«
lÈ
e
lk
e
j
A
e
lUm
e
yC
Ó
«
j
A
e
l
zC
e
c
e
EXP
j
INCTX
«
l
~(
e
lÑ
e
j
A
z~
e
l^ mǨ~
e
d
C
Ó
«
e
c
e
EXP
j
INCTX
«
l
2
e
l2÷
e
j
;A
e
ldm
e
C
Ó
«
e
c
e
EXP
j
INCTX
«
l
u
j
A
e
lk
e
yC
Ó
«
j
;A
e
l
zC
Ñ
j
;A
e
yC
e
c
e
EXP
j
INCTX
«
l
w
ÌïjÈÞ
7
EXPASS
±
p
Ô
l
K
p
Ô
o
j
A
e
l
Ã
p
lAÒÓ
p
Ô
l
Å¢m
e
Ã
p
HÒÓ
p
Ô
Å
~C
Ó
«
e
c
e
EXP
p
c
p
c
p
e
c
p
e
PAT
j
INCTX
«
l
x
Ì j=Þ
b
EXPASS
±
p
Ô
l
p
o
j
A
e
l
Ã
p
lAÒÓ
p
Ô
l
Åzmd~
p
)
e
d
C
Ó
«
e
c
e
EXP
p
c
p
c
p
e
PAT
j
INCTX
«
l
{
ÌïjÈÞ
7
EXPASS
±
p
l
K
p
o
j A
z~
p
l,
e
lU mU~
p
e
S
C
Ó
«
e
c
e
EXP
p
c
p
PAT
j
INCTX
«
l
|
ì´
Æíw
p
Ô
<
ì´
ÆMw
p
j
HA
e
Ã
p
ÒÓ
p
Ô
Å
~C
6Ó
«
j
e
Vj
j
ADC
o^Ã
p
Ô
ÒÓ
p
Å
o^Ã
p
ÒÓ
p
Ô
Å
j
INCTX
e
EXP
p
c
p
e
PAT
Figure 4.7: Intersection Normalization
Rules
c
Ù®
0o
to
c
+®
q
handle the intersection of translations and/or schemas which cannot
fit, because the corresponding patterns cannot be unified.
Rule
c
Ù®
0r
models the lifting of hiding translations out of an intersection context (cf.
Figure 3.28 (on page 63)).
Complement
Rule
c
Øöq
in Figure 4.8 (on the next page) absorbs consecutive complement. Rules
c
Øöä®
and
c
ÖöDö
distribute set complement over union and intersection. Rule
c
Öö
ve
distributes
complement over embedding translations that are exhaustive. Rule
c
Öö
lp
distributes com-
plement over schema, adding those values that cannot match the schema’s pattern.
78 Computation in
Z
«
}
Ëj=
e
o
Ó
«
ee
EXP
«
zl
j
e
lk
e
o
Ó
«
e
l
e
e
c
e
EXP
«
ø
j
e
lk
e
o
Ó
«
e
l
e
e
c
e
EXP
«
(
ì´
Æíw
p
ð
ì´
ÆMw
p
Ô
p
×
PATEX
p
Ô
×
PATEX
Ëj
e
Ã
p
ÒÓ
p
Ô
Å
o
Ó
«
j=
e
ofÃ
p
ÒÓ
p
Ô
Å
e
EXP
p
c
p
e
PAT
«
D2
~
p
e
FÓ
«
~
p
e
H>Ëj
ÿ
Ã
p
ÒÓ
p
Å
o
p
PAT
e
EXP
Figure 4.8: Complement Normalization
Translation
Rules
c
Öö
s
and
c
Öö
vo
in Figure 4.9 (on the facing page) distribute translation over set union
and intersection. For intersection, only embedding translations can be distributed; hidings
are in fact lifted as described earlier (Rule
c
Ù®
0r
). Rule
c
Öö
reduces the translation of the
empty set. Rule
c
Öö
vq
eliminates a translation by the same exhaustive pattern. (An instance
where this rule applies is a translation by the same variable, x
ÒÓ
x.)
Rule
c
Öö
vr
handles consecutive translations that are contradictory, because the target
pattern of the first translation cannot be unified with the source pattern of the second.
Rule
c\e
Dq
tackles consecutive translation that can be contracted. It is only applied
if the resulting translation is a hiding or an embedding, in order to prevent a circular
application w.r.t. Rule
c\e
»®
, that splits a translation which is not a hiding or embedding
into a consecutive embedding and hiding.
Rule
c\e
'ö
reduces a translation of a schema whose pattern does not unify with the
translation’s source pattern. Rule
cbee
eliminates an embedding translation of a schema
by substituting in the schema’s property the assignment resulting from unification of the
schema’s pattern with the translation’s source pattern.
Schema
Rules
cbevp
and
c\es
in Figure 4.10 (on the next page) handle distribution of schema over
set union and intersection. Rules
c\eo
and
cbe
eliminate schemas with tautological prop-
erties.
Rule
cbeq
describes the conversionof a schema property,
j
D
l
o
, into apattern membership-
test, p
×
c(as discussed above on page 75). This rule is sketched only informally. We
assume that
j
D
l
o
is normalized as far as possible, and that constructor decomposition is
not applied after this rule (otherwise we run into a cycle, since a candidate for constructor
decomposition is introduced by the rule). Moreover, the fact that a renaming of double
variables in
wf'w
Ô
phas to be performed, adding corresponding alias equations, is not
formalized.
4.2 Normalization 79
«
u
j
e
lk
e
o^Ã
p
ÒÓ
p
Ô
Å$Ó
«
e
l
Ã
p
ÒÓ
p
Ô
Å'
e
Ã
p
ÒÓ
p
Ô
Å
e
c
e
EXP
p
c
p
e
EXP
«
w
ì´
Æíw
p
ð
ì´
ÆMw
p
Ô
j
e
lk
e
o^Ã
p
ÒÓ
p
Ô
Å$Ó
«
e
l
Ã
p
ÒÓ
p
Ô
Å'
e
Ã
p
ÒÓ
p
Ô
Å
e
c
e
EXP
p
c
p
e
EXP
«
x
Ã
p
lGÒÓ
p
BÅÓ
«
p
c
p
PAT
«
{
p
×
PATEX
e
Ã
p
ÒÓ
p
ÅÓ
«
ee
EXP
p
PAT
«
|
Ìïj=Þ
b
EXPASS
±
p
p
(
o
e
Ã
p
lGÒÓ
p
ÚÅ
Ã
p
(
ØÒÓ
p
2
BÅ$Ó
«
e
EXP
p
c
p
c
p
t
c
p
PAT
«
(}
p
p
(
ì´
ÆMwñj:w^'w
p
l
o
ð
ì´
Æíw jwf'w
p
2
o
Ê
ì´
Æíw jwf'w
p
2
o
ð
ì´
ÆMwñj:w^'w
p
l
o
e
Ã
p
lGÒÓ
p
ÚÅ
Ã
p
(
ÖÒÓ
p
2
ÚÅÓ
«
e
Ã
wf'w
!
p
lAÒÓ wf'w
p
2
BÅ
e
EXP
p
c
p
c
p
t
c
p
PAT
EXPASS
«
(
zl
Ì
ì´
Æíw
p
l
ð
ì´
ÆMw
p
SHÌ
ì´
Æíw
p
ð
ì´
Æíw
p
l
p
Ô
j j
o
/.
Öì´
ÆM½¶ÆM¼'yÆj
ì´
Æíw
p
l%
ì´
Æíw
p
o o
e
Ã
p
lAÒÓ
p
ÚÅ$Ó
«
e
Ã
p
lGÒÓ
p
Ô
Å
Ã
p
Ô
ÒÓ
p
ÚÅ
e
EXP
p
c
p
c
p
e
PAT
«
(
ø
Ìïj=Þ
b
EXPASS
±
p
l
p
o
~
p
l)
e
Ã
p
ÖÒÓ
p
(
¢ÅÓ
«
e
EXP
p
c
p
c
p
t
PAT
«
((
p
l
p
S
ì´
Æíw
p
ð
ì´
Æíw
p
(
~
p
l,
e
Ã
p
ÖÒÓ
p
(
BÅÓ
«
~w^'w
p
(
wf'w
e
e
EXP
p
c
p
c
p
t
PAT
EXPASS
Figure 4.9: Translation Normalization
«
(D2
~
p
e
lk
e
SYÓ
«
~
p
e
lUG@~
p
e
S
p
PAT
e
c
e
EXP
«
(
u
~
p
e
l
e
dYÓ
«
~
p
e
l^H@~
p
e
S
p
PAT
e
c
e
EXP
«
(
w
~
p
Ñ;Ó
«
p
PAT
«
(
x
~
p
ÿ
;Ó
«
ÿ
Ã
p
ÒÓ
p
Å
p
PAT
«
(
{
xi
×
ì´
ÆMw
p
qi
qj
Ô
~
x
lGÒÓ_wf'w
p
ldmSnSnSnhm
xn
ÒÓ_w^'w
!
pn
x
¨ì´
Æí½'Æí¼'yÆj
ì´
ÆMwñjwf'w
q
l
o
j
ì´
Æíw
Á
Æ
´
u
Ô
Â
o¢o
~
p
j
Jj;A
z~
x
lU
Ã
p
lAÒÓ
q
lzÅzmSndnSnWmd~
xn
Ã
pn
ÒÓ
qn
Å
~C
o
;Ó
«
~w^'w
Ô
p
äj
x
o
×ïjwf'w
Ô
j
Jj;ADC
o¢o^Ã
w^'w
q
lGÒÓ j
x
o
Åx
p
c
pi
c
qi
PAT
j
INCTX
c
e
EXPASS
x
UZVYX
VAR
Figure 4.10: Schema Normalization
4.2.3 Properties of Normalization
The relation
Ó
«
has some properties that will be investigated below. Let
«
be
the lifting of
Ó
«
to a context rewriting, such that e
l
«
e
iff there exists a context
#
and subexpressions e
Ô
l
m
e
Ô
such that e
l
#
e
Ô
l
,e
Ô
l
Ó
«
e
Ô
, and e
#
e
Ô
.
80 Computation in
Z
PROPOSITION 4.1 The relation
«
is sound w.r.t. the meaning of
Z.
Proof (informal)
. The rules are directly derived from the equational laws.
,
PROPOSITION 4.2 The relation
«
is terminating.
Proof (informal)
. The rules of
Ó
«
can be characterized in terms of three classes:
elimination rules which decrease the size of their operands; distributivityrules which push
a
Zoperator down into an expression, thus possibly duplicating some operands; and
lifting rules which do the opposite of distribution. The elimination rules are obviously
safe as regards termination. Distributivity and lifting rules are safe if they exclude each
other: what has been distributed must not be lifted to its original form in a later rewriting
step. There are two problematic cases here:
±
Rule
c\e
Dq
composes and rule
cbe
»®
splits translations. But the application conditions
have been chosen such that composition is only performed if splitting cannot be
applied to the result.
±
Rule
cbe
decomposes patterns and rule
c\eq
synthesizes them. Preventing a cycle
in the application of these rules is not been formalized (because Rule
cbevq
is left
informal) but it is easily possible: since the effect of
c\eq
is localized to a schema’s
property, normalization can be sequentialized. First the rule system is comprehen-
sively applied without using Rule
c\eq
, then in a second pass
c\eq
is comprehen-
sively applied.
,
PROPOSITION 4.3
«
is confluent w.r.t. extensional equality.
Proof (informal)
. Since we can assume soundness, the problem reduces to showing that
for each derivation that leads to an extensional value (one which is in the domain of
),
each alternative derivation also leads to an extensional value. The sources for increasing
extensionality in a derivationare elimination rules. The question is whether the possibility
of applying some of these rules is obstructed if we prefer applying another rule before a
possible elimination step:
±
The Boolean elimination rules cause no problems here. A union or intersection con-
text is either reduced to a tautology, which is the “best” result that can be achieved,
or a duplicate operand is removed, still allowing elimination in its context with the
remaining operand.
±
The application of distributivity and lifting rules actually increases the potential for
simplification, so there is no problem if one prefers distributing before a possible
elimination step.
,
On the basis of Proposition 4.2 and Proposition 4.3, we can assert the existence of a
total function
u'ÆÈ{
which normalizes and simplifies an expression. For nonextensional
4.2 Normalization 81
results of normalization, where confluence cannot be asserted, some arbitrary but fixed
reduction order is assumed:
u'ÆÈ{
EXP
EXP
PROPOSITION 4.4 The function
u'Æ{
puts an expression into disjunctive normal form, as
specified by the grammar in Figure 4.3.
Proof (informal)
. In general, establishing a disjunctive normal form is a standard pro-
cess. Our rule system differs from this only in that translations need to be treated, and
properties of schemas must be normalized. The decomposition of any nonhiding and
nonembedding into an embedding followed by a hiding, and the strict distribution of
embeddings and lifting of hidings, ensures that translations are normalized as required.
Establishing the normal form for properties was justified on Page 75.
,
PROPOSITION 4.5 There exists an innermost-out reduction strategy, an inductive algo-
rithm over the expression structure, which implements
u'ÆÈ{
.
Proof (informal)
. The algorithm is the usual one for establishing a disjunctive normal
form. For example, for distributivity of intersection over union, we can give an inductive
rule in the style of:
jA
e
l
fC)
«
e
Ô
l
j;A
e
yC)
«
e
Ô
e
Ô
l
e
Ô
Ó
«
e
Ô
j
A
e
lk
e
l
zC)
«
e
Ô
In general, distributivity and lifting rules drive the algorithm. Elimination rules are ap-
plied at each expression depth (here depicted by e
Ô
l
e
Ô
Ó
«
e
Ô
o
before the final result
expression is returned.
,
82 Computation in
Z
l
#
"j
j A
x~
p
vk
¾ md~
b
C
o
u'Æ{Yj
#
"j
j A
z~
p
w^'w jx{
Uwf'w¾j
p
m
b
o¢o
k
¾ md~
b
C
oÚo
EXPCTX
j
INCTX
b
EXPB
EXPP
p
PAT
p
p
S
#
9j
JjHA
z~
p
vk
W md~
b
Ã
p
lÒÓ
p
ÚÅ
~C
o
u'ÆÈ{;j
#
9j
JjA
z~wf'w
p
wf'w jz{
L
dwf'w¾jwf'w
p
lUm
b
oÚo
k
¾ m
~
b
Ã
p
lÒÓ
p
BÅ
~C
o¢o
EXPCTX
j
INCTX
b
EXPB
i
EXPP
p
c
p
c
p
PAT
EXPASS
(
ì´
ÆMw
c
ì´
ÆMw
p
;:
#
9jx~
p
p
Ô
×
c
o
u'ÆÈ{;j
#
9j
c
Ã
p
Ô
ÒÓ
p
Å
oÚo
EXPCTX
p
c
p
e
PAT
c
EXPC
2
assert continuity of d
#
9j:é%ê
p
ë
d
o
u'Æ{Yj
#
¿jwf'w2jz{
L
Uw^'w¾j
p
mÚéçê
p
ë
d
o¢o
d
o¢o
EXPCTX
p
PAT
d
EXPD
Figure 4.11: Narrowing Rules
4.3 Narrowing Semantics
In normalized expressions nearly all the equational laws of
Zare exploited. The laws
not used are property substitution,membership lifting and fixed-point unrolling. Consid-
ering the normal form of expressions, these are the laws driving reduction: with property
substitution, variables are bound; with membership lifting, schemas are eliminated; and
with fixed-point unrolling, a circular expression is lifted one level upwards in its con-
text. Applying each of these steps may provide further simplification and normalization
potential.
We will thus define the narrowing semantics of
Zas consecutively applying sub-
stitution, membership lifting and unrolling in an expression context, and afterwards re-
normalizing the entire context. The strategy for selecting the next redex can thereby be
altered. In the general case, where redex selection is arbitrary, we conjecture a complete-
ness result w.r.t.
Z’s equational theory. A possible restriction is an outermost-in strategy.
A feasible restriction is “strict narrowing”, which is not complete, but more adequate for
Zthan outermost-in, as will be discussed.
4.3.1 General Narrowing
The relation
represents a narrowing step:
EXPB
S
EXPB
The rules for
, using an arbitrary expression context
#
, are given in Figure 4.11.
Rule
®
implements property substitution for the case of a plain intersected singleton set;
rule
ö
does so for a translated singleton set. These rules are direct applications of the law
found in Figure 3.35 (on page 66). Rule
He
realizes membership lifting (cf. Figure 3.34
(on page 65)). Rule
Hp
implements fixed-point unrolling (cf. Section 3.4.7 (on page 66)),
where continuity of the expression dneeds to be asserted.
4.3 Narrowing Semantics 83
We investigate some relevant properties of
: soundness, extensional conflu-
ence, and extensional completeness.
PROPOSITION 4.6 The relation
is sound w.r.t. the meaning of
Z, modulo the
assertion that in each appearance of the fixed-point operator, the fixed expression is con-
tinuous.
Proof (informal)
. Normalization is sound. The additional rules of
are directly
derived from the equational laws of the
Zcalculus.
,
PROPOSITION 4.7 The relation
is confluent w.r.t. extensional equality.
Proof (informal)
. We can assume extensional confluence and termination of normaliza-
tion as well as soundness. As with the argument for confluence in Proposition 4.3 (on
page 80), the question is whether indeterminism in the reduction order obstructs the po-
tential for obtaining an extensional value in a derivation. This is excluded because each
individual rule in fact increases potential for simplification, regardless of the order in
which they are applied: rules
®
and
ö
instantiate variables, and Rules
He
and
Hp
lift
expressions out of their isolated context of a schema property into an intersection context,
where further interactions are enabled.
,
CONJECTURE 4.8 The relation
is extensionally complete w.r.t. the equational
theory of
Z: whenever e
$
e
Ô
and e
Ô
is extensional, then there exists an e
Ô Ô
e
Ô
, such that
u'Æ{
e
e
Ô Ô
.
A formal proof of this conjecture is omitted. In fact, the proof has been indirectly provided
by construction of normalization and narrowing, providing a strategy for the comprehen-
sive, directed application of
Z’s equational laws:
±
The normalization of translations – hidings are pulled, embeddings pushed – en-
ables maximal elimination of them.
±
All possibilities for applying property substitution are detected.
±
The normalization to DNF, together with constructor decomposition, enables all
simplifications in intersections.
±
The normalization of schema properties recovers all possibilities for applying the
membership lifting law.
±
Complements, which hinder the application of property substitution and other laws,
are pushed as far as possible. The “excluded middle” for singletons is not obstructed
by this. Consider
~
e
H¨~
x
x
× ~
e
» n
Using membershiplifting before pushing complement yields
~
e
G>~
e
, enabling
the application of excluded middle. On the other hand, pushing the complement
over the schema yields in
~
e
H9~
x
j
x
×F~
e
o
n
84 Computation in
Z
However, now property substitution can be applied, resulting in
~
e
H9~
x
E j
e
×F~
e
o
m
which likewise reduces to
after some steps.
General narrowing is so powerful because the reduction order is undetermined. Since
all orders of reduction are possible , the “right” one (which terminates if termination is
possible at all) is also contained in
. However, this also means that there are
many derivations leading to a non-terminating “dead-end”, and thus general narrowing is
not very feasible for implementing computation.
4.3.2 Outermost-in Narrowing
The narrowing semantics defined in the previous section can be modified by supplying
an outermost-in strategy for selecting the next redex. In order to model “parallel-or” and
“parallel-and”, indeterminism still needs to be present in the reduction order, but it can be
significantly pruned.
The selection of an outermost-in redex is described by a context, declared as
×
OUTEREDEX
EXP
EXP and specified by the following “grammar with a hole”:
j
AY
C
j
AY
C
Ëj
[
o
6j
[
ofÃ
p
lAÒÓ
p
BÅ $Xj
[
o
³
The redex selection is indeterministic in the choice of the member of an intersection or
a union, which models the “concurrency” of reduction by interleaving. Note that we do
not select subexpressions in constructor terms, schema, and singleton set: this reflects the
non-strictness of this order.
By replacing the expression context
#
in the narrowing rules
®
to
p
by a context
, we get an outermost-in narrowingstrategy. We conjecture that this strategy is “shallow
complete”: for forced expressions it obtains the same results as general narrowing. A
forced expression is one captured by the context
during a derivation sequence. For
example, if we have initially
~äj
x
m
y
o
x
×
y
H@~
c
Ã
y
ÒÓ j m
y
o
Å
then cwill be protected by the singleton set, but after substitution we get
~äj
x
m
y
o
x
×
c
H@~
c
Ã
y
ÒÓ j m
y
o
Å
which is then transformed by membership lifting to
c
Ã
x
ÒÓ j
x
m
o
Ŷ9~
c
Ã
y
ÒÓ j m
y
o
Å
such that cis now captured by
. In an actual implementation of this strategy, one would
use sharing techniques such that the reduction of the bubbled cin the translation would
also rewrite the original cin the singleton set – yielding a “lazy” reduction strategy.
The problem with this strategy is that, by contrast to functional logic languages which
base on lazy narrowing [Hanus, 1994], in
Zequality and unequality is required for sim-
plification rules concerned with sets of sets – a further possible source apart from the
4.3 Narrowing Semantics 85
redex selection for forcing reduction. For example,
~'~
e
l^ H9~'~
e
d
reduces (by normal-
ization Rule
c
+®
@p
) to
, if e
l
and e
reduce to an extensionally unequal value. Should we
force the reduction of elements of singleton sets in an intersection, such that extensional
equality or unequality might be applicable? The problem is thus to transparently define
when values are forced. For this and other reasons, we prefer another strategy, called
“strict narrowing”.
4.3.3 Strict Narrowing
The basic decision in strict narrowing is to extend the selection of a redex to the elements
of singleton sets, such that we get the following refined redex definition compared with
outermost-in narrowing:
c
V
v
j
A[c
@
C
j
A[c
@
C
Ëj
[c
V
o
Xj
[c
9
o^Ã
p
lAÒÓ
p
ÚÅË5³j
Yc
V
o
6~
0c
@
By replacing the general expression context
#
with
c
in the narrowing rules, and by fur-
ther demanding that the property substitution rules,
®
and
>ö
, are only performed if the
element of the singleton set cannot be further reduced by
, we obtain a strict nar-
rowing strategy. This strategy is still indeterministic because of the undetermined choice
of which operand in union and intersection is to be selected next. It is not completely
identical to what is usually described as “innermost-out” narrowing [Hanus, 1994], since
we still do not look inside of schemas. Rather, it is related to applicative order reduction
and weak head-normal form in the
¬
-calculus [Barendregt, 1984].
Since, by constructor decomposition, expressions of the kind
~ikj
b
o
are normalized
to
~
b
Ã
x
ÒÓ ikj
x
o
Å
, it is useful for reasons of transparency to also make constructor appli-
cation strict. We therefore add to the above definition of
c
contexts that select operands
of constructor application (we do not formalize this).
Strict narrowing will be our operational semantics of choice, and the computation
model developed in the next section will be based on this strategy. Its restriction is that
diverging reduction of elements of singleton sets which would be not “forced” in lazy nar-
rowing propagates to the context. However, if in this context other reductions determine
the result, as in
~
diverges
G
reducesToEmpty, then the nontermination will be caught by
the concurrent reduction model.
86 Computation in
Z
4.4 The Reference Computation Model
In this section, the reference computation model of
Z, called RCM, is described, using
the style of natural semantics [Kahn, 1987]. The intention is to obtain a model that is ab-
stract enough to still support a conceptual idea of computation in
Z, but also near enough
to an implementation to serve as a starting point for the design of an abstract machine for
“off-line” computation. The strict narrowing semantics given in the previous section is not
well suited to this purpose, since it is based on the symbolic manipulation of terms and
requires renormalization of complete expression contexts after each narrowing step. In
the model given here, substitution is to be replaced by environments and renormalization
by techniques which can be mapped to backtracking and search.
In the previous section, we have already discussed why for conceptual reasons we
prefer a strict semantics for computation. The model designed here has a few further
restrictions, driven by the goals of efficient implementability and transparent traceabil-
ity of execution. The last point is particularly important for the application to test-case
evaluation, where the reason for execution failure needs to be traceable by humans. The
following restrictions will be imposed in comparison with the strict narrowing semantics:
±
In principle, the strict narrowing semantics provides “symbolic computation”. An
expression is irreducible if it cannot be further reduced by
, but such an
irreducible expression may still be processed, for example, by substituting it in a
property.
In the RCM of
Zdefined here, expressions need to be reducible to a value. If
this value form is not reached, and the expression is needed to continue computa-
tion, then computation will stop. The restriction to value forms allows an efficient
representation in an abstract machine, and makes the sources of failure traceable.
±
The strict narrowing semantics given in the previous section allows arbitrary “paral-
lel or” and “parallel and” reduction. In an implementation, this would mean that any
subexpression of union and intersection has to be computed by concurrent threads,
which causes significant efficiency problems.
The RCM presented here makes a distinction between deterministic, “functional”
reduction and indeterministic, “logic” resolution. The deterministic reduction is de-
signed using the residuation technique [Ait-Kaci et al., 1987], which lets a compu-
tation suspend as soon as it encounters a free “logic” variable. The logic resolution
uses parallel execution techniques.
Reduction takes place for evaluating set expressions and plain expressions. Reso-
lution is done when a reduced set value vis tested for membership, p
×
v. “Parallel
or” is not provided – disjunctions are executed from left to right, thus enabling
backtracking techniques for their implementation.
For defining the RCM, we first specify values, a subset of expressions. Though values
are still represented symbolically, we will later see in Chapter 5 that they correspond to
an efficient representation in an implementation. We then define a set of inference rules
which describe computation.
4.4 The Reference Computation Model 87
v
×
EXPV
ikj
v
o
G~
v
3
p
l
.
v
5×
CTR
|
Ã
k
lkÄ
G
S-
lkÊ
G
S
|7×
VALASS
}
VAR
ó
EXPV
m
å
CTR
CTR
Ã
?@
VALASS
@
EXPP
CTR
ì´
Æíw
CTR
VAR
VALASS
CTR
ó
CTR
|
j
~
lkÊ
S
oÕ
j|
l
o
ÊVj|
S
o
|
j
~
lkÄ
S
oÕ
j|
l
o
ÄVj|
S
o
|
j|
Ô
Ã
k
o
j|}Ï|
Ô
oHÃ
k
ÍÏÎ
¸'и
|ñmB|
Ô
VALASS
5
lUm
z
S
CTR
bk
EXPP
´
wzw
CTR
ó
VALASS
´
wzwWj
lÊ
G
S
oÖ ´
wzw
¡
l%
´
w¢w
¡
S
´
wzwWj
lÄ
G
S
oÖ ´
wzw
¡
l%
´
w¢w
¡
S
´
wzwÕ|
Ã
k
|
ÍÏÎ
¸'и
|
VALASS
5
lUm
z
S
CTR
bk
EXPP
UVCTX
m
IVCTX
2j
@
EXPV
EXP
o
m ÷
ñj
EXP
VALASS
EXP
o
m ÷
ñj
EXP
VALASS
VALASS
EXP
o
Figure 4.12: Values and Constraints
4.4.1 Values and Constraints
Values are a subset of normalized expressions, enriched by a tailored representation of a
schema-like construct, called an intension. An intension consists of a pattern and a con-
straint. A basic constraint,
|
Ã
k
, is a value assignment paired with a property expression.
Constraints may be composed by conjunction and by disjunction, though we expect only
conjunctions in intensions (disjunctions are needed later on). The definitions, together
with some auxiliary functions on constraints and values, are given in Figure 4.12.
An intension
p
|
Ã
¢k¡
can be interpreted as the schema
~
p
¶w^'w)|
£k
¾
. However,
there are a few differences. First, it is possible that the above expansion results in an
infinite term, since
|
may contain an assignment referring to the intension itself. This
circularity of assignments is used to express fixed-points in the computation model. Sec-
ond, the property
k
may contain free variables which are bound neither by pnor by
|
.
These variables may be considered “locally existential” for the intension, and are used to
represent hiding translations by intensions. When an intension is instantiated in a context,
then these variables need to be renamed away from the variables of the context.
Some auxiliary functions for working with constraints are introduced. We write
for a conjunction of constraints, and
å
for a disjunction. For a sequence of basic con-
straints,
|
Ã
is written. The set of free variables used in a constraint can be retrieved by
ì´
Æíw
>
.
|
describes the propagation of an assignment into a constraint, and distributesover
88 Computation in
Z
conjunction and disjunction. For a basic constraint, we have
|
j|
Ã
¡k
o
j:|}Ï|
Ô
oÕÃ
+k
.
Here, propagation is only defined if
|}Ï|
Ô
yields a proper function. This is only the case
if, in their common domain, both assignments map to the same value (or the common
domain is empty).
Given a constraint, its overall assignment is selected with the function
´
w¢w
+
. The
assignment
´
w¢w
¡
is only defined if the union of the assignments of the subconstraints
yields a proper function.
Some auxiliary functions for working with values are required. Value union and inter-
section contexts,
j
×
UVCTX and
j
×
IVCTX, are a special case of general union and
intersection contexts, UNCTX and INCTX, but expect the sequence elements to be values.
In Section 4.1 (on page 72) we defined a (partial) extensional equality and extensional
unequality. These definitions carry over to values. As schemas can not be decided as
equal or unequal, intensions cannot. On the basis of value equality and unequality, a uni-
fication for “extended patterns”, built from constructor application, variables and values,
and written as p
l
p
, is assumed. This unification uses
for comparing values
found at the bottom of constructor terms. The form p
l÷
p
decides whether unification
fails (using
÷
). The notation p
l)
e
p
“refines” the assignment
|
to the assignment
|
Ô
by the result of unifying
wf'w)|
p
l
with
wf'w)|
p
: similarly p
l5÷
e
p
for the failure
case.
In principle, more powerful notions of unification can be embedded in our computa-
tion model (e.g. set unification). This would require some technical modifications to the
rules given in the next section to deal with sets of unifiers returned by unification instead
of a single unifier.
4.4.2 Computation
Computation is defined by two relations, which are mutually dependent. The first relation,
e
g
Ó
¤
e
Ô
, describes a strict reduction step on expressions under the value assignment
|
. It
cannot be applied to unbound variables, which means, in the context of its usage, that the
corresponding computation “suspends”. The relation e
g
Ó
¤
e
Ô
has indeterminism, but it
is “don’t care”: an implementation can choose some arbitrary fixed order to implement
reduction.
The second relation,
¥§¦¨
Ô
, describes a resolution step by mapping a constraint
onto a constraint.
is expected to be in disjunctive normal form, and
Ô
will be, too.
The indeterminism in this relation (provided it does not result from recursive application
of e
g
hÓ
©¤
e
Ô
) is “don’t know”. Thus, an implementation has to provide a concurrent
(interleaving) application strategy.
g
ÑÓ
¤
2j
EXP
VALASS
EXP
o
§¦
CTR
S
CTR
We expect that, before computation starts, expressions will be normalized to disjunc-
tive normal form, as specified by the function
u'ÆÈ{
ein Section 4.2. However, during
computation, no renormalization is necessary. Thus normalization can be done at “com-
pile time”. In contrast to the narrowing semantics, where simplification is an intrinsic
part of normalization, the strict computation model does not actually depend on initial
4.4 The Reference Computation Model 89
¤
l
e
g
Ó
ª¤
e
Ô
c
e
g
Ó
ª¤!c
e
Ô
e
c
e
e
EXP
VALASS
«
SREDEX
Figure 4.13: Strict Context Reduction
¤
S
x
×9¼'½»{"|
x
g
hÓ
¤
|
x
x
VAR
VALASS
¤(
ì´
Æíw
e
ð
ì´
ÆMw
p
¿¼'½»{9|
~
p
e
g
Ó
¤«
p
|
Ã
e
p
PAT
e
EXP
VALASS
¤2
p
e
v
e
e
g
hÓ
¤
e
l
e
g
Ó
ª¤
nSndn
en
e
g
Ó
¤
v
é%ê
p
ë
e
g
hÓ
©¤
v
p
PAT
e
EXP
c
e
VALASS
v
EXPV
Figure 4.14: Variable, Schema, and Fixed-Point Reduction
simplifications. The essential conditions are that properties of schemas are normalized,
as described in Section 4.2 (on page 74), and complement is pushed.
Expression Reduction Rules
Rule
¬
G®
in Figure 4.13 describes an inductive reduction step in a strict expression context,
c
×
SREDEX
ð
EXP
EXP. A strict context
c
is specified as with the strict narrow-
ing semantics. As explained above, the freedom of choice in selecting a strict redex in
expression reduction amounts to “don’t care” indeterminism instead of “don’t know”.
The rules in Figure 4.14 model the step where an expression is converted into a value.
Rule
¬
ñö
describes the substitution of a variable, which will only be possible if the variable
is bound by
|
. This is one source of “suspension”. Rule
¬e
reduces a schema to an
intension. The rule is only applicable if free variables of the property are either bound
by the pattern or by the substitution – i.e. variables from outer scopes are not allowed
to be free. This is the other source of “suspension”. Rule
¬p
describes the construction
of a fixed-point. The rule is cyclic in its premise, forestalling the resulting value vin an
assignment
|
Ô
which is used to calculate this value (the usual technique used in natural
semantics for constructing fixed-points). A finite number of reduction steps is required to
map the expression eto a value v: the expression emay contain several schemas, and the
value form is not reached until all these schemas have been converted to intensions.
The rules in Figure 4.15 describe the reduction of translation and complement. Rule
¬s
converts a translation into an intension. It exploits the possibility of using existential
variables in an intensions constraint: p
l
may contain variablesnot bounded by p
. Rule
¬o
describes the translation of a complement into an intension.
The rules in Figure 4.16 (on the next page) describe the evaluation of set operators
¤
u
v
Ã
p
lGÒÓ
p
BÅ
g
ÑÓ
¤«
p
:
Ã
p
lÕ×
v
v
EXPV
p
c
p
PAT
VALASS
¤
w
x
×
fresh
v
g
Ó
¤«
x
:
Ã
j
x
×
v
o
v
EXPV
x
VAR
VALASS
Figure 4.15: Translation and Complement Reduction
90 Computation in
Z
¤
x
j
A
È
_C
g
ÑÓ
¤®j
ADC
VALASS
j
UVCTX
¤
{
v
lk
v
j
A
v
lUm
v
C
g
hÓ
©¤®j
A
v
l
fC
v
c
v
EXPV
VALASS
j
UVCTX
¤
|
j
®A
È
¯C
g
hÓ
¤
)
VALASS
j
UVCTX
¤
l
~}
v
l÷
v
j
®A
v
l^m
v
yC
g
Ó
¤
}
v
c
v
EXPV
VALASS
j
UVCTX
¤
løl
v
lÑ
v
j
®A
v
ldm
v
C
g
hÓ
¤ j
¨A
v
l
zC
v
c
v
EXPV
VALASS
j
UVCTX
¤
lÈ
p
lA
e
p
exvs
ì´
Æíw
/
Sñæ
ì´
ÆMw
p
S
'
×
exvs
fresh
j®A?
p
l)
l
l
?
Sm
@
p
}
S
fC
g
Ó
¤¨j°A?
=wf'w)|
Ô
p
l)|
Ô
j
~
lkÄÉj
Y
S
o¢o
C
p
c
p
PAT
±
c
±
CTR
c
e
VALASS
exvs
²
VAR
VALASS
j
IVCTX
¤
l
~(
p
l÷
e
p
j
®Ai
p
l,
v
l
m
p
S
fC
g
Ó
ª¤
}
p
c
p
PAT
±
c
±
CTR
c
e
VALASS
j
IVCTX
¤
l
2
j®A
v
lk
v
yC
g
Ó
¤°A
v
l
zC
k
®A
v
C
v
c
v
EXPV
c
e
VALASS
j
IVCTX
Figure 4.16: Set Value Reduction
¤
l
u
x
×
fresh
v
g
Ó
¤
)
¤
j
x
m
:
Ã
x
×
v
o
v
EXPV
x
VAR
VALASS
¤
l
w
§§¦d
Ô
¤
j
x
m
z
o
g
Ó
¤
¤
j
x
m
z
Ô
o
x
VAR
VALASS
±
c
±
e
CTR
¤
l
x
|
E1
q
M
i
¼'½»{ |
±
x
×9¼'½»{$j |
i
o
M
i
m
j
¼'½»{ |
±
|
ix
|
jx
¤
j
x
m
å
j|
Ã
ÿ
o¢o
g
Ó
¤
|®
x
x
VAR
VALASS
UWVYX
VALASS
Figure 4.17: Mu-Value Reduction
on set values. Rules
¬
to
¬q
describe the elimination of tautologies in a union of set
values; Rules
¬r
to
¬
G®D®
for the intersection of set values. Rules
¬
G®ö
and
¬
H®
e
model the
combination of intensional values by intersection: if the patterns can be unified, then we
simply concatenate the constraints of the intensions, making local existential variables
disjoint by a renaming
into fresh variables. If the patterns do not unify, the intersection
reduces to
. Finally, Rule
¬
G®
p
describes the distribution of intersection over unionvalues.
It should be noted that, in an implementation, intersection can be realized more efficiently
as suggested by the rules: given a total order on values and set values in a normalized
form
~
v
Ö
p
, the intersection of two such values can be realized by processing
the extensional part, v, in linear time, and then the combinations with the intensional part.
The remaining rules in Figure 4.17 describe the handling of the
-operator. Once
the argument of
has been reduced to a value v, the elements of vare enumerated by
resolving a constraint x
×
v. The state of this subresolution is stored in an intermediate
expression construct,
¤
j
x
m
z
o
. When the subresolution is in solved form,
å
j |
Ã
ÿ
o
, a
4.4 The Reference Computation Model 91
¦
Sl
£§¦
å
Ô
å
j |
Ã
ÿ
=³
A~vC
³
o
§¦
å
j |
Ã
ÿ
=³
Ô
³
o
±
CTR
±
c
±
e
UZVYX
CTR
UZVYX
VALASS
¦
d
å
j
A
|
Ã
ä
_C
³
o
§¦
å
VALASS
±
UWVYX
CTR
¦(
j
[chA
|
Ã
ä
_C
o
§¦
V|
Ã
ä
VALASS
«
´fµ¶·
CTR
¦y2
j
[chA
|
Ã
ÿ
C
o
§¦
j
[cdA~C
o
VALASS
«
´fµ¶·
CTR
¦
u
©§¦
å
n
j
YcdA~vC
o
§¦
å
A
´
wzw(j
Ö®
o
j
[cEA
Ö®
C
o
mSnSnSn(m
´
wzwWj
n
o
j
[chA
n
C
o
C
±
CTR
±
UWV[X
CTR
«
´fµ¶·
CTR
n
¸
Figure 4.18: Compound Constraint Resolution
¦
w
e
g
Ó
¤
e
Ô
|
Ã
p
×
e
§¦
V|
Ã
p
×
e
Ô
VALASS
e
c
e
e
EXP
p
PAT
¦
x
e
g
Ó
¤
e
Ô
|
Ã
se
§¦
V|
Ã
se
Ô
VALASS
e
c
e
e
EXP
s
c
¦
Figure 4.19: Expression Reduction in Constraints
unique assignment for xis extracted, if it exists.
Constraint Resolution Rules
Compound constraints are resolved by the rules in Figure 4.18. Rule
¹
ñ®
describes the
left-to-right resolution of disjunctive constraints, Rule
¹
¾ö
the elimination of unsolvable
constraints. Rules
¹ne
and
¹ºp
describe the elimination of unsolvableand solved constraints
in a conjunction. Rule
¹ns
describes a resolution step of a basic constraint in a conjunction,
where S
A~C
is a sequence context. This rule models the concurrent execution of constraints
by “interleaving”. An arbitrary basic constraint is selected (remember that constraints are
in DNF) and resolved one step, possibly yielding a disjunction. Maintaining the DNF by
pushing the conjunctive context
c
over each member of the disjunction corresponds to
backtracking in an implementation. The assignments of the conjuncts,
i, are propagated
over
c
, such that a steady refinement of the assignments is guaranteed.
The rules in Figure 4.19 describe the reduction of expressions in basic constraints.
These rules are only able to fire if all free variables in eare bounded by
|
– otherwise
e
g
Ó
¤
e
Ô
is “suspended”.
The rules in Figure 4.20 (on the next page) describe the resolution of pattern mem-
bership in readily reduced set values, and resolution of equality constraints. Rule
¹ºq
decomposes the membership test on a union of values into a disjunctive constraint. This
is the only way basic constraints can rewrite into disjunctions, thereby introducing the
need for backtracking. Rules
¹nr
and
¹
ñ®q
describe a basic resolution step, reducing a
membership test on a singleton set to an assignment or a failure. Rules
¹
ñ®D®
and
¹
2®ö
describe the resolution of a membership test on an intension. Variables used in the inten-
sion’s pattern and constraint are renamed by
to fresh ones. Rules
¹
2®
0e
and
¹
ñ®
p
model
the resolution of a pattern equality.
The remaining rules in Figure 4.21 (on the following page) describe the resolution of
92 Computation in
Z
¦
{
|
Ã
p
×òj
v
lk
v
o
§¦
Fj:|
Ã
p
×
v
l
o
Ê j|
Ã
p
×
v
o
VALASS
p
PAT
v
c
v
EXPV
¦
|
p
e
v
|
Ã
p
×F~
v
»§¦
9|
Ô
Ã
ÿ
c
e
VALASS
p
PAT
v
EXPV
¦
Sl
~}
p
÷
e
v
|
Ã
p
× ~
v
§¦
V|
Ã
ä
c
e
VALASS
p
PAT
v
EXPV
¦
Sløl
×
ì´
Æíw
>
Õ
ì´
Æíw
p
Ô
fresh
p
e
w^'w
p
Ô
|
Ã
p
×
p
Ô
¼§¦
9|
Ô
j
Y
o
c
e
VALASS
p
c
p
e
PAT
±
CTR
VALASS
¦
SlÈ
×
ì´
Æíw
p
Ô
fresh
p
÷
e
w^'w
!
p
Ô
|
Ã
p
×
p
Ô
§¦
V|
Ã
ä
c
e
VALASS
p
c
p
e
PAT
±
CTR
VALASS
¦
Sl
~(
p
lG
e
p
|
Ã
p
l
p
½§¦
V|
Ô
Ã
ÿ
c
e
VALASS
p
c
p
PAT
¦
Sl
2
p
l÷
e
p
|
Ã
p
l
p
§¦
V|
Ã
ä
c
e
VALASS
p
c
p
PAT
Figure 4.20: Membership and Equality Resolution
¦
Sl
u
x
×
fresh
|
Ã
sv
§¦
|
Ã
s
j
x
m
:
Ã
x
×
v
o
¦
VALASS
v
EXPV
x
VAR
s
c
¦
¦
Sl
w
§§¦d
Ô
|
Ã
s
j
x
m
z
o
¦£§¦
|
Ã
s
j
x
m
z
Ô
o
¦
VALASS
x
VAR
±
c
±
e
CTR
s
c
¦
¦
l
x
|
Ã
s
j
x
m
å
j
A
|
Ô
Ã
ÿ
C
³
oÚo
¦£§¦
V|
Ã
s
c
e
VALASS
x
VAR
±
UZVYX
CTR
s
c
¦
¦
Sl
{
|
Ã
s
j
x
mÚ|
Ô
Ã
ä
o
¦¾§¦
V|
Ã
compls
c
e
VALASS
x
VAR
±
UWV[X
CTR
s
c
¦
Figure 4.21: Test-Emptiness Resolution
set tests,
sv, where the tested set has been reduced to a value. Similar to the treatment
of
in expression reduction, a subresolution is started which enumerates the elements
of the set vby resolving the constraint x
×
v. The state of this resolution is stored in an
intermediate property expression,
s
j
x
m
z
o
¦
, where sis either
ÿ
or
, depending on the pole
of the test. The test succeeds (or fails, depending on s) if at least one constraint can be
solved; it fails (or succeeds) if no constraint can be solved (which requires enumerating
the entire set).
4.5 Discussion 93
4.5 Discussion
We have developed several models for computation in
Z. Further points and related
work are discussed below.
Normalization and Simplification
Normalization has been defined as a prerequisite for any kind of computation, and will
be also required for compilation in the next chapter. Applying normalization ensures that
negative information is distributed as far as possible to the leaves of expressions, enabling
resolution techniques in the lifted positive contexts. Local resolution can be used in the
remaining (minimized) negative contexts. Universal quantification, which is represented
in
Zas the combination of complement and hiding, is, for example, solved by local
resolution.
A well-known problem of normalization toward a disjunctive normal form is the ex-
plosion of the expression size. This is one reason why we interleaved normalization
with simplification: pruning this explosion early. As a rule of thumb, “sensitive”
Z
expressions do not explode if simplification is interleaved with DNF production. How-
ever, pathological cases might still cause serious problems. Temporary variables may be
used to avoid the explosion of the DNF. For example, the expression e
Vj
e
lÑ
e
o
can be
normalized to the form:
j»~äj
x
m
t
o
x
e
t
V~
e
lk
e
S
Ã
t
ÒÓ j m
t
o
Å
ofÃ
j
x
m
o
ÒÓ
x
Å
With this technique, expression sharing can also be preserved, and new sharing poten-
tials can be exploited using common subexpression elimination. However, the technique
also has its disadvantages: the number of constraints increases and the introduction of
new temporary variables implies administrative overhead for binding and accessing these
variables.
An alternative approach for avoiding explosion of expression size on normalization
is to use directed acylcic graphs (DAGs) with optimal sharing for representing expres-
sions. Structurally equal expressions do not appear twice in such a DAG. It is known
e.g. from symbolic model checking [McMillan, 1993] that, for boolean algebras, quite
efficient algorithms for constructing and maintaining this representation exist. However,
further experiments are required, particularly regarding the treatment of the non-Boolean
operators of
Z, like translation,
-selection, etc.
Narrowing
Narrowing can be elegantly expressed in
Z’s framework by pure expression transforma-
tion, combining normalization and simplification with substitution, membership lifting
and unrolling. This is a result of the “higher-orderness” of the
Zcalculus, which allows
us to represent “meta” information, like the set of (partial) solutions, by expressions of
the calculus itself.
In rule based functional logic languages, solutions are represented as substitutions
on the meta level. Here, narrowing is defined as follows (see Hanus [1994] for a sur-
vey): given a (nonground) goal expression, a subexpression is selected which unifies
94 Computation in
Z
with the left-hand side of some rule under a minimal substitution, and is replaced by its
right-hand side instantiated with the substitution. The substitution is then applied to the
entire expression. At a first sight, this looks different from what we call narrowing in
Z. However, the same elements are, in fact, present as a special case in
Z. The “rules”
belonging to a function or relation symbol are simply represented as a union of schemas,
R
~
p
l}
e
lUG nSndnÇ9~
pn
en
. A “goal” is then merely the intersection of Rwith some
(partial) data binding, represented by a (translated) singleton set: R
@~
e
Ã
p
lAÒÓ
p
BÅ
. Rule
“selection” is represented by distributing the singleton set over the union Rand perform-
ing property substitution. Each member of the resulting union is part of the explicitly
represented search space, which, in narrowing for rule-based languages, is coded in the
nondeterminism of the narrowing relation.
As e.g. demonstrated by Hanus [1994], modifying the selection strategy for the next
redex in narrowing is a powerful tool for investigating variations of computation. This
technique has been applied to our version of narrowing in
Zas well, defining general
narrowing, outermost-in narrowing and strict narrowing. Strict narrowing is the oper-
ational semantics of choice for
Zbecause outermost-in narrowing lacks a transparent
definition of forcing in
Z.
We have not formalized a strategy for needed narrowing [Antony et al., 1994], which
can be considered “state-of-the-art” for narrowing in functional logic languages, since it
yields certain optimality results regarding the length of derivations. Needed narrowing is
expressible in our framework. Consider a goal like
jx~
p
l6
e
lUG nSnSnB@~
pn
en
o
9~
e
:
needed narrowing would mean that before distribution we force eas far as required by
every pi–i.e. to the shallow structure of the most special pattern, where each piis a spe-
cialization of. In the worst case, this pattern is just a variable, so that no forcing happens.
Actually, we have “definitional trees” [Antony,1992], as used for defining needed narrow-
ing, directly in the calculus, because we have set union and schemas. However, it seemed
more important to support extensional equality, which obstructs a transparent notion of
forcing for needed narrowing. We should note that extensional equality and unequality is
only required to deal with sets of sets – for example for reducing
~'~
e
lU G@~'~
e
S
to
,
if e
l
and e
reduce to an extensionally unequal value. If
Z’s computation model would
be restricted to not use extensional equality and unequality, as it is the default in other
frameworks, lazy or needed narrowing could be easily adapted.
Reference Computation Model
The reference computation model given in Section 4.4 (on page 86), using the technique
of natural semantics, is a trade-off between computation power and execution efficiency.
It prepares a straight-forward transition to an implementation by the abstract machine
ZAM, as shown in the next chapter. The model is even more strict than in strict narrowing,
using a combination of functional reduction by residuation [Ait-Kaci et al., 1987] and
logic resolution. The justification for this decision is, on the one hand, easier traceability
of execution by humans, which is important for the application to test data evaluation,
and, on the other hand, a strongly assumed better overall performance. The last point
draws on experience with functional programming and language implementation: the
theoretical result of optimality of lazy or needed reduction does not coincide with the
practical experience, because the overhead of laziness has to be paid for significantly,
4.5 Discussion 95
which often results in that programmers use strictness annotations [Hartel et al., 1996].
The RCM is related to the one described by Hanus [1997] for Curry. Set values in
our semantics,
~
v
p
, are comparable to the “definitional trees” used here
and in work about narrowing. However, since set values are first-order inhabitants of the
operational domain, which definitional trees are not, they can be combined by intersection
and union at computation time, and, moreover, augmented by extensional data. This is
important in the realm of set-based programming, where sets, relations and functions are
often used for representing data structures, which are incrementally constructed.
Unlike the model of Hanus [1997], subresolutions are supported, which are invoked
from expression reduction for the
-operator and for dealing with set tests. This tech-
nique corresponds to “deep guards” and “encapsulated search”, as found, for example,
in the computation model of Oz [Smolka, 1994a] or
~
log
[Dovier et al., 1996]. Our
computation model has some similarities to the one given for Oz by Smolka [1994a].
The so-called “computation spaces” in this work, which represent a constraint store, are
given in our model as a conjunction of properties paired with assignments. Writing to
the constraint store is equivalent in our model to a resolution step, which updates the as-
signments. A subspace is opened when a subresolution is started for the
-operator or
emptiness-tests. However, as discussed in the previous chapter, there is no equivalent to
committed choice in
Zand its computation model.
Computing More
The computation models we have presented are not the end of the story. There are three
major potential ways of increasing computation power which are not considered here:
higher-order unification (or narrowing), set unification and subset logic programming.
Higher-order unification [Snyder and Gallier, 1989] is used in theorem provers such
as Isabelle [Paulson, 1994] for the highly generic formulation of inference rules. Higher-
order narrowing is proposed as an extension for functional logic languages [Prehofer,
1994; Hanus and Prehofer, 1999] or logic languages such as
¬
Prolog [Nadathur and
Miller, 1988]. The underlying idea of both applications is to extend unification to the
synthesis of
¬
-terms. Substitution is then augmented by
O
-reduction. Carrying this po-
tential over to
Zwould require to synthesize schemas during unification, which needs a
generalization of higher-order unification that deals only with functions.
Unification over (finite) sets extends unification on free term algebras to the nonfree
algebra of sets, and amounts, technically, to unification modulo an associative, commu-
tative and idempotent equational theory [Siekmann, 1989]. Algorithms and complex-
ity investigations are found, e.g., in [Spratt, 1996; Arenas-Sanchez and Dovier, 1997;
Stolzenburg, 1999]. Adapting these techniques to
Zwould allow unification on the ex-
tensional part of sets. For example, let S
~äj
x
m
y
m
z
o
z
x
y
. If we are going to bind
the variable zto an extensional set, then, with set unification, we expect that xand yare
assigned all possible partitions of z. Because of idempotency of set union, these partitions
are not necessarily disjoint, which makes up the computational complexity of set unifi-
cation. Leaving aside efficiency considerations, for the framework of
Zan integrated
unification method is ultimately required, which combines higher-order unification with
set-unification, yielding an algorithm that can deal with extensional as well as intensional
set representations. More research needs to be done in this direction.
96 Computation in
Z
The major computation potential subset logic programming adds to the mentioned
techniques is extending fixed-point construction from equationsto subset relations [Moon,
1997; Jayaraman and Moon, 1999]. This technique allows us to compute the smallest
set satisfying cyclic subset constraints. The computation of such fixed-points is quite
complex, in the general case. Moon [1997] uses memoization techniques for relations
to make it feasible. His model is first-order, and further investigation of its possible
integration in the higher-order framework of
Zis required.
Chapter 5
Abstract Machine
Mit anderen kann man sich belehren,
Begeistert wird man nur allein.
(Goethe)
This chapter describes an abstract machine, called ZAM, a compilation of
Zto the ma-
chine’s instruction set and an implementation of the machine in C++. The ZAM realizes
the reference computation model (RCM) defined in Section 4.4 (on page 86) in the previ-
ous chapter. Its specification in Z is on a level of abstraction that addresses the issues of
efficient implementation but is still sufficiently concise to reason about the machine.
The ZAM uses concurrently executing threads for constraint resolution (modeling the
relation
§¦
of the RCM). Each thread has a local value stack for expression reduction
(modeling
g
Ó
ª¤
). In the current implementation ofthe ZAMin C++, the stack is in fact
mapped to registers (which is possible because its size is bound), but for the machine’s
specification the stack model is better suited since it is more abstract.
The ZAM’s threads synchronize via variables: accessing an unbound variable sus-
pends a thread and binding a variable resumes threads waiting for it (called residuation,
[Ait-Kaci et al., 1987]). Backtracking is implemented by maintaining a choice point stack
which is shared by the threads working on a resolution goal. Choice points are created if
a thread executes a constraint p
×
v
l
v
: in this case, the thread continues its execution
with p
×
v
l
and creates a choice point for the alternative p
×
v
. A simple but powerful
optimization of the ZAM is to lower the scheduling priority of threads that try to create
choice points, giving preference to threads that can continue deterministically under the
current variable binding (called the “Andorra Principle”, [Warren, 1990]).
The compilation of
Zto ZAM instructions is based on the normalization of expres-
sions introduced in Chapter 4. Together with the stack-based machine model, this makes
it easy to formulate and retrace.
This chapter is organized as follows. First, we introduce the model of the ZAM,
defining its basic data types and instruction set. It follows a comprehensive specification
of the meaning of the instructions in Z’s sequential specification style. Next, we give
the compilation schema. Finally, we discuss the prototypical implementation of the ZAM
in C++, including optimizations such as implementing the reduction stack by registers.
Some first benchmarks of the implementation are given. The chapter concludes with a
discussion of the results and of related work.
98 Abstract Machine
VarInx
-
Value
Var
VarInx
Term
CONS
Value
Set
_?@
Value
@
Intension
Figure 5.1: ZAM Values
5.1 Basic Model of the ZAM
The basic model of the ZAM is described in this section. After defining the represen-
tation of values,goals and threads, the instructions are discussed informally. A formal
specification of the machine’s instructions is given in the next section.
5.1.1 Values
Figure 5.1 shows the basic types used by the ZAM to represent values. There are three
variants of values: variables (represented by an index in a variable table, as described
later on), terms and sets1.
A set value, Set
j
extens
m
intens
o
, consists of two sequences, the first containing the
extensional part of a set and the second the intensionalpart (the type Intension is described
in the next section – it corresponds to an intension of the RCM). Let vjbe the values in
extens and ikbe the intensions in intens; then a set value of the ZAM represents the set
value of the RCM
~
v
l^H nSndnÇ9~
vn
H
i
lk nSndnÇ
im
n
The ZAM’s representation is well suited for implementing the union and intersection of
sets:
±
For set union, we simply unite the extensional and intensional parts:
Set
j
extens
lUm
intens
l
o
Set
j
extens
Sm
intens
o
Set
j
extens
l
¿
extens
Sm
intens
l
9¿
intens
o
Here,
¿
denotes a suitable union function which conforms to extensional equality
in the RCM (cf. Section 4.1 (on page 72)). In an implementation, we would in fact
use ordered sequences for representing extens and intens, and their union could thus
be implemented with linear time complexity.
±
Set intersection is realized as follows (using
Z’s notation for intensions):
Set
j
extens
lUm
intens
l
o
Set
j
extens
Um
intens
o
Set
j
extens
l
À
extens
m
A?
x
x
×
Set
j
extens
lUm
0ADC
o
Ä
x
×
Set
j
fA~C
Um
intens
o
m
x
x
×
Set
j
extens
Sm
0ADC
o
Ä
x
×
Set
j
fA~C
Um
intens
l
o
m
x
x
×
Set
j
ADC
Um
intens
l
o
Ä
x
×
Set
j
fADC
^m
intens
o
yC
o
1In fact, there is also a fourth variant for representing native values such as numbers; this, however, is
not relevant to the conceptual model of the ZAM.
5.1 Basic Model of the ZAM 99
Code
Á@
Instruction
Intension
varcnt
-
pat
Value
env
?@
j
GoalInx
VarInx
o
params
Value
constrs
Code
Figure 5.2: ZAM Intensions
Thus we can construct the disjunctive normal form of intersected set values in a
constant number of steps. If any of the extensior intensiis empty, the above con-
struction can be further optimized, since in this case the corresponding constructed
intension is known to denote the empty set and can be dropped. In particular, if
both sets are completely extensional, we need to compute only the intersection
À
,
which – in an implementation by ordered sequences – can be done in linear time.
5.1.2 Intensions
An intension (Figure 5.2) is described by the count of variables it allocates for its exe-
cution, a value (representing the pattern in an
Zintension
p
), a sequence of index
references representing the environment the intension was constructed in, a sequence of
values describing parameters and a sequence of constraints. A constraint is given by a
sequence of instructions.
Instantiation. When an intension is instantiated in a goal context (goals are discussed
in the next section), the number of variables it requires are allocated in a block of the
variable table of the goal context (variable tables are just a mapping from variable indices
to information about the state of the variable). Then, for each constraint of the intension,
a thread is spawned, parameterized by the offset of the allocated variable block. From the
executing thread, variables are accessed by adding a static offset found in the code to this
dynamic offset.
Consider, for example, the
Zintension
=ikj
x
m
y
o
5
l
Ã
x
m
z
Å}Ä
S
Ã
z
m
y
Å
W
. Here, zis a
“local existential” variable of the intension. This intension is represented in the ZAM as
Â
varcnt
e
»m
pat
Term
j:i m
A
Var
q»m
Var
®
C
o
m
env
nSnSn(m
params
}
nSnSnWm
constrs
A
l
Ã
q»mÇöÅÈm
f
Ã
ömS®dÅ
ÃCfÄ
where the offsets used for addressing the variables are
q
for x,
®
for y, and
ö
for z. The
reentrant instantiation of an intension is realized as follows: let varshift be the base offset
of the intension’s variable block in the instantiation context; then, we simply
±
“shift” the pattern pat, adding to each variable the offset varshift (resulting in
Term
j:i m
A
Var
j
varshift
Å
q
o
m
Var
j
varshift
Å
Ë®
o
C
o
)
100 Abstract Machine
±
store varshift in the threads that execute the constraints
l
and
S
, such that, for each
access to a variable from a thread, varshift is added to the static offset
q
,
®
or
ö
Environment. The environment of an intension, env, is a sequence of indices which
refer to pairs of goal indices (as discussed in the next section) and a variable block offset.
The environment allows access to the variables of the lexical enclosing goal contexts this
intension was created in.
For example, in the
Zexpression
é%ê
f
ë~äj
x
m
y
o
y
E
Ã
f
m
x
Å:
, the variable fis bound
by the enclosing fixed-point operator. fis accessed from the intension created for the
inner schema via the first element of env.
For schemas, the RCM demands that before an according intension can be con-
structed, all context variables are bound (cf. expression reduction rule
¬e
). However,
the situation is different for fixed-points (cf. Rule
¬p
): during the creation of an intension
for the fixed-point, the environment may contain “holes” which are bind immediately
after the intension has been created, constructing a circular dependency between the in-
tension and its environment. For this reason, it is not possible to directly represent the
environment by the bindings of the free variables. An extra level of indirection has to be
introduced using goal indices.
Parameters. The parameters of an intension, params, are used to pass values from the
creation context of an intension. In fact, parameters serve a purpose similar to that of
the environment; however, they can be used to pass temporary values which do not have
a variable counterpart in the context. On the other hand, parameters cannot have cyclic
dependencies to the intension they belong to.
5.1.3 Threads and Goals
Athread executes the code of a constraint. A goal is a collection of threads which to-
gether work on a set of variables and which share a stack of choice points (Figure 5.3 (on
the facing page)). A goal is created to execute an intension. During execution, further
intension may be dynamically instantiated in the context of a goal (corresponding to the
membership test of an element in an intension; cf. resolution rule
¹
2®D®
of the RCM.)
For threads and goals, the index types ThreadInx andGoalInx are defined, which allow
references of them via thread and goal tables defined in a configuration of the ZAM (see
next section)2.
A thread refers to two goals: the parent where it belongs to and a possible child,
describing a subresolution. In turn, a subgoal refers via its parent field to the thread that
executes it. Subgoal resolution corresponds to the execution of the
-operator (Rules
¬
G®
s
-
¬
H®
0
of the RCM) and the test for emptiness (Rules
¹
2®
s
-
¹
2®
0q
).
A thread may be in the status running, indicating that it has not yet finished its ex-
ecution, or it may be in one of the states success,failure or error, indicating that it has
stopped executing. The error status results from the execution of the
-operator on a
2Instead of using indices here, we could have well used a notion of memory and references. This would
complicate the declarative description of the ZAM in Z, however.
5.1 Basic Model of the ZAM 101
ThreadInx
H-
GoalInx
;-
Priority
~q»mS®
Status
running
failure
success
error
Thread
parent
m
child
GoalInx
prio
Priority
status
Status
env
?@
j
GoalInx
VarInx
o
params
?@
Value
stack
?@
Value
varshift
VarInx
code
Code
Goal
parentThread
ThreadInx
pat
Value
threads
ThreadInx
choices
Choice
vtab
VarInx
Æ
Binding
Binding
Free
+
ThreadInx
Bound
Value
Choice
bound
VarInx
dump
ThreadInx
Æ
?@
Value
Code
spawned
ThreadInx
Figure 5.3: ZAM Threads and Goals
nonsingleton set, or from the undecidable equality test of intensions in unification. failure
corresponds to failure in unification.
A thread inherits the environment of the intension whose constraint it executes as well
as the parameters (fields env and params).
A goal holds the set of threads spawned in its realm. The resolution represented by the
goal has succeeded if all its threads are in status success; it has failed if one of its threads
is in status failure.
A goal’s field vtab represents the variable table as a mapping from variable indices to
a value of type Binding. If a variable is free, a set of threads may be attached which are
waiting for the variable to become bound (variant Free of type Binding).
The field choices of a goal represents the choice stack. During execution of a thread,
whenever the thread encounters a constraint such as p
×
v
lk
v
, it continues execution
with p
×
v
l
and pushes a new choice to the stack, holding the information for the alter-
native p
×
v
and accumulating changes made to the goal which need to be undone on
backtracking:
±
bound indicates which variables were bound while this choice was active (the active
choice is the topmost one on the choice stack). Whenever a variable is bound during
unification, it is added to this set. On backtrack, these bindings are undone.
±
dump saves the (earliest) state of threads which have advanced during this choice
was active. Whenever a thread performs an execution step and has not yet dumped
102 Abstract Machine
Config
ttab
ThreadInx
Æ
Thread
gtab
GoalInx
Æ
Goal
root
GoalInx
active
ThreadInx
Figure 5.4: ZAM Configurations
its state to the active choice, it now does so. The dump of a thread is described by
its stack and by its current constraint (instruction stream). On backtracking, these
values are restored3.
Note that the mapping dump also contains the information to resume the thread
that initiated this goal with the next alternative, p
×
v
. For more details, see the
specification (Section 5.2 (on page 105)).
±
spawned describes the threads that have been spawned while this choice was active.
On backtracking, these threads are killed.
The ZAM uses a simple but efficient strategy for thread dumping: whenever a thread
executes its next instruction but has not yet dumped its state to the topmost choice, it now
does so. This is made possible by choice point scheduling. Only if no other threads can
continue (because all other threads are waiting for variables to become bound) is a thread
creating a choice point scheduled for execution. Thus, computations that are independent
of a particular choice are performed automatically before the corresponding choice point
is created.
5.1.4 Configurations
Aconfiguration describes the overall state of the ZAM (Figure 5.4). It contains tables of
threads and goals, the root goal and a sequence of thread indices describing the active
threads in the order they are to be scheduled (a formal specification of scheduling is given
in Section 5.2 (on page 105)).
In the specification of the ZAM, we assume that an unlimited number of threads and
goals can be allocated from the tables in a configuration. Similarly, we allocate from the
variable table of goals without trying to retrieve “unused” variables. In the implemen-
tation in C++, garbage-collection techniques are used to manage this requirement (cf.
Section 5.4 (on page 129)).
5.1.5 Instructions
The instructions of the ZAM are summarized in Figure 5.5 (on the facing page). Their
meaning is informally described below.
3Dumping the entire stack is indeed expansive. In the implementation in C++, instead of stacks for
storing temporaries, we use a “single assignment” register model, which makes dumping very efficient.
This is discussed in Section 5.4 (on page 129).
5.1 Basic Model of the ZAM 103
Instruction
LOAD
VarInx
WAIT
VarInx
LOADENV
+-
l
VarInx
LOADPAR
+-
l
STORE
VarInx
UNIFY
MEMBER
MKTERM
CONS
E-
¾
MKEMPTY
MKSINGLE
MKVAR
VarInx
MKINTEN
+-
É
E-
7
¼?@
Code
UNION
ISECT
TEST
TESTNATIVE
MU
SUCCESS
Figure 5.5: ZAM Instructions
Waiting for Variables. TheWAIT
j
inx
o
instruction lets the executingthread suspend un-
til the addressed variable (and all the variables it indirectly refers to by a possible binding)
are bound.
Loading Values. The LOAD
j
inx
o
instruction loads the variable with the given index
from the current goal’s variable table to the executing thread’s stack. If the variable is
bound (maps to the variant Boundval in the variable table), the bound value is pushed,
otherwise the term Varinx.
The LOADENV
j
dist
m
inx
o
instruction loads the value of the environment variable inx
to the stack, from the goal described by the lexical nesting distance dist. The environment
variable is accessed as follows: let thr be the executing thread and
j
goalInx
m
varshift
oH
thr
n
envdist the environment entry; then, the variable
j
config
n
goalsgoalInx
o
n
vtab
j
varshift
Å
inx
o
is selected. The addressed variable is expected to be bound, and its binding must not
refer to other free variables, which has to be guaranteed by the compilation scheme (thus
corresponding to the RCM, which ensures that intensions can only be created if context
variables are bound or become immediately bound after fixed-point construction).
TheLOADPAR
j
inx
o
instruction loads the parameter value indexedby inx (thr
n
paramsinx).
Storing and Unifying Values. The STORE
j
inx
o
instruction pops a value from the stack
and unifies it with the variable addressed by inx. The UNIFY instruction pops two values
from the stack and unifies them. If unification fails, the thread stops in status failure;
if unification is not decidable (for instance, because it requires the comparison of inten-
sions), it stops in status error.
104 Abstract Machine
Checking for Membership. The MEMBER instruction checks whether the value found
beneath the top of the stack is a member of the set on top of the stack. This instruction is
the only one that creates choice points.
Before execution of this instruction continues, the priority of the thread is lowered and
the thread suspends (if the priority is not already low). Then a choice point is created and
the thread proceeds as follows. Let Set
j
elems
m
intens
o
be the set on top of the stack, and u
the element beneath the top, for which membership is tested:
±
If
elems
intens
q
, the executing thread stops in status failure, after remov-
ing its choice point from the stack.
±
Otherwise, if elems
v
rest, then the top of the stack is replaced by v, and the
alternative Set
j
rest
m
intens
o
is recorded in the choice. Then. the thread behaves as
with the UNIFY instruction (the stack consists of v
u
nSnSn
at this time).
±
Otherwise, let
elems
q
and intens
inten
rest. The alternative Set
j
fADC
Um
rest
o
is
recorded in the choice and the intension inten is instantiated:
1. A block of inten
n
varcnt variables is allocated in the variable table of the goal.
Let the start index of this variable block be called varshift in the sequel.
2. The pattern inten
n
pat is “shifted” by adding to each variable the offset varshift
and pushed to the stack.
3. For each constraint in inten
n
constrs. a thread is spawned and initialized with
varshift. If the choice stack is not empty, then the new thread is added to the
set choice
n
spawned.
4. Thethread behaves as with theUNIFY instruction (the stack consists ofshift
j
inten
n
pat
m
varshift
o
u
at this time).
Constructing Values. The MKTERM
ji m
arity
o
instruction pops arity number of argu-
ments from the stack and pushes the value Term
ji m
args
o
to the stack. The MKVAR
j
inx
o
instruction pushes the value Varinx to the stack.
TheMKEMPTY instruction pushes the empty set, Set
j
ADC
Um
A~C
o
, to the stack. The MKSINGLE
instruction pops the value vfrom the stack and pushes a singleton set, Set
jz~
v
¶m
ADC
o
.
The MKINTEN
j
parcnt
m
varcnt
m
constrs
o
instruction creates a new intension inten and
pushes the set Set
j
fADC
UmU~
inten
o
to the stack. The instruction expects parcnt parameters
on the stack, which are stored in the params field. Above the parameters, on top of the
stack, the pattern of the intension is expected, which is stored in the pat field. The created
intension inherits its environment from the executing thread: let thr be this thread, then
inten
n
env
j
thr
n
parent
m
thr
n
varshift
o
thr
n
env. The constraints of the intension are given
by the sequence constrs.
Unionand Intersection. The UNION instruction pops two set values from the stack and
pushes their union, constructed as discussed in Section 5.1.1 (on page 98). The ISECT
instructions pops two set values and pushes their intersection.
5.2 Specification 105
Unique Selection. The MU instruction pops a value u
Set
j
elems
m
intens
o
from the
stack and behaves as follows:
±
If
elems
intens
q
, or if
elems
1
>®
, then the thread stops in status error.
±
If elems
~
v
and
intens
q
, then the thread pushes the value v.
±
Otherwise, a reference value is calculated: if elems
~
v
, the reference value
is v, otherwise it is the result of the first successful subresolution of one of the
intensions. Then, for all backtracks over all subresolutions of all intensions in the
set, it is checked whether they yield the same value as the reference value. If this
is the case, the reference value is pushed to the stack; otherwise, the thread stops in
status error.
For more details, the reader is referred to the specification of the ZAM’s instructions in
the next section.
Test for Emptiness/Nonemptiness. The TEST instruction pops a set value from the
stack and checks if it is nonempty. If so, it continues; otherwise, it stops in status failure.
The TESTNATIVE instruction fails if the value on the stack is empty.
The test of nonemptiness or emptiness immediately succeeds or fails if the set on the
stack has a nonempty extensional part. Otherwise, intensions in the set are tried to resolve
in a subresolution.
Succeeding. The SUCCESS instruction lets the executing thread stop in status Succeed.
5.2 Specification
In this section, the instructions of the ZAM are comprehensively specified in Z’s sequen-
tial specification style (cf. e.g. Woodcock and Davies [1996]). The specification is in-
tended to be executable by the ZAM itself.
5.2.1 Axiomatic Definitions
A set of axiomatic definitions for working with the data types of the ZAM is defined in
this section.
Working with Values
The auxiliary function shift offsv yields a value where offs is added to each variable’s in-
dex (Figure 5.6 (on the following page)). Since, by construction, variables cannot appear
in sets, the definition needs only to recurse over term values.
The auxiliary function freezevtabv returns a value where all variables in vwhich are
bound in vtab are replaced by their actual binding (Figure 5.7 (on the next page)).
The auxiliary function freev returns the set of indices of variables found in the value
v(Figure 5.8 (on the following page)). Variables are only expected to occur in terms, not
in sets.
106 Abstract Machine
shift
VarInx
Value
Value
shiftoffs
j
Vari
o ©
Var
j
i
Å
offs
o
j
Term
ji m
vs
oÚo%©
Term
ji m
shiftoffs
.
vs
o
v
©
v
ÍÏÎ
¸'и
offs
VarInx
v
Value
vs
@
Value
i
CONS
i
VarInx
Figure 5.6: Shifting Values
freeze
j
VarInx
Æ
Binding
o
Value
Value
freezevt
j
Vari
o ©
ùOú
0Ç
v
Ô
Value
i
×9¼'½{
vt
Ä
vti
Boundv
Ô
¹
Î
¸¶ü
freezevtv
Ô
¸¶·:ýd¸
Vari
j
Term
ji m
vs
oÚoW©
Term
j:i m
freezevt
.
vs
o
v
©
v
ÍÏÎ
¸'и
vt
VarInx
Æ
Binding
v
Value
vs
Value
i
CONS
i
VarInx
Figure 5.7: Freezing Values
Equality and Unification
The (partial) auxiliaryfunction equal
j
v
lUm
v
o
determines equalityof two values (Figure 5.9
(on the next page)). Confirming to extensional equality in
Z’s RCM, the function is
undefined if the values cannot be compared, which happens if sets are tried to compare
which have a nonempty intensional part.
The (partial) auxiliary function unify
j
vt
m
u
m
v
o
tries to unify the given values uand v,
under the variable table vt (Figure 5.10 (on page 108)). On success, the function returns a
new variable table and the set of indices of variables which have been bound. The defini-
tion is based on a function uni whose type is appropriate for sequence catamorphisms, and
a function uniVar which unifies a variable with a value. The function may be undefined
for similar reasons as the equal function (since it uses equal to determinate equality of
sets). The function uniVar makes an occurrence test before it binds a variable.
Merging and Joining Value Sequences
The auxiliary function vs
¿
us constructs the union of two value sequences, removing any
duplicates according to equal. It is undefined if equality is undefined (Figure 5.11). In
vars
Value
VarInx
vars Vari
©
~
i
Term
j:i m
vs
o¾©
~
v
Æ
´
u
vs
±
varsv
v
©
:
ÍÏÎ
¸'и
i
VarInx
v
Value
vs
v@
Value
i
CONS
Figure 5.8: Getting the Variables of a Value
5.2 Specification 107
equal
Value
Value
ó è
equal
j
Var i
m
Vari
o ©
sÇÆÈy
j
Term
ji m
vs
l
o
m
Term
j:i m
vs
o¢o%© Ã
vs
l
vs
d
M
i
¼'½{
vs
l
±
equal
j
vs
l
i
m
vs
i
o
Å
j
Set
j
es
lUm
A~C
o
m
Set
j
es
Um
ADC
o¢o © Ã
es
l
es
d
M
v
Æ
´
u
es
l
±
Þ
u
Æ
´
u
es
±
equal
j
v
m
u
o
Å
j
Set
j
es
lUm
is
l
o
m
Set
j
es
dm
is
o¢o ©
j
v
m
u
o © ²:´¶µ
w¢y
ÍÏÎ
¸'и
i
VarInx
Gi
CONS
vs
ldm
vs
?@
Value
es
ldm
es
Value
is
lUm
is
@
Intension
v
m
u
Value
Figure 5.9: Equality
order to remove undeterminism in the ordering of the result, we assume a (unspecified)
predicate someorder on value sequences. Similarly, the function vs
À
us constructs the
intersection of two value sequences.
Adding Information to Choices
The auxiliary function addBound adds information to the bound field of a choice, the
function addDump to the dump field and the function addSpawned to the spawned field
(Figure 5.12).
Ordering Index Sets
Sometimes, we require to order a finite set of indices (for variables, threads and goals).
The function orderinx implements some (fixed but arbitrary) order on index sets (Fig-
ure 5.13 (on page 109)), yielding a sequence containing the order.
5.2.2 Auxiliary Instructions
For representing internal states of threads auxiliary instructions are used. These can be
considered as a kind of “micro programs” implementing other instructions. For example,
let MEMBER
rest be the instruction stream of a thread. For executing the MEMBER
instruction, a choice point needs to be created, and the thread initiating the choice needs
to dump a state thatcontinues with an alternativeto the choice. We realize this bydumping
TRYNEXT
j
pat
m
extens
m
intens
o
rest
as the instruction state of the thread, where TRYNEXT is an auxiliary instruction executing
the next alternative (pat
×
Set
j
extens
m
intens
oÚo
. A similar technique is used for specifying
subresolutions of the MU,TEST, and TESTNATIVE instructions.
The auxiliary instructions are declared in Figure 5.14 (on page 109), and will be ex-
plained as they are used.
108 Abstract Machine
UniRes
v
Ok
j
VarInx
Æ
Binding
oA
%
VarInx
Fail
unify
j
VarInx
Æ
Binding
o
Value
Value
ó
UniRes
uni
j
Value
Value
oA
UniRes
ó
UniRes
uniVar
VarInx
Value
UniRes
ó
UniRes
unify
¬
vt
VarInx
Æ
Binding
u
m
v
Value
±
uni
j¢j
u
m
v
o
m
Ok
j
vt
m
:
$oÚo
uni
j¢j
u
m
v
o
m
Fail
o ©
Fail
Dj¢j
Vari
m
Vari
o
m
res
o ©
res
Dj¢j
Vari
m
v
o
m
res
o ©
uniVar
j
i
m
v
m
res
o
Dj¢j
u
m
Vari
o
m
res
o ©
uniVar
j
i
m
u
m
res
o
Dj¢j
Term
ji m
us
o
m
Term
j:i m
vs
o¢o
m
res
o¾©
ùOú
!
us
vs
¹
Î
¸äü
j
uni
m
res
o
¯È4É
t °Öj
us
m
vs
o
¸¶·ýU¸
Fail
Dj¢j
u
m
v
o
m
Ok
j
vt
m
b
o¢o ©
ùOú
equal
j
freezevtu
m
freezevtv
o
¹
Î
¸äü
Ok
j
vt
m
b
o
¸¶·ýU¸
Fail
ÍÏÎ
¸'и
u
m
v
Value
us
m
vs
Value
i
VarInx
i
CONS
res
UniRes
vt
VarInx
Æ
Binding
b
VarInx
uniVar
j
i
m
v
m
Ok
j
vt
m
b
oÚo(©
ù:ú
Ç
u
Value
vti
Bound u
¹
Î
¸¶ü
uni
jÚj
u
m
v
o
m
Ok
j
vt
m
b
oÚo
¸ä·:ýd¸
ùOú
i
8
×
vars
j
freezevtv
o
¹
Î
¸äü
Ok
j
vt
î
~
i
ÒÓ
Boundv
¶m
b
V~
i
o
¸¶·ýU¸
Fail
ÍÏÎ
¸'и
i
VarInx
v
Value
vt
VarInx
Æ
Binding
b
VarInx
Figure 5.10: Unification
¿
m
À
@
Value
¼
Value
ó
?@
Value
someorder
2j
Value
o
j
¿
o
j
vs
m
us
oW©
j
ws
Value
Æ
´
u
ws
~
w
Value
Þ
v
Æ
´
u
vs
@Æ
´
u
us
±
equal
j
w
m
v
o
¶
Ì4Þ
i
m
j
¼'½»{
ws
i
÷
j
±
equal
j
wsi
m
wsj
o
someorderws
o
ÍÏÎ
¸'и
vs
m
us
?@
Value
j
À
o
j
vs
m
us
oW©
j
ws
Value
Æ
´
u
ws
~
w
Value
Þ
v
Æ
´
u
vs
u
Æ
´
u
us
±
equal
j
w
m
v
o
Ä
equal
j
w
m
u
o
¶
Ì4Þ
i
m
j
¼'½»{
ws
i
÷
j
±
equal
j
wsi
m
wsj
o
someorderws
o
ÍÏÎ
¸'и
vs
m
us
?@
Value
Figure 5.11: Merging and Joining Value Sequences
5.2 Specification 109
addBound
VarInx
Choice
Choice
addDump
ThreadInx
Value
Code
Choice
Choice
addSpawned
ThreadInx
Choice
Choice
addBound
j
b
m
c
o¾©
LÊ
Ã
bound
Å
Choice
Choice
c
bound
Ô
bound
b
±
Choice
Ô
ÍÏÎ
¸'и
b
VarInx
c
Choice
addDump
j
t
m
stack
m
code
m
c
o(©
LÊ
Ã
dump
Å
Choice
Choice
c
dump
Ô
dump
î
~
t
ÒÓ j
stack
m
code
o
±
Choice
Ô
ÍÏÎ
¸'и
t
ThreadInx
stack
@
Value
code
Code
c
Choice
addSpawned
j
ts
m
c
o¾©
LÊ
Ã
spawned
Å
Choice
Choice
c
spawned
Ô
spawned
ts
±
Choice
Ô
ÍÏÎ
¸'и
ts
ThreadInx
c
Choice
Figure 5.12: Adding Information to Choices
orderinx
-
?@Ë-
Æ
´
uäj
orderinxs
oñ
s
ÍÏÎ
¸'и
s
I-
Figure 5.13: Ordering Index Sets
5.2.3 Execution Step and Selection
The state overwhich instructions are specified, and a single executionstep of the ZAM, are
defined in Figure 5.15 (on the next page). The state, called a selection, is an enrichment of
the ZAM’s configuration, Config, by the inclusion of those thread’s and goal’s data fields
which are selected for execution. The enrichment allows a direct access to these fields in
the specification, supporting Z’s sequential specification style.
The execution step of the ZAM chooses a thread to execute based on the order given
by the active sequence of a configuration and of thread priorities. It initializes the data
fields from the thread and goal tables, dispatches the instruction (dispatching is defined
later on), and stores the data fields contained in the selection back to the configuration.
In Figure 5.15 (on the following page), the signature of the operation Schedule is
Instruction
ndnSn
TRYNEXT
Value
¼?@
Value
@
Intension
SEARCH
SearchState
SearchMode
?@
Intension
SearchState
v
Select
Resume
Backtrack
SearchMode
v
MuFirst
MuNext
Value
Test
TestN
Figure 5.14: ZAM Auxiliary Instructions
110 Abstract Machine
Selection
Config
Goal
Thread
this
ThreadInx
instr
Instruction
Step
Schedule
Ì
Dispatch
Ì
Restore
Schedule
Ê
Ã
active
Å
Config
Selection
Ô
i
-
l
... . .. . . . . . .
active
1
òq
i
min
~
j
¼'½»{
active
M
k
¼'½»{
active
k
1
j
±
j
ttab
j
activek
o¢o
n
prio
Í
j
ttab
j
activej
o¢o
n
prio
this
Ô
activei
active
Ô
~
j
¼'½{
active
j
÷
i
Î
active
Thread
Ô
ttabthis
Ô
Goal
Ô
gtabparent
Ô
Restore
Ê
Ã
ttab
m
gtab
Å
Selection
ttab
Ô
ttab
î
~
this
ÒÓ j
~
Thread
o
gtab
Ô
gtab
î
~
parent
ÒÓ j
~
Goal
o
Figure 5.15: ZAM Execution Step
Ã
Ê
Config
Selection
Ô
Å
, the signature of the operation Dispatch is
Ã
Ê
Selection
Å
, and the
signature of the operation Restore is
Ã
Ê
Config
Selection
Å
. Thus the signature of the
overall Step is
Ã
Ê
Config
Å
: one configuration is mapped into the next one, with the help of
the intermediate data in the selection.
Dispatching is defined in Figure 5.16 (on the next page). The basic dispatch operation
is enclosed by two operations, PreDispatch and PostDispatch, which perform actions
common to the execution of every instruction:
±
PreDispatch dumps the executing thread’s state (stack and instruction stream) to
the active choice, if one exists and if a dump to this choice has not already been
performed (cf. discussion of dumping in Section 5.1.3 (on page 100)). It then loads
the next instruction into the instr field of the operation, and advances the instruction
stream, code.
±
PostDispatch checks whether the threads belonging to the current goal have fin-
ished. If this is the case, and the goal has a parent thread, this parent is resumed.
5.2.4 Instructions
The meaning of the instructions of the ZAM is specified in the sequel. The reader is
referred to Section 5.1.5 (on page 102) for an informal description of the instructions.
5.2 Specification 111
Dispatch
PreDispatch
Ì
BasicDispatch
Ì
PostDispatch
PreDispatch
Ê
Ã
choices
m
code
Å
Selection
ùOú
choices
1
òqÄ
this
8
×9¼'½»{$j
head choices
o
n
dump
¹
Î
¸äü
choices
Ô
addDump
j
this
m
stack
m
code
m
headchoices
o
tailchoices
¸¶·ýU¸
choices
Ô
choices
j
instr
m
code
Ô
oñ
j
head code
m
tailcode
o
BasicDispatch
}
XWait
Ê
XLoad
Ê
XLoadEnv
Ê
XStore
Ê
XUnify
Ê
XMember
Ê
XTryNext
Ê
XMkInten
Ê
XMkTerm
Ê
XMkEmpty
Ê
XMkSingle
Ê
XUnion
Ê
XIsect
Ê
XMu
Ê
XTest
Ê
XTestN
Ê
XSearch
Ê
XSuccess
PostDispatch
Ê
Ã
active
Å
Selection
ùOú
status
÷
running
Ä
j
M
t
¼'½»{
threads
t
÷
this
±
j
ttabt
o
n
status
÷
running
o
Ä
j
gtabparent
o
n
parentThread
÷
q
¹
Î
¸äü
active
Ô
active
j
gtabparent
o
n
parentThread
¸¶·ýU¸
active
Ô
active
Figure 5.16: ZAM Dispatching
XLoad
Ê
Ã
active
m
stack
Å
Selection
inx
VarInx
val
Value
... . .. . . . . . .
instr
LOAD
j
inx
o
val
ù:ú
Ç
v
Value
vtab
j
varshift
Å
inx
oñ
Bound v
¹
Î
¸¶ü
v
¸ä·:ýd¸
Var
j
varshift
Å
inx
o
stack
Ô
val
stack
active
Ô
active
this
Figure 5.17: The LOAD Instruction
The LOAD Instruction
The LOAD
j
inx
o
(Figure 5.17) instruction loads the variable, addressed by varshift
Å
inx,
or its binding, to the stack (recall that varshift is the offset added for the variable instances
of the executing thread).
112 Abstract Machine
XWait
Ê
Ã
active
m
vtab
m
code
Å
Selection
inx
m
cand
VarInx
cands
VarInx
... . .. . . . . . .
instr
WAIT
j
inx
o
cands
ùOú
Ç
v
Value
vtab
j
varshift
Å
inx
o
Boundv
¹
Î
¸¶ü
vars
j
freezevtabv
o
¸¶·:ýd¸
~
varshift
Å
inx
ùOú
cands
÷
;:
¹
Î
¸äü
cand
×
cands
vtab
Ô
vtab
î
~
cand
ÒÓ
Free
j¢j
Free
À
o
j
vtabcand
o
V~
this
o
code
Ô
WAIT
j
inx
o
code
active
Ô
active
¸¶·ýU¸
active
Ô
active
this
Figure 5.18: The WAIT Instruction
XLoadEnv
Ê
Ã
active
m
stack
Å
Selection
dist
-
ld
ginx
GoalInx
inx
m
vshift
VarInx
val
Value
... . .. . . . . . .
instr
LOADENV
j
dist
m
inx
o
j
ginx
m
vshift
oç
envdist
stack
Ô
freeze
j
gtabginx
o
n
vtab
j¢j
Bound
À
o
jÚj
gtabginx
o
n
vtab
j
vshift
Å
inx
o¢oÚo
stack
active
Ô
active
this
Figure 5.19: The LOADENV Instruction
The WAIT Instruction
The WAIT
j
inx
o
instruction (Figure 5.18) calculates the set of free variables, the index
varhshift
Å
inx refers to directly or indirectly. If this set is nonempty, it takes an arbitrary
one of it, adds the running thread to the waitingset of this variable, and prepares to execute
WAIT again when the thread is resumed. Otherwise, the thread just continues.
The LOADENV Instruction
The LOADENV
j
dist
m
inx
o
instruction loads the variable inx from the goal of the lexical
distance dist to the stack. The environment variable is expected to be bound, as well as
all variables its binding refers to. The loaded value is frozen using the variable table of
the goal context. Freezing is essential since the variable indices appearing in the binding
of the environment variable are local to the environment’s goal, and have no meaning in
the current context.
5.2 Specification 113
XUnify
Ê
Ã
stack
m
status
m
active
m
choices
Å
Selection
b
VarInx
... . .. . . . . . .
instr
UNIFY
stack
Ô
tail
j
tailstack
o
ùOú
Ìïj
vtab
m
stack
öäm
stack
®
o
×9¼'½»{
unify
¹
Î
¸äü
status
Ô
error
active
Ô
active
¸¶·ýU¸
ùOú
unify
j
vtab
m
stack
öm
stack
®
o
Fail
¹
Î
¸¶ü
status
Ô
failure
active
Ô
active
¸¶·:ýd¸
Ok
j
vtab
Ô
m
b
o
unify
j
vtab
m
stack
öm
stack
®
o
status
Ô
status
active
Ô
active
³
orderinx
j
~
i
b
±
j
Free
À
o
j
vtabi
o
oÑ
this
ùOú
K
choices
1
ïq
¹
Î
¸¶ü
choices
Ô
addBound
j
b
m
headchoices
o
tailchoices
¸¶·:ýd¸
choices
Ô
choices
Figure 5.20: The UNIFY Instruction
XStore
Ê
Ã
code
m
active
Å
Selection
inx
VarInx
... . .. . . . . . .
instr
STORE
j
inx
o
code
Ô
LOAD
j
inx
o
j
UNIFY
code
o
active
Ô
active
this
Figure 5.21: The STORE Instruction
The UNIFY Instruction
The UNIFY instruction (Figure 5.20) pops two values from the stack and unifies them. If
unification fails, the executing thread fails; if unification is undefined, the thread switches
to the error status. Otherwise, the variable table is updated, threads which are waiting
for the bound variables are resumed and – if the choice stack is not empty – the variables
bound by the unification are recorded in the active choice.
The STORE Instruction
TheSTORE
j
inx
o
instruction (Figure 5.21) isexplained by thecode substitution LOAD
j
inx
o
UNIFY.
The MEMBER Instruction
The MEMBER instruction (Figure 5.22 (on the following page)) is implemented by the
auxiliary instruction TRYNEXT. On execution of MEMBER, first the priority of the run-
ning thread is lowered, if it is not already low. Otherwise, a choice point is created, and
the instruction TRYNEXT is scheduled for execution.
114 Abstract Machine
XMember
Ê
Ã
prio
m
code
m
stack
m
choices
m
active
Å
Selection
es
@
Value
is
?@
Intension
... . .. . . . . . .
instr
MEMBER
ùOú
prio
1
òq
¹
Î
¸äü
prio
Ô
q
code
Ô
MEMBER
code
stack
Ô
stack
choices
Ô
choices
active
Ô
active
this
¸¶·ýU¸
Set
j
es
m
is
oç
head stack
choices
Ô
Â
bound
H:
m
dump
;:
m
spawned
H:
Ä
(
choices
code
Ô
TRYNEXT
j
head
j
tailstack
o
m
es
m
is
o
code
stack
Ô
tail
j
tailstack
o
prio
Ô
®
active
Ô
active
this
Figure 5.22: The MEMBER Instruction
XTryNext
XTryNextEmpty
Ê
XTryNextExten
Ê
XTryNextInten
XTryNextEmpty
Ê
Ã
choices
m
status
Å
Selection
p
Value
... . .. . . . . . .
instr
TRYNEXT
j
p
m
ADC
^m
ADC
o
choices
Ô
tailchoices
status
Ô
failure
Figure 5.23: The TRYNEXT Auxiliary Instruction: The Empty Case
The instruction TRYNEXT
j
p
m
es
m
is
o
is specified by three cases, depending on the value
of es and is. If both es and is are empty, the executing thread fails after removing the
corresponding choice from the choice stack (Figure 5.23).
If the extensional part of TRYNEXT
j
p
m
es
m
is
o
is not empty, one value is extracted, a
continuation with the remaining values is dumped to the choice, and pis unified with the
extracted value (Figure 5.24 (on the facing page)).
If the extensional part of TRYNEXT
j
p
m
es
m
is
o
is empty, but the intensional part is not
empty, one intension iis extracted and instantiated in the context of the current goal
(Figure 5.25 (on the next page)). The variable table is extended by i
n
varcnt free variables.
For each constraint in i
n
constrs, a thread is spawn and initialized with the offset of the
allocated variables and the intension’s stored environment and parameters. The spawned
threads are added to theactivechoice, and the alternativefor this choice is dumped, similar
as in the extensional case. The thread continues unifying pwith the shifted intension’s
pattern, shiftvshift inten
n
pat.
5.2 Specification 115
XTryNextExten
Ê
Ã
code
m
stack
m
choices
m
active
Å
Selection
p
Value
es
@
l
Value
is
?@
Intension
... . .. . . . . . .
instr
TRYNEXT
j
p
m
es
m
is
o
choices
Ô
addDump
j
this
m
stack
m
TRYNEXT
j
p
m
tailes
m
is
o
code
m
headchoices
o
tailchoices
stack
Ô
head es
j
p
stack
o
code
Ô
UNIFY
code
active
Ô
active
this
Figure 5.24: The TRYNEXT Auxiliary Instruction: The Extensional Case
XTryNextInten
Ê
Ã
code
m
stack
m
choices
m
active
m
vtab
m
ttab
m
threads
Å
Selection
p
Value
i
Intension
is
v@
Intension
spawned
ThreadInx
... . .. . . . . . .
instr
TRYNEXT
j
p
m
ADC
^m
i
is
o
vtab
Ô
vtab
V~
v
vtab
Å
Ë®ÕnSn
vtab
Å
i
n
varcnt
±
v
ÒÓ
Free
:
ttab
Ô
ttab
@~
t
ttab
Å
訯nSn
ttab
Å
i
n
constrs
±
t
ÒÓ
Â
parent
parent
m
child
q»m
prio
®Dm
status
running
m
env
i
n
env
m
params
i
n
params
m
stack
}
ADC
Um
varshift
}
vtab
Å
ˮDm
code
i
n
constrs
j
t
g
ttab
o
Ä
^
spawned
¼'½»{
ttab
Ô
æÕ¼'½»{
ttab
choices
Ô
addDump
j
this
m
stack
m
TRYNEXT
j
p
m
ADC
Um
is
o
code
m
addSpawned
j
spawned
m
headchoices
oÚo
tailchoices
threads
Ô
threads
spawned
stack
Ô
shift
j
vtab
Å
¨®
o
i
n
pat
j
p
stack
o
code
Ô
UNIFY
code
active
Ô
active
³
orderinxspawned
this
Figure 5.25: The TRYNEXT Auxiliary Instruction: The Intensional Case
The Make Instructions
The MKEMPTY instruction pushes an empty set to the stack. The MKSINGLE instruc-
tions pops a value from the stack and pushes a singleton set containing this value (Fig-
ure 5.26 (on the following page)).
The MKVAR
j
inx
o
instruction (Figure 5.27 (on the next page)) pushes the value Varinx
to the stack. The MKTERM
ji m
n
o
instruction pops narguments from the stack and pushes
the value Term
j:i m
args
o
.
The MKINTEN
j
parcnt
m
varcnt
m
constrs
o
instruction (Figure 5.28) creates a new inten-
sion and pushes it to the stack; the environment of the intension is created from the exe-
cuting threads context.
116 Abstract Machine
XMkEmpty
Ê
Ã
stack
m
active
Å
Selection
instr
MKEMPTY
stack
Ô
Set
j
ADC
Um
ADC
o
stack
active
Ô
active
this
XMkSingle
Ê
Ã
stack
m
active
Å
Selection
instr
MKSINGLE
stack
Ô
Set
j
fA
headstack
C
Um
ADC
o
tailstack
active
Ô
active
this
Figure 5.26: The MKEMPTY and MKSINGLE Instructions
XMkVar
Ê
Ã
stack
m
active
Å
Selection
inx
VarInx
... . .. . . . . . .
instr
MKVAR
j
inx
o
stack
Ô
Var
j
inx
o
stack
active
Ô
active
this
XMkTerm
Ê
Ã
stack
m
active
Å
Selection
i
CONS
n
-
... . .. . . . . . .
instr
MKTERM
ji m
n
o
stack
Ô
Term
ji mjz®ÕnSn
n
o
Î
stack
o
j¢j
n
Å
Ë®ÕnSn
stack
o
Î
stack
o
active
Ô
active
this
Figure 5.27: The MKTERM Instruction
The UNION and ISECT Instruction
The UNION instruction pops two values from the stack and builds the union of them
(Figure 5.29 (on the facing page)). If the union is undefined (because it requires equality
on values which cannot be computed) the thread stops in status error.
The ISECT instruction pops two values from the stack and builds the intersection of
XMkInten
Ê
Ã
stack
m
active
Å
Selection
parcnt
m
varcnt
-
constrs
Code
... . .. . . . . . .
instr
MKINTEN
j
parcnt
m
varcnt
m
constrs
o
stack
Ô
Set
j
ADC
Um
A
Â
varcnt
varcnt
m
pat
headstack
m
params
j¢®ÕnSn
parcnt
o
Î
tailstack
m
env
}
j
parent
m
varshift
o
env
m
constrs
constrs
ÄC
o
j
parcnt
Å
Ë®ÕnSn
stack
o
Î
tailstack
active
Ô
active
this
Figure 5.28: The MKINTEN Instruction
5.2 Specification 117
XUnion
Ê
Ã
active
m
stack
m
status
Å
Selection
es
ldm
es
@
Value
is
lUm
is
?@
Intension
... . .. . . . . . .
instr
UNION
stack
ö
Set
j
es
lUm
is
l
o
stack
®
Set
j
es
Sm
is
o
ùOú
j
es
ldm
es
o
×@¼'½»{$j
¿
o
¹
Î
¸äü
stack
Ô
Set
j
es
l
¿
es
Sm
is
l
³
is
o
tail
j
tailstack
o
active
Ô
active
this
status
Ô
status
¸¶·ýU¸
status
Ô
error
active
Ô
active
stack
Ô
tail
j
tailstack
o
Figure 5.29: The UNION Instruction
XIsect
Ê
Ã
active
m
stack
m
status
Å
Selection
es
ldm
es
@
Value
is
lUm
is
?@
Intension
... . .. . . . . . .
instr
ISECT
stack
ö
Set
j
es
l^m
is
l
o
stack
®
Set
j
es
Sm
is
o
ùOú
j
es
ldm
es
o
×@¼'½»{$j
À
o
¹
Î
¸äü
stack
Ô
Set
j
es
l
À
es
Sm
join
j
Set
j
es
l^m
ADC
o
m
Set
j
ADC
Um
is
oÚo
³
join
j
Set
j
es
dm
ADC
o
m
Set
j
ADC
Um
is
l
oÚo
³
join
j
Set
j
fADC
^m
is
l
o
m
Set
j
fA~C
Um
is
l
o¢o
o
tail
j
tailstack
o
active
Ô
active
this
status
Ô
status
¸¶·ýU¸
status
Ô
error
active
Ô
active
stack
Ô
tail
j
tailstack
o
join
Æ
´
u
Set
Æ
´
u
Set
?@
Intension
join
j
Set
j
es
lUm
is
l
o
m
Set
j
es
Sm
is
o¢o¾©
ùOú
!
es
l
nÅ
is
l
71
q}Ä
es
Å
is
=1
q
¹
Î
¸¶ü
A
Â
varcnt
®Dm
pat
Var
q»m
env
ADC
^m
params
A
Set
j
es
l^m
is
l
o
m
Set
j
es
dm
is
o
C
Um
constrs
AfA
LOAD
jq
o
m
LOADPAR
j¢®
o
m
MEMBER
m
SUCCESS
C
Um
A
LOAD
jq
o
m
LOADPAR
j=ö
o
m
MEMBER
m
SUCCESS
CfCfÄC
¸¶·:ýd¸
ADC
ÍÏÎ
¸'и
es
ldm
es
Value
is
lUm
is
@
Intension
Figure 5.30: The ISECT Instruction
them (Figure 5.30). If the intersection of the extensional parts undefined (because it re-
quires equality on values which cannot be computed) the thread stops in status error. The
specification uses an auxiliary function join
j
v
®Dm
v
ö
o
that creates an intension, implement-
ing the
Zform
x
x
×
v
lkÄ
x
×
v
f
(cf. discussion of intersection, Section 5.1.1 (on
page 98)). For realizing the constraints of this intension, we pass the set values v
l
and v
as intension parameters.
118 Abstract Machine
XSuccess
Ê
Ã
status
Å
Selection
instr
SUCCESS
status
Ô
success
Figure 5.31: The SUCCESS Instruction
XMu
Ê
Ã
active
m
stack
m
status
m
code
Å
Selection
es
@
Value
is
?@
Intension
... . .. . . . . . .
instr
MU
Set
j
es
m
is
o
stack
Ô
stack
ùOú
es
q
¹
Î
¸äü
code
Ô
SEARCH
j
Select
m
MuFirst
m
is
o
code
status
Ô
status
active
Ô
active
this
¸¶·ýU¸
ùOú
es
®
¹
Î
¸¶ü
code
Ô
SEARCH
j
Select
m
MuNext
j
head es
o
m
is
o
code
status
Ô
status
active
Ô
active
this
¸¶·:ýd¸
status
Ô
error
active
Ô
active
code
Ô
code
Figure 5.32: The MU Instruction
The SUCCESS Instruction
The SUCCESS instruction stops the running thread and puts into status success (Fig-
ure 5.31).
The MU Instruction
TheMU instruction (Figure 5.32) delegates itsworkto the auxiliary instruction SEARCH
j
state
m
mode
m
is
o
that implements subresolution for a sequence of intensions, is.SEARCH is started in
state Select and one of two modes: MuFirst indicates that no candidate value is present
for unique selection, whereas MuNext cand defines a candidate (the details are discussed
later on). The candidate is initialized from a singleton extensional part of the set on top
of the stack. If the extensional part contains more then one element, the MU instruction
immediately switches to status error.
The TEST and TESTNATIVE Instructions
As the MU instruction, the TEST and TESTNATIVE instructions (Figure 5.33 (on the next
page)) are based on the auxiliary instruction SEARCH
j
state
m
mode
m
is
o
(defined in the next
section). Both instructions are decided immediately, if the extensional part of the set on
top of the stack is nonempty: the TEST instruction which checks for nonemptiness then
succeeds, whereas the TESTNATIVE instruction fails.
5.2 Specification 119
XTest
Ê
Ã
active
m
stack
m
code
Å
Selection
es
@
Value
is
?@
Intension
... . .. . . . . . .
instr
TEST
Set
j
es
m
is
o
stack
Ô
stack
ùOú
es
q
¹
Î
¸äü
code
Ô
SEARCH
j
Select
m
Test
m
is
o
code
active
Ô
active
this
¸¶·ýU¸
code
Ô
code
active
Ô
active
this
XTestN
Ê
Ã
active
m
stack
m
status
m
code
Å
Selection
es
@
Value
is
?@
Intension
... . .. . . . . . .
instr
TESTNATIVE
Set
j
es
m
is
o
stack
Ô
stack
ùOú
es
q
¹
Î
¸äü
code
Ô
SEARCH
j
Select
m
TestN
m
is
o
code
status
Ô
status
active
Ô
active
this
¸¶·ýU¸
status
Ô
failure
code
Ô
code
active
Ô
active
Figure 5.33: The TEST and TESTNATIVE Instructions
The SEARCH Auxiliary Instruction
Theauxiliary instruction SEARCH
j
state
m
mode
m
is
o
implements “encapsulated search” and
is used to model the MU and TEST
8
TESTNATIVE instructions. The state is one of the
following:
±
Select: select the next intension from is and start a subgoal for its resolution. After
selection, the executing thread suspends until the subgoal’s execution has finished.
±
Resume: the state in which the current thread continues when it is resumed since
the subgoal’s execution has finished. Actions are performed in dependency on the
mode of the search: the search may be finished, backtracking may be invoked or
the next intension may be tried.
±
Backtrack: indicates that the current subgoal shall be backtracked
The mode describes which functionality is implemented by the search:
±
MuFirst: search for a
-value. No candidate is yet known.
±
MuNext cand: search for a
-value. A candidate is known, which must equal to
each other possible candidate.
±
Test: test for nonemptiness. The search stops and the initiating thread continues
normally as soon as the first resolution is successful.
120 Abstract Machine
XSearch
XSearchSelectMore
Ê
XSearchSelectEndMuFirst
Ê
XSearchSelectEndMuNext
Ê
XSearchSelectEndTest
Ê
XSearchSelectEndTestN
Ê
XSearchResumeSuccessMu
Ê
XSearchResumeSuccessTest
Ê
XSearchResumeSuccessTestN
Ê
XSearchResumeFailure
Ê
XSearchResumeError
Ê
XSearchBacktrack
Figure 5.34: The SEARCH Auxiliary Instruction: Dispatching
XSearchSelectMore
Ê
Ã
child
m
ttab
m
gtab
m
active
m
code
Å
Selection
mode
SearchMode
i
Intension
is
Intension
... . .. . . . . . .
instr
SEARCH
j
Select
m
mode
m
i
is
o
child
Ô
gtab
Å
Ë®
ttab
Ô
ttab
@~
t
ttab
Å
訯nSn
ttab
Å
i
n
constrs
±
t
ÒÓ
Â
parent
child
Ô
m
child
q»m
prio
®Dm
status
running
m
env
i
n
env
m
params
i
n
params
m
stack
}
ADC
Um
varshift
®Dm
code
i
n
constrs
j
t
g
ttab
o
Ä
^
gtab
Ô
gtab
É~
child
Ô
ÒÓ
Â
parentThread
this
m
pat
i
n
pat
m
threads
¼'½»{
ttab
Ô
æؼ'½»{
ttab
m
choices
ADC
Um
vtab
}
~
v
®ÕnSn
i
n
varcnt
±
v
ÒÓ
Free
:
lÄ
^
code
Ô
SEARCH
j
Resume
m
mode
m
is
o
code
active
Ô
active
³
orderinx
j¼'½»{
ttab
Ô
æؼ'½»{
ttab
o
Figure 5.35: The SEARCH Auxiliary Instruction: Select, More Intensions
±
TestN: test for emptiness. The search stops in status failure as soon as the first
resolution is successful.
The SEARCH
j
state
m
mode
m
is
o
instruction is defined by several schemas that discriminate
over state,mode and the sequence of intensions is. The dispatcher is defined in Fig-
ure 5.34.
Selection State. Figure 5.35 defines the selection state for the case that the intension
sequence is nonempty, which is independent of the mode of the search. For the next
intension i, a new subgoal is created and stored in the child field of the executing thread.
The spawned threads are activated and the executing thread suspends, after preparing to
continue in search state Resume.
Figure 5.36 (on the facing page) defines the selection state for the case that the inten-
sion sequence is empty. The action performed depends on the mode: in mode MuFirst,
the initiating MU instruction produces an error (the set MU is executed on is empty). In
mode MuNext cand,cand is the unique result of executing MU. In mode Test, the tested
5.2 Specification 121
XSearchSelectEndMuFirst
Ê
Ã
status
Å
Selection
instr
SEARCH
j
Select
m
MuFirst
m
ADC
o
status
Ô
error
XSearchSelectEndMuNext
Ê
Ã
active
m
stack
Å
Selection
cand
Value
.. .. . .. .. . . .
instr
SEARCH
j
Select
m
MuNext cand
m
ADC
o
stack
Ô
cand
stack
active
Ô
active
this
XSearchSelectEndTest
Ê
Ã
status
Å
Selection
instr
SEARCH
j
Select
m
Test
m
0ADC
o
status
Ô
failure
XSearchSelectEndTestN
Ê
Ã
active
Å
Selection
instr
SEARCH
j
Select
m
TestN
m
ADC
o
active
Ô
active
this
Figure 5.36: The SEARCH Auxiliary Instruction: Select: No More Intensions
set is empty which lets the executing thread fail; in mode TestN, the test for emptiness has
succeeded and the executing thread just continues.
Resume State. Figure 5.37 (on the next page) defines schemas for the Resume state
in case the subgoal has been successfully resolved. We end here since a thread is auto-
matically resumed by the general dispatch operation PostDispatch (Figure 5.16) when the
threads of its subgoal have finished. The subgoal is successful if all its threads are in status
success. The action depends on the mode of search: in case of Test or TestN, the search
is finished, and the executing thread either continues or stops in status failure. In case of
MuFirst or MuNextcand, the result of the subresolution is frozen and compared with a
possible previous candidate for unique selection. The frozen value must not contain free
variables; if it does so, or if a previous candidate does not equal to the frozen result, or if
equality is undefined (since the compared values contain intensions), the executing thread
stops in status error. Otherwise, the search switches either to status Backtrack if there are
pending choices, or to status Select if there are no more choices, trying the next possible
intension.
Figure 5.38 (on page 123) defines schemas for the Resume state in case the subgoal
has failed or is in status error. In case of a failure, the next alternative is tried, either by
backtracking or by selecting the next intension. An error status is just propagated to the
executing thread.
Backtrack State. Figure 5.39 (on page 123) defines the Backtrack status of a search. It
can be asserted that the choice stack is not empty. In the subgoal, changes as described
by the topmost choice entry are undone: dynamically spawned threads are removed, the
choice itself is pruned and the variables are reset to be free. The threads which have
dumped to the choice are restored. The restored threads are reactivated (they may run or
not on backtrack) and the executing thread suspends after preparing to continue in state
Resume when the backtracked subgoal has finished.
122 Abstract Machine
XSearchResumeSuccessTest
Ê
Ã
active
Å
Selection
is
Intension
sgoal
Goal
... . .. . . . . . .
instr
SEARCH
j
Resume
m
Test
m
is
o
sgoal
gtabchild
M
t
sgoal
n
threads
±
j
ttabt
o
n
status
success
active
Ô
active
this
XSearchResumeSuccessTestN
Ê
Ã
status
Å
Selection
is
Intension
sgoal
Goal
... . .. . . . . . .
instr
SEARCH
j
Resume
m
TestN
m
is
o
sgoal
gtabchild
M
t
sgoal
n
threads
±
j
ttabt
o
n
status
success
status
Ô
failure
XSearchResumeSuccessMu
Ê
Ã
active
m
code
m
status
Å
Selection
mode
SearchMode
is
?@
Intension
sgoal
Goal
cand
m
res
Value
... . .. . . . . . .
instr
SEARCH
j
Resume
m
mode
m
is
o
mode
MuFirst
Ê
mode
MuNext cand
sgoal
gtabchild
M
t
sgoal
n
threads
±
j
ttabt
o
n
status
success
res
freezesgoal
n
vtabsgoal
n
pat
ùOú
varsres
;:
Ä
j
mode
MuNext cand
ô j
cand
m
res
o
×9¼'½{
equal
Ä
equal
j
cand
m
res
o¢o
¹
Î
¸äü
code
Ô
SEARCH
j
ùOú
K
sgoal
n
choices
1
q
¹
Î
¸¶ü
Backtrack
¸¶·:ýd¸
Select
m
MuNextres
m
is
o
code
active
Ô
active
this
status
Ô
status
¸¶·ýU¸
code
Ô
code
active
Ô
active
status
Ô
error
Figure 5.37: The SEARCH Auxiliary Instruction: Resume: Subgoal Success
5.2 Specification 123
XSearchResumeFailure
Ê
Ã
active
m
code
Å
Selection
mode
SearchMode
is
?@
Intension
sgoal
Goal
... . .. . . . . . .
instr
SEARCH
j
Resume
m
mode
m
is
o
sgoal
gtabchild
Þ
t
sgoal
n
threads
±
j
ttabt
o
n
status
failure
code
Ô
SEARCH
j
ù:ú
K
sgoal
n
choices
1
òq
¹
Î
¸¶ü
Backtrack
¸ä·:ýd¸
Select
m
mode
m
is
o
code
active
Ô
active
this
XSearchResumeError
Ê
Ã
status
Å
Selection
mode
SearchMode
is
?@
Intension
sgoal
Goal
... . .. . . . . . .
instr
SEARCH
j
Resume
m
mode
m
is
o
sgoal
gtabchild
M
t
sgoal
n
threads
±
j
ttabt
o
n
status
÷
failure
Þ
t
sgoal
n
threads
±
j
ttabt
o
n
status
error
status
Ô
error
Figure 5.38: The SEARCH Auxiliary Instruction: Resume: Subgoal Failure
XSearchBacktrack
Ê
Ã
gtab
m
ttab
m
code
m
active
Å
Selection
mode
SearchMode
is
?@
Intension
sgoal
Goal
choice
Choice
... . .. . . . . . .
instr
SEARCH
j
Backtrack
m
mode
m
is
o
sgoal
gtabchild
sgoal
n
choices
1
q»
choice
head sgoal
n
choices
gtab
Ô
gtab
î
~
child
ÒÓ
Â
parentThread
}
sgoal
n
parentThread
m
pat
}
sgoal
n
pat
m
threads
sgoal
n
threads
æ
choice
n
spawned
m
choices
Â
bound
;:
m
dump
:
m
spawned
:
Ä
(
tailsgoal
n
choices
m
vtab
vtab
î
~
v
choice
n
bound
±
v
ÒÓ
Free
:
lÄ
^
ttab
Ô
ttab
î
~
t
¼'½»{
choice
n
dump
±
t
ÒÓ j:
Ê
Ã
stack
m
code
m
status
Å
Thread
l
Thread
ttabt
j
stack
Ô
m
code
Ô
o2
choice
n
dumpt
status
Ô
running
±
Thread
Ô
o
code
Ô
SEARCH
j
Resume
m
mode
m
is
o
code
active
Ô
~
t
Æ
´
u
active
t
8
×
sgoal
n
threads
ËÎ
active
³
orderinx
j¼'½»{
choice
n
dump
o
Figure 5.39: The SEARCH Auxiliary Instruction: Backtracking
124 Abstract Machine
ENV
j
VAR
Æ
VarInx
oG
j
VAR
Æ
-
çoG
E
VAR
enter
ENV
%
VAR
ENV
index
¬
=
ENV
x
VAR
±
çn®
x
nest
¬
Ë
ENV
x
VAR
±
%nvö
x
mkflex
}
¬
Ë
ENV
vars
VAR
±
j
[
%n®Dm
%n öm
%n
e
Õ
vars
o
flex
¬
Ë
ENV
±
%n
e
enter
j
Y
%m
vars
o¾©
·O¸'¹
order
}ì´
Æí½'ÆM¼'yÆ
vars
±
j
[
%n®
î
~
i
¼'½»{
order
±
order i
ÒÓ
i
g
ò®E¶m
¬
x
VAR
±
ùOú
x
×
vars
¹
Î
¸¶ü
q
¸ä·:ýd¸
nest
j
[
%m
x
o
Å
ˮDm
flex
æ
vars
o
ÍÏÎ
¸'и
ENV
vars
VAR
Figure 5.40: Compilation Environment
5.3 Compilation
In this section, the compilation of
Zto ZAM instructions is described. Compilation
works on expressions normalized as described in Section 4.2 (on page 74) in Chapter 4.
A top-level expression, constituting a
Z“program”, may, for example, be given as a
property with free variables, such as x
×
e, where xdescribes the output of the program.
Compiling x
×
ewith an initial environment declaring xyields a sequence of code instruc-
tions which can be executed as the constraint of an intension of the ZAM. Backtracking
over the goal for this intension yields the possible bindings for x.
5.3.1 Environment
The compilation is based on an environment holding information about variable names in
the contextof a compiled expression. An environment,
9×
ENV, is atriple
j
indices
m
nests
m
flex
o
,
where indices is a mapping from variables to their associated indices, nests a mapping
from variables to their scoping nest and flex a set of variables which are considered as
“flexible”. For flexible variables, in contrast to nonflexible, it is not require to emit a
WAIT instruction before they can be accessed. The specification of environments is given
in Figure 5.40.
The enter
j
Y
%m
vars
o
function extends the environment for entering a scope which de-
clares the variables vars. Variables from outer scopes are shadowed; for those which are
still visible the scoping nest is incremented by one. The function index
j
[
%m
x
o
retrieves the
index of the variable xin
, the function nest
j
Y
%m
x
o
the scoping nest of x. The function
mkflex
j
[
%m
vars
o
adds the given variables to the flex set, the function flex
retrieves the flex
set.In the definition of enter, we use the function
ì´
ÆM½'Æí¼'yÆ
that makes a sequence of some
fixed but arbitrary order from a finite set of variables. Note that variable indices in the
ZAM start with
q
(whereas Z’s sequences are indexed starting from
®
). From the flex set,
we remove the newly entered variables, since any variables with the same name in this set
are shadowed, and the flexible information becomes invalid for them.
5.3 Compilation 125
¹
BAS
ENV
EXPB
Code
¹
DIS
ENV
EXPD
Code
¹
CON
ENV
EXPC
Code
¹
LIT
ENV
EXPL
Code
¹
PRO
ENV
EXPA
Code
Figure 5.41: Declaration of Compilation Functions
¹
BAS
¿j:ikj
b
o^o%©
³
8
j
Y¹
BAS
.
b
oÑ
MKTERM
ji m
b
o
d
©
¹
DIS
d
c
©
¹
CON
c
l
©
¹
LIT
l
ÍÏÎ
¸¶Ð¸
ENV
b
@
EXPB
i
CONS
d
EXPD
c
EXPC
l
EXPL
Figure 5.42: Compiling General Expressions
5.3.2 Compilation Functions
For each level of the disjunctive normal form (described in Figure 4.3 (on page 74)), a
compilation function is provided: general expressions, disjunctions, conjunctions, literals
and properties. These functions constitute a mutual recursive system, which will be spec-
ified in the subsections below. The declaration of the compilation functions is given in
Figure 5.41.
Compiling General Expressions
The function
¹
BAS
btakes any expression in normal form and compiles it to a sequence
of instructions (Figure 5.42). For constructor application,
ikj
b
o
, code is generated which
pushes the arguments, and the MKTERM instruction is appended to this code. For other
expressions, the appropriate specialized compilation function is called.
Compiling Disjunctions and Conjunctions
The compilation of disjunction (union) and conjunction (intersection) is defined in Fig-
ure 5.43 (on the next page). For unions,
c,UNION instructions are folded into the
instructions generated from the operands c. A simple optimization can prevent the cre-
ation of the empty set as a neutral element, which we have omitted. For the compilation
of intersection,
l,ISECT instructions are folded into the instructions generated from
the literal operands. The sequence of conjuncted literals can be assumed to be nonempty
by the normal form of expressions.
Compiling Literals
The compilation of literals (and atoms, which we subsume here) is defined in Figure 5.44
(on the following page). The following comments:
126 Abstract Machine
¹
DIS
¿j
c
o%©
j=¬
c
EXPC
code
Code
±
code
³
¹
CON
c
UNION
m
A
MKEMPTY
C
o
æ
c
ÍÏÎ
¸¶Ð¸
ENV
c
EXPC
¹
CON
¿j
~
l
o¾©
jȬ
l
EXPL
code
Code
±
code
³
¹
LIT
l
ISECT
m
¹
LIT
5j
head l
o¢o
æ
taill
ÍÏÎ
¸¶Ð¸
ENV
l
EXPL
l
1
òq
Figure 5.43: Compiling Disjunctions and Conjunctions
¹
LIT
¿j
x
o ©
ùOú
nest
j
[
%m
x
o
q
¹
Î
¸¶ü
ù:ú
x
8
×
flex
¹
Î
¸¶ü
A
WAIT
j
index
j
Y
çm
x
oÚo
m
LOAD
j
index
j
Y
%m
x
oÚo
C
¸ä·:ýd¸
A
LOAD
j
index
j
[
%m
x
o¢o
C
¸¶·:ýd¸
A
LOADENV
j
nest
j
[
%m
x
o
m
index
j
Y
%m
x
oÚo
C
jz~
b
o ©
¹
BAS
b
MKSINGLE
j
d
o ©
¹
DIS
d
MU
j=
a
o ©
¹
LIT
a
MKVAR
jÈq
oÑ
MKINTEN
j¢®Dmd®Dm
AfA
WAIT
jÈq
o
m
LOAD
jÈq
o
m
MKSINGLE
m
LOADPAR
jz®
o
m
ISECT
m
TESTNATIVE
m
SUCCESS
CC
o
j
c
Ã
p
lAÒÓ
p
ÚÅ
o%©_·O¸'¹
vars
}ì´
Æíw
p
lç
ì´
Æíw
p
±
·O¸'¹
Ô
mkflex
j
enter
j
[
%m
vars
o
m
vars
o»±
¹
CON
c
³
¹
BAS
Ô
p
MKINTEN
j¢®Dm
vars
m
AY¹
BAS
Ô
p
l
³
A
LOADPAR
j¢®
o
m
MEMBER
m
SUCCESS
CfC
o
jz~
p
vk
¾
o ©_·O¸'¹
w
~
x
Dì´
ÆMw
ºk
5æj
ì´
ÆMw
p
flex
o
nest
j
[
%m
x
o
qä
±
·O¸'¹
Ô
enter
j
[
%m
ì´
ÆMw
p
o»±
j=¬
x
w
±
WAIT
j
index
j
Y
%m
x
oÚo¢o
>.
Øì´
ÆM½'Æí¼'yÆ
w
³
¹
BAS
j
mkflex
j
Y
Ô
m
ì´
Æíw
p
oÚo
p
MKINTEN
jÈq»m
j
ì´
Æíw
p
o
m
AY¹
PRO
Ô
k¢C
o
j:é%ê
p
ë
b
o ©_·O¸'¹
w
~
x
Dì´
ÆMw
b
æ}j
ì´
Æíw
p
flex
o
nest
j
Y
çm
x
oñ
q
±
·O¸'¹
Ô
mkflex
j
enter
j
[
%m
ì´
ÆMw
p
o
m
ì´
ÆMw
p
o»±
j=¬
x
w
±
WAIT
j
index
j
Y
%m
x
oÚo¢o
>.
Øì´
ÆM½'Æí¼'yÆ
w
³
¹
BAS
Ô
p
MKINTEN
jÈq»m
j
ì´
Æíw
p
o
m
AY¹
PRO
Ô
j
p
b
o
C
oÑ
MU
ÍÏÎ
¸¶Ð¸
ENV
x
VAR
b
EXPB
d
EXPD
a
EXPA
c
EXPC
3k
EXPP
p
m
p
lUm
p
PAT
Figure 5.44: Compiling Literals
±
For a variable,x, we distinguish whether it is local (its lexical nesting is
q
) or from
the context. For local variables, we generate a LOAD instruction, prepending a
WAIT instruction if the variable is nonflexible. For a context variable, we generate
aLOADENV instruction.
5.3 Compilation 127
¹
PRO
¿j
p
l
p
o%©
¹
BAS
j
mkflex
j
Y
çm
ì´
Æíw
p
l
oÚo
p
l
³
¹
BAS
j
mkflex
j
Y
çm
ì´
Æíw
p
oÚo
p
UNIFY
SUCCESS
j
x
b
o ©
¹
BAS
b
STORE
j
index
j
[
%m
x
oÚoÑ
SUCCESS
j
p
b
o ©
¹
BAS
j
mkflex
j
Y
çm
ì´
Æíw
p
oÚo
p
³
¹
BAS
b
UNIFY
SUCCESS
j
p
×
d
o ©
¹
BAS
j
mkflex
j
Y
çm
ì´
Æíw
p
oÚo
p
³
¹
DIS
d
MEMBER
SUCCESS
j
c
o ©
¹
CON
c
TEST
SUCCESS
j
0
c
o ©
¹
CON
c
TESTNATIVE
SUCCESS
ÍÏÎ
¸¶Ð¸
ENV
p
m
p
l^m
p
PAT
x
VAR
d
EXPD
c
EXPC
b
EXPB
Figure 5.45: Compiling Properties
±
For a singleton-set construction,
~
b
, code is generated to strictly create the element
on the stack, and the MKSINGLE instruction is appended.
±
For a singleton-set selection,
d, code is generated which pushes the value of dto
the stack, and the MU instruction is appended.
±
For a set complement,
a, code is generated that realizes the
Zintension
x
0
jz~
x
ñ
v
o
, where vrepresents the evaluated value of a, which is passed as an
intension parameter.
±
For a translation, c
Ã
p
lÕÒÓ
p
ÚÅ
, code is generated that realizes the
Zintension
p
p
lÕ×
v
, where vrepresents the evaluated value of c, which is passed as an intension
parameter.
±
For a schema,
~
p
bk
¾
, code for creating an intension is generated. Before the
creation of the intension, code is inserted which waits for all free variables of the
schema which are in the current scope and which are not flexible. This ensures that
the newly created intension does not refer to free variables from the environment.
It is sufficient to wait for the variables of the current scope (from the viewpoint of
the code creating the intension), since, inductively, the variables of the outer scopes
are bound. Flexible variables are excluded from this treatment.
±
A fixed-point,
éçê
p
ë
b, is compiled as the form
~
p
p
b
, with the difference
that during compilation of p
bwe add the variables from pto the set of flexible
variables. This allows for the construction of cyclic intensions. Note that we need
the temporarily constructed intension that is immediately deconstructed by the MU
operator in order to get an environment where inner intensions created for bcan
depend on.
Compiling Properties
The compilation of properties is defined in Figure 5.45. The following comments:
±
A pattern equality, p
l
p
, is mapped to a UNIFY instruction where the patterns
are compiled such that all variables in them are flexible. Note that, by normal-
ization, the variables appearing in the patterns must be directly bounded by the
enclosing schema.
128 Abstract Machine
±
The next three cases are variants of pattern membership, p
×
c. For the case of a
direct assignment to a variable, x
b(a shortcut for x
×>~
b
) we use the STORE
instruction as an optimization. For the case of an assignment to a pattern, p
b, the
UNIFY instruction is used. In compiling the pattern p, the variables of the pattern
are made flexible. Finally, the general case, p
×
cis compiled to the MEMBER
instruction.
±
The remaining two cases handle the test for emptiness or nonemptiness of the set c,
and are mapped to the TEST resp. TESTNATIVE instructions.
5.4 Implementation 129
5.4 Implementation
A prototypical implementation of the ZAM in C++ has been realized, which is discussed
in this section. The implementation differs from the specified model in the following
respects:
±
In order to make dumping of thread states efficient, we use a persistent single as-
signment register machine instead of a stack machine. Since a single assignment
register can be never overwritten, it is sufficient to just dump a program counter – a
thread backtracking to an execution point always finds a valid temporary state. The
usage of a register machine has some influences on the instruction set, as will be
seen below.
±
Once having the concept of persistent single assignment registers, we may use dif-
ferent techniques for passing parameters to the MKINTEN instruction and other
instructions. Instead of copying the parameters, we just pass a reference to a persis-
tent register area (a pointer to a C++ array of values)4.
±
Since we have no problems with creating cyclic data structures in C++, the con-
struction of environments for intensions as in the ZAM’s Z specification can be
completely avoided, using intension parameters instead. Since the intension param-
eters are passed by a reference to a register area, it is particularly easy to back-patch
fixed-points.
Below, we sketch the data model of the ZAM in C++ and the instruction set of the register
version. Some first benchmarks for the prototypical implementation are also given.
5.4.1 Data Model
Figure 5.46 (on the following page) shows the basic types used in C++ to represent ZAM
values. Here, we also sketch the realization of native values, used for implementing
numbers and other builtin types. Native values are characterized by a virtual method
compare which implements a total order on them (in the C++ implementation, ordering
instead of extensional equality is used).
A set value, SetData(extens,intens), consists of two sorted sequences, rep-
resented as STL vectors. C++’s standard template library provides us with algorithms for
set union and intersection on sorted sequences.
As discussed, an intension in the C++ implementation does not hold an environment
but only an array of parameters. For each free variable of the intension’s constraints, the
params field must contain an entry where a copy of this variable’s value is stored. The
resulting representation of environment variables is very similar to closures, as yielded by
implementing nested functions by
Ï
-lifting in the implementation of functional languages.
A constraint is represented by an abstract class, which provides a method to spawn
athread executing this constraint. This abstraction allows the easy integration of spe-
cialized constraint implementations (for example, the intensions dynamically created for
4Pointers to registers seem to be an abuse of notions. We justify this by that the instruction set of the
C++ ZAM actually corresponds to a register transfer language. Moreover, storing registers in reentrant
memory is also a characteristic feature of RISC like processor architectures.
130 Abstract Machine
typedef ValueData const * Value; typedef Inten-
Data const * Inten;
typedef ConstrData const * Constr;
enum Kind { TERM, VAR, SET, NATIVE };
struct ValueData { Kind kind; };
struct TermData : ValueData { Constr cons; Value args[]; };
struct VarData : ValueData { int index; };
struct SetData : ValueData { vector<Value> extens;
vector<Inten> intens; };
struct NativeData : ValueData { virtual int com-
pare(...) = 0; ... };
struct IntenData { int varcount; Value pat; Value params[];
Constr constrs[]; };
struct ConstrData { virtual Thread spawn(..., int varshift) = 0; }
Figure 5.46: Value Types of the ZAM in C++
typedef ThreadData * Thread; typedef GoalData * Goal;
struct ThreadData { enum Status { RUNNING, SUCCESS, FAIL-
URE, ER-
ROR, MWAIT, TWAIT } status;
Instr * code; int varshift; int dumpDepth;
enum Priority { LO, HI } prio;
Value params[]; Value registers[];
union { <<data for MWAIT and TWAIT>> };};
struct VarInfo { Value binding; vector<Thread> wait-
ing; };
struct ChoiceInfo { Thread initiator; <<data for alterna-
tive>>; vector<int> bound; vec-
tor<ThreaDump> dumps;vector<Thread> spawned; };
struct ThreadDump { Thread dumper; Instr* code; };
struct GoalData { Thread parent; vector<Thread> threads;
Value pat;
vector<VarInfo> vtab;
vector<ChoiceInfo> choices; };
Figure 5.47: Control Types of the ZAM in C++
realizing set intersection (cf. Figure 5.30 (on page 117)). The spawn method is passed the
variable shift of the intension’s instance.
The representation of threads and goals in the C++ implementationis givenin Figure 5.47.
It is very similar to the specification in Z. There are the following differences:
5.4 Implementation 131
MKEMPTY
Ð
r
Ñ
v
MKSINGLE r
Ñ
v
Ñ
p
Ð
r
Ñ
v
MKINTEN s r
Ò Ó Ð
r
Ñ
v
FIXINTEN r
Ñ
v
MKTERM c
Ô
r
Ò Ó Ð
r
Ñ
v
UNION r
Ñ
v
Ñ
p
Ô
r
Ñ
v
Ñ
p
Ð
r
Ñ
v
ISECT r
Ñ
v
Ñ
p
Ô
r
Ñ
v
Ñ
p
Ð
r
Ñ
v
WAIT v
MOVE r
Ñ
v
Ñ
p
Ð
r
Ñ
v
UNIFY r
Ñ
v
Ñ
p
Ô
r
Ñ
v
Ñ
p
MEMBER r
Ñ
v
Ñ
p
Ô
r
Ñ
v
Ñ
p
MU r
Ñ
v
Ñ
p
Ð
r
Ñ
v
TEST r
Ñ
v
Ñ
p
TESTNATIVE r
Ñ
v
Ñ
p
SUCCESS
Figure 5.48: Register Transfer Instruction Set of the ZAM
Õ
For reasons of efficiency, auxiliary instructions such as TRYNEXT
Ö
p
Ô
es
Ô
is
×
which
carry a data state can not be used. We thus have additional data in choices, rep-
resenting the state contained in TRYNEXT. Furthermore, threads have additional
states, MWAIT and TWAIT, and corresponding data components for execution the
MU and TEST/TESTNATIVE instructions; this data is only valid if a thread is in
one of these states.
Õ
The need of a thread to dump its state to the active choice is encoded in a more
efficient way than in the specification. The field ThreadData::dumpDepth
contains the maximal choice depth a thread has been dumped to, and monotonically
increases during the thread’s progress. The test for the need to dump is coded as
goal->choiceTable.size() > thread->dumpDepth.
As discussed, it is sufficient to just restore the program counter to backtrack threads
since the ZAM uses a single assignment register model for storing temporaries (field
ThreadData::registers):. Thus a thread can be restored to an arbitrary execu-
tion point, always finding a valid temporary state at this point5.
5.4.2 Instruction Set
The ZAM’s C++ implementation uses a register transfer instruction language. The in-
structions are summarized in Figure 5.48. The operands of instructions are the followings:
Õ
r: the index of a register. This addresses the field ThreadData::registers
of the executing thread.
Õ
v: the index of a variable. This addresses the GoalData::vtab field of the goal,
the executing thread belongs to. If the variable is bound, its binding is denoted,
otherwise a VarData term holding the variable’s index. The executing thread adds
the ThreadData::varshift value to the index, which determines the base of
the variable frame of on associated instantiation. If a variable is the destination of
an instruction, then the value of the instruction’s result is unified with the addressed
variable’s value.
5By construction, a thread can never dump in state MWAIT or TWAIT – since in these states it does not
progress. Thus the special temporary control data stored in ThreadData for these states needs not to be
dumped.
132 Abstract Machine
Õ
p: the index of a parameter. This addresses the field ThreadData::params of
the executing thread.
Õ
r
Ñ
v
Ñ
p: alternatively, a register, variable or parameter index. Similar as the Java
Virtual Machine, the ZAM provides in fact a set of specialized instructions for the
different addressing modes, which avoid dynamic encoding at runtime, but from
which is abstracted here. Around a hundred concrete instructions are derived from
the combinations of addressing modes in the abstract instructions in Figure 5.48 (on
the preceding page).
Õ
r
Ò Ó
: a reference to a register region. Provided is the starting index of a consecutive
region of registers.
Õ
s: the index of an intension. This points to a global table of intensions belonging to
the executed unit (the “constant pool” in notions of the JVM).
Õ
c: the index of a constructor. This points to a global table of constructors belonging
to the executed unit.
The following remarks on the instructions:
Õ
The MKEMPTY instruction stores the empty set in the destination operand, the
MKSINGLE instruction a singleton set containing the value in the source operand.
The value in the source operand must not contain free variables, otherwise the be-
havior is undefined (the compiled code ensures this with the WAIT instruction).
Õ
The MKINTEN instruction creates a new intension. The parameters of the in-
tension are found in the register region starting at r
Ò Ó
. In the intension’s field
IntenData::params,just apointer to the registerregion isstored. The FIXINTEN
instruction commits the parameters of the addressed intension to be completely ini-
tialized. This instruction may make a copy of IntenData::params; however,
by the assertion of “single assignments” to registers, the FIXINTEN instruction may
as well do just nothing. (Making a copy avoids space leaks, since the live-time of
the created intension may exceed the live-time of the creating thread; in this case, if
no copy is made, the entire register array of the thread cannot be reclaimed by the
garbage collector unless the intension is.)
Õ
The MKTERM instruction creates a new constructor term. The arguments of the
constructor are passed in the register region r
ÒØÓ
. Again, a copy of this region is not
required, though omitting it can create space leaks. (To copy or not, or to let this be
determined by compiler optimizations, is an open question.)
Õ
The UNION and ISECT instruction implement set union and intersection, as de-
scribed in the specification.
Õ
The WAIT instruction lets the executing thread suspend until the addressed variable
(and all the variables it indirectly refers to by a possible binding) are bound.
5.4 Implementation 133
Õ
The MOVE instruction transfers the source to the destination. If the destination is a
variable and is bound, this is similar to unification. The UNIFY instruction performs
a unification of its operands. If unification fails, the executing thread fails.
Õ
The MEMBER instruction tests whether the first operand is member of the second
set operand, as described in the specification.
Õ
The MU,TEST and TESTNATIVE instructions create subgoals for resolving their
operand, as described in the specification.
Õ
The SUCCESS instruction terminates the executing thread. If all threads of a goal
have been successfully terminated, then an associated parent thread of the goal is
resumed (which is present if the goal is a subgoal).
5.4.3 Memory Management
A Boehm-style conservative garbage collector [Boehm, 1993] is employed for memory
retrieval. The collector needs to handle inferior pointers (references “into” a memory
cell), because pointers to register regions may be stored in values, but also since the
standard template library of C++ is involved, which may use local allocation strategies
for containers. Nevertheless, the implementation of the garbage collector is compact (300
lines of code) and portable: this becomes possible since garbage collection can be invoked
synchronously inbetween the execution steps of threads, where no hardware stack exists,
and the only root to consider is the ZAM’s configuration which points to the topmost goal.
5.4.4 Performance
Since the compiler from
Ù
Zto ZAM’s register transfer code is not yet ready, performance
measurements can be only very rudimentary. As a first guess, an “assembler” implemen-
tation of the list concatenation function app has been used:
Ú9Û
app
ÜÞÝÖßDàÔ
ys
Ô
zs
×7Ñ
zs
á
ys
â\ã
ÝÖ
x
äåä
xs
Ô
ys
Ô
zs
×çæ
t
ÑÖ
xs
Ô
ys
Ô
t
×5è
app
é
zs
á
x
äåä
t
â
All solutions for app
Ö
xs
Ô
ys
Ô
c
×
, where cis a constant list of length
êëvì
, have been queried,
in a loop executed thousand times (such that garbage collection needs to be invoked).
The current implementation requires
êí¯îðï
seconds on a Pentium II/400, hence
ê0í¯îñï
ms for
one evaluation of app, backtracking over all possible 128 partitions. Around
ëîðò
million
instruction steps are executed, which amounts to
êóvóvôôô
steps per second.
As a further test, a recursive definition of the fac function has been coded:
Ú9Û
fac
ÜÞÝÖ
x
Ô
y
×=Ñ
x
áô5é
y
áõêvâ\ã
ÝÖ
x
Ô
y
×=Ñ
x
öHêé
y
á
x
÷\ÙFÖ?Ö
fac
éÝ
x
øêvâçÒ
x
ùÐ Ö
x
Ô ×~Ó×yÒúÖ Ô
y
×ùÐ
y
Ó×fâ
For numbers and arithmetics, a native implementation is used (the ZAM has also some
instructions for natives that have not been specified). Executing fac
ì
thousand times is
done in
êîí
seconds, requiring
ûôvûôôô
steps: thus one recursive function application as
134 Abstract Machine
implemented with the
Ù
-operator requires around
ô¯îë
ms. In contrast, a highly efficient
implementation of a functional language such as that of Opal [Schulte and Grieskamp,
1992] requires around
ô¯îðôô¯êï
ms per recursive call –
ê@ïë
times faster. This is not surpris-
ing, since the code the Opal compiler generates for fac is identical regarding efficiency
to that of an according recursive C function – whereas function application via the
Ù
-
operator deals with relations. Nevertheless, more effort has to be invested to get function
application in the ZAM more efficient for special cases.
Taking into account that the ZAM is a virtual byte-code machine, these results are en-
couraging, though real benchmarking is required to get a clearer picture, and comparisons
with the performance of other implementations of functional logic languages have to be
made.
5.5 Discussion 135
5.5 Discussion
We defined the abstract machine ZAM, supplied a comprehensive specification of its op-
eration (which also serves as a case study for the Z specifications we wish to execute by
our approach), provided a compilation of normalized
Ù
Zinto the machine’s instruction
set and outlined the implementation of the machine in C++. Related work is discussed
below.
There are a wide variety of abstract machines for functional logic languages. Even
five years ago, Hanus [1994] mentioned fourteen different designs, which he considered
as the “most important” ones. In general, these machines can be divided into those that
have evolved from machines for logic languages, those from functional languages and
those that use techniques for concurrent constraint resolution.
Extending Logic Implementation Techniques
Machines based on implementation techniques for logic languages are often extensions
of Warren’s Abstract Machine [Warren, 1983; Ait-Kaci, 1991]. The WAM provides an
efficient implementation of Prolog, which breaks down unification and backtracking to a
level of well-designed, specialized low-level instructions. The ZAM does not attempt to
do this: its instructions are complex; unification, for example, is contained as “atomic”
functionality.
Some extensions of the WAM integrate narrowing (outermost or innermost) into the
machine, for example by adding the possibility of term replacement on heap values, as in
the A-WAM [Hanus, 1990]. Other extensions such as the K-WAM [Bosco et al., 1989]
are based on translating functions into relations, with the result that deterministic program
parts are executed using the full indeterministic machinery. This is, in fact, close to the
ZAM, where functions are already mapped to relations at the calculus level of
Ù
Z(though
the ZAM has the advantage of choice point scheduling, which Prolog implementations
can only hardly achieve because of the sequential execution model of Prolog.) Concep-
tually, both approaches are inadequate for implementing
Ù
Z, since concurrent constraint
resolution is essential for our application. Furthermore, these techniques do not treat
higher-orderness in the sense that the ZAM does, allowing arbitrary set extensions and
intensions to be combined at runtime to form new sets, relations and functions.
Extending Functional Implementation Techniques
Machines based on implementation techniques for functional languages use stack-based
reduction (as first described for the SECD machine, [Landin, 1964]), continuation-passing
style reduction (CPS, Appel and Jim [1989]), and graph-based reduction, the most promi-
nent instance of which is the STG (Spineless Tagless G-machine, [Jones and Salkild,
1988; Jones, 1992]). The stack-based implementations of functional languages have the
advantage that they can be mapped to off-the-shelf hardware, making effective use of the
target architecture’s hardware stack and registers, as is achieved, e.g., in the implemen-
tation of the functional language OPAL by compilation of (recursive) OPAL functions to
(recursive) C procedures [Schulte and Grieskamp, 1992; Schulte, 1992]. CPS techniques
make the reduction stack implicit by passing a continuation to each function application
136 Abstract Machine
to be called with the result of evaluation, implying that “stack frames” are actually allo-
cated on the heap. Given a good garbage-collection scheme, this technique can be rather
efficient [Appel, 1987], since it allows a natural optimization of tail calls, efficient real-
ization of exceptions (important for the implementation of ML [Milner et al., 1990]), and
a stackless implementation of concurrent threads, as used, e.g., for CML [Reppy, 1991].
The STG-based implementations use the graph-reduction paradigm, resulting in com-
piled code which looks – interestingly enough – rather similar to the final code generated
for higher-order functions in stack-based or CPS approaches. A “suspension” in the STG
is represented as a closure with an associated evaluation method. The first time the sus-
pension is forced, the evaluation result is memorized in the closure and the evaluation
method is updated. The next time the suspension is consulted, the updated method sim-
ply retrieves the result from the previous evaluation. In the stack-based implementation
of the strict language OPAL, exactly the same effect is achieved by memorization of the
evaluation result of
ô
-ary function abstractions,
ÏnÖ×
Õ
e, in closures, with the only sig-
nificant difference to the STG that strict stack-based evaluation is the default and lazy
closure-based evaluation the special case.
One of the first attempts to extend functional reduction by logic computation is the
BAM [Kuchen et al., 1990]and its lazy version, the LBAM [Moreno-Navarro et al., 1990],
which are used to implement the functional logic language BABEL [Moreno-Navarro and
Rodriguez-Artalejo, 1992]. These machines extend graph reduction by nodes for logic
variables and use choice points and trailing as in the WAM (and the ZAM) to deal with
backtracking. An optimization by deterministic rule detection at runtime is described by
Loogen and Winkler [1991]. If the application of a rule does not bind any logic variable,
then – by orthogonality of the functional rule system – choice points for other cases can
be discarded. The ZAM, by contrast, cannot rely on orthogonality, since whether a set is a
function is not represented in
Ù
Z. Hpwever, we have shown how choice point scheduling
results in similar effects as the “dynamic cut” of Loogen and Winkler [1991].
Based on the STG model and the above-described closure technique, the JUMP ma-
chine [Chakravarty and Lock, 1991; Lock, 1992; Chakravarty and Lock, 1997] provides
an interesting approach for integrating logic computation into a functional machine. The
notion of a “closure” is extended to an “active object”, which is used to represent several
kinds of runtime objects – among them suspensions and logical variables. “Jumping” in
this machine amounts to calling the evaluation method of an active object, which behaves
differently in dependency of kind and state of the object. The JUMP machine uses tech-
niques similar to that of the WAM and the ZAM for dealing with backtracking: choice
points are used to hold information for restoring the state of the machine. The machine
can avoid the creation of choice points if functions are applied to ground terms, since it
can assume orthogonality of the function’s rules. One technical problem with the archi-
tecture of the JUMP machine is that it does not match well with modern, cache-based
processor architectures, since it makes abundant use of indirect code jumps between very
small code chunks – on these architectures, the older technique of “tag-based branching”
for compiled code might be in fact more appropriate, and a byte code interpreter is not
much slower.
The machines mentioned are examples of extending functional implementation tech-
niques by logic computation. Again, these techniques, like the discussed extensions of
the WAM, are inadequate for implementing
Ù
Z. The main problem is the lack of support
5.5 Discussion 137
for concurrent constraint resolution and the possibility to freely combine extensions and
intensions to build sets, relations and functions at runtime.
Concurrent Constraint Resolution
An influential design of a concurrent constraint-resolution machine is the implementation
of the Andorra Kernel Language, AKL [Janson and Haridi, 1991; Franzen et al., 1992;
Janson, 1994]. Among others, the “Andorra Principle” [Warren, 1990], of which the
ZAM’s technique of choice scheduling is an instance, is implemented by this machine.
One of the more recent designs of a constraint-resolution machine is the Oz machine,
part of the Mozart system [Mehl et al., 1995; Scheidhauer, 1998; Mehl, 1999]. The Oz
machine uses a so-called store to represent Oz’s computation spaces, containing bindings,
constraints and values. A so-called worker executes a thread, which is represented by a
stack of so-called tasks that are executed until the stack is empty. Tasks are tuples of envi-
ronments and instruction pointers. On execution of a task, new tasks may be pushed to the
stack of a worker, thus realizing dynamically calculated control flow. Since tasks encap-
sulate their environment, they can be moved between thread workers: hence suspensions
of computations that access unbound variables can be handled by moving the related task
to a newly created, suspended thread worker and continuing with the next task on the
stack of the current worker. One advantage of this model in comparsion with the ZAM
is that, initially, only one thread is used to execute a set of constraints, whereas the ZAM
spawns a thread for each constraint from the start. On the other hand, the representation
of tasks and of context switching to environments attached to each task has to be paid
for in the Oz machine, whereas thread creation in the ZAM costs only a few instructions.
Moreover, minimizing the number of active threads can also be performed by optimiza-
tion at compile time: based on a mode analysis that evaluates static data dependencies, a
set of
Ù
Zconstraints can be compiled to execute in a single ZAM thread.
The Oz machine does not use trailing and backtracking for implementing choices, but
instead copies stores. This allows several search strategies (breadth-first, depth-first) to be
easily realized. Copying is closely related to implementing search in functional languages
using a “continuation” function that holds the alternative of a choice, the current set of
context bindings, stored in a closure. The general problem with copying is that it is
speculative: it is not known whether the copy will actually be used during subsequent
computations.
A quite recent machinerealizing concurrent constraint-resolution is describedby Hanus
and Sadre [1999] for the implementation of Curry. This machine uses “and parallelism” as
usual in constraint resolution, but also “or parallelism” for the execution of disjunctions:
independent threads are spawned for the different choices in a disjunction, effectively
implementing breadth-first search, as required by Curry’s semantics. Choice scheduling,
resembling the Andorra principle [Warren, 1990] as in the ZAM, is applied to prune the
overhead of choices. To avoid copying, this machine associates with each thread a unique
key, and each variable contains a hash table of bindings indexed by thread keys. Though
speculative copying is avoided, the overhead of this approach is that each variable access
requires selection via a hash table.
The ZAM has a simpler and much more compact design than the other machines
mentioned, which it inherits from the minimalistic
Ù
Zcalculus. But the ZAM is also less
138 Abstract Machine
complex because it is restricted to built-in depth-first search, implemented by the classical
trailing and backtracking technique. Forproblems that can be solved by depth-first search,
this leads to more efficient execution results than copying of stores (as in the Oz machine)
or variable hashing (as in the Curry machine), but problems which require breadth-first
search cannot be handled adequately by the ZAM.
Chapter 6
The ZeTa System
“Sie meinen also tats¨achlich,
daß ein Kunstwerk kollektiv
hergestellt werden k¨
onnte?”
- : “Ab¨
arrj´
a!”
(Arno Schmidt: Die Gelehrtenrepublik)
The concepts presented in this thesis are applied in the broader context of the ZeTa sys-
tem, which was developed by the author together with Robert B¨ussow in the course of the
ESPRESS project. We conclude the thesis with a review of ZeTa and the application of
the
Ù
Zimplementation, called ZaP, in the context of the ZeTa system.
6.1 Three Dimensions of Integration
The goal of the ZeTa system is to provide an open environment for editing, browsing and
analyzing integrated specifications, assembled from heterogeneous formalisms – includ-
ing Statecharts, Z, temporal logic, message-sequence charts and others. These formalisms
are processed by different techniques, such as deduction-based analysis, model checking,
systematic testing and simulation. Established CASE tools (such as Statemate [Harel
et al., 1990]) shall be used in combination with the existing powerful tools for formal
methods (such as the deduction system Isabelle [Paulson, 1994] or the model checker
FDR [Formal Systems , Europe]), and specialized tools newly developed in the context of
ESPRESS – such as the ZAP compiler.
ZeTa’s design as an open environment for notations and tools was derived from the
experiences in the application oriented research project ESPRESS, in which the industrial
partners determined the choice of formalisms and tools. In basic research one can stick to
a particular notation or tool over a period of years, carefully tuning the approach. On the
other hand, in industrial research, comprehensible results are asked for soon and require-
ments and fashions change fairly quickly. From the point of view of basic research, it is
therefore desirable to have a flexible approach with regards to the “front-end” technology,
one which can easily cope with new requirements while at the same time allowing scope
for steady enhancement of the underlying “back-end” technology.
The ZeTa system sets out to achieve this goal by defining three dimensions of in-
tegration at the front-end level: semantic integration,document integration and tool in-
tegration. This logical integration levels are accompanied by graphical user interfaces.
The ultimate goal is to make basic tools, e.g. for computation, once they have been in-
tegrated on the semantic and the tool level, reusable for different document formats and
input languages.
140 The ZeTa System
.....
External Notations
and Tools
Statemate
Standard Z (data) µSZ core
(behavior)
µSZ with plugins
....
Temporal Logic
HOL-Z prover SMV Model Checker ZAP Compiler
Generic Tools
ü>ý
SC
ü¢ý
AC
ü¢ý
TL
þ¢ÿ
P
Q
Figure 6.1: Semantic Integration in ZeTa
6.1.1 Semantic Integration
Semantic integrationin ZeTais realized by the
Ù
notation [B¨ussowet al., 1996, 1997a;
B¨ussow and Grieskamp, 1999].
Ù
is based on a core, which is a collection of con-
ventions for specifiying structure and behavior in Standard Z. External notations are inte-
grated by so-called languageplugins, which are defined by a shallow syntactic translation
into the
Ù
core. This is illustrated in Fig. 6.1.
The
Ù
core provides a model for concurrent components. Shared and private data
can be described, thus constituting the data space. A set of traces of bindings of the data
space defines the dynamic behavior. The dynamic behavior can be specified in several
ways: for example, by giving a data-state-transition relation, which can be executed by
ZaP, or by giving axiomatic constraints on the set of traces (which are not as easy to
execute – but see, however, future work in Chapter 7). Prior to trace construction, the
data space is extended by information to model concurrent access to its variables. To this
end, each variable of the data space is equipped with a lock, which can be acquired by
concurrently executing activities. The locks allow us to resolve racing, the situation in
which two parallel activities write to the same variable during the same execution step.
Racing is a prototypical situation of concurrent resource allocation and can be used to
model higher-level communication facilities, such as channels and service-access points
(i.e. remote procedure calls). For further details, see [B¨ussow and Grieskamp, 1997,
1999].
To integrate a new formalism, it is necessary to define a translation of this formalism
into the
Ù
core. For tool integration, a so-called model source adaptor that does the
translation has to be implemented. The adaptor concept is outlined below in Section 6.1.3
(on the next page). Whether integration of a formalism is possible depends on whether a
translation can be found. To what extent generic tools such as ZAP can be reused depends
on the
Ù
core definitions resulting from this translation.
6.1 Three Dimensions of Integration 141
.......
Statemate Event Diagram Editor
Die Kontrolle des Fahrgschwindigkeitskonstanter
wird durch diue folgende Klasse beschrieben:
\begin{class}{Control}
\end{class}
\includeMSL{STM:cntrl.sch}
\includeMSL{STM:cntrl.ach}
\includeMSL{EVD:cntrl.diag}
MSL = Model Source Locator
MSZ:control.tex
Editing Browsing Analyzing
.....
External Tools
User Views
Compound Document
Figure 6.2: Document Integration in ZeTa
6.1.2 Document Integration
The “cement” of integration in the ZeTa environment is an integrated specification docu-
ment (ISD). In most cases, this is a
Ù
specification, but in general an ISD needs not to
contain formal parts.
An ISD is given in a markup language and contains references to fragments of spec-
ification contributed by external tools. The references are described by model source
locators (MSL), a concept comparable to URLs. An MSL identifies the tool that is to
provide the (sub-)model and a tool specific identifier for the desired portion. This is illus-
trated in Figure 6.2. Besides the external tool Statemate, a tool for editing event diagrams
(providing a graphical frontend for temporal logics) is shown as an example.
The major difference between the concept of URLs and that of MSLs is that the latter
are interpreted in different ways, depending on the operation to be performed on an ISD.
For example, if an ISD is browsed, its MSLs are resolved to encapsulated postscript. If
it is analyzed, the MSLs may be resolved to an
Ù
core abstract syntax term which is
inserted in the enclosing component (depending on the kind of analysis and MSL).
The ISD itself is addressed by anMSL as well: if the ISD is givenin theL
A
TEX-markup,
then such an MSL looks like this: LTX:ICC#CruiseControl.tex. Here, LTX de-
notes the tool providing this MSL (the L
A
TEX-System), ICC denotes a
Ù
component
and CruiseControl.tex a file where this component is found.
6.1.3 Tool Integration
The basic operation provided by the ZeTa integration environment is querying the con-
tent of an MSL. This query is parameterized by the type of the desired content. Typical
types are “gif”, “encapsulated postscript”, “parsed abstract syntax”, “type-checked ab-
142 The ZeTa System
stract syntax”, “plugin abstract syntax”, and so on. Types may become more complex
containing further selective information, e.g. “the precondition of schema S”.
The ZeTa environment behaves as a broker between queries and tools that have reg-
istered in the environment the ability to compute content of specific types. Once a tool is
contacted to compute a particular content, it may recursively query the environment for
further content. For example, when a type checker is contacted to compute the “checked
abstract syntax” of an
Ù
class, it first queries the “parsed abstract syntax”. If this syntax
contains MSLs referring to external notations, it next queries the “plugin abstract syntax”,
then merges the syntaxes, and finally performs its type-check operation. This way, tool
chains are realized.
The basic model of ZeTa is comparable to a traditional Unix make, but it is more
powerful and reliable, since it is embedded in the strongly-typed Java programming envi-
ronment:
Õ
The content exchanged by tools via ZeTa are standardized data formats defined by
Java APIs. For example, for the
Ù
language (and the Z language embedded in
Ù
), the abstract syntax is prescribed by ZeTa in a Java representation.
Õ
A tool is represented in a ZeTa session as a Java object whose instances implement
the interface of so-called tool adaptors, and which can have state and behavior. The
adaptor object may implement its functionality completely in Java, or may wrap
another Unix process, or may be an RMI (remote method invocation) proxy to a
remotely running JVM.
Õ
Tool adaptors may import external models into the ZeTa session from other running
tools, not just the file system. For instance, the Statemate adaptor imports initial
content for its MSLs, STM:<chart>, by connecting to the “dataport” of a running
Statemate session.
Õ
ZeTa caches content resulting from computations, thus providing an outdating
mechanism. While make uses time stamps of files to decide whether an initial
content is outdated, in ZeTa adaptors that provide initial content may use arbitrary
techniques for this purpose.
Õ
ZeTa realizes a session protocol for computations, which keeps a record of the
diagnostics produced by tools, among other things.
The plugins of the
Ù
notation directly correspond to certains kind of tool adaptors
plugged into the ZeTa environment (in fact, historically, the ZeTa plugins preceded the
Ù
plugins). These adaptors, which import an external notation into ZeTa by providing
initial content for MSLs, are called model source adaptors (MSA).
In the simplest case, an MSA directly performs the translation of the external notation
to the
Ù
core. Usually, however, there are intermediate steps in the way from an
external notation to
Ù
, and the intermediate content may be used by tools specially
tailored for its type.
This is illustrated in Figure 6.3 (on the next page). The Statemate-MSA initially
creates an abstract syntax for the Statechart, denoted by the MSL STM:ICCCONTROL,
which, in a second step, is converted to the
Ù
core syntax. In turn, the L
A
TEX-MSA
6.1 Three Dimensions of Integration 143
STM:ICCCONTROL / statechart absy LTX:ICC / µSZ lexis
LTX:ICC / µSZ parsed absySTM:ICCCONTROL / µSZ plugin absy
LTX:ICC / STM Simulation Model
LTX:ICC / µSZ checked absy
LTX:ICC / HOLZ model
Figure 6.3: Chains of Content Queries
initially creates a
Ù
lexis for the MSL LTX:ICC (the file name in the MSL has been
omitted), which is converted first to a parsed abstract syntax, then to a type-checked ab-
stract syntax. Assuming that the component denoted by LTX:ICC refers to the MSL
STM:ICCCONTROL, the type checker queries the abstract syntax of the
Ù
plugin as-
sociated with this MSL and includes it in the resulting type-checked abstract syntax (thus
checking the type consistency of the plugin within its component context).
Now the generation of a model for the HOLZ proveradaptor [Santen, 1999] is entirely
based on the checked abstract syntax, with the plugins expanded. However, in order to
generate a model for the Statemate simulator, it is necessary to query the checked
Ù
syntax as well as the original representation of the Statechart. Generating a simulation
model amounts to compiling code for the Z schemas referred to from transitions and
bind them to the Statemate simulator. To generate the binding code, the structure of the
Statechart has to be known.
This example shows that in the real world the integration provided by
Ù
plugins
is not always the only underlying representation for tools. The translation of an external
notation to the
Ù
core is an abstraction step in which information (in a syntactical
sense) is lost.
6.1.4 Graphical User Interfaces
ZeTa realizes a strict partition of model, view and controller. The model is effectively
implemented by the individual tool adaptors and the ZeTa content-query broker. The
controller is based on a command language that can be also used in batch mode. Two
“views” (GUIs) are provided on top of the controller.
XEmacs GUI. This GUI is based on the extendable texteditor XEmacs (see Figure 6.4).
It is primarily intended for users working under UNIX, who are used to the Emacs editing
environment. It maintains a session log, which utilizes for each operation the produced
output and supports browsing diagnostics contained in the output. It further provides
VTEX, a “what-you-see-is-what-you-mean” editing mode for L
A
TEX/Z documents. VTEX
is a customizable XEmacs mode that incrementally parses and visualizes the L
A
TEX struc-
tures and math symbols entered by the user.
144 The ZeTa System
Figure 6.4: The XEmacs GUI
Swing GUI. This GUI is based on Java’s Swing system (see Figure 6.5). It allows the
activationof ZeTaoperations by graphical dialogs and maintains a session log that utilizes
for each operation the produced output. Browsing diagnostics is supported by contacting
an external editor, which may be Emacs, but other editors (in particular. MS-Windows-
specific editors) may be used as well.
6.2 The ZaP Compiler
ZaP (version
ê
) is an experimental compiler for the Z language, which supports the full
higher-order functional sublanguage of Z. It is a predecessor of the forthcoming ZaP-
6.2 The ZaP Compiler 145
Figure 6.5: The Swing GUI
ë
, whose underlying concepts are described in this thesis and which will support the
functional logic sublanguage embedded in Z. Apart from its more powerful computation
model, the forthcoming ZaP-
ë
will not differ from ZaP-
ê
, so we can present the user’s
view of ZaP based on the old system.
ZaP follows the approach of compiling every Z construct. Nonexecutable constructs
of Z will be rejected once their execution has been attempted at runtime. This approach
reflects that whether a Z construct is executable depends on how it is used at runtime. For
example, a function might be defined in such a way that there is no constructive mapping
from input to output and that the application of the function to an input is not executable.
However, it might be still possible to test whether a given pair of input and output values
is in the function’s graph1.
1For future versions of ZaP, it is planned to have an analysis which gives hints for non-executable
146 The ZeTa System
Below, the well-known example of the birthday book specification is used to illustrate
the basic operation of ZaP. Please note that this example cannot serve as a systematic
outline of ZaP’s computation power, but it at least illustrates the ability to execute the
schema calculus, to lift schemas to functions and to define recursive higher-order func-
tions and relations – in an application context for test data evaluation. Starting with the
usual abstract specification of the birthday book, we refine it for the purpose of executabil-
ity (mainly fixing given types in the specification), and add a framework for evaluating
test data described by input/output behavior.
6.2.1 The Basic Specification of the Birthday Book
The specification is partitioned into several Standard Z sections. The first one, BBSpec,
contains the basic, or “abstract” specification of the birthday book example, as usually
found in the literature. The section is opened with the following declaration (all Z para-
graphs followingthis declaration until the next section declaration will belong to BBSpec):
BBSpec
We first define the given types NAME and DATE, and the data state of the birthday book:
Ò
NAME
Ô
DATE
Ó
BirthdayBook
known
ä
NAME
birthday
ä
NAME
DATE
known
á
birthday
An initial state of the birthday book is given by the following schema:
InitBirthdayBook
áLá°Ò
BirthdayBook
Ñ
birthday
á
!Ó
The value of this schema can be evaluated. In order to perform the evaluation the user
types in the name InitBirthdayBook in the Execute panel of the Swing GUI or in the
command line of the XEmacs GUI, resulting in the following (conceptual) output:
InitBirthdayBook
!
{<birthday == {},known == {}>}
Note that the field known of InitBirthdayBook is implicitely defined by the invariant of
the schema BirthdayBook,known
á
"
birthday.
Up to now, we have specified the state of the birthday book and a possible initial value,
but no state transitions. These are defined by the following Z “operation” schemas:
constructs at compilation time.
6.2 The ZaP Compiler 147
AddBirthday
#
BirthdayBook
name
$
ä
NAME
%
date
$
ä
DATE
name
$'&
è
known
birthday
(
á
birthday
ã%Ý
name
$
ùÐ
date
$
vâ
FindBirthday
)
BirthdayBook
name
$
ä
NAME
%
date
*
¡ä
DATE
name
$
è
known
date
*
á
birthday
Ö
name
$
l×
Remind
)
BirthdayBook
today
$
ä
DATE
%
cards
*
¡ä
NAME
cards
*
áõÝ
n
ä
known
Ñ
birthday
Ö
n
×á
today
$
vâ
Remove
#
BirthdayBook
name
$
ä
NAME
birthday
(
áõÝ
name
$
vâ
,+
birthday
The schema AddBirthday adds a mapping name
$
GùÐ
date
$
to the birthday book’s state,
the schema FindBirthday lookups the birthday of a given name
$
, and the schema Remind
yields the set of names whose birthday is today
$
. The schema Remove deletes the entry
for name
$
from the birthday book.
We are not yet able to execute any state transitions, since the types NAME and DATE
are given (uninterpreted). In the next section, we will refine these types.
6.2.2 Refining the Birthday Book for Execution
A refinement of the section BBSpec for the purpose of executionis provided by the section
BBExec:
BBExec
-/.0
12
BBSpec
The purpose of the refinement is to fix the given types NAME and DATE. The Z of ZeTa
allows to refine given types by free types:
NAME
äåäá
Werner
Ñ
Barbara
Ñ
Martin
DATE
äWäá
date
3
Date
4
148 The ZeTa System
Date
day
ä¯ê=î@î0û¯ê
month
ä¡ê7î@îêë
year
ä
576
month
áë
98
day
:
Bëvò
%
month
è£Ýï_Ôzí¯ÔóÔzò¯Ôêêlâ
;8
day
:
Áûô
We can now evaluate expressions by applying the date constructor to bindings:
date
<
day
áá¨êÔ
month
áá êÔ
year
áá êòòò
=
!
date <day == 1,month == 1,year == 1999>
The next application of the date constructor is undefined, since the passed binding is not
in its domain (the month February has no
ûô
th day):
date
<
day
ááHûô¯Ô
month
ááHëÔ
year
ááõê0òòò
=
!
ERROR[LTX:bbook.tex(186.3-186.56)]:
execution failed
reason:
application undefined:
relation: date
argument: <day == 30,month == 2,year == 1999>
backtrace:
at testing membership:
value: (30,29)
set: _\leq_
at testing membership:
value: <day == 30,month == 2,year == 1999>
set: LTX:bbook.tex(171.22-171.32)
at applying relation:
relation: date
argument: <day == 30,month == 2,year == 1999>
at evaluating command input
ZaPprints a backtrace describing the reason of the undefinedness. The ZeTa commander
– either via the Java GUI or the XEmacs GUI – allows to browse locators as contained in
the above output by clicking on them.
Next we introduce some convenience functions for describing operations on birthday
books. These functions make use of the new features of the Z ISO Standard as regards to
the unification of schema expressions and plain expressions. They yield a set of bindings
(a schema) which can be referred in schema expressions:
add
ááHÏ
name
ä
NAME
%
date
ä
DATE
Õ
Ö
?>
name
$
áá
name
%
date
$
áá
date
Õ
AddBirthday
×
find
ááHÏ
name
ä
NAME
Õ
Ö
?>
name
$
Káá
name
Õ
FindBirthday
×
remind
ááHÏ
today
ä
DATE
Õ
Ö
@>
today
$
Káá
today
Õ
Remind
×
remove
áLáHÏ
name
ä
NAME
Õ
Ö
?>
name
$
áá
name
Õ
Remove
×
6.2 The ZaP Compiler 149
Note that the existential quantifiers in these definitions are schema quantifiers.
We can now execute transitions of the birthday book’s state, starting with the initial
state:
InitBirthdayBook
A
add
Ö
Werner
Ô
date
<
day
ááóÔ
month
áLá
"B
Ô
year
áá¨ê0òëlò
=
×
!
{<birthday == {},
birthday’ ==
{(Werner,date <day == 7,month == 5,year == 1929>)},
known == {},known’ == {Werner}>}
InitBirthdayBook
A
add
Ö
Werner
Ô
date
<
day
ááóÔ
month
áLá
"B
Ô
year
áá¨ê0òëlò
=
×
A
add
Ö
Barbara
Ô
date
<
day
áLá ê0ì¯Ô
month
áá êêvÔ
year
áLá ê0òû
BC=
z×
A
add
Ö
Martin
Ô
date
<
day
ááõê0ì¯Ô
month
áá¨êêÔ
year
ááõê0òû
BC=
z×
A
find
Ö
Werner
×
A
remind
Ö
date
<
day
áá¨ê0ì¯Ô
month
áá êvêÔ
year
áLáõê0òû
B=
×
A
remove
Ö
Martin
×
!
{<birthday == {},
birthday’ ==
{(Barbara,date <day == 18,month == 11,year == 1935>),
(Werner,date <day == 7,month == 5,year == 1929>)},
cards! == {Barbara,Martin},
date! == date <day == 7,month == 5,year == 1929>,
known == {}, known’ == {Barbara,Werner}>}
The last evaluation deserves some notes on the schema calculus operator,
A
.Op
6
A
Op
D
binds primed names x
(
from the signature of Op
6
to unprimed counterparts xin the
signature of Op
D
. Variables not bound this way (such as cards
*
and date
*
) or kept as is. In
the evaluation result, these variables represent the result of applying the find and remind
operations, respectively.
The application of a unique schema InitBirthdaybook (representing by a singleton
binding set) to deterministic operations yields a singleton binding set. But ZaP is also
capable of handling non-unique initial states and indeterministic operations. Consider the
following definition:
InitBirthdayBookUndet
áá
InitBirthdayBook
E
Ò
BirthdayBook
Ñ
birthday
á
Ý
Werner
ùÐ
date
<
day
áá;óÔ
month
áLá
"B
Ô
year
áá ê0òëlò
=
yâ0Ó
Evaluation yields in:
InitBirthdayBookUndet
150 The ZeTa System
!
{<birthday == {},known == {}>,
<birthday ==
{(Werner,date <day == 7,month == 5,year == 1929>)},
known == {Werner}>}
InitBirthdayBookUndet
A
Ö
add
Ö
Barbara
Ô
date
<
day
áá¨ê0ì¯Ô
month
áLá êêÔ
year
áá¨ê0òû
CBC=
×
E
add
Ö
Martin
Ô
date
<
day
áá¨ê0ì¯Ô
month
áá¨êvêÔ
year
áá¨ê0òû
B=
××
!
{<birthday == {},
birthday’ ==
{(Barbara,date <day == 18,month == 11,year == 1935>)},
known == {},known’ == {Barbara}>,
<birthday == {},
birthday’ ==
{(Martin,date <day == 18,month == 11,year == 1935>)},
known == {},known’ == {Martin}>,
<birthday ==
{(Werner,date <day == 7,month == 5,year == 1929>)},
birthday’ ==
{(Barbara,date <day == 18,month == 11,year == 1935>),
(Werner,date <day == 7,month == 5,year == 1929>)},
known == {Werner},
known’ == {Barbara,Werner}>,
<birthday ==
{(Werner,date <day == 7,month == 5,year == 1929>)},
birthday’ ==
{(Martin,date <day == 18,month == 11,year == 1935>),
(Werner,date <day == 7,month == 5,year == 1929>)},
known == {Werner},
known’ == {Martin,Werner}>}
Of course, such evaluations might easily lead to an explosion of possible states. ZaP-
ê
will run into efficiency problems if they are hundreds of them – ZaP-
ë
, using the com-
putation model described in this thesis, shall easily cope with several ten-thousands of
states.
6.2.3 Refining the Birthday Book for Testing
A refinement of the section BBExec for the purpose of evaluation of test data with ZAP is
given by the Z section BBTest:
BBTest
-/.0
12
BBExec
The test-data will be specified by sequences of input and output behavior of the birthday
book. However, the original specification does not provide unique input and output in-
terfaces. But we can lift the original specification without modifying it to such unique
6.2 The ZaP Compiler 151
interfaces. First, we define free types for describing the input and output behavior:
INPUT
äåäá
addI
3
NAME
F
DATE
4
©Ñ
findI
3
NAME
4
§Ñ
remindI
3
DATE
4
©Ñ
removeI
3
NAME
4
OUTPUT
äWäá
okayO
Ñ
dateO
3
DATE
4
§Ñ
namesO
3
NAME
4
Next, we lift the operations of the original specification to ones with unique in-
put/output interfaces:
UniqueAdd
áá
Ò
AddBirthday
%
in
ä
INPUT
%
out
ä
OUTPUT
Ñ
Ö
name
$
Ô
date
$
l×ùÐ
in
è
addI
%
out
á
okayO
Ó
HG
)Ö
name
$
Ô
date
$
l×
UniqueFind
áLá
Ò
FindBirthday
%
in
ä
INPUT
%
out
ä
OUTPUT
Ñ
name
$
KùÐ
in
è
findI
%
date
*
ùÐ
out
è
dateO
Ó
G
)Ö
name
$
Ô
date
*
×
UniqueRemind
áLá
Ò
Remind
%
in
ä
INPUT
%
out
ä
OUTPUT
Ñ
today
$
KùÐ
in
è
remindI
%
cards
*
ùÐ
out
è
namesO
Ó
G
9Ö
today
$
Ô
cards
*
×
UniqueRemove
áá
Ò
Remove
%
in
ä
INPUT
%
out
ä
OUTPUT
Ñ
name
$
KùÐ
in
è
removeI
%
out
á
okayO
Ó
IG
Ö
name
$
l×
ZaP has no problems with the execution of such morphed operations. Instead of illustrat-
ing this now, we directly continue by defining a framework which tests if sequences of
INPUTS and OUTPUTS do match the specification.
The possible state transitions of the birthday book are defined as the disjunction of all
the operations with unique I/O interface:
UniqueOps
áá
UniqueAdd
E
UniqueFind
E
UniqueRemind
E
UniqueRemove
For test data evaluation, we define a function which, given a pair of input and out-
put states, yields a relation between admissible pre- and post-states of the birthday book
w.r.t. the I/O behavior:
step
áá
Ï
in
ä
INPUT
%
out
ä
OUTPUT
Õ
Ý
#
BirthdayBook
Ñ
UniqueOps
Õ
KJ
BirthdayBook
ùÐ
J
BirthdayBook
(
â
Finally, a recursive “test”-function is defined which computes the post-states resulting
152 The ZeTa System
from a sequence of input and output traces. The function takes as a parameter a set of
initial states – the condition to let it be executable is that this set is finitely enumeratable:
test
ä
1L2MNMPO,Q
çÖ
?
BirthdayBook
R
SUTWV
INPUT
F
SNTV
OUTPUT
R
BirthdayBook
×
test
áÏ
init
ä
BirthdayBook
Õ
Ï
is
ä
SNTV
INPUT
%
os
ä
SUTWV
OUTPUT
Ñ
YX
is
á
ZX
os
Õ
[
X
is
áHô
\]1
init
1^_W
step
Ö
lastis
Ô
lastos
×
W`
test
Ö
init
×Ö
frontis
Ô
frontos
×
ba
The
L2McMdO,Q
constructor around the type of the function test tells ZaPnot to try to check
whether the set test is actually a total function of the specified type. This check would not
be executable.
To test “test”, some I/O traces representing test data are defined:
date
êáá
date
<
day
áá;óÔ
month
áá
ZB
Ô
year
ááõê0òëvò
=
date
ëáá
date
<
day
áá¨ê0ì¯Ô
month
ááõêêÔ
year
áá¨ê0òû
CBC=
in
êáá°ß
addI
Ö
Werner
Ô
date
êl×ià
out
êáLá¨ß
okayO
à
in
ëáá°ß
addI
Ö
Werner
Ô
date
êl×zÔ
findI
Ö
Werner
×ià
out
ëáLá¨ß
okayO
Ô
dateO
Ö
date
ê×ià
out
ë
a
áá®ß
okayO
Ô
dateO
Ö
date
ë×ià
in
ûLáá°ß
addI
Ö
Werner
Ô
date
êl×zÔ
addI
Ö
Barbara
Ô
date
ë×zÔ
addI
Ö
Martin
Ô
date
ë×zÔ
findI
Ö
Werner
×zÔ
remindI
Ö
date
ë×ià
in
û
a
áá°ß
addI
Ö
Werner
Ô
date
êl×zÔ
addI
Ö
Werner
Ô
date
ë×zÔ
addI
Ö
Barbara
Ô
date
ë×zÔ
findI
Ö
Werner
×zÔ
remindI
Ö
date
ë×ià
out
ûLáLá¨ß
okayO
Ô
okayO
Ô
okayO
Ô
dateO
Ö
date
êl×zÔ
namesO
ÖiÝ
Barbara
Ô
Martin
â×ià
out
û
a
áá®ß
okayO
Ô
okayO
Ô
okayO
Ô
dateO
Ö
date
êl×zÔ
namesO
ÖÝ
Barbara
â×ià
We can now run some evaluations:
test
Ö
InitBirthdayBook
×zÖ
in
êvÔ
out
êl×
!
{<birthday ==
{(Werner,date <day == 7,month == 5,year == 1929>)},
known == {Werner}>}
test
Ö
InitBirthdayBook
×zÖ
in
ëÔ
out
ë×
!
{<birthday ==
{(Werner,date <day == 7,month == 5,year == 1929>)},
known == {Werner}>}
test
Ö
InitBirthdayBook
×zÖ
in
ëÔ
out
ë
a
×
!
{}
6.2 The ZaP Compiler 153
test
Ö
InitBirthdayBook
×zÖ
in
ûÔ
out
û×
!
{<birthday ==
{(Barbara,date <day == 18,month == 11,year == 1935>),
(Martin,date <day == 18,month == 11,year == 1935>),
(Werner,date <day == 7,month == 5,year == 1929>)},
known == {Barbara,Martin,Werner}>}
test
Ö
InitBirthdayBook
×zÖ
in
û
a
Ô
out
û×
!
{}
test
Ö
InitBirthdayBook
×zÖ
in
ûÔ
out
û
a
×
!
{}
Failing tests are indicated in that they yield an empty set as the post-state of an execution.
A refined version of the function test is given as a partial function, which always yields
nonempty sets:
ptest
ä
L2McMdO,Q
¢Ö
?
BirthdayBook
R
SUTWV
INPUT
F
SNTV
OUTPUT
BirthdayBook
×
ptest
áÏ
init
ä
BirthdayBook
Õ
Ï
is
ä
SNTV
INPUT
%
os
ä
SUTWV
OUTPUT
Ñ
YX
is
á
ZX
os
Õ
[
X
is
áHô
\]1
init
1^_W
ÖÙ
post
áá
step
Ö
lastis
Ô
lastos
×
`
ptest
Ö
init
×zÖ
frontis
Ô
frontos
×
ca
KÑ
post
e
á
I×
The
Ù
-form lets the executing function be undefined if the post states become empty.
Evaluating a failing test now results in a detailed backtrace which tells us the reason for
the failure (the actual backtrace has been ommited):
ptest
Ö
InitBirthdayBook
×zÖ
in
ëÔ
out
ë
a
×
!
ERROR[LTX:bbook.tex(530.2-530.36)]:
execution failed
reason:
mu-value undefined:
set: {}
...
154 The ZeTa System
6.3 Discussion
We briefly discuss integration frameworks related to ZeTa and the execution of Z specifi-
cations.
Integration Frameworks
Few projects tackle the problem of integrating tools for formal methods and existing
commercial CASE tools like the ZeTa system. The approach of the UniForM Work-
bench [Krieg-Br¨uckner et al., 1999] comes closest to doing so. However, whereas ZeTa’s
integration language Java is object-oriented, UniForM employs a functional language
(Haskell) for this task. Also, the architecture of UniForM is more ambitious (and thus
more difficult to implement and maintain) as regards to version control. On the other
hand, UniForM is less specialized than ZeTa and does not provide conventions for inte-
grating notations and documents.
Other approaches like the Concurrency Factory [Cleaveland et al., 1994] or AutoFo-
cus [Sch¨atz and Huber, 1999] present more homogeneous environments, with most tools
written from scratch and less emphasis on integrating existing tools.
Encoding of Z
Some basic principles of a mapping from Z to
Ù
Zhave been outlined in Chapter 3, but
we have not discussed the intrinsic details. In the ZaP implementation, the mapping of
Z to
Ù
Zhas to convert axioms to definitions where possible, e.g., eliminate quantifiers
in axioms of the kind
f
x
ä
X
Õ
f
Ö
x
×4á
e, map recursion to
Ù
Z’s fixed-point operator,
and so on. The mapping must also weaken the specification by turning some axioms into
assumptions: if a user, for example, declares a function to be “total” by using Z’s total
function arrow, f
ä
A
R
B, this assertion cannot be computed if f’s definition is non-finite,
and need therefore be converted into an assumption (which can be done explicitely by the
user or implicitely by ZaP, depending on switches). All this has been implemented in
the ZaP tool and will be ported to the new design of functional logic computation in the
forthcoming ZaP-
ë
.
Other Approaches Executing Z
Animation of the “imperative”part of Z is provided by the ZANS tool [Jia, 1996], impera-
tive meaning Z’s specification style for sequential systems using state transition schemas.
This approach is highly restricted, as it cannot even handle the functional sublanguage
of Z. An elaborated functional approach for executing Z has been described by Valentine
[1992, 1995], though no implementationexists today. A translation to Haskell is described
in [Goodman, 1995], where monads are used for dealing with the sequential specifica-
tion style, but no logic resolution is employed. Mappings to Prolog are described, e.g.,
in [West and Eaglestone, 1992]. Mappings of Z to Mercury are described in [Winikoff
et al., 1998]: however, in this approach the effective power of execution is restricted com-
pared with ours, because the data flow has to be determined statically. The approach
presented in this thesis goes beyond all the others, since it allows the combination of the
functional and logic aspects of Z in a higher-order setting, treating sequential behaviors
6.3 Discussion 155
as first-order citizins, comparable as to the integration of imperative computation into
functional languages using monads.
Chapter 7
Conclusion
Dreiundsechzighundert Hektometer
¨
uberm Spiegel seiner Wohnung steht er;
sieht die Gasschiff-Flotte der Korona
und erblickt das Mondschaf in Persona.
(Christian Morgenstern:
Palmstr¨om: Angewandte Wissenschaft)
Motivated by the desire of executing a subset of the set-based specification language Z,
we have introduced the set-based calculus
g
Z, defined a computation model for
g
Zas
well as an abstract machine implementing this model, a compilation of
g
Zto the ma-
chine’s instruction set and an efficient implementation strategy for the machine in C++.
The application of this work in the ZeTa system has also been outlined. A discussion
of the results obtained and of related work has been given in the relevant chapters. In
this concluding chapter, we summarize the contributions of the work and discuss some
possible directions for the future.
7.1 Contributions
g
ZCalculus
The
g
Zcalculusprovidesa newwayof viewingthe
h
-calculus, predicatecalculus, schema/module
calculus, set algebra, etc. within a unified framework. The calculus is considered an “in-
vention of the obvious”: to the author’s knowledge, there is no comparable language
though none of the ingredients of the calculus are actually new. The most unusual individ-
ual construct of
g
Zis its operator of set translation, providing a means for the constructive
description of morphisms in the category of
g
Zsets and, in combination with the other
operators, supplying
g
Z’s expressive power.
g
Z’s semantic model of partial set algebras, a generalization of three-valued logics,
is – at least as a model for Z related languages – a new approach. The author believes
that it is actually a more suitable model for Z itself than the one currently proposed by
Z’s Draft ISO Standard. The standard leaves the treatment of undefinedness and partiality
quite vague, in an unfortunate formal method’s tradition. In this thesis, we have at least
shown that it is possible to define a model of undefinedness for a set-based formalism
that is based on simple notions of lattice theory and does not require deep insight into
mathematical set theory (which cannot be expected of computer scientists.)
Computation Model
The reference computation model of
g
Z, defined in the style of natural semantics, pro-
vides a new view of computation in the realm of languages that can be encoded in
g
Z,
158 Conclusion
leading to a realistic efficient implementation. New is the representation of set values
by unions of singleton-set values and of intensions, the latter describing “computation
receipts” for sets. Intensions are a generalization of “closures”, as used in computation
models for functional languages.
Given the minimality of the
g
Zcalculus, its computation model could have been kept
minimal as well, and the different embedded models – functionalreduction and concurrent
constraint resolution – could have been clearly worked out. The interfaces of these two
worlds of computation are clearly visible – via the
g
-operator that invokes constraint
resolution from value reduction and via the p
i
econstraint that calls value reduction
for efrom constraint resolution. The presence of nondeterministic computation and the
need to introduce choice points in an implementation is isolated in computing a constraint
p
i
v
j
+ã
v
k
, where we can choose between p
i
v
j
and p
i
v
k
. The higher-order nature of
the model shows up in the instantiation of an intension for the computation of p
iml
p
npo
qsr
outv
, where we “import” the first-order citizen, the constraint
qsr
o7t
, into a resolution
context.
Abstract Machine
The abstract machine, ZAM, and its implementation emerged as a consequence of
g
Z’s
computation model. It was possible to keep the machine small, being easy to understand
(relative to the inherent complexity of the computation problem in
g
Z). The overall ar-
chitecture of the machine is innovative in this respect. Most of the organizational details
of the machine can be regarded as “folklore”: for example, implementation of residua-
tion using wait sets at variables, or employing the “Andorra Principle” for choice point
scheduling.
The implementation of the ZAM in C++ provides an innovative architecture by its
persistent single-assignment registers. On the one hand, persistent registers allow an effi-
cient realization of thread dumping, because only the program counter needs to be trailed,
and on the other hand, they enable callees to export references to register regions out of
their lexical scope. In combination with conservative garbage collection, this leads to an
integrated stack/heap model of memory allocation, which can be utilized by high-level
optimizations that employ a region analysis.
Formalization in Z
We have given a comprehensive formal specification in strictly type-checked Z of
g
Z’s
syntax and semantics, equational theory, computation model and abstract machine. Thus,
this work represents a case study for the use of Z as a meta language. For this purpose, it
was essential to extend Z. The first category of extensions we made – such as inference-
rule systems and recursive partial functions – could be explained as pure syntactic sugar
and are actually implemented this way by the E
wx
macro preprocessor. The second cate-
gory – such as independence of the textual order of paragraphs – needed real extensions
in comparison to Standard Z, which are implemented by the E
wx
type checker. The ex-
periment shows that – with the extensions used – Z is not only suitable for specifying
sequential systems in the style found in the textbooks, but also for the complex axiomatic
specifications as found in this thesis.
7.2 Future Work 159
7.2 Future Work
Apart from minor enhancements of the basic model, its didactic presentation, a full-
fledged implementation and case studies applying the implementation, the basic work
presented in this thesis provides a starting point for further lines of research. The most
important of these are outlined below.
Adding Solvers
For specialized constraint problems (e.g. subset constraints), tailored solving techniques
and tools are available. The trend in constraint-solving systemsis therefore to use modular
frameworks, where components for specialized solvers can be easily integrated, on the
semantical as well as the tool level. The aim of future work on
g
Zand its implementation
will be to support such modularity, and integrate further resolution techniques.
On the implementation level, the thread-based architecture of the ZAM and its im-
plementation in C++ is in principel prepared for modularity. An extension would need
to convert intensions and threads into abstract classes, providing abstract methods for
spawning a thread, executing a thread’s next step, trailing, backtracking and choice point
creation. This may allow third-party constraint solvers to be integrated, thereby inheriting
the generic capabilities of the ZAM for representing constraints as first-class values, for
choice point management and for variable allocation.
Static Analyses
The
g
Zcalculus provides an optimal setting for investigating and realizing static analyses
using the set-based approach. In his diploma thesis, Wieland [1999] has developed initial
steps toward a subset constraint solver on
g
Zterms, which is applied to extended type
checking of Z. Another application of this framework might be determinism and mode
analysis for the optimized compilation of
g
Zitself. (As Brandes [1997] has shown in his
diploma thesis, set-based analysis in principle can be used for this purpose.)
Both the extended type checking and the determinism problem are formulated as ab-
stractions from
g
Zterms into (specialized) set expressions, which can be directly ex-
pressed in
g
Zitself. For example, for the type analysis, a constant expression
y
is ab-
stracted into the expression
z1y
vâ
, denoting a singleton type. Future research might, then,
focus on a reflective approach: an analysis of a
g
Zexpression (and hence the high-level
form it encodes) is described by a translation into a more abstract
g
Zexpression, which
is then interpreted by compilation and execution. To obtain the full power of set-based
analysis, a solver component for subset constraints must, of course, added to the ZAM.
Computing Interval Logics
In [B¨ussow and Grieskamp, 1997; B¨ussow et al., 1997b] we described a modest exten-
sion of Z that adds temporal interval logic to the language. The addition of traces to a
set-based model was shown to work well: a temporal formula merely represents a set of
traces. A promising line of research would be to add a solver to
g
Z, implementing a few
primitive operators of discrete temporal interval logics. One interesting application area
is test data evaluation for reactive and embedded systems; a further is the execution of
160 Conclusion
watchdogs monitoring the allowed modal actions of safety- or security-critical systems.
Since interval logics can be used as a natural model for the constructive description of re-
active behavior (B¨ussow and Grieskamp [1997], for example, provide a shallow encoding
of Statecharts in interval logics), the animation and prototyping of reactive systems might
also be possible using this approach.
Bibliography
H. Ait-Kaci. Warren’s Abstract Machine – A Tutorial Reconstruction. MIT Press, 1991.
reprinted version from the author’s WWW page.
H. Ait-Kaci, P. Lincoln, and R. Nasr. Le Fun: Logic, equations, and functions. In Proc.
4th IEEE Internat. Symposium on Logic Programming, San Francisco, 1987.
S. Antony. Definitional trees. In Proc. 3rd International Conference on Algebraic and
Logic Programming, volume 632 of Lecture Notes in Computer Science. Springer-
Verlag, 1992.
S. Antony, R. Echahed, and M. Hanus. A needed narrowing strategy. In Proc. 21st ACM
Symposium on Principles of Programming Languages, 1994.
A. W. Appel. Garbage collection can be faster then stack allocation. Information Pro-
cessing Letters, 25:275–279, 1987.
A. W. Appel and T. Jim. Continuation-passing, closure-passing style. In Proceedings of
POPL ’89. ACM, 1989.
P. Arenas-Sanchez and A. Dovier. A minimality study for set unification. Journal of
Functional and Logic Programming, 1997(7), 1997.
H. Barendregt, editor. The Lambda Calculus: Its Syntax and Semantics. North-Holland,
Amsterdam, 1984. (revised edition).
M. Barr and C. Wells. Category Theory for Computing Science. Prentice Hall, 1990.
H. Boehm. Space efficient conservative garbage collection. In Proceedings of the ACM
SIGPLAN ’93 Conference on Programming Language Design and Implementation,
volume 28 of SIGPLAN Notices, pages 197–206, June 1993.
P. G. Bosco, E. C. Cecchi, and C. Moiso. An extension of the WAM for K-LEAF: a wam-
based compilation of conditional narrowing. In Proceedings of the Sixth International
Conference on Logic Programming (Lisboa). MIT Press, 1989.
O. Brandes. Automatische Verfahren zur Ausf¨uhrbarkeitsanalyse und ¨
Ubersetzung der
mengenbasierten Spezifikationssprache Z. Diplomarbeit, TU Berlin, Mai 1997.
R. B¨ussow, H. D¨orr, R. Geisler, W. Grieskamp, and M. Klar.
g
SZ – ein Ansatz zur system-
atischen Verbindung von Z und Statecharts. Technical Report TR 96-32, Technische
Universit¨at Berlin, Jan. 1996.
162 BIBLIOGRAPHY
R. B¨ussow, R. Geisler, W. Grieskamp, and M. Klar. The
gwx
Notation Version 1.0.
Technical Report 97–26, Technische Universit¨at Berlin, Fachbereich Informatik, Dec.
1997a.
R. B¨ussow and W. Grieskamp. Combinig Z and Temporal Interval Logics for the For-
malization of Properties and Behaviors of Embedded Systems. In R. K. Shyamasundar
and K. Ueda, editors, Advances in Computing Science – Asian ’97, LNCS 1345, pages
46–56. Springer-Verlag, 1997.
R. B¨ussow and W. Grieskamp. A Modular Framework for the Integrationof Heterogenous
Notations and Tools. In K. Araki, A. Galloway, and K. Taguchi, editors, Proc. of the
1st Intl.Conference on IntegratedFormal Methods – IFM’99.Springer-Verlag, London,
June 1999.
R. B¨ussow, W. Grieskamp, W. Heicking, and S. Herrmann. An Open Environment for the
Integration of Heterogeneous Modelling Techniques and Tools. In Proc. of Intl. Work-
shop on Current Trends in Applied Formal Methods, volume 1641 of Lecture Notes in
Computer Science. Springer-Verlag, Berlin, 1998.
R. B¨ussow, W. Grieskamp, F. Lattemann, and E. Lehmann. The Defini-
tion of Dynamic Z. ESPRESS interner Projektbericht. URL: http://uebb.cs.tu-
berlin.de/˜wg/papers/dynz.ps, May 1997b.
M. M. Chakravarty and H. C. R. Lock. Towards the uniform implementation ofdeclarative
languages. Computer Languages, 23(2-4), 1997.
M. M. T. Chakravarty, Y. Guo, M. K¨ohler, and H. C. R. Lock. GOFFIN: Higher-order
functions meet concurrent constraints. Science of Computer Programming, 30(1-2),
1997.
M. M. T. Chakravarty and H. C. R. Lock. The implementation of lazy narrowing. In Pro-
gramming Language Implementation and Logic Programming, volume 528 of Lecture
Notes in Computer Science. Springer Verlag, 1991.
R. Cleaveland, J. Gada, P. Lewis, S. Smolka, O. Sokolsky, and S. Zhang. The concurrency
factory — practical tools for specification, simulation, verification, and implementation
of concurrent systems. In Proceedings of the DIMACS Workshop on Specification of
Parallel Algorithms, Princeton, NJ, May 1994.
C. Consel and O. Danvy. Tutorial notes on partial evaluation. In ACM Symposium on
Principles of Programming Language, 1993.
L. Damas and R. Milner. Principal type-schemes for functional programs. In Proceedings
of POPL ’82, pages 207–212. ACM, 1982.
B. A. Davey and H. A. Priestly. Introduction to Lattices and Order. Cambridge Mathe-
matical Text Books. Cambridge University Press, 1990.
BIBLIOGRAPHY 163
K. Didrich, A. Fett, C. Gerke, W. Grieskamp, and P. Pepper. OPAL: Design and Im-
plementation of an Algebraic Programming Language. In J. Gutknecht, editor, Pro-
gramming Languages and System Architectures, International Conference, Zurich,
Switzerland, March 1994, volume 782 of Lecture Notes in Computer Science, pages
228–244. Springer, 1994. URL http://uebb.cs.tu-berlin.de/papers/
published/DesignImplOpal.ps.gz.
K. Didrich, W. Grieskamp, C. Maeder, and P. Pepper. Programming in the large: the
algebraic-functional language opal 2
{
. In Proceedings of the 9th International Work-
shop on Implementation of Functional Languages, St Andrews, Scotland, September
1997 (IFL’97), Selected Papers, volume 1467 of Lecture Notes in Computer Science,
pages 323 – 338. Springer, 1998.
A. Dovier, E. G. Omodeo, E. Pontelli, and G. Rossi.
z
log
â
: A language for programming
in logic with finite sets. Journal of Logic Programming, 28(1), 1996.
H. Ehrig and B. Mahr. Fundamentals of Algebraic Specifications 1: Equations and Ini-
tial Semantics, volume 6 of EATCS Monographs on Theoretical Computer Science.
Springer Verlag, Berlin, Heidelberg, New York, Berlin, 1985.
A. Fett and W. Grieskamp. Berlin proposals for the Z standard. http://uebb.cs.
tu-berlin.de/˜wg/zstan/, September 1998.
Formal Systems (Europe) Ltd. Failures Divergence Refinement, FDR2 User Manual.
Formal Systems (Europe) Ltd., 1997.
T. Franzen, S. Haridi, and S. Janson. An overview of the andorra kernel language. In Pro-
ceedings of the 2nd Workshop on Extensions to Logic Programming. Springer Verlag,
1992.
T. Frauenstein, W. Grieskamp, P. Pepper, and M. S¨udholt. Communicating functional
agents and their application to graphical user interfaces. In Proceedings of the 2nd
International Conference on Perspectives of System Informatics, Novosibirsk, LNCS.
Springer Verlag, Jun 1996a. URL http://uebb.cs.tu-berlin.de/papers/
published/PSI96-EA.ps.gz.
T. Frauenstein, W. Grieskamp, and M. S¨udholt. Temporal Semantics of a Concur-
rency Monad with Choice and Services. In Proceedings of the 2nd FUJI Interna-
tional Workshop on Functional and Logic Programming, Nov 1996b. URL http:
//uebb.cs.tu-berlin.de/papers/published/FUJI96.ps.gz.
H. S. Goodman. The Z-into-Haskell tool-kit: An illustrativecase study. In J. P. Bowen and
M. G. Hinchey, editors, ZUM’95: The Z Formal Specification Notation, volume 967 of
Lecture Notes in Computer Science, pages 374–388. Springer-Verlag, 1995. ISBN
3-540-60271-2. URL http://www.comlab.ox.ac.uk/archive/z/zum95.
html.
M. Gordon and T. Melham, editors. Introduction to HOL: A theorem proving environment
for higher-order logics. Cambridge University Press, 1993.
164 BIBLIOGRAPHY
W. Grieskamp, M. Heisel, and H. D¨orr. Specifying Embedded Systems with Statecharts
and Z: An Agenda for Cyclic Software Components. In E. Astesiano, editor, Proc. of
the 1st Intl. Conf. on Fundemantal Approaches to Software Engineering – FASE’98,
volume 1382 of Lecture Notes in Computer Science, pages 88–106. Springer-Verlang,
1998.
M. Hanus. Compiling logic programs with equality. In Proceedings of the 2nd Interna-
tional Workshop on Programming Language Implementation and Logic Programming,
volume 456 of Lecture Notes in Computer Sciene. Springer-Verlag, 1990.
M. Hanus. The integration of functions into logic programming: From theory to practice.
Journal of Logic Programming, 19(20), 1994.
M. Hanus. A unified computation model for declarative programming. In Proc. of the
1997 Joint Conference on Declarative Programming, Grado (Italy), 1997.
M. Hanus. Curry – an integrated functional logic language. Technical report, Internet,
1999. Language report version 0.5.
M. Hanus and C. Prehofer. Higher-order narrowing with definitional trees. Journal of
Functional Programming, 9(1), 1999.
M. Hanus and R. Sadre. An abstract machine for Curry and its concurrent implementation
in Java. Journal of Functional and Logic Programming, 1999(6), 1999.
D. Harel, H. Lachover, A. Naamad, A. Pnueli, M. Politi, R. Sherman, A. Shtull-Trauring,
and M. Trakhtenbrot. Statemate: A working environment for the development of com-
plex reactive systems. IEEE Transactions on Software Engineering, 16 No. 4, Apr.
1990.
P. H. Hartel, M. Feeley, M. Alt, L. Augustsson, P. Baumann, M. Beemster, E. Chail-
loux, C. H. Flood, W. Grieskamp, J. H. G. van Groningen, K. Hammond, B. Hausman,
M. Y. Ivory, R. E. Jones, J. Kamperman, P. Lee, X. Leroy, R. D. Lins, S. Loosemore,
N. R¨ojemo, M. Serrano, J.-P. Talpin, J. Thackray, S. Thomas, P. Walters, P. Weis, and
P. Wentworth. Benchmarking implementations of functional languages with “pseudo-
knot”, a Float-Intensive benchmark. J. of Functional Programming, 6(4), 1996.
P. Hudak, S. P. Jones, P. Wadler, et al. Report on the programming language Haskell.
ACM SIGPLAN Notices, 27(5), March 1992.
D. Jana and B. Jayaraman. Set constructors, finite sets, and logical semantics. Journal of
Functional Programming, 38(1), 1999.
S. Janson. AKL – A Multiparadigm Programming Language. PhD thesis, Computer
Science Departement, Uppsala University, Sweden, 1994.
S. Janson and S. Haridi. Programming paradigms of the andorra kernel language. In
Saraswat and Ueda, editors, Logic Programming: Proceedings of the 1991 Interna-
tional Symposium. The MIT Press, 1991.
BIBLIOGRAPHY 165
B. Jayaraman and K. Moon. Subset logic programs and their implementation. Journal of
Logic Programming, 19(20), 1999.
X. Jia. An approach to animating Z specifications. Internet: http://saturn.cs.
depaul.edu/˜fm/zans.html,1996.
S. L. P. Jones. Implementing lazy functional languages on stock hardware: the Spineless
Tagless G-machine. Journal of Functional Programming, 2(2), 1992.
S. L. P. Jones and J. Salkild. The spineless tageless G-machine. In Workshop on Imple-
mentation of Lazy Functional Languages, Aspensas, Schweden, 1988.
G. Kahn. Natural semantics. In Symposium on Theoretical Computer Science
(STACS’97), volume 247 of Lecture Notes in Computer Science, 1987.
B. Krieg-Br¨uckner, J. Peleska, E. Olderog, and A. Baer. The UniForM workbench, a
universal development environment for formal methods. In J. Wing, J. Woodcock,
and J. Davies, editors, FM’99 – Formal Methods, volume 1708 of Lecture Notes in
Computer Science. Springer, 1999.
P. Kruchten, E. Schonberg, and J. Schwartz. Software prototyping using the SETL pro-
gramming language. IEEE Software, 1(4), 1984.
H. Kuchen, R. Loogen, J. J. Moreno-Navarro, and M. Redriguez-Artalejo. Graph-based
implementation of a functional logic language. In Proceedings of European Sympo-
sium on Programming (ESOP ’90), volume 432 of Lecture Notes in Computer Science.
Springer Verlag, 1990.
P. J. Landin. The mechanical evaluation of expressions. Computer Journal, 6, 1964.
P. Larsen and W. Pawlowski. The formal semantics of ISO VDM-SL. Computer Stan-
dards and Interfaces, 17(5-6), 1995.
H. C. R. Lock. The Implementation of Functional Logic Languages. PhD thesis, Tech-
nische Universit¨at Berlin, 1992.
R. Loogen and S. Winkler. Dynamic detection of determinism in functional logic lan-
guages. In Proceedings of the 3rd International Symposium on ProgrammingLanguage
Implementation and Logic Programming, volume 528 of Lecture Notes in Computer
Science. Springer Verlag, 1991.
K. L. McMillan. Symbolic Model Checking. Kluwer Academic Publishers, 1993.
M. Mehl. The Oz Virtual Machine - Records, Transients, and Deep Guards. PhD thesis,
Technische Fakult¨at der Universit¨at des Saarlandes, 1999. submitted.
M. Mehl, R. Scheidhauer, and C. Schulte. An Abstract Machine for Oz. Research Re-
port RR-95-08, Deutsches Forschungszentrum f¨ur K¨unstliche Intelligenz, Stuhlsatzen-
hausweg 3, D66123 Saarbr¨ucken, Germany, June 1995. Also in: Proceedings of
PLILP’95, Springer-Verlag, LNCS, Utrecht, The Netherlands.
166 BIBLIOGRAPHY
R. Milner, M. Tofke, and R. Harper. The Definition of Standard ML. Mass. Institute of
Technology Press, Cambridge, Mass., 1990.
K. Moon. Implementation of Subset Logic Languages. PhD thesis, State University of
New York at New Buffalo, 1997.
J. J. Moreno-Navarro, H. Kuchen, R. Loogen, , and M. Rodriguez-Artalejo. Lazy nar-
rowing in a graph-machine. In Proceedings of the Conference on Algebraic and Logic
Programming, volume 463 of Lecture Notes in Computer Science. Springer Verlag,
1990.
J. J. Moreno-Navarro and M. Rodriguez-Artalejo. Logic programming with functions and
predicates: The language BABEL. Journal of Logic Programming, 12, 1992.
G. Nadathur and D. Miller. An overview of
h
Prolog. In Proc. 5th Conference on Logic
Programming & 5th Symposium on Logic Programming (Seattle). MIT Press, 1988.
O. Owe. Partial logic reconsidered: A conservative approach. Formal Aspects of Com-
puting, 5:208–223, 1997.
L. C. Paulson. Isabelle: A Generic Theorem Prover. Springer LNCS 828, 1994.
N. Plat and P. Larsen. An overview of the ISO/VDM-SL standard. SIGPLAN Notices, 27
(8), 1992.
C. Prehofer. Higher-order narrowing. In Proc. 9th Annual IEEE Symposium on Logic in
Computer Science. IEEE Press, 1994.
J. Reppy. CML: A higher-order concurrent language. In SIGPLAN Conf. on Programming
Language Design and Implementation, pages 293–305. ACM, Jun. 1991.
G. Rossi. The SETLOG programming language. Internet, 1997.
T. Santen. A Mechanized Logical Model of Z and Object-Oriented Specification. PhD
thesis, Fachbereich Informatik, Technische Universit¨at Berlin, Ger many, 1999.
B. Sch¨atz and F. Huber. Integrating formal description techniques. In J. Wing, J. Wood-
cock, and J. Davies, editors, FM’99 – Formal Methods, volume 1708 of Lecture Notes
in Computer Science. Springer, 1999.
R. Scheidhauer. Design, Implementierung und Evaluierung einer virtuellen Maschine
fr Oz. PhD thesis, Universit¨at des Saarlandes, Fachbereich Informatik, Saarbr¨ucken,
Germany, Dec. 1998.
W. Schulte. Effiziente und korrekte ¨
Ubersetzung strikter applikativer Programmier-
sprachen. PhD thesis, Technische Universit¨at Berlin, 1992.
W. Schulte and W. Grieskamp. Generating Efficient Portable Code for a Strict Applicative
Language. In Phoenix Seminar and Workshop on Declarative Programming. Springer
Verlag, Berlin, Heidelberg, New York, 1992.
BIBLIOGRAPHY 167
J. Siekmann. Unification theory. Journal of Symbolic Computation, 7(1), 1989.
G. Smolka. A calculus for higher-order concurrent constraint programming with deep
guards. Research Report RR-94-03, Deutsches Forschungszentrum f¨ur K¨unstliche In-
telligenz, Stuhlsatzenhausweg 3, D-66123 Saarbr¨ucken, Germany, Feb. 1994a.
G. Smolka. A foundation for higher-order concurrent constraint programming. In J.-P.
Jouannaud, editor, 1st International Conference on Constraints in Computational Log-
ics, Lecture Notes in Computer Science, vol. 845, pages 50–72, M¨unchen, Germany,
7–9 Sept. 1994b. Springer-Verlag.
G. Smolka. Concurrent constraint programming based on functional programming. In
C. Hankin, editor, Programming Languages and Systems, Lecture Notes in Computer
Science, vol. 1381, pages 1–11, Lisbon, Portugal, 1998. Springer-Verlag.
W. Snyder and J. Gallier. Higher-order unification revisited: Complete sets of transfor-
mations. Journal of Symbolic Computation, 8, 1989.
J. M. Spivey. The Z Notation: A Reference Manual. Prentice Hall International Series
in Computer Science, 2nd edition, 1992. ISBN 013-978529-9. URL http://www.
blackwell.co.uk/cgi-bin/bb_item?0139785299.
L. Spratt. Seeing the Logic of Programming with Sets. PhD thesis, University of Kansas,
1996.
F. Stolzenburg. An algorithm for general set unification and its complexity. Journal of
Automated Reasoning, 22(1), 1999.
I. Toyn. Innovations in standard Z notation. In J. P. Bowen, A. Fett, and M. G. Hinchey,
editors, ZUM’98: The Z Formal Specification Notation, volume 1493 of Lecture Notes
in Computer Science, pages 193–213. Springer-Verlag, 1998. URL http://www.
fmse.cs.reading.ac.uk/zum98/.
S. Valentine. The programming language Z
|H|
.Information and Software Technology, 37
(5–6):293–301, May–June 1995.
S. H. Valentine. Z
|H|
, an executable subset of Z. Workshops in Computing, pages 157–
187. Springer-Verlag, 1992. ISBN 3-540-19780-X. URL http://www.dcs.gla.
ac.uk/springer-verlag/21.html.
R. L. Vaught. Set Theory – An Introduction. Birkh¨auser, 1995.
P. Wadler and S. Blott. How to make ad–hoc polymorphism less ad hoc. In 16th ACM
Symposium on Principles of Programming Languages, pages 60–76, 1989.
D. H. D. Warren. An abstract Prolog instruction set. Technical Report 309, SRI Interna-
tional, 1983.
D. H. D. Warren. The extended andorra model with implicit control. In ICLP’90 Parallel
Logic Programming Workshop, 1990.
168 BIBLIOGRAPHY
M. M. West and B. M. Eaglestone. Software development: Two approaches to animation
of Z specifications using Prolog. IEE/BCS Software Engineering Journal, 7(4):264–
276, July 1992.
J. Wieland. A resolution algorithm for general subtyping constraints. Master’s thesis,
Technische Universit¨at Berlin, 1999.
M. Winikoff, P. Dart, and E. Kazmierczak. Rapid prototyping using formal specifications.
In Proceedings of the Australasian Computer Science Conference, 1998.
M. Wirsing. Handbook of Theoretical Computer Science, chapter Algebraic Specification
(13), pages 675–788. North-Holland, 1990. edited by J. van Leeuven.
J. C. P. Woodcock and J. Davies. Using Z: Specification, Proof and Refinement. Prentice
Hall International Series in Computer Science, 1996. ISBN 0-13-948472-8. URL
http://www.comlab.ox.ac.uk/usingz.html.
Z-ISO. Drafts for the Z ISO standard. Ian Toyn (editor). Available via the URL
http://www.cs.york.ac.uk/˜ian/zstan, 1999.
Concept Index
h
-calculus, 39
g
Zabbreviation forms, 39, 56
g
Zforms, 38
AKL, 140
algebra, 41
Andorra Principle, 140
backtracking, 87, 93, 99, 140
benchmark, 136
binding, 48
boolean
algebra, 58
laws, 58
values, 47
breadth-first search, 141
C++, 132
characteristic function, 43
choice point, 99, 103, 111
closure, 102
closure passing style, 138
committed choice, 70
common subexpression elimination, 95
compilation, 127
complete lattice, 35
configuration, 104
conjunctive normal form, 58
constraint, 41, 89, 101
constructor
application form, 52
decomposition laws, 60
continuous function, 36
cpo, 35
Curry, 41, 140
cycles, 102
deep guards, 97
definitional tree, 96
De Morgan’s laws, 58, 75
depth-first search, 141
deterministic computation, 87
disjunctive normal form, 58, 75, 95
dispatching, 112
encapsulated search, 97
excluded middle, 44, 58
excluded middle laws, 59
execution step, 112
expression
assignment, 57
context, 57
substitution, 57
type, 50
expression sharing, 95
extensional
completeness, 84
confluence, 74, 81, 84
equality, 73, 109
unequality, 73
fixed-point
construction, 68
form, 55
theorem, 36
unrolling law, 66
flexible, 127
flexible variable, 76
freely generated, 46
free type, 46
free variables, 57
functional logic languages, 41
garbage collection, 136
goal, 102
Goffin, 41
graph reduction, 95
higher-order, 42
unification, 97
170 CONCEPT INDEX
HOL, 69
Horn clause, 41
indeterministic resolution, 87
infimum, 34
instantiation, 101, 106
instruction, 104, 113, 134
intension, 88, 101
interval logic, 70, 164
JUMP machine, 139
lattice, 35, 48
lazy narrowing, 85
logic languages, 41
matching context, 74
meaning function, 51
module, 41
Mozart System, 140
narrowing, 83, 95, 138
natural numbers, 47
needed narrowing, 96
normal form, 75
normalform, 127, 128
normalization, 75, 95
normalization function, 82
Opal, 138
outermost-in narrowing, 85
Oz, 70, 140
parallel and, 87
parallel or, 87
partial
logic, 44
order, 34, 48
pattern
context, 57
type, 50
persistent, 132
power set, 45
predicate calculus, 40
Prolog, 41
redex selection strategy, 96
reduction step, 89
reflective analysis, 163
register, 132
register transfer language, 134
residuation, 41, 87, 99
resolution step, 89
schema
calculus, 40
complement lifting law, 65
distributivity laws, 64
elimination law, 64
form, 55
membership lifting law, 65, 76
property substitution law, 66
translation elimination law, 65
SECD machine, 138
selection, 112
set intersection, 100, 109
operator forms, 53
operators, 43
ordering, 48
representation, 43
selection elimination law, 59
translation form, 53
unification, 97
union, 100, 109
value, 100
set-based analysis, 163
SETL, 69
SETLOG, 69
single-assignment, 132
singleton
set display form, 52
set selection form, 52
soundness, 80, 84
spineless tagless G-Machine, 138
strict
narrowing, 86
reduction step, 89
semantics, 87
strictness, 97
subset logic programming, 69, 97
supremum, 34
symbolic model checking, 95
temporal logic, 164
termination, 80
CONCEPT INDEX 171
thread, 102
three-valued logic, 44
top-level program, 127
translation
composition law, 60
distributivity laws, 61
elimination law, 63
identity law, 60
lifting law, 63
product law, 62
splitting law, 63
tuple, 48
typeclasses, 34
relation, 50
substitution, 45
terms, 44
unification, 45
undefinedness, 38, 39, 68
unification, 89, 109
universe, 45
value, 100
constructor, 46
form, 88
variable form, 55
variable table, 101
WAM, 138
Z extensions, 28
ad-hoc overloading, 31
Delta and Xi, 31
free type recursion, 31
if-exists notation, 28
IF in predicates, 30
inference rules, 28
locals in schema boxes, 29
paragraph order, 31
recursive partial functions, 29
redeclarations, 31
selective delta, 30
where notation, 28
Z language, 25
constants, 26
function abstraction, 26
genericity, 26
polymorphism, 26
quantifiers, 26
schemas, 25
schema text, 25
set comprehension, 26
types, 25
undefinedness, 26
universe, 25
Z toolkit, 32
Booleans, 33
order and lattices, 34
sequences, 32
set reduction, 32
Symbol Index
LOADENV,105,114, 115,129, 130
MKEMPTY,105,107,118,129,134, 135
FIXINTEN,134, 135
MKINTEN,105,107,119,130,132,134, 135
ISECT,105,107,119, 120,128–130,134, 135
LOAD,105,113–116,120,129, 130
MEMBER,105, 106,111,116, 117,120,130,
131,134,136
MKVAR,105, 106,118, 119,130
MOVE,134,136
MU,105,107,112,121–123,129, 130,134,
136
} ~
,50–55
EXPUT,50–56
EXPA,75,128,130
EXPB,75,83,128,130, 131
EXPC,75,83,128–131
EXPD,75,83,128,130, 131
EXPL,75,128, 129
EXPP,75,83,88,130
EXPV,88,90–93
PATEX,50,55,60, 61,79, 80
PATLIN,50,54, 55,65
PATUT,50, 51,54, 55
TSUBS
,44, 45,47,51,54
TYPE
,44, 45,49
,48
,18,38,50,52,60,62,64,73,75,77,86,
88,128
,56,60,77
r
o
,88–93,162
r
o
,88, 89,92
]
,18,38, 39,41, 42,48, 49,55,66,68,
75,83,90,102,129, 130,136, 137
l o v
,88,90, 91,93,97,100, 101,120,129,
162
,54,61, 62
,51,54, 55,61,64,66
,57,60–62,64–66,78,80, 81,83
z o
,18, 19,37–43,48,55,64–66,68,70,
75–81,83–85,88,90,95, 96,98,102,
129, 130,136, 137
z
,18,37–39,41,52,56, 57,59, 60,62–66,
71,73,75–78,81,83–86,88,91,93,
95–97,100,129, 130,137
r
,44–47
2
,39, 40,56,75, 76,80, 81,131
,56,75,91,129,131
,93, 94
,61
r
,18, 19,38–40,42,53, 54,56, 57,
60–66,75–81,83,85, 86,91,95, 96,
129, 130,137
,54,61, 62
,47, 48,64
?
,47, 48,64
,45,52–55
,48,63,80, 81
,88, 89,91
,88, 89,93
,88, 89,91
,88–90,93
,51–55,66
LOADPAR,105, 106,120,130
r
,30,111,113–122,124–126
MKSINGLE,105,107,118,129, 130,134,
135
STORE,105, 106,115, 116,130, 131
SUCCESS,105,107,120, 121,130, 131,134,
136
MKTERM,105, 106,118, 119,128,134, 135
TEST,105,107,112,121, 122,131,134,136
TESTNATIVE,105,107,112,121, 122,130,
131,134,136
UNIFY,105, 106,115–118,130, 131,134,
136
SYMBOL INDEX 173
UNION,105,107,119, 120,128, 129,134,
135
WAIT,105,113,115,127,129, 130,134–136
,47, 48,55
,27,109
,56
,18, 19,39,44,47, 48,56,60,62–64,77
,127–131
,33,43,45–49,52,55,64,109
¡¢ £c¤
,33,43,48, 49,53, 54,59,61, 62,64,109
¥
,47, 48
¦¨§_©
¤
,33,43,48, 49,52, 53,55,59,61, 62,64,
109
¦¨§
,54
¦ª¦
,47, 48,55
©«2¬
¤d
,45–48,52,55–57
,18,58–66,68,73,84
®
,34, 35,48, 49,56
¯
,34, 35
}
,50–55
,39,42,48,55, 56,62, 63,65,75–77,93,
95,129–131,136
i
,19,39–42,56,65,70,74–77,80, 81,83–
85,87,91–94,99, 100,103, 104,112,
120,127,129–131,136,162
°
,18,38, 39,53,56,58–60,64–66,75, 76,78,
80, 81,85, 86,91–94,96,129,131
±
,39, 40,56,58, 59,64, 65,75, 76,78–81,
92–94,131
²
,47, 48
³
,33
´
,32, 33,110
µ
,57, 58,80,83,85, 86
¶
,57
·¸º¹p»
,74,92
¼
,50–55
½
,32, 33,129
¾
,18, 19,38–44,48,53,56,58–64,66,68,
70,75–81,84–86,95, 96,100,129,
136, 137
~À¿
,32, 33,106, 107,111,114–122,124–126
Á
,18,37, 38,41–43,53,56,58, 59,61,64, 65,
70, 71,78–82,91,93,95, 96,98–100,
103,136, 137,162
ÂÃ
,45,52–55
,57,60–62,64–66,76,78,80, 81,83,91,93
Ä
,51,54, 55,61,64,66
Å
,88,91,100,120
Æ
,88,93
Ç
,85, 86
w
,74,92
w
,86,90
È7ɪÈ
,27,29
Ê
BAS,128,130, 131
Ê
CON,128–131
Ê
DIS,128–131
Ê
LIT,128–130
Ê
PRO,128,130, 131
§¡Ë ¦¡Ì
,44,46
2£N£
,88, 89,92
Í
,46, 47
¦¡ÌÎ
¤
,46–48
¢Ï
¦cÐ
,35, 36,49
¢Ï
¦
,35
ÑÓÒ
£
©Ô
£
,57,66,83
Ǥ
Ñ
,82–84,90
£c¤
Ñ
,46, 47,52
£c¤
Ñ
,51–55,66
£c¤
Ñ
,45,47–49,51–55,64,66
£
©Ô
£
,57,60–63,65, 66,76,80, 81,83,88, 89,
91,93
£
©Ô
£
,44, 45,47,51–55,66
£
©Ô
£
,51
¦ÕËÖ«
£
¦
,46,52
¦¡ÌÎ
¤
,46
¦¡ÌÎ
¤
,50–55,58,66
×
§ÙØ1§Ù¬
¤
§
,57,80, 81,127,130
×
§
£
,88, 89,91,93
×
§
£
,38,55,57,61–63,65, 66,76,78–81,83,
90, 91,93,130, 131
×
§
£
,44–46,51
Ú
ËÖÎ
,32, 33,110
,73,78,89,91
,73, 74,78,81,84,89,91, 92
g
,18,38,42,52, 53,56, 57,59, 60,66,75,77,
85, 86,92,94, 95,97,103,129, 130,
137,162
gÛ
,92
Ü
,45
Ü
,44, 45,47–49,52–55
Ý
,88, 89,91–93
174 SYMBOL INDEX
,18, 19,38–40,44,53,56,58, 59,61,64, 65,
70,75,78, 79,84–86,91,129, 130
Þ
,35
ß
,35
àÃ
,45, 46,49,52–55
¿á~
,32, 33,114–122,124–126,128–131
â
,34–36,55
ã
,34–36
ä
å
,89,91
ä
å
,74,78,81–83,85, 86
ä
æ
,89,91
ä
æ
,74,78,85, 86
å
,56,60,74–77,80,91,128, 129
æ
,56,73–75,77,88,91,97,128, 129
ç
,88, 89,92, 93
è
,88, 89,92
,35, 36
é
,32
ê
,35
ç
,33, 34,54
è
,33, 34
Binding,103,108,110
Bound,103,105,108,110,114, 115
Choice,103,111,126
Code,101,103,105,111,119,128, 129
CONS,38,46–48,50,52,60,73,77,100,
105,108–110,119,128
CTR,88,90–93
ENV,127–131
error,103,106, 107,115, 116,119–121,124–
126
EXP,18,38,50–66,73–75,77–83,85,88,
90–93,128–131
EXPASS,57,60,62,64–66,78,80, 81,83
EXPCTX,57, 58,83
Fail,110,116
failure,103,106, 107,116, 117,122–126
Free,103,115, 116,118,124,126
Goal,103,105,113,125, 126
GoalInx,101–103,105,115
INCTX,74,78,81,83,89
Instruction,101,105,112, 113
Intension,100, 101,109,112,117, 118,120–
122,124–126
IVCTX,88, 89,91
Ok,110,116
OUTEREDEX,85
PAT,18,38,50, 51,54, 55,57,60–66,78–81,
83,90, 91,93,130, 131
PATCTX,57
Priority,103
running,103,114,118,124,126
SEMCTX,51–55,66
Set,100,106, 107,109,112,117–122
SREDEX,90
Status,103
success,103,121,123,125
TCONS,44,46,48
Term,100–102,106,108–110,118, 119
Thread,103,105,113,126
ThreadInx,102, 103,105,111,113,118
TSUBS,44, 45,47,51–55
TVAR,44–47,53
TYPASS,50–55
TYPE,44–47,49,51–55
UNCTX,74,78,89
UNIASS,51,54, 55,64,66
UniRes,110
UNIV,45–47,49,51, 52,54, 55,61, 62
UVCTX,88, 89,91
VALASS,88,90–93
Value,100, 101,103,108–112,114, 115,117,
118,120–122,124, 125
VAR,38,50, 51,55–57,60,63,77,81,88,
90–93,127,130, 131
Var,100–102,105, 106,108–110,114,118–
120
VarInx,100, 101,103,105,108–111,114–
116,119,127
