ce.sharif.educe.sharif.edu/~mirian/accepted paper/sqrl-001.pdf · nondeterminism in constructive z...

NONDETERMINISM IN CONSTRUCTIVE Z

HASSAN HAGHIGHI AND SEYYED-HASSAN MIRIAN-HOSSEINABADI

Abstract. The abstraction inherent in most specifications and the need to

specify nondeterministic programs are two well-known sources of nondetermin-

ism in formal specifications. In this paper, we present a formalism, includingthe notion of multi-schema and a new set of schema calculus operations, by

which one can specify bounded, unbounded, loose, strict, erratic, angelic, de-

monic, singular, and plural nondeterminism in the CZ formal specificationlanguage. CZ is a Z-style notation that is based upon a constructive set the-

ory, namely, CZ set theory. While our definitions can be modified slightly to

be used in the Z notation, we have chosen CZ, instead of Z, because of itsconstructive basis that allows us to investigate the notion of nondeterminism

from the formal program development point of view. More precisely, we for-

mally construct functional programs from CZ specifications and then probe theeffects of the initially specified nondeterminism on final programs. Our investi-

gation will show that without specifying nondeterminism explicitly, the effectsof the nondeterminism involved in initial specifications will not be preserved in

final programs. On the other hand, we will interpret all the nondeterministic

constructs of the formalism, proposed by this paper, in CZ and then provethat using this formalism for writing nondeterministic specifications leads to

programs that preserve the initially specified modalities of nondeterminism.

We will show the practicability of the new formalism via several examples.

1. Introduction

Traditional methods for developing software systems basically rely on programtesting to demonstrate that the program works successfully and meets the speci-fication. Such an approach has long been criticized: testing must be complete incovering every possible operational situation. For real systems, this is either expen-sive or impossible to achieve [15]. Thus, it is not a good vehicle for the developmentof reliable software systems [3].

As a solution to increase the level of reliability of software systems, formal meth-ods have been proposed which are based on mathematics [58, 75]. Usually thesemethods are introduced to the software life-cycle by adding the formal specificationstage to the stages of software projects. At this stage, we describe what has to bedone instead of how it has to be done. Formal specifications should be written ina soundly based specification language [75]. Z [63, 75] is an excellent specificationnotation that is based upon a well-known set theory, namely, Z set theory, and thefirst order predicate logic. Together, they make up a mathematical language thatis easy to learn and to apply [75]. Also, the set theoretical specification in Z of aproblem is as abstract as possible; hence, it makes no commitment to operationaldetails. Another advantage of Z pertains to the schema calculus. This provides asystematic tool for structuring and organizing specifications of large systems.

Key words and phrases. formal specification, formal program development, constructive Z,Martin-Lof’s theory of types, nondeterminism, modalities of nondeterminism.

1

2 HASSAN HAGHIGHI AND SEYYED-HASSAN MIRIAN-HOSSEINABADI

Having specified a problem formally, the question is how a program can be de-veloped so as to guarantee that it meets the specified requirements. There are anumber of approaches in the literature for developing programs from Z specifica-tions. One approach is to refine an abstract specification to code using the rulessuggested by the refinement calculus: via a series of steps the specification is grad-ually transformed into a program, usually an imperative one [50]. While involvinga well-developed program development calculus, refinement does not smoothly in-tegrate with Z since the concepts in the two regimes are rather different. The maindifficulty is knowing which rules to apply; it does highlight the large gulf that existsbetween the pure set theoretical specification and the imperative target code.

The second branch of activities for developing programs from Z specificationsconsists of those activities that employ a functional target language and attemptto translate Z specifications directly to code. A survey of such activities can befound in [47]. Unfortunately, none of these activities provide a complete algorith-mic translation between Z specifications and programs. In addition to the twomentioned methods, there are approaches, based upon constructive mathematics,that try to derive programs from correctness proofs of formal specifications. In thisarea, Martin-Lof ’s theory of types [42] is a well-known formalism for program devel-opment; the proof rules of this theory can be used to derive a correct program fromthe correctness proof of a specification as well as to verify that a given program hasa certain property [55]. Furthermore, this theory allows us to express both speci-fications and programs within the same formalism. However, its infrastructure forthe organization and manipulation of specifications is rather meager.

To employ both the facilities of Z as a specification medium and the abilities ofconstructive theories in program development, in [47] and [48], the CZ (ConstructiveZ) formal specification language has been introduced. CZ is a Z-style notationwhich is interpreted by a constructive set theory, called CZ set theory. Indeed,the difference between CZ and Z notations lies in the interpretation and not theappearance; the intention for developing CZ is to retain the whole of the Z notationincluding the schema calculus but provide it with a different interpretation, namely,one in a constructive theory. In [47] and [48], the CZ set theory has been interpretedin Martin-Lof’s theory of types.

1.1. Nondeterminism in formal specifications. It is crucial that a specifica-tion specifies exactly the desired result, not less and not more [20]. Obviously, ifit specifies less, then we might end up with a program that satisfies the specifica-tion, but is still not what is wanted. If the specification over-specifies, then theprogrammer is deprived of some routes to take in developing the program. In thisway, some appropriate implementations might be excluded, or in the worst case,all implementations might be excluded. Using abstraction in specifications helpsnot to over-specify. However, abstraction causes formal specifications to determineseveral behaviors of final programs, and thus nondeterminism remains an inher-ent part of them [23, 28]. The next example shows how abstraction can lead tonondeterministic specifications.Example 1. Consider the sorting problem. For convenience, we confine ourselvesto sorting elements whose keys are natural numbers. An informal specification ofthis problem is:

NONDETERMINISM IN CONSTRUCTIVE Z 3

sorting problem: for any sequence of elements whose keys are natural num-bers, there exists a permutation in which the keys are in the increasing order[20].

This abstract specification is nondeterministic since for a sequence having differentelements with equal keys, it determines more than one permutation in which thekeys are in the increasing order1. 4

In addition to abstraction, another source of nondeterminism in formal spec-ifications is the need to specify nondeterministic programs. A program is non-deterministic if for at least one input, it produces more than one output. Forexample, consider a program controlling a drinks machine that serves tea and cof-fee. When asked whether they would like tea or coffee, indecisive people replyEither. For them, the program may have a nondeterministic behavior. Concurrentand parallel systems are familiar nondeterministic programs: in a multiprogram-ming environment, at several points of the execution, such as process (or thread)creation, synchronization and communication, two or more entities (programs, pro-cesses, threads, or expressions) may want to use a common resource (e.g., a lock,an address space, a communication network, or a shared variable) at the same time[9, 56, 61]. To resolve this competition, a choice should be made whose result isnot necessarily deterministic; hence, various approaches to the theory and specifi-cation of concurrent systems, such as CSP [34], ACP [5] and CCS [46], include thephenomenon of nondeterminism.

The next example2 shows an instance of nondeterminism involved in concurrentsystems. The example indicates that when we use a lock-based method to handleconcurrency in a database management system, at several points of the execution,two or more transactions may compete for acquiring a lock on a common dataitem. This competition can be resolved by a nondeterministic choice among thecompeting transactions. In subsection 2.2, we will refer to the next example bywriting a CZ specification of the concurrency control in a database managementsystem. In subsection 3.5, we will change this specification to bring nondeterminismexplicitly into its structure.Example 2. In a database management system, some operations are executed ondata items among which the most primitive ones are the following atomic opera-tions:

• a = read(x): Reads the value of the data item x and stores it in a.• write(a, x): Writes the value of a to x.

A transaction is a sequence of the above operations that satisfies the ACID (Atomic-ity, Consistency, Isolation and Durability) properties [17]. The goal of a concurrentdatabase management system is to increase efficiency by allowing several transac-tions to execute concurrently. Of course, the effect should be the same as if thetransactions were executed in some serial order. In this way, data items involvedin operations are left in a consistent state. A usual way to achieve this goal is to

1We will refer to the sorting problem several times throughout the paper. In subsections 2.2

and 2.3, we will write set theoretical and type theoretical specifications of this problem in CZ andMartin-Lof’s theory of types, respectively. In subsection 2.4, we will produce a functional programfrom the initial CZ specification of the problem. Again, in section 3, we will change the previousCZ specification of this problem to explicitly bring nondeterminism into its structure. Then, we

will extract a new program from the explicitly nondeterministic specification.2This example comes from [53].


consider a scheduler that schedules conflicting operations. Two operations conflictiff they are involved in different transactions, at least one of them is the write op-eration, and both operate on the same data item. The scheduling can take placethrough locking mechanisms. Locking is the oldest, and still most widely used, formof concurrency control: when a transaction needs access to a data item, it tries to ac-quire a lock on it. When it no longer needs the item, it releases the lock. The job ofthe scheduler is to grant and release locks in a way that guarantees valid schedules.Sometimes the schedular encounters more than one transaction whose requests foracquiring a lock are valid. The schedular must resolve such a competition by makinga nondeterministic choice. 4

We have informally described the sorting problem in example 1. In example 3,we will give a formal specification of this problem in CZ. Although this specificationcorresponds to more than one implementation, the specification structure does notimply such a nondeterministic behavior. In other words, nondeterminism doesnot come into the specification explicitly. In this paper, we use the terminologyimplicitly nondeterministic specification to denote such specifications. As we willshow in section 3, at the end of deriving a program from a correctness proof ofan implicitly nondeterministic specification, only one of the possible behaviors isextracted from the proof tree and appears in the final program. In other words, theeffects of the initially specified nondeterminism will be lost in the final program.Such a result seems not to be wrong in a situation where the nondeterminism isdue to the abstraction involved in the specification while we still want the finalimplementation to be deterministic (e.g., in the sorting problem); however, in suchsituations, we encounter another problem: the programmer is deprived of someroutes to take in developing the program or some good implementations might beexcluded.

The above problem seems to be more serious when we consider specificationsof nondeterministic programs. If the nondeterminism involved in such programsis not specified explicitly, it will be lost during the development of programs fromtheir formal specifications, and thus will not exist in final programs. Let us in-vestigate this problem in the specification and development of concurrent systems.Concurrency is usually modelled by the nondeterministic interleaving of atomic op-erations[23]. For instance, Evans in a series of his papers (for example, [21], [22],and [23]) has tried to describe the concurrent behavior of a system in terms ofits allowable computations that result from the interleaved execution of concurrentprocesses. However, an Evans’s specification of a concurrent system is implicitlynondeterministic and results in a program provided with only one of the possibleinterleaved executions of concurrent processes. In example 4, we will give a for-mal specification of a lock-based method for controlling concurrency in a databasemanagement system. In subsection 3.1, we will show that while this specificationimplies the competition between concurrent transactions, such a competition willnot be preserved in the resulting program.

To solve this problem, it seems that we must directly specify all possible be-haviors which are obtained from nondeterminism. As we will show in section 3,although this method solves the problem, but it yields longer and more compli-cated specifications which are harder to read and write. Also, using this idea, thewriter of a nondeterministic specification him/herself must take care that his/her


method to specify all possible behaviors is suitable at the same time that s/he de-scribes the functional properties of the system. Both of these issues become moreserious when we need to specify modalities of nondeterminism such as strict, an-gelic, demonic, singular, and plural that each of them is useful for some applicationsin the real world (We will give some examples in section 3. For further examples,see [2, 33, 56, 71]).

To address the above mentioned issues, a number of attempts have been under-taken to introduce nondeterministic constructs into different formal specificationlanguages. A survey of these attempts can be found in [25]. Using these constructs,we can specify modalities of nondeterminism at the same time that we apply ourusual procedures to specify functional properties of the system. In this way, nonde-terminism comes into our specifications without decreasing our focus on describingthe functional properties of the system. On the other hand, since these constructsdo not change the main structure of a specification, they do not lead to longer andmore complicated specifications.

To produce nondeterministic programs from specifications which involve nonde-terministic constructs, one of the following approaches can be adopted:

1. Extending current formal program development frameworks in somehow totransform nondeterministic constructs of specifications into final programs.

2. Interpreting the nondeterministic constructs in the specification languageitself. Having such an interpretation, there is no need to change the currentframeworks for formal program development.

Now we are ready to say what this paper is intended to do.

1.2. The contribution of the paper. The aim of this paper is to present a CZ-based formalism by which one can bring bounded, unbounded, loose, strict, erratic,angelic, demonic, singular, and plural nondeterminism into formal specifications.The new formalism includes a new notion of schemas, called multi-schema, and a setof new operations for the schema calculus. We will interpret all the new constructsin CZ itself; hence one can use the current translation of CZ into Martin-Lof’stheory of types [47, 48] to extract programs from nondeterministic specificationswritten in the new formalism.

While our definitions can be modified slightly to be used in the Z notation, wehave chosen CZ, instead of Z, because of its constructive basis, namely, CZ settheory, that allows us to probe the effects of the initially specified nondeterminismon constructed programs. In this way, we will prove that specifications writtenin the new formalism lead to functional programs that are provided with all pos-sible behaviors according to the initially specified modalities of nondeterminism.More precisely, by the new formalism, one can write his/her own nondeterminis-tic specifications and then interpret these specifications in CZ. Using the currenttranslation of the CZ set theory into Martin-Lof’s theory of types, the resulting CZspecifications can be transformed into their type theoretical counterparts. Finally,functional programs, which satisfy the initial nondeterministic specifications, canbe extracted from correctness proofs of the type theoretical specifications.

Our work is close to that of [53] in which some nondeterministic constructs havebeen added to the CZ specification language to model strict, unbounded, erratic,angelic, and demonic nondeterminism. In [53], although all proposed nondetermin-istic constructs have been interpreted in CZ, the constructive basis of CZ has not


been regarded, and thus the notion of nondeterminism has not been investigatedfrom the formal program development point of view; In order to overcome thisdrawback, in [26], we have interpreted the nondeterministic constructs of CZ [53]in Martin-Lof’s theory of types and have thus introduced a way to construct pro-grams from CZ nondeterministic specifications. In this paper, we extend/modifyour previous work in three ways:

1. In addition to the strict, unbounded, erratic, angelic, and demonic modal-ities of nondeterminism, which have been considered in the previous work,we will model bounded, loose, singular, and plural nondeterminism in CZ.Also, unlike [53] and [26], which only regard the non-abortion of programsto distinguish angelic and demonic nondeterminism, we will introduce ageneral approach for modelling the angelic and demonic choices. This ap-proach also covers game-like situations in which the combination of bothmodalities of nondeterminism are used to simulate conflicting agents. Tomodel singular and plural nondeterminism in CZ, we can adopt two alter-native ideas (see subsection 3.3.3); however, only one of these ideas can besupported in the specification phase. Therefore, We will interpret singularand plural nondeterminism in terms of this idea. The issues related to theother one will be stated, but the complete investigation will be delegatedto future work.

2. Since the operations of the schema calculus will no longer work in thepresence of the new nondeterministic constructs, we will give a new setof schema calculus operations which properly operate on schemas havingproposed nondeterministic constructs.

3. Our method in [26] is based on adding nondeterministic constructs to typetheory, and thus extending the current interpretation of CZ in type theory[47, 48] to translate nondeterministic constructs of CZ into their counter-parts in type theory. In this paper, however, we interpret all the newconstructs in CZ itself. Of course, we use the current translation of CZ intoMartin-Lof’s theory of types to investigate the notion of nondeterminismfrom the formal program development point of view. Our investigation willshow that without specifying nondeterminism explicitly, the effects of thenondeterminism involved in initial specifications will not be preserved infinal programs. The proposed formalism in this paper helps us to developprograms which are provided with all possible behaviors in terms of theinitially specified modalities of nondeterminism. We will show the applica-bility of the new formalism by constructing programs from nondeterministicspecifications of simple problems, such as the sorting problem, and probingthe effects of the specified nondeterminism on final programs. Also, as acase study of concurrent systems, in subsection 3.5, we will apply the newformalism to a familiar concurrent problem, the strict 2PL algorithm. Inthis way, we will demonstrate that our formalism can be considered as astarting point for specifying concurrent systems and developing them suchthat the developed programs preserve the initially specified nondetermin-ism.

The paper is organized in the following way. In section 2, we give a brief overviewof the CZ set theory, the CZ specification language, Martin-Lof’s theory of types,and the interpretation of CZ in type theory. In section 3, we explore the notion of


nondeterminism in CZ and introduce a number of nondeterministic constructs anda new operations of the schema calculus to model modalities of nondeterminism inset theoretical specifications of CZ. The last section is devoted to the conclusionand directions for future work.

The contribution of the paper begins from section 3 when we present a CZ-like (or Z-like) formalism by which one can bring modalities of nondeterminisminto formal specifications. However, since we want to investigate the notion ofnondeterminism from the formal program development point of view, we shouldintroduce the formal framework which is intended to develop programs from CZspecifications. This includes two main theories, namely, the CZ set theory andMartin-Lof’s theory of types, and the translation of the former into the latter. Tomake the paper self contained, we dedicate numerous pages for reviewing thesematerials in detail; it substantially leads to a long paper. Nevertheless, readerswho are familiar with the mentioned theories or only interested in following themain contribution of the paper, can skip the corresponding subsections.

2. Preliminaries

In this section, we review the constructive framework for formal program de-velopment which will be used in section 3 to investigate the notion of nondeter-minism from the program development point of view. This includes a relativelydetailed description of the CZ set theory, the CZ formal specification language,and Martin-Lof’s theory of types in subsections 2.1, 2.2, and 2.3, respectively. Theinterpretation of CZ in Martin-Lof’s theory of types is summarized in subsection2.4.

2.1. CZ set theory. As in classical, axiomatic set theories, in Constructive settheories, a few simple axioms about the primitive notions of set and membershipare formulated, and then basic set theoretical principles are obtained from these ax-ioms. However, Constructive set theories have been defined to discover formalismswhich isolate the essential principles of constructive mathematics in the same waythat Zermelo-Fraenkel (ZF) set theory isolates the principles underlying classicalmathematics. Constructive set theories originated with Myhill’s paper [54] thatattempted to formalize the content of Bishop’s constructive mathematics [6, 7].Aczel in [1] has given the description of the system CZF (Constructive Zermelo-Fraenkel) of the constructive set theory that is an extension of Myhill’s system anda subsystem of the classical Zermelo-Fraenkel set theory.

In [47] and [48], another constructive set theory, called CZ set theory, has beenintroduced that is a weaker version of CZF and is intended to give constructiveinterpretations for Z-style specifications. The language of the CZ set theory is thesame as that of CZF. We adopt the following BNF syntax for the language of theCZ set theory:

well-formed formulas: φ ::= α |φ ∨ φ |φ ∧ φ |φ⇒ φ | ∀x · φ | ∃x · φatomic formulas: α ::= t ∈ t | t = t |Ωterms: t ::= x ,

where Ω is absurdity, and x is a variable name. Negation is defined in terms ofabsurdity and implication in the usual manner:¬φ ∼= φ⇒ Ω


We employ ⇔ for the bi-implication and y ⊆ x for y is a subset of x, both definedin the standard way. Bounded quantification is introduced by definition as follows:∀x ∈ t · φ ∼= ∀x · x ∈ t⇒ φ∃x ∈ t · φ ∼= ∃x · x ∈ t ∧ φAll proof rules of the classical set theory ZF can be used in CZ except the rule

of classical negation which is given in the following:¬φ ` Ωφ

The reason for discarding the rule of classical negation in CZ is as follows. In theclassical mathematics, a proposition is thought of as being true or false indepen-dently of whether we can prove or disprove it. On the other hand, a propositionis constructively true only if we have a method of proving it, and false if the as-sumption on its correctness results in contradiction. For example, classically thelaw of excluded middle, namely, A ∨ ¬A, is true since the proposition A is eithertrue or false. Constructively, however, a disjunction is true only if we can proveone of the disjuncts. Since we have no method of proving or disproving an arbitraryproposition A, we have no proof of A ∨ ¬A, and thus the law of excluded middleis not constructively valid [55]. For this reason, in constructive set theories, theaxiom of excluded middle and other axioms and rules which can be derived fromthis axiom, such as the rule of classical negation, must be discarded.

All the axioms of CZ shadow those of the classical theory; indeed, most axiomsremain intact. However, three axioms including separation, foundation and powerset have to be modified to satisfy constructive scruples. In contrast to the axiomsof CZF, the axioms of CZ do not include the Collection axiom3. Also, modify-ing the power set axiom yields a new axiom concerning the cartesian product setconstructor. In the following, we describe the set theoretical axioms of CZ:

Extensionality : ∀x · ∀y · (x = y ⇔ (∀z · z ∈ x⇔ z ∈ y))This axiom states that two sets are equal if they have exactly same mem-bers.

Empty set : ∃x · ∀y · ¬(y ∈ x)This axiom guarantees the existence of the empty set. By the Extensionalityaxiom, this set is unique. ∅ is used as the symbol of this unique set.

Bounded separation: ∀x · ∃z · ∀y · y ∈ z ⇔ (y ∈ x ∧ φ[y]) (φ is bounded 4)Like the axiom of Separation in ZF, the Bounded separation axiom enablesus to define any subset of a set which satisfies the formula φ. Unlike theSeparation axiom, the requirement in the Bounded separation axiom, thatφ is bounded, shows that the condition part in the definition of a certain setmust only refer to sets which were or might have been defined previously.In this way, CZ follows the strictures of constructivism and only permitsbounded formulas to determine subsets.

3In CZF, there exists the following axiom, called Collection:

(∀x ∈ u · ∃y · φ[x, y]) ⇒ ∃v · ∀x ∈ u · ∃y ∈ v · φ[x, y]In this axiom, if φ[x, y] is read as xnominates y, then the axiom guarantees the existence of

the set of all nominees when each member of a set u nominates at least one object. This axiom isequivalent to the axiom of Replacement of ZF. The reason for ignoring the Collection axiom in CZis the same as the reason for using Z set theory (ZF set theory without the axiom of Replacement)instead of ZF as the basis for the Z notation. For a detailed description, see [47].

4A formula φ is bounded if it is constructed from atomic formulas using only conjunction,

disjunction, implication and bounded quantification.


Pairing : ∀x · ∀y · ∃z · x ∈ z ∧ y ∈ zThis axiom expresses that for every two sets, there is a set that they belongto. Let x and y be two sets and let z be the set guaranteed by Pairing.Applying the Bounded separation axiom to z can yield a set whose ele-ments are precisely x and y (u ∈ z |u = x ∨ u = y), which is unique byExtensionality. We use x, y for the set whose members are exactly x andy and use x for x, x, the singleton set whose only member is x. Wealso employ the following standard definition of ordered pairs:

(x, y) ∼= x, x, yUnion: ∀x · ∃z · ∀y ∈ x · ∀u ∈ y · u ∈ z

This axiom defines how to build a set from the members of other sets.By the Bounded separation and Extensionality axioms, there is a uniqueset whose members are precisely of members of x; we employ

⋃x for this

guaranteed set which we call union. In particular, we write a∪b for⋃a, b.

Set induction: (∀y · (∀x ∈ y · φ[x]) ⇒ φ[y]) ⇒ ∀x · φ[x]The Foundation axiom in ZF is the only axiom of this theory which impliesthe law of excluded middle for bounded formulas (For a detailed description,see [48]). This axiom has therefore been replaced with the axiom of Setinduction.

Infinity : ∃x · ∀y · y ∈ x⇔ y = ∅ ∨ ∃u ∈ x · y = uThis axiom guarantees the existence of an infinite set. By the Set inductionaxiom, this guaranteed set is unique. We write N for this unique set, i.e.the set of natural numbers. We employ 0 for ∅ and s(n) for n.

Decidable power set : ∀x · ∃z · ∀y · y ∈ z ⇔ y v xIn the above axiom, the relation y v x indicates that y is a decidable subsetof x. This relation is defined as follows:

Definition 2.1.1. y is a decidable subset of x iff y ⊆ x and ∀u ∈ x · u ∈y ∨ ¬(u ∈ y)

In the classical set theory ZF, the Power set axiom is as follows:Power set : ∀x · ∃z · ∀y · y ∈ z ⇔ y ⊆ x

In the above axiom, the power set is not restricted: any kind of subset ispermitted, not just the decidable ones. It is the most important differencebetween CZ and the classical set theory ZF. CZ only permits subsets whichcan be constructed in the sense that we can determine their membershiprelative to their superset. Intuitively, the decidable subsets can be iden-tified with decision procedures which test for membership. Indeed, thisis precisely how they are introduced in [7]. such a constraint is more inkeeping with constructive scruples which reject the Power set axiom in itstraditional form because of its impredicativity.

Our main way of forming subsets is via bounded separation: which ofthese are decidable? The following notion gives a partial answer to thisquestion; it will be useful in determining which subsets of a set are decid-able.

Definition 2.1.2. A well-formed formula φ is decidable relative to a set aiff ∀x ∈ a · φ ∨ ¬φ.

Decidable, well-formed formulas (relative to a given set) are closed underthe propositional connectives: if φ and ψ are decidable relative to a then


so are their negations, conjunction, disjunction, and implication. Now if bis a decidable subset of a, and φ (bounded) is decidable relative to a, thenx ∈ b |φ[x] is also a decidable subset of a. This follows directly fromthe definitions 2.1.1 and 2.1.2. The following notion of sets with decidableequality will also be useful in the paper.

Definition 2.1.3. A set a has decidable equality iff ∀x ∈ a · ∀y ∈ a · x =y ∨ ¬(x = y).

Cartesian product : ∀x · ∀y · ∃z · ∀u ∈ x · ∀v ∈ y · (u, v) ∈ zThe usual way of defining the cartesian product of two sets, in the presenceof the power set, is as follows:x× y ∼= z ∈ P (P (x ∪ y)) | ∃u ∈ x · ∃v ∈ y · z = (u, v)

Since the decidable version of the power set is used, it is not sensible to usethis definition, and it is necessary to add the Cartesian product of two setsas an axiom. By the Bounded separation axiom, we have:∀x · ∀y · ∃z · ∀w · (w ∈ z ⇔ ∃u ∈ x · ∃v ∈ y · w = (u, v))For every two sets x and y, the uniqueness of z (see the above proposi-

tion) is guaranteed by the Extensionality axiom. z is called the cartesianproduct of x and y and is written as x× y.

In contrast to the Z set theory, which is a classical theory, the CZ set theory canbe considered as a constructive interpretation of the Z language. Specially, replacinginstances of the power set by decidable ones provides a way for determining whetherspecifications specify decidable problems or not. In the next subsection, we showthat CZ set theory is enough for the purposes of program specification in the style ofZ. To achieve this goal, we indicate how some basic infrastructure of Z is representedin CZ. In this way, we introduce the CZ formal specification language as a Z-styleformalism for writing specifications based on the CZ set theory. Therefore, thedifference between the CZ and the Z notations lies in the interpretation and notthe appearance. The CZ set theory has an interpretation in a constructive typetheory, namely, Martin-Lof’s theory of types (see subsection 2.4), and does notpermit the specification of non-computable functions. In other words, while non-computable functions are definable in Z, they will no longer be definable in the CZspecification language.

2.2. CZ formal specification language. In this subsection, we introduce the CZformal specification language as a Z-style formalism for writing specifications basedon the CZ set theory. We show that the common set theoretical constructionsemployed in Z are available in CZ. Specifications in CZ find their meanings asoperations upon sets. Hence, as in the Z notation, a set is a primitive notion inCZ. The existence of sets, in particular the empty set (∅) and the set of naturalnumbers (N), are guaranteed by the set theoretical axioms of the CZ set theorystated in the previous subsection. The definitions of operations on sets, namely,Union (∪), Generalized Union (

⋃), Intersection (∩), Generalized Intersection, (

⋂)

and Difference (\), and the definition of Decidable Subset (v) are derived from theaxioms of the CZ set theory (For a detailed description, see [47]). The function #is defined to count the number of members of finite sets.

The CZ specification language is a strongly typed language; it means that usingthe type inference rules of CZ, any CZ expression must be assigned one and onlyone type (To see the list of type inference rules of CZ, refer to [47]). Types are


maximal sets to which variables and expressions belong. The type of a variable isdeclared in the same way as the membership relation between the variable and itstype.

In the next subsection, we introduce some types and type constructors of CZ.

2.2.1. The type system of CZ. In the CZ language, the definitions of types (asmaximal sets) are obtained from the axioms of the constructive set theory CZ.The type of natural numbers (N) is a basic type in this language, derived fromthe Infinity axiom. Given set is the other basic type in CZ. Additional types canbe created using the decidable power set (P ) and the cartesian product (A × B)constructors. In the following, we describe the primary types and type constructorsof CZ:

• Given type: A given set can be used as a given type. This type is a setwhose internal structure is invisible. We may introduce elements of such aset, and associate properties with them, but we can assume nothing aboutthe set itself. Names of given types are identified within square brackets atthe first stage of writing a specification without any further assumptionsabout their internal structures. In example 4, at the beginning of thespecification of a concurrent database management system, we will definetwo given types DataItem and Value as the types of data items and theirvalues, respectively:

[DataItem,Value]It is assumed that all given types have no elements in common and havedecidable equality (see definition 2.1.3).

• Cartesian product : The cartesian product of two types A and B is the typeA × B consisting of all ordered pairs whose first elements are in A andwhose second elements are in B.

• Relation: As in Z, we can define a relation R between two types A and Bas a set of ordered pairs (x, y) where x ∈ A and y ∈ B. The relation R isshown as R ∈ A ↔ B where A ↔ B ∼= P (A × B): unlike Z, the class ofrelations is restricted to decidable subsets of A × B. Using the axiom ofBounded separation (see subsection 2.1), various sets and operations canbe defined on relations. We give the definitions of those sets and operationsthat we will use in this paper:(1) domain : If R ∈ A↔ B, then

domR ∼= x ∈ A | ∃y ∈ B · (x, y) ∈ R(2) range : If R ∈ A↔ B, then

ranR ∼= y ∈ B | ∃x ∈ A · (x, y) ∈ R(3) domain restriction : If R ∈ A↔ B and u v A, then

u C R ∼= (x, y) ∈ A×B |x ∈ u ∧ (x, y) ∈ R(4) range restriction : If R ∈ A↔ B and u v B, then

u B R ∼= (x, y) ∈ A×B | y ∈ u ∧ (x, y) ∈ R(5) domain anti -restriction : If R ∈ A↔ B and u v A, then

u E R ∼= (x, y) ∈ A×B |x /∈ u ∧ (x, y) ∈ R(6) range anti -restriction : If R ∈ A↔ B and u v B, then

u D R ∼= (x, y) ∈ A×B | y /∈ u ∧ (x, y) ∈ R• Function: A relation f ∈ A ↔ B is a partial function if for every x in A,

there is at most one y in B such that (x, y) ∈ f . If, in addition, we knowthat for every x in A, there is a unique y in B such that (x, y) ∈ f , then f is


called a total function. Other types of functions, namely, partial injection,total injection, partial surjection, total surjection, bijection, finite partialfunction, and finite partial injection are defined similar to the definitionsof their counterparts in Z [63, 75]. However, unlike Z, CZ does not supportall classical functions: the restriction of the class of subsets to decidableones also affects the class of functions. Since functions are special kind ofrelations, all operations defined over relations can also be used on functions.Moreover, Functional Overriding [63, 75] with the operator ⊕ is defined asfollows:

Functional Overriding: functional overriding : If f and g are two func-tions from A to B, thenf ⊕ g ∼= ((dom g) E f) ∪ g

• Sequence: Sequences are used to model ordered collections of objects. In asequence, some elements may appear more than once. For any set X, seqXdenotes the type of sequences including elements of X. Formally, seqX isthe set of all partial functions f from N to X such that ∃n ∈ N · dom f =Nn, where Ni

∼= 1, ..., i. Sequences are written enclosed in angle brackets,i.e. 〈 and 〉, with their elements separated by commas. The empty sequenceis written as 〈〉; a non-empty sequence l is written as h :: t where h and tare the head and the tail of l, respectively. The ith element of the sequenceS is written as S.i. Since a sequence is a function or, in general, a set, wecan use all set or function operations to manipulate sequences. There arefour more functions, namely, head, tail, front and last, which are definedas usual. The concatenation operator, _, is used to join two sequencestogether by placing one in front of the other.

• Free type: As in Z, we use free types as sets with explicit structuring infor-mation to model enumerated collections, compound objects, and recursivelydefined structures. To begin with free types, consider the special case inwhich the set to be introduced has a small number of elements. In example4, we will introduce the new commands commit and abort to the databasemanagement system in addition to the commands read and write, defined inexample 2. We will define a free type Command as the set of commands ofthe database management system by introducing its four distinct elements:

Command ::= Read |Write |Commit |AbortOnce this definition has been made, we may infer that Command is thesmallest set containing the four distinct elements Read , Write, Commit ,and Abort . The order in which these elements are introduced is unimpor-tant [75].

We may include copies of other sets as part of a free type, using con-structor functions. The notation

FreeType ::= constructor〈〈source〉〉introduces a collection of constants, one for each element of the set source.constructor is an injective function whose target is the set FreeType. Con-stants and constructor functions may be used together in the same defini-tion, as in the following free type:

FreeType ::= constant | constructor〈〈source〉〉What is more, the source type of a constructor function may refer to thefree type being defined. The result is a recursive type definition: FreeType


is defined in terms of itself. For example, in the following, we define arecursive data structure resembling the natural numbers:

nat ::= zero | succ〈〈nat〉〉Every element of nat is either zero or the successor of a natural number.zero is not a successor, and every element of nat has a unique successor.The set nat is the smallest set containing the following collection of dis-tinct elements: zero, succ(zero), succ(succ(zero)), and so on. As anotherexample, we may define a free type of binary trees, in which every elementis either a leaf or a branching point:

BinaryTree ::= leaf 〈〈N 〉〉 | branch〈〈BinaryTree × BinaryTree〉〉Each leaf contains a number; each branching point joins a pair of sub-trees.

In the next subsection, we show how the language of CZ can be used to specifyprograms.

2.2.2. Specification construction units. In CZ, the specification of an operation canbe written as a proposition in the following general form:∀x1 ∈ A1, x2 ∈ A2, ..., xm ∈ Am · (φ⇒ ∃y1 ∈ B1, y2 ∈ B2, ..., yn ∈ Bn · ψ),

where φ and ψ are the pre- and postconditions of the operation, respectively. Also,xi(i : 1..m) are input (or before state) variables and yj(j : 1..n) are output (or afterstate) variables. To distinguish between after and before state variables, and inputand output variables, we use the same conventions as in Z. That is, plain variablenames are used for before state variables while primed variable names are used forafter state ones, and the variable names ending with ? represent the input variableswhile the variable names ending with ! are used for output variables.

As in Z, we use the schema language to structure and compose descriptions:collating pieces of information, encapsulating them, and naming them for reuse. Aschema consists of two parts: a declaration of variables; and a predicate constrainingtheir values. We write the text of a schema in the following form:

Name ∼= [Declaration |Predicate]The declaration and predicate are separated by a vertical bar, and the schema textis delimited by brackets. When no predicate constrains the schema variables, thepredicate part can be removed.

We can use schemas as types when we require a composite type, one with avariety of different components. A schema type differs from a cartesian productin that the components are stored not by position but by name. In example 4,we will use the schema bellow which corresponds to a composite data type withthree components: a data item of the database called dataItem, the identifier of atransaction called transId , and a Read or Write command, called command . Thesecomponents together show that the command command of a transaction with theidentifier transId has granted a lock for the data item dataItem.

Lock ∼= [dataItem ∈ DataItem, transId ∈ N, command ∈ Command |command ∈ Read ,Write]

The schema type Lock is the set of all bindings in which dataItem, transId , andcommand are bound to a data item, a natural number, and a command, respec-tively. Of course, we are limited to only those bindings in which command is amember of the set Read ,Write. As in Z, to write an object of a schema type inextension, we list the component names and the values to which they are bound.For example, for the schema type Lock above, we use [dataItem 7→ x, transId 7→2, command 7→ Write] to show a binding in which dataItem, transId , and command


are bound to x, 2, and Write, respectively. We introduce elements of the schematype Lock in the usual way: the declaration lock ∈ Lock introduces an object lockof the schema type Lock . In other words, lock is declared to be a binding thatmeets the constraint part of the schema Lock . To refer to a particular component,we employ the selection operator ”.”. For example, we write lock .command to de-note the command component of lock . Two bindings are equal if they bind theircomponent names to equivalent values.

A schema may also be used whenever a declaration is expected: in a set com-prehension, in another schema, or following a logical quantifier. The effect is tointroduce the variables mentioned in the declaration part of the schema, under theconstraint of the predicate part. As in Z, when we conjoin two schemas by includingone in the declaration part of the other, the declarations are merged and the pred-icates conjoined. If the same variable is declared in both schemas, then the typesmust match. Otherwise, the resulting schema will be undefined. In example 3, wewill use two schemas Increasing and Perm in the declaration part of the schemaSort .

The notion of state schema is used to describe system states. The form of astate schema is similar to that of schema types given earlier:

State ∼= [Declaration |Predicate],where the declared variables correspond to the components of the specified state.The Predicate part gives the properties of, and relationships between, the declaredvariables, and thus describes the invariant properties of the state. When the statehas no such properties, the Predicate part can be removed. Each object of theschema type State represents a valid state: a binding of schema variables in whichPredicate is satisfied. We say that Predicate forms part of the state invariant forthe system: a constraint that must always be satisfied.

The notion of operation schema is used to describe an operation upon the stateof a system. An operation schema has the following form:

Operation ∼= [Declaration |Precondition,Postcondition]We describe an operation by including two copies of the state schema in the

Declaration part of the operation schema: one representing the state before theoperation; the other representing the state afterwards. To distinguish between thetwo, we decorate the components of the second schema, adding a single prime toeach name. Some operations involve either input to the system or output from it.To model such operations, in addition to before (plain) and after (primed) statevariables, we include input (end with ?) and output (end with !) variables inthe Declaration part of the operation schema. The predicate part of an operationschema is divided into two parts, namely, Preconditions and Postconditions5. Bothpredicates together describe the relationship between the schema variables, andthus characterize the operation: the Precondition part states what must be true ofthe state if the effect of the operation is to be fully defined; the Postcondition partdescribes the effect of the operation upon the values of the state variables.

Separating preconditions and postconditions is one of the major differences be-tween operation schemas of CZ and those of Z. In fact, we follow the B Methodor VDM in this regards. Having separate pre- and postconditions encourages the

5Notice that the separation of preconditions and postconditions occurs only in operation

schemas. In state schemas, schemas as types, and schemas as declarations, we have still a singlepredicate part.


writer of a specification to prove the well-formedness theorem (i.e., the precondi-tion must guarantee the existence of a final state satisfying the postcondition) [62].Moreover, if one wishes to extract programs from specifications, there are manycircumstances in which mixed pre- and postconditions impose a serious burden:the task of discharging preconditions is, in the worst case, equivalent to deriving aprogram [31]. For example, in deriving a sorting algorithm, discharging the precon-dition of the specification requires a demonstration that sorted permutations alwaysexist: but this may be equivalent to the task of deriving a sorting algorithm. Theseparate pre- and postconditions have also been suggested by other researchers; forexample, see [10, 31, 50].

There is a convention for including two copies of the same schema, one of themdecorated with a prime. If State describes the state of a system, then ∆State is aschema including both State and State ′: that is,

∆State ∼= [State,State ′]This schema could be included whenever we wish to describe an operation that maychange the state of the system. As in Z, within an operation schema, we use θStateto indicate the before state binding. Frequently, we will wish to equate θState tothe after state binding, thereby insisting that nothing has changed. To do this, weuse a decorated version of the same binding. In other words, the decorated bindingθState ′ associates the components of State with the values of decorated variables.Equating decorated and undecorated bindings of State is thus a way of insistingthat the before state variables are equal to their corresponding after state variables:each component has been left with the same value. Again, there is a convention:we write ΞState to denote the schema that includes State and State ′ and equatestheir bindings:

ΞState ∼= [∆State | θState = θState ′]This schema could be included whenever we wish to describe an operation that doesnot change the state of the system. Finally, as in Z, we may include a description ofthe initial state of the system being specified. This may be seen as the result of anoperation, some form of initialization, that does not refer to the state beforehand.The initial state of a system may be described by a decorated copy of the stateschema, representing the state after initialization:

StateInit ∼= [State ′ | true, P ]The predicate P describes the initial constraints upon the components of the state.

The schema calculus operations are useful in CZ as well as in the Z notation forreducing the length of a specification, modularizing it, and enabling reuse. In Z,all propositional connectives (∧, ∨, ⇒, ⇔ and ¬), Hiding operators (\, ∀, and ∃),Sequential Composition (;), and Renaming convention are defined in the world ofschemas [63, 75]. The schema calculus of CZ consists of the operations Negation(¬c), Conjunction (∧c), Disjunction (∨c), Existential Quantifier (∃c), UniversalQuantifier (∀c), and Sequential Composition (;c), which are selected from the Zschema calculus operations. In [47], all the above mentioned operators except ¬c

have been defined on both state schemas and operation schemas; Negation has beenonly defined on state schemas. Here, we give the semantics of these operators whenapplied to operation schemas:

Definition 2.2.1. Let [d |φ, ψ], [d1 |φ1, ψ1] and [d2 |φ2, ψ2] be operation schemas.Then we have:

(1) [d1 |φ1, ψ1] ∧c [d2 |φ2, ψ2] ∼= [d1, d2 |φ1 ∧ φ2, ψ1 ∧ ψ2]


(2) [d1 |φ1, ψ1] ∨c [d2 |φ2, ψ2] ∼= [d1, d2 |φ1 ∨ φ2, (φ1 ∧ ψ1) ∨ (φ2 ∧ ψ2)],where d1, d2 is the union of two sets of declarations d1 and d2.

(3) ∃cuh · [d |φ, ψ] ∼= [d− uh | ∃uh · φ,∃uh · φ ∧ ψ](4) ∀cuh · [d |φ, ψ] ∼= [d− uh | ∀uh · φ,∀uh · ψ],

where uh is the set of hidden variables, and d−uh is the set of declarationswhich are in d and not in uh.

(5) [d1 |φ1, ψ1] ;c [d2 |φ2, ψ2] ∼= ∃c da1 [

′′/ ]·([d1 |φ1, ψ1][

′′/ a]∧c[d2 |φ2, ψ2][

′′/ b])

For the composition to be defined, both schemas must refer to the samestate: for any primed component in [d1 |φ1, ψ1], there must be an unprimedcomponent of the same name in [d2 |φ2, ψ2]. For the schema A, we writeA[new/old ] to denote the schema obtained from A by replacing componentname old with new. Throughout the paper, we use other conventions: forthe set of declarations d, we write d[

′′/ ] to denote the result of substitut-

ing all variables of d by their versions ending with′′. Moreover A[

′′/ a]

(A[′′/ b]) corresponds to replacing after state (before state) variables of

the schema A by their versions ending with′′.

In definition 2.2.1, as in Z, it has been assumed that the operands of the binaryoperators are in their normalized6 form and are type compatible7. In [47], it has beenproved that the above presented definitions of the schema calculus operations aresound, by showing that schemas constructed from the schema calculus operationsin CZ are refinements of their counterparts in Z.

In examples 1.1 and 1.2, we have given informal specifications of the sortingproblem and concurrency control in a database management system, respectively.In examples 2.1 and 2.2, we will write formal specifications of the two mentionedproblems in the CZ notation. We will see that in the constructive approach theformal specifications remain as in the classical approach. Indeed, the differencebetween CZ and Z specifications lies in the interpretation and not the appearance8.Therefore, when we write specifications in CZ, we can proceed as we do in Z since CZinvolves the whole of the Z toolkit. We only must take care that CZ specificationsare interpreted in a constructive set theory. This has important implications forthe program development stage. For example, all functions and relations we use inCZ are restricted to the decidable ones which induce program developments.

In section 3, we will back to the specifications given in the next two examplesby explicitly specifying the nondeterminism involved in them.Example 3. Consider a special sorting problem: we want to sort students identi-fiers in an increasing order in terms of their scores in a course. The following CZschema specifies such an operation formally. The input of the schema, i.e. in?, isa sequence of ordered pairs whose components are natural numbers. Each orderedpair corresponds to one student: the first component of the ordered pair is thestudent (unique) identifier and the second one is the student score. To develop a

6A normalized schema is a schema that all its declarations are given in their full form, and allthe constraint information appears in the predicate part [75].

7Two schemas are type compatible if each variable common to two schemas has the same type

in both of them.8Of course, as we have stated earlier, there is a slight difference between operation schemas in

two languages: CZ operation schemas have separate preconditions and postconditions.


program from this specification more simply later, we have considered both com-ponents of type N . Hence, as has been assumed in example 1, the sequence beingsorted has elements whose keys are natural numbers.

Sort ∼= [Increasing ,Perm, in? ∈ seq(N ×N), out ! ∈ seq(N ×N)| true,out ! ∈ increasing ∧ (in?, out !) ∈ perm]

This schema includes two other schemas, namely, Increasing and Perm, whichwill be defined later. The precondition is true and the postconditions define theintention of the sort operation, i.e., the output has to be an increasing permutationof the input sequence.

Increasing ∼= [increasing ∈ P (seq (N ×N)) |∀s ∈ seq (N ×N) · s ∈ increasing ⇔(∀i ∈ dom s · ∀j ∈ dom s · i < j ⇒ s.i.2 ≤ s.j.2)]

In the above schema, increasing is the set of all sequences of ordered pairs of naturalnumbers that are increasingly sorted in terms of their second components. SinceIncreasing is not an operation schema, it includes a single predicate part.

Perm ∼= [perm ∈ seq (N ×N) ↔ seq (N ×N) |∀s ∈ seq (N ×N) · ∀t ∈ seq (N ×N) · (s, t) ∈ perm ⇔((∀x ∈ ran s · occ(x, s) = occ(x, t)) ∧ (∀x ∈ ran t · occ(x, s) = occ(x, t)))]

Two sequences are permutations of each other when the number of occurrences ofevery element in both sequences are equal. In the schema Perm, occ is a functionthat counts the number of occurrences of a given ordered pair in a given sequenceof ordered pairs:

occ : ((N ×N)× seq (N ×N)) → Nocc(x, 〈〉) = 0

(occ(x, h :: t) = occ(x, t) + 1 ∧ x = h) ∨ (occ(x, h :: t) = occ(x, t) ∧ x 6= h)

All the above defined schemas are similar to their Z counterparts in appearance.In other words, they are syntactically indistinguishable from their counterparts inZ. However, they differ in their intended interpretation. For example, in the schemaIncreasing , the operator P denotes the decidable power set which only allows de-cidable subsets. A similar argument exists for the notion of relation (seq (N×N) ↔seq (N×N)) employed in the schema Perm. 4Example 4. In example 2, we described how lock-based methods control concur-rency in a database management system. A well-known lock-based method is thetwo-phase-locking (2PL) protocol. In this protocol, before reading or writing a dataitem, a lock must be obtained. Once the scheduler has released any lock on behalfof a transaction T , it will never grant another lock on behalf of T , regardless ofwhich data item T is requesting the lock for. A variant of 2PL is strict two-phaselocking which adds the restriction that all locks must be released after the transac-tion commits or aborts. Now we give a CZ specification of strict 2PL. At first, weintroduce two new commands of the database management system in addition tothe commands read and write, defined in example 2:

• commit : Finishes a transaction and asks for finalizing the results.• abort : Finishes a transaction and asks to abort the results.

Now we formalize the above description.[DataItem,Value]Command ::= Read |Write |Commit |AbortDatabase ∼= [database ∈ DataItem → Value]


Operation ∼= [command ∈ Command , dataItem ∈ DataItem, value ∈ Value]Transaction ∼= [operations ∈ seq Operation |

(last operations).command ∈ Commit,Abort∧∀op ∈ (ran front operations) · op.command ∈ Read ,Write]

Database state is a function assigning values to all data items. A transaction ismodelled as a sequence of operations in which there exists one and only one commitor abort operation at the end.

Lock ∼= [dataItem ∈ DataItem, transId ∈ N, command ∈ Command |command ∈ Read ,Write]

LockBase ∼= [locks ∈ P Lock | ∀x, y ∈ locks · x.dataItem = y.dataItem ⇒(x.transId = y.transId ∨ (x.command = Read ∧ y.command = Read))]

The schema Lock shows that a data item is locked for a command of a transactiondetermined by the identifier transId . The schema LockBase indicates the set ofcurrent locks. The invariant condition for the schema is that no two conflictinglocks exist in this set.

CCDB ∼= [dataBase ∈ DataBase, lockBase ∈ LockBase, activeTransactions ∈seq Transaction, runningTransactions ∈ seq Transaction, localDBs ∈ seq DataBase |dom runningTransactions = dom activeTransactions∧dom localDBs = dom activeTransactions∧∀lock ∈ lockBase.locks · lock .(transId ∈ dom activeTransactions)]

CCDB is the state schema of the system. In this schema, activeTransactions de-notes a sequence of current transactions whereas runningTransactions indicatesremaining operations of each active transaction. For example, activeTransactions.i(runningTransactions.i) is associated with a binding of the schema type Transactionin which operations is bound to a sequence of all (the remaining) operations of thetransaction with identifier i. To prevent the operations of a transaction from beingundone when it aborts (e.g., because of deadlock), we assume that each transac-tion has its local copy of the database. All transactions apply operations to theirlocal copies of the database. When a transaction sends its commit operation, itslocal copy is applied to the main database. localDBs.i denotes the local copy ofthe database maintained for the transaction with identifier i. The domains of thevariables activeTransactions, runningTransactions, and localDBs correspond to theset of identifiers of all active transactions, and thus are equal to each other.

Before we give the operation schemas of the system, we write the initializationschema of the system:

CCDBInit ∼= [CCDB ′ |true,lockBase ′.locks = ∅∧activeTransactions ′ = ∅∧runningTransactions ′ = ∅∧localDBs ′ = ∅]

Now we present the operation schemas of the system in turn. The followingaxiomatic definition will be used in the first operation schema.


conflictLock : (N × Transaction) ↔ LockBase∀id ∈ N, transaction ∈ Transaction, lockBase ∈ LockBase·

((id , transaction), lockBase) ∈ conflictLock ⇔(∃lock ∈ lockBase.locks · (head(transaction.operations)).dataItem = lock .dataItem∧

id 6= lock .transId∧((lock .command = Read ∧ (head(transaction.operations)).command = Write)∨

(lock .command = Write ∧ (head(transaction.operations)).command ∈ Read ,Write)))

Using the relation conflictLock defined by the above axiomatic definition, we cancheck whether the first operation of the transaction transaction whose identifier isid conflicts with the locks existing in a particular lockBase.

AcquireLock ∼= [∆CCDB , transId ! ∈ N | true,transId ! ∈ dom activeTransactions∧((transId ! C runningTransactions) ∩ conflictLock(lockBase) = ∅)∧(lockBase ′.locks = lockBase.locks∪[transId 7→ transId !, command 7→ FirstCommand(runningTransactions.transId !),

dataItem 7→ FirstDataItem(runningTransactions.transId !)])]FirstCommand and FirstDataItem, which are not specified here, return the firstcommand and the first data item of their input transactions, respectively. Theabove schema specifies the selection of a transaction that can acquire a lock for itsfirst operation. If such a transaction exists, the lock related to its first operationis added to the set of current locks, and its identifier is returned. This schema isnondeterministic since more than one transaction may satisfy its postconditions.

Read ∼= [∆CCDB , transId? ∈ N, value! ∈ V alue |FirstCommand(runningTransactions.transId?) = Read ,value! = (localDBs.transId?).database(FirstDataItem(runningTransactions.transId?))∧runningTransactions ′ = runningTransactions⊕(transId?, [operations 7→ tail(runningTransactions.transId?.operations]))]

Using functional overriding (⊕) in the above schema, we specify that the first oper-ation of the transaction with the identifier transId? is removed from the sequenceof its operations.

Write ∼= [∆CCDB , transId? ∈ N |FirstCommand(runningTransactions.transId?) = Write,(runningTransactions ′ = runningTransactions⊕(transId?, [operations 7→ tail(runningTransactions.transId?.operations)]))∧(localDBs ′ = localDBs⊕(transId?, [database 7→ localDBs.transId?.database⊕

(FirstDataItem(runningTransactions.transId?),FirstValue(runningTransactions.transId?))]))]

Using ⊕ in the above schema, it has been shown that the first operation of the trans-action with the identifier transId? overwrites the copy of the database maintainedfor transId?. FirstValue, which is not specified here, returns the value related tothe first operation of its input transaction.

Commit ∼= [∆CCDB , transId? ∈ N |FirstCommand(runningTransactions.transId?) = Commit ,runningTransactions ′ = transId? E runningTransactions∧activeTransactions ′ = transId? E activeTransactions∧localDBs ′ = transId? E localDBs∧dataBase ′.database = dataBase.database ⊕ (localDBs.transId?).database]


Abort ∼= [∆CCDB , transId? ∈ N |FirstCommand(runningTransactions.transId?) = Abort ,runningTransactions ′ = transId? E runningTransactions∧activeTransactions ′ = transId? E activeTransactions∧localDBs ′ = transId? E localDBs]

The schemas Commit and Abort define operations which remove the transactionwith identifier transId? from active and running transactions. Due to the conditionsdefined in the state schema CCDB , locks acquired by transId? are removed fromthe set of current locks. In addition to the above mentioned operations, the schemaCommit overwrites the main database by the local database of transId?.

The final specification of the strict 2PL algorithm is as follows:STwoPL ∼= AcquireLock ;c (Read ∨c Write ∨c Commit ∨c Abort)

STwoPL is the sequential composition of acquiring the requested lock for a trans-action transId? and sending transId? for execution to one of the operation schemasRead , Write, Commit , or Abort . 4

As we have stated in example 2, the concurrent database management systemspecified formally in the above example is a nondeterministic system: at each timeof the execution, there exists a set (possibly containing more than one element) oftransactions which ask for a lock and do not conflict with the set of current locks;hence, the scheduler may be forced to select a transaction between several alterna-tives and deliver a lock to it. In section 3, we will show that a program constructedfrom a correctness proof of an implicitly nondeterministic specification, such asthe one presented in the above example, is provided with only one of the possiblebehaviors. For example, our specification of the concurrent database managementsystem results in a program that is provided with only one of the possible interleavedexecutions of concurrent transactions. In other words, the final program does notinvolve the initially specified competition among transactions.

A framework for formal specification and formal program development mustguarantee that it produces all possible implementations of a nondeterministic spec-ification. Later in the implementation phase, the program makes a choice in termsof the implementation considerations. For example, in a distributed database man-agement system, the program may select a transaction, according to the currentload of the network, from the set of those transactions that can acquire their re-quired locks. In example 16, using the nondeterministic constructs that will beintroduced in section 3, we will revise the current specification of the strict 2PLmethod to address the above mentioned issue.

2.3. Martin-Lof ’s theory of types. Constructive type theory was originally de-veloped as a formalism for the precise codification of the constructive mathematicsby Per Martin-Lof [42]. He, in [43], has explained why the constructive theory oftypes may equally well be viewed as a programming language, and it no longer seemspossible to distinguish the discipline of programming from constructive mathemat-ics. Since the publication of Martin-Lof’s original paper, there has been rapidlygrowing literature on type theory and its application in formal specification andprogramming. A survey of these attempts has been given in [47].

Martin-Lof’s theory of types is well suited as a theory for program construction;the proof rules of this theory can be used to derive a correct program from thecorrectness proof of a specification as well as to verify that a given program has acertain property. Furthermore, this theory allows us to express both specifications


and programs within the same formalism. As a programming language, type theoryis similar to typed functional languages, such as Hope and ML [55]. The relationshipbetween type theory and functional programming has been shown in [65]. Also, in[67], Turner has given a constructive foundation for functional languages.

As it has been stated earlier, type theory was originally developed with theaim of being a clarification of constructive mathematics, but unlike most otherformalizations of mathematics, type theory is not based on the first order predicatelogic; instead, the predicate logic can be interpreted within type theory through thecorrespondence between propositions and types 9. A proposition is interpreted as atype whose elements represent the proofs of the proposition. A type cannot only beviewed as a proposition; it is also possible to see a type as a problem description,and the elements of the type as the possible solutions to the problem. Similarly,if we see the type as a specification of a programming problem, the elements arethe programs that satisfy the specification. Hence, set membership and programcorrectness are the same problem in type theory; because all programs terminatein type theory, correctness means total correctness [55].

The language for types in type theory is similar to the type system in program-ming languages except that the language is much more expressive. In addition tothe usual set forming operations which are found in type systems of programminglanguages, such as Bool, A + B,A → B,A × B, and List(A), there are operationswhich make it possible to express properties of programs or write specificationsusing the usual connectives in the predicate logic. Suppose that A and B are types.Then:

• The form A ⇒ B is the type of functions λx · t[x] such that t[x] ∈ B forx ∈ A. This type is called function space, the type theoretical equivalentof the proposition A⇒ B.

• The form A⊗B10 is a type called cartesian product of two types. It is thetype of pairs (x, y) such that x ∈ A and y ∈ B. if z is the ordered pair(x, y), then fst(z) and snd(z) are equal to x and y, respectively. This formis the type theoretical equivalent of the proposition A ∧B.

• The form A⊕B is a type called disjoint union of two types. It is the typeof objects of the form inl(x) with x ∈ A or inr(y) with y ∈ B. This formis the type theoretical equivalent of the proposition A ∨B.

• The form I[A, x, y] is a type provided that x and y are elements of thetype A. It has an element e if x = y. It can be viewed as the followingproposition:x and y are identical elements of the type A

• The form N is the type of natural numbers. It is the type of objects of theform 0 and s(n) (The successor of n), provided that n is an element of N .In some of the literature (for example, [65]), for each nonnegative integern, a form Nn has been considered as the type containing the n objects1, 2, ..., n. N0 is the empty type (∅) or the type theoretical equivalent of the

9The Curry-Howard interpretation of propositions as types is one of the basic ideas behindMartin-Lof’s theory of types [65]. However, another source for type theory is the proof theory.Using the identification of propositions and types, normalizing a derivation is closely related tocomputing the value of the proof term which corresponds to the derivation [55].

10For convenience and ease of reference, we adopt the presentation of the constructive type

theory given in [66].


proposition Ω (absurdity). For n ≥ 1, Nn is equivalent to the propositiontrue.

• The form Πx ∈ A.B is the type of functions which take an arbitrary objectx of a type A into an object of a type B[x]. This type is a dependenttype, called dependent product. A dependent type is a type expressionwhich describes different sets of objects depending on the value taken bya variable appearing in the type expression. To define these new forms oftype, it is useful to define a family of types over a type A. Such a familyof types is a function λx.B[x] that assigns a type B[x] to each x ∈ A. Theequivalent proposition of Πx ∈ A.B is ∀x ∈ A.B.

• The form Σx ∈ A.B is another dependent type, called dependent sum. Thisis the type of pairs (x, y) where x and y are elements of types A and B[x],respectively. The equivalent proposition of Σx ∈ A.B is ∃x ∈ A.B.

The language to express the elements of types in type theory constitutes a typedfunctional programming language with lazy evaluation order. The program formingoperations are divided into constructors and selectors. Constructors are used toconstruct objects in a type from other objects, examples are 0, s (The successorfunction) , inl, inr and λ. Selectors are used as a generalized pattern matching,examples are fst and snd [55].

In this paper, we use an intensional type theory which has been strengthenedwith the type U (universe) and the type constructor W (well-founded). Inten-sional means that the judgmental equality is understood as definitional equality ;in particular, the equality is decidable (see definition 2.1.3). The existence of theintensional equality is a prerequisite for developing computerized tools that supportthe construction of proofs within type theory [55]. In the following paragraphs, wewill illustrate the intuition behind the type U and the type constructor W . Bothof these play an important role in interpreting the CZ set theory in Martin-Lof’stheory of types.

All types that have so far been introduced are called small types since theirelements are not themselves types. With only small types in place, type theorycannot handle the following situations for example [65]:

• We may wish to make an element depend upon a type parameter.• We might want to assert the existence of a type with certain properties:

this is the content of an abstract type definition.• Some functions are most naturally defined over the collection of all objects

of all types.

For this reason and generally to have a richer notion of type, we can see the merit ofintroducing a type U which is called the universe and whose elements are themselvestypes together with the reflection principle. Roughly speaking, this principle saysthat whatever we can do with types can also be done inside the universe U . Forinstance, this principle leads us to have∅ ∈ U,N ∈ U,A⊕B ∈ U,I[A, x, y] ∈ U, (x and y are elements of the type A),(Πx ∈ A.B) ∈ U, and(Σx ∈ A.B) ∈ U,


where A and B are types in U . Note that we do not wish to have U ∈ U , because itwould mean, intuitively, that U is the universe of all types, from which a paradoxcan be derived [66].

Figure 1. Two natural numbers 0 and 2, and the sequence 〈1, 0〉 [65].

Figure 2. A binary numeric tree [65].

Now we give the intuition behind the constructor W . To incorporate recursivedata types like lists and trees into type theory, Martin-Lof has proposed well-founded types. They are types over which we can define objects by recursion andprove properties by induction. Informally, for this to be possible, we need to besure that when we make a recursive definition (or an inductive proof), we neverencounter an infinite sequence of activities [65]. In general, we can think of theelements of any recursive type as trees. In Fig. 1, we see three trees representingthe natural numbers 0 and 2 (i.e. suc(suc(0))), and the sequence 〈1, 0〉. Fig. 2shows an example from binary numeric trees.

The general form of elements of well-founded types is that each node is builtfrom a certain collection of predecessors of the same type. Considering the typeof binary numeric trees, null nodes, illustrated by black discs in Fig. 2, have nopredecessors, whereas other nodes, shown in white, have two predecessors. For ageneral recursive type,we will have a type A of sorts of node. In the case of binarynumeric trees, this type is best thought of as a disjoint union type, T ⊕N , where Tis the one element type, for the null node, and N is for the non-null nodes, whichcarry numbers.

Different kinds of nodes have different numbers of predecessors. For a particularkind of node a ∈ A, we specify what form the predecessors of the node take bysupplying a type B(a), which we can think of as the type of names of predecessorsplaces. For a particular node of that sort, we specify the collection of predecessors ofthe node by a function from B(a) to the type in question. Considering the particularcase of the type binary numeric trees, since the null node has no predecessors, wesay B(null) ≡df ∅, and for a binary node a, we have two predecessors, so we defineB(a) ≡df N2.


The type we build is determined by the class of sorts of node, A, and the familydetermining the nature of the set of predecessors of each sort of node, B(x). Thetype thus constructed is Wx ∈ A.B whose elements denoted by sup(a, f ), wherea ∈ A and f is a function from B[a] to Wx ∈ A.B. W is used as a reminder thatthe type is well-founded. An important property of the type constructor W is thatwe can always, for each element α ∈ (Wx ∈ A.B), recover a node a ∈ A and afunction f ∈ (B[a] ⇒ (Wx ∈ A.B)), such that α = sup(a, f) [66].

Formation Rule for ⊕

A type B type⊕f

A ⊕ B type

Introduction Rules for ⊕

q ∈ Ap ∈ A⊕i2⊕i1

inr(q) ∈ (A ⊕ B)inl(p) ∈ (A ⊕ B)

Elimination Rule for ⊕

r ∈ (A ⊕ B) f ∈ (A ⇒ C) g ∈ (B ⇒ C)⊕e

case r f g ∈ C

Computation Rules for ⊕

case inl(p) f g → f p case inr(q) f g → g q

Figure 3. The inference rules for the type constructor ⊕ [65].

After illustrating the language of types, specially the type U and the type con-structor W in type theory, now we briefly review the program development processin this theory: in type theory, specifications are expressed by mathematical propo-sitions, and program development process consists of functional specification of aproblem, by giving its type, and then constructing an object of that type, usingthe inference rules of the logic. This object, if existing, can be viewed as a programwhich satisfies the specification. The inference rules in type theory are presented inGentzen’s natural deduction style. For each type constructor in type theory, thereare four types of inference rules:

• Formation rule: This rule states under what conditions A is a type.• Introduction rule: The constructors of a type, i.e. operators that construct

elements of the type, are introduced by this rule which corresponds tothe introduction rules of natural deduction systems for predicate logic. Inother words, this rule states how to form the canonical elements of a typeA and when two canonical elements are equal. Intuitively, the canonicalelements are the final values of programs whose evaluations cannot proceed.Examples of canonical elements in type theory are 3, true, (3, 4), and λx ·xand examples of non-canonical elements are 3+5, (λx ·x+1)(12+13), andif 3 = 4 then fst((3, 4)) else snd((3, 4)).


• Elimination rule: This rule, which corresponds to the elimination rulesof natural deduction systems for predicate logic, states how to prove aproperty for an element of a type A. The selectors are introduced by thisrule.

• Computation rule: This rule defines the computational meaning of thetype constructors. In this way, computation rules show how to evaluatenon-canonical elements.

For instance, we show the inference rules for the type constructor ⊕ in Fig. 3. Theselector case, which is introduced by the elimination rule for the type constructor⊕ (see Fig. 3), can be described as follows: we know that the object r should eitherbe a (tagged) member of A, having the form inl(p) or be a (tagged) member of B,having the form inr(q). The functions f and g are sufficient to give us a memberof C in either case: in the first case, we get a member of C by applying f to p, andin the second, by applying g to q. This computational information is expressed bythe computational rule for ⊕ (see Fig. 3).

Before ending this subsection, in the next example, we write a type theoreticalspecification of the sorting problem that we have given its CZ specification in ex-ample 3. By this specification, those readers who are familiar with set theoreticalspecification languages can see how a specification in Martin-Lof’s theory of typeslooks like. Also, we can compare this specification with the specification that willbe derived in the next subsection from the interpretation of the CZ specification intype theory.Example 5. The type theoretical specification of the sorting problem, which wasspecified in example 3, is as follows:

Sort ∼= Πl1 ∈ List(N ⊗N) · Σl2 ∈ List(N ⊗N) · Increasing(l2)⊗ Perm(l1, l2)For convenience, we assume the existence of the type constructor List , as a specialcase of W , throughout the paper. We use List for modelling ordered collections ofobjects. The inference rules for this type can be found in [47]. The empty list isshown as 〈〉; a non-empty list l is written as h :: t where h and t are the head and thetail of l, respectively. The ith element of the list l is written as l(i). Two predicatefunctions Increasing and Perm specify the intention of the sort operation, i.e., theoutput has to be an increasing permutation of the input sequence. We define thesetwo functions as follows:

Increasing(l) ∼= Πi ∈ N ·Πj ∈ N ·(Σn ∈ N ·I[N, j, i+n]) ⇒ (Σm ∈ N ·I[N, snd(l(j)), snd(l(i))+

m])Perm(l1, l2) ∼= Πx ∈ l1·I[N, occ(x, l1), occ(x, l2)]⊗Πx ∈ l2·I[N, occ(x, l1), occ(x, l2)]

Two sequences are permutations of each other when the number of occurrences ofevery element in both sequences are equal. In the above definition, occ is a functionthat counts the number of occurrences of a given ordered pair in a given sequenceof ordered pairs. We define occ as follows:

occ = λn · λs · lrec(s, 0, λh · λt · λr · if n = h then r + 1 else r)lrec is the symbol of recursion on lists. Indeed, it is the selector of type List, derivedfrom the elimination rule for this type. You can see the rule in [47]. However, wepresent the definition of lrec here:

lrec(〈〉, e, f) = elrec(h :: t, e, f) = f(h, t, lrec(t, e, f))

Therefore, occ is the following recursive function:


occ : ((N ⊗N)⊗ seq (N ⊗N)) ⇒ Nocc(x, 〈〉) = 0occ(x, h :: t) = occ(x, t) + 1 if x = hocc(x, h :: t) = occ(x, t) if x 6= h 4In example 6, we will extract a program from a correctness proof of the type

theoretical specification of the sorting problem.

2.4. Interpretation of CZ in Martin-Lof ’s theory of types. In [47], to givea constructive meaning to the set theoretical notions of CZ, their interpretationwere justified into Martin-Lof’s theory of types. Informally, the idea behind theinterpretation is to find a constructive version of the classical, iterative notion ofsets. In order to interpret the language of the CZ set theory, it is necessary to havea type (or set) which can be used as the universe of sets and the model for CZ.More precisely, the intention is to build a modelν =< V, ∈, = >

of CZ in Martin-Lof’s theory of types11 in which each set is associated with a pairconsisting of a base type together with a family of types, i.e. its elements. This isfurnished as follows:V ∼= Wx ∈ U.x,

where U is the universe, and W is the type constructor for recursive types (seesubsection 2.3). As has been described in subsection 2.3, each α ∈ V can be splitinto two components α− and α˜ such that α = sup(α−, α˜) where α− ∈ U andα˜ ∈ α− ⇒ V (Notice that in the definition of V above, B(x) is equal to x. Thus,B(α−) = α− here). Therefore, V is a tree whose nodes are members of U , andthus are themselves types having a predecessor for each of their elements (because ofB(x) = x). In other words, each node of V is a type whose elements (or predecessorsof the node) are themselves types. In this way, we obtain an interpretation of theiterative notion of sets in the constructive type theory.

To complete the description of the model, we need to define the two binaryrelations = and ∈. It is necessary to distinguish between = and ∈ on the onehand, which are primitive symbols in type theory, and = and ∈, which have beendefined as the type theoretical interpretations of = and ∈ from CZ, respectively.The equality = between α and β of V is defined as follows:α =β ∼= (Πx ∈ α− · α˜x ∈β)⊗ (Πx ∈ β− · β˜x ∈α)

Thus, the equality between sets is explained in terms of the equality between theirelements. In other words, the above definition corresponds to the extensional equal-ity in set theories, stated by the Extensionality axiom. Indeed, this definition canbe considered as the interpretation of the Extensionality axiom of the CZ set theoryin type theory (for a detailed description, see [47]). The membership ∈ between αand β is now explained as:α ∈β ∼= Σx ∈ β− · β˜x =α

The symbols = and ∈ have been defined by simultaneous recursion. if Φ[x] is aproposition for x ∈ V , then by definition we have:∀x ∈α · Φ[x] ∼= ∀x ∈ α− · Φ[α˜x]∃x ∈α · Φ[x] ∼= ∃x ∈ α− · Φ[α˜x]Now using the model ν, we interpret the set theoretical notions of CZ in type

theory. We begin by giving the interpretation of the empty set and the set of natural

11This approach for model construction has been adopted from that given in [1].


numbers as two basic sets in CZ. Since the empty set ∅ is in U (see subsection 2.3),and we can have a function R0 ∈ ∅ ⇒ V 12, we certainly have sup(∅, R0), which weshall abbreviate Θ, as the interpretation of the empty set and the natural number0. Having the interpretation of the natural number 0, we can use the von Neumanndefinition for natural numbers to interpret other natural numbers:

0 ∼= ∅1 ∼= 0 = ∅2 ∼= 0, 1 = ∅, ∅3 ∼= 0, 1, 2 = ∅, ∅, ∅, ∅...

Thus, if s(n) denotes the successor of n, then we have s(n) = n ∪ n.According to the above discussion, if in the model ν, boldface numbers represent

natural numbers, and α+ is the successor of α13, we have the following definitions:0 ∼= Θ = sup(∅, R0)α+ ∼= sup( α− ⊕α−14, λu · case u α ˜ α),

where u ∈ α− ⊕ α−, α˜ ∈ (α− ⇒ V ), and α is a constant function here. Forexample, for the natural number 1, we can write:

1 ∼= 0+ = sup(0− ⊕ 0−, case u0˜0) = sup(∅ ⊕ ∅, case uR0 0)Similarly, we can treat the natural numbers 2,3, . . .. Now let ω ∼= 0,1,2, ... bethe set of natural numbers in ν; hence, it is a member of V , and we can define itas follows:ω ∼= sup(N,natrec(n,Θ, λx · λy · y+)),

where n ∈ N , and natrec is the symbol of recursion on natural numbers. Indeed,natrec is the selector of type N , derived from the elimination rule for this type.You can see the rule in [47]. However, we present the definition of natrec here:

natrec(0, e, f) = enatrec(s(u), e, f) = f(u,natrec(u, e, f))

It is easy to see that ω˜0 = 0, ω˜1 = 1, ω˜2 = 2, . . .. For example, for ω˜2, we have:ω˜2 = natrec(2,Θ, λx · λy · y+) = sf (1,natrec(1,Θ, sf )) = (natrec(1,Θ, sf ))+ =(sf (0,natrec(0,Θ, sf )))+ = ((natrec(0,Θ, sf ))+)+ = (Θ+)+ = (0+)+ = 1+ = 2,

where we have used sf as an abbreviation for the function λx · λy · y+.After interpreting the empty set and the set of natural numbers in type theory,

in [47], an assignment function ξ has been defined which assigns elements of Vto well-formed formulas and atomic formulas of the CZ set theory (See the BNFsyntax for the language of CZ presented in subsection 2.1). The following equalitiesdefine this function:

[Ω]ξ = Ω[x = y]ξ = ξ(x) = ξ(y)[x ∈ y]ξ = ξ(x) ∈ ξ(y)[φ ∧ ψ]ξ = [φ]ξ ⊗ [ψ]ξ[φ ∨ ψ]ξ = [φ]ξ ⊕ [ψ]ξ

12For any type T , there is a function from the type ∅ to T , given by the abort construct as

follows [65]:afun ≡df λx · abortT x

We can therefore take R0 ≡df λx · abortV x here.13In the subsequent sections, we use the more familiar notation s(α) to denote the successor

of α in the model ν. Here we dedicate a new notation to distinguish it from its counterpart in CZ.14Indeed, α− ⊕α− is s(α−) which itself is a natural number in CZ, the successor of α−.


[φ⇒ ψ]ξ = [φ]ξ ⇒ [ψ]ξ[∀x ∈ y · φ]ξ = Πα ∈ (ξ(y))− · [φ]ξ[(ξ(y))˜α/x]

[∀x · φ]ξ = Πα ∈ V · [φ]ξ[α/x]

[∃x ∈ y · φ]ξ = Σα ∈ (ξ(y))− · [φ]ξ[(ξ(y))˜α/x]

[∃x · φ]ξ = Σα ∈ V · [φ]ξ[α/x]

As the last step in the translation of CZ into type theory, in [47], it has beenshown how each construct of the CZ set theory, which is related to an axiom, istransformed into an element of V . Here, we mention two of such transformationswhich will be required in our subsequent examples and proofs in the paper:

Cartesian product : (α× β)− ∼= α− ⊗ β− ,(α× β) (a, b) ∼= (α˜a, β˜b)

Decidable power set : P (α)− ∼= α− ⇒ Bool ,P (α)˜f ∼= sup(Σβ ∈ α− · fβ=true, λu · α fst(u))

As discussed above, a framework has been provided in [47] and [48] which trans-lates sets, atomic formulas, and well-formed formulas of CZ into Martin-Lof’s theoryof types. This framework also interprets each construct related to an axiom of theCZ set theory. However, to translate a CZ specification into a type theoreticalone, we need to interpret the schema calculus, as a distinctive feature of the CZspecification language, in type theory. In [40], some methods have been introducedto interpret the schema calculus of Z in the type theory UTT 15 [39]. The initialsolution of [40] corresponds to a direct encoding of schemas as Σ-types. This solu-tion turns out to be unsatisfactory because encoding the operations of the schemacalculus requires the ability to perform computations on the syntax of schemas.Thus, in [40], Maharaj has developed some methods by which this syntax can alsobe represented. However, these methods are considerably more complicated thanthe initial one.

Since it is not intended in this paper to deal with the issues of the interpretationof CZ in type theory, we assume that all the operations of the schema calculus usedin a specification are applied to schemas before we begin the translation. Thus, tointerpret CZ specifications in type theory, we can only concentrate on the schemasand ignore the operations of the schema calculus. As a future work, we can extendthe current translation to interpret the schema calculus of CZ in Martin-Lof’s theoryof types. In this way, we obtain an alternative semantics for the schema calculusoperations, based on type theory rather than set theory.

Now we employ the first approach of [40] to treat the schemas of CZ and interpretthem in type theory. As we have stated in subsection 2.2, a schema in CZ has oneof the following general forms:

(1) Schema1∼= [s1 ∈ S1, s2 ∈ S2, ..., sl ∈ Sl | θ]

(2) Schema2∼= [x1 ∈ A1, x2 ∈ A2, ..., xm ∈ Am, y1 ∈ B1, y2 ∈ B2, ..., yn ∈

Bn |φ, ψ]

Forms (1) and (2) are the general forms of state schemas16 and operation schemas,respectively. θ corresponds to invariants of states; φ and ψ denote the pre- andpostconditions of operations, respectively. Also, si(i : 1..l) are state variables,xj(j : 1..m) are input (or before state) variables, and yk(k : 1..n) are output (or

15Unifying Theory of Dependent Types16As we have stated in subsection 2.2, a schema given in form (1) can also be used as a type

or as a part of a declaration.


after state) variables. Now we extend the function ξ to translate the schemasSchema1 and Schema2 above into two elements of V as follows:

[Schema1 ]ξ = Σα1 ∈ (ξ(S1))−, α2 ∈ (ξ(S2))−, ..., αl ∈ (ξ(Sl))− · ([θ]ξ)[(ξ(Si))αi/si]

[Schema2 ]ξ = Πα1 ∈ (ξ(A1))−, α2 ∈ (ξ(A2))−, ..., αm ∈ (ξ(Am))−·([φ]ξ ⇒ Σβ1 ∈ (ξ(B1))−, β2 ∈ (ξ(B2))−, ..., βn ∈ (ξ(Bn))−·[ψ]ξ)[(ξ(Ai))αi/xi][(ξ(Bj))βj/yj ]

By the definition of the function ξ and its recent extension, we can conclude thefollowing equalities:

[Schema1 ]ξ = [∃s1 ∈ S1, s2 ∈ S2, ..., sl ∈ Sl · θ]ξ[Schema2 ]ξ = [∀x1 ∈ A1, x2 ∈ A2, ..., xm ∈ Am · (φ⇒ ∃y1 ∈ B1, y2 ∈ B2, ..., yn ∈

Bn · ψ)]ξThe above equalities introduce a constructive interpretation of schemas which

induces proof obligations which facilitates the translation of CZ schemas into typetheory and thereby yields implementations of these schemas. Now, given a specifi-cation in CZ, we can use the function ξ to translate the specification into a type intype theory and then extract a program (a term in type theory) which meets thespecification (more precisely, meets its representation in type theory). To illustratethis approach, in the next example, we employ the CZ specification of the sortingproblem given in example 3. We show that our method of program developmentextracts a deterministic program from this specification whereas the specification isitself nondeterministic. In the next section, we will investigate this problem indetail.Example 6. We use the extended version of the function ξ to translate the opera-tion schema Sort , given in the CZ specification of the sorting problem (see example3). For convenience, we do not translate two schemas Increasing and Perm whichare included in the schema Sort . To consider these schemas in the translation pro-cess, we can bring their declaration and predicate parts into Sort before we beginthe translation.

[Sort ]ξ = Πα ∈ (ξ(seq(N ×N)))− · Σβ ∈ (ξ(seq(N ×N)))−·([out ! ∈ increasing ∧ (in?, out !) ∈ perm]ξ)[(ξ(seq(N×N)))α/in?][(ξ(seq(N×N)))β/out!]

= Πα ∈ (ξ(seq(N ×N)))− · Σβ ∈ (ξ(seq(N ×N)))−·(ξ(seq(N×N)))β ∈ ξ(increasing)⊗((ξ(seq(N×N)))α, (ξ(seq(N×N)))β) ∈ ξ(perm)

Since α and β are themselves elements of V , we have(ξ(seq(N ×N)))α = α(ξ(seq(N ×N)))β = β

Thus, the following equality holds:[Sort ]ξ = Πα ∈ (ξ(seq(N ×N)))− ·Σβ ∈ (ξ(seq(N ×N)))− · β ∈ ξ(increasing)⊗

(α, β) ∈ ξ(perm)To continue the translation, we use the interpretations of the set of natural numbersand the cartesian product constructor in type theory, stated in this subsection. Onthe other hand, in [47], seqX was translated into a set of finite boolean-valuedfunctions whose domains are decidable subsets of N⊗(ξ(X))−. This interpretationthen was proved to be equivalent to the semantics of the type constructor List intype theory (For a detailed description, see [47]). Thus, we can easily map seqX ofCZ to List(X) of type theory. Using this mapping and the interpretations of theset of natural numbers and the cartesian product constructor in type theory, wecan conclude the following equality:

[Sort ]ξ = Πα ∈ List(N⊗N)·Σβ ∈ List(N⊗N)·β ∈ ξ(increasing)⊗(α, β) ∈ ξ(perm)


T = N ⊗ N

A ≡ ∑β ∈ List(T) • β ∈ IN ⊗ (α, β) ∈ P

B ≡ β ∈ IN ⊗ (α, β) ∈ P

sort = λα • t t = lrec(α, u, f)

u = (z, r) z = ⟨⟩ r = (r1, r2)

f = λa • g g = λx • h

Γ ≡ α∈List(T) h = λh1 • h2 h2 = (v, q) q = (q1, q2)

v = Insert(a, fst(h1))

Insert = λn • λs • lrec(s ⟨n⟩

Δ ≡ α∈List(T), a∈T, x∈List(T), h1∈A[x/α]

Insert λn • λs • lrec(s, ⟨n⟩,

λh • λt • λr • if snd(n) ≤ snd(h) then ⟨n⟩^(h::t) else ⟨h⟩^r)

Γ z=⟨⟩

Hyp

r1∈(⟨⟩∈IN)Γ Γ z=⟨⟩

Hyp

r2∈((⟨⟩ ⟨⟩)∈P)ΓHyp Hyp

r1∈(z∈IN)Γ

Γ z=⟨⟩sub

r1∈(⟨⟩∈IN)Γ

r2∈((⟨⟩, z)∈P)Γ

Γ z=⟨⟩sub

r2∈((⟨⟩, ⟨⟩)∈P)Γ v=Insert(a, fst(h1))Δ v=Insert(a, fst(h1))Δ

∑i

Hyp⊗i

Δ q1∈(v∈IN) Δ q2∈((a::x, v)∈P)

subΓ ⟨⟩∈List(T)

Listi1Γ z=⟨⟩

Hyp

⊗i

v∈List(T) Δ Δ q∈B[a::x/α][v/β]

Listf

Γ

T typeα∈List(T), a∈T, x∈List(T)

∏i

α∈List(T), a∈T, x∈List(T), h2∈A[a::x/α]⇒i

h1∈A[x/α]z∈List(T) r∈B[⟨⟩/α][z/β]Γ

h∈(A[x/α]⇒A[a::x/α])⊗fN type N type

Liste

assList(T) type

Listf

u∈A[⟨⟩/α] α∈List(T) α∈List(T) f∈(∏a∈T•∏x∈List(T)•A[x/α]⇒A[a::x/α])α∈List(T)∏i

α∈List(T), a∈T g∈(∏x∈List(T)•A[x/α]⇒A[a::x/α])∑i

α∈List(T)

sort ∈ (∏α∈List(T) • ∑β∈List(T) • β∈IN ⊗ (α, β)∈P)∏i

t∈Aα∈List(T)

Figure 4. Program extraction from the operation schema Sort

Notice that the resulting type theoretical specification of the sorting problem issimilar to the one which was directly written in example 5. We now derive aprogram from a correctness proof of the resulting specification. An initial part ofsuch a proof is shown in Fig. 4 (To see the complete proof, refer to [47]). In theproof tree, we have used two conventions IN = ξ(increasing) and P = ξ(perm).Also, throughout the paper, the dashed lines in proof trees indicate those parts ofthe proof that must proceed, but are not shown in the proof tree; by a solid line,however, we transfer a part of the proof to another space because of the lack of thespace.

The extracted program is as follows:sort = λα · lrec(α, (〈〉, r), λa · λx · λh1 · (Insert(a, fst(h1)), q))

We first give an abstract illustration of the program. The readers interested indetails of the program can see them later in this example. The program sort isa recursive function that for each input sequence of ordered pairs, results in apermutation in which the elements are in the increasing order in terms of theirsecond components:


sort : List(N ⊗N) ⇒ List(N ⊗N)sort(〈〉) = 〈〉sort(h :: t) = Insert(h, sort(t)),

where the function Insert(n, s) results in a permutation of 〈n〉_ s whose elementsare in the increasing order in terms of their second components, provided that theelements of s are themselves in the increasing order:

Insert : (N ⊗N)⊗ List(N ⊗N) ⇒ List(N ⊗N)Insert(n, 〈〉) = 〈n〉Insert(n, h :: t) = if snd(n) ≤ snd(h) then 〈n〉_ (h :: t) else 〈h〉_ Insert(n, t)A detailed description of the program sort is as follows: r and q are the proof

objects of 〈〉 and Insert(a, fst(h1)), respectively (see Fig. 4). lrec is the symbolof recursion on lists defined in the previous subsection (see example 5 where thefunction occ has been defined). Thus, sort is a recursive function which results in〈〉 for the input α = 〈〉. In the recursive step, the program tries to compute anoutput for the input α = h :: t while it has generated an output for the input α = t.Since the output for α = t, i.e. h1, is an ordered pair whose second element is theproof object of the first one, applying fst to it removes the proof part. Thus, wecan conclude that sort(h :: t) = Insert(h, sort(t)).

The rules that yield v = Insert(a, fst(h1)) have not been shown in Fig. 4.Nevertheless, these rules can validate the following equality [47]:

Insert = λn · λs · lrec(s, 〈n〉, λh · λt · λr · if snd(n) ≤ snd(h) then 〈n〉 _ (h ::t) else 〈h〉_ r)

The program sort extracted in example 6 is correct according to the initialspecification of the sorting problem given in CZ: for each input sequence of or-dered pairs, this program produces a permutation in which the elements are in theincreasing order in terms of their second components. However, it has a determin-istic behavior and produces only one of the possible outputs for each input sequencewhereas the initial specification is nondeterministic: for input sequences having dif-ferent elements with identical keys, the operation schema Sort allows more thanone sorted permutation. In the next section, we will look for the origin of this prob-lem by investigating our program development method when applied to a typicalnondeterministic CZ specification. We will show that the initial nondeterminism,specified implicitly in CZ specifications, will be lost during the process of programdevelopment. Such a result seems not to be wrong in a situation where the abstrac-tion involved in the specification leads to nondeterminism while we still want thefinal implementation to be deterministic (e.g., in the sorting problem); however, insuch situations, we still encounter a problem: the programmer is deprived of someroutes to take in developing the program or some good implementations might beexcluded. The above problem seems to be more serious when we consider specifica-tions of nondeterministic programs (See our description given for the specificationof a concurrent database management system at the end of example 4).

In the next section, we will see that the above mentioned problem could be ad-dressed by specifying all possible behaviors directly in a nondeterministic specifica-tion. However, it yields longer and more complicated specifications which are harderto read and write. Also, the writer of a nondeterministic specification him/herselfmust take care that his/her method to specify all possible behaviors is suitable atthe same time that s/he describes the functional properties of the system. Both


of these issues become more serious when we need to specify modalities of nonde-terminism. Therefore, we will introduce a number of nondeterministic constructsand a set of new operations for the schema calculus by which we can specify modal-ities of nondeterminism easily at the same time that we use our usual procedures tospecify functional properties. On the other hand, these constructs enter into spec-ifications without changing their main structures. Thus, they do not yield longerand more complicated specifications. We will interpret all the new constructs in CZitself; hence, using the current translation of CZ into Martin-Lof ’s theory of types[47], we can develop programs which are provided with all possible implementationsaccording to the initially specified modalities of nondeterminism.

3. Nondeterminism in CZ

In this section, we first explore the notion of nondeterminism in CZ specifica-tions from a formal program development point of view. We then introduce amathematical toolkit to specify modalities of nondeterminism in CZ.

3.1. Exploring nondeterminism. At first, it is necessary to formalize the notionof nondeterminism in CZ. To achieve this goal, as in [53], we regard the existence ofseveral after state valuations for a single before state binding in an operation schemaas a clear notion of nondeterminism in CZ. The following definition formalizes thisnotion:

Definition 3.1.1. An operation schema Op is nondeterministic iff ∃b1, b2 ∈ Op ·b1 6= b2 ∧ bbi1 = bbi2 .

For a binding b ∈ Op, we use the notation bbi to denote that part of b in whichbefore state or input variables of Op are bound to some values. By the above defini-tion, an operation schema is nondeterministic iff there exists a combination of valuesof before state and input variables that with two or more different combinations ofvalues of after state and output variables satisfy the schema predicates.Example 7. According to definition 3.1.1, the operation schema Sort given inexample 3 is nondeterministic since there are two different bindings

[in? 7→ 〈(1, 16), (2, 18), (3, 16)〉, out ! 7→ 〈(1, 16), (3, 16), (2, 18)〉] ∈ Sort and[in? 7→ 〈(1, 16), (2, 18), (3, 16)〉, out ! 7→ 〈(3, 16), (1, 16), (2, 18)〉] ∈ Sort

whose parts related to the before state and input variables of Sort are equal.Notice that a specification may be deterministic whereas it involves a nondeter-

ministic schema. For example, consider the following simple specification:Report ::= OK |Not ExistsS1

∼= [a? ∈ N, b! ∈ N, r! ∈ Report | a? > 0, b! < a? ∧ r! = OK ]S2

∼= [a? ∈ N, r! ∈ Report | a? = 0, r! = Not Exists]TS ∼= ∃cb! ∈ N · (S1 ∨c S2 )

Using the definition of ∃c and ∨c, we can show the following equality:TS ∼= [a? ∈ N, r! ∈ Report | true,∃b! ∈ N ·

(a? > 0∧b! < a?∧r! = OK )∨(a? = 0∧r! = Not Exists)]While the schema S1 is nondeterministic, the schema TS which includes S1 is itselfdeterministic. Informally, we can say a specification is nondeterministic iff afterapplying all operations of the schema calculus existing in the specification, it stillinvolves at least one nondeterministic schema.

The existence of nondeterministic schemas may cause specifications to involvenondeterminism implicitly. As it has been shown in example 6, after deriving a


program from a correctness proof of an implicitly nondeterministic specification,only one of the possible outputs is guaranteed for each input. We investigate thisproblem more precisely using the general form of operation schemas in CZ, definedin subsection 2.2 as follows:

OP Schema ∼= [x1 ∈ A1, x2 ∈ A2, ..., xm ∈ Am, y1 ∈ B1, y2 ∈ B2, ..., yn ∈Bn |φ, ψ],where φ and ψ denote the pre- and postconditions of the specified operation, re-spectively. Also, xi(i : 1..m) are its input (or before state) variables, and yj(j : 1..n)are its output (or after state) variables. In subsection 2.4, we have defined the as-signment function ξ which interprets formulas of the language of CZ in type theory.We have also extended this function to translate schemas of CZ in type theory. Bythe extended version of ξ, the following equality holds:

[OP Schema]ξ = Πα1 ∈ (ξ(A1))−, α2 ∈ (ξ(A2))−, ..., αm ∈ (ξ(Am))−·([φ]ξ ⇒ Σβ1 ∈ (ξ(B1))−, β2 ∈ (ξ(B2))−, ..., βn ∈ (ξ(Bn))−·[ψ]ξ)[(ξ(Ai))αi/xi][(ξ(Bj))βj/yj ],

where [OP Schema]ξ is the type theoretical equivalent of OP Schema. We use thefollowing conventions:A′i = (ξ(Ai))− for i : 1..mB′

j = (ξ(Bj))− for j : 1..nφ′ = [φ]ξ[(ξ(Ai))αi/xi][(ξ(Bj))βj/yj ]

ψ′ = [ψ]ξ[(ξ(Ai))αi/xi][(ξ(Bj))βj/yj ]

Therefore, [OP Schema]ξ is equal to the following type in type theory:Πα1 ∈ A′1, α2 ∈ A′2, ..., αm ∈ A′m · (φ′ ⇒ Σβ1 ∈ B′

1, β2 ∈ B′2, ..., βn ∈ B′

n · ψ′)

Hyp

Γ ≡ α1∈A′1, …, αm∈A′m

prog = λ(α1, …, αm) • t

t = ((v1, …, vn), q)

∑i

prog ∈ (∏α1∈A′1, …, αm∈A′m.

∑β1∈B′1,…, βn∈B′n. ϕ′)

∏it ∈ (∑β1∈B′1, …, βn∈B′n. ϕ′)

Γ v1∈B′1, …, vn∈B′n q∈(ϕ′[v1/β1]…[vn/βn])

Γ

Γ

Figure 5. Program extraction from the operation schema Op Schema

We can now derive a program from a correctness proof of the above type theoret-ical specification. An initial part of such a proof is shown in Fig. 5. The extractedprogram is as follows:

prog = λ(α1, α2, ..., αm) · λt1 · ((v1, v2, ..., vn), q),


where t1 and q are the proof objects of φ′ and ψ′[v1/β1][v2/β2]...[vn/βn], respec-tively. For each valuation of α1 ∈ A′1, α2 ∈ A′2, ..., αm ∈ A′m, this program producesonly one output, i.e. the n-ary (v1, v2, ..., vn), although the schema Op Schemamay be itself nondeterministic according to definition 3.1.1. This problem is dueto the fact that when we use the introduction rule for dependent sum (Σi) in theproof tree (see the circled Σi in Fig. 5), we can replace the n-ary (β1, β2, ..., βn) byonly one value.

It seems that if the writer of a nondeterministic specification indicates all possiblebehaviors explicitly in the initial specification, then a program can be obtained thatinvolves all possible behaviors. In this way, the mentioned problem will be addressedwithout changing the rules of type theory and/or the translation of CZ into typetheory. To evaluate this solution, suppose that the operation schema OP Schema,which has been introduced earlier in this section, is nondeterministic (according todefinition 3.1.1). We rename and rewrite this schema as follows:

N OP Schema ∼= [x1 ∈ A1, x2 ∈ A2, ..., xm ∈ Am, aovar ∈ P (B1 × B2 × ... ×Bn) |φ,

∀(y1, y2, ..., yn) ∈ (B1×B2×...×Bn)·(y1, y2, ..., yn) ∈ aovar ⇔ ψ]In the new schema, we have promoted the combination of the after state and outputvariables to a maximal set (i.e. aovar) of possible combinations of these variableswhich satisfy the postcondition of the schema. Notice that if we promoted each afterstate or output variable to a distinct set and placed a universal quantifier in front ofthe schema postconditions to contain all possible values, the relationship betweenvaluations that make the schema predicates true would disappear. To overcome thisproblem, we have combined all previous after state and output variables in a newvariable using the cartesian product of their types. Theorem 3.1.2 shows that ap-plying our program development method to the schema N OP Schema rather thanOP Schema, we can extract a program which preserves the initial nondeterminisminvolved in OP Schema.

Theorem 3.1.2. Let prog be the program that is constructed after applying thefunction ξ to the schema N OP Schema and then proving the correctness of the re-sulting type theoretical specification. For all X1 ∈ A1, ..., Xm ∈ Am, if φ(X1, ..., Xm) =true, then prog, when applied to ξ(X1), ..., ξ(Xm), produces a boolean-valued func-tion dv : (ξ(B1)⊗ ...⊗ ξ(Bn)) ⇒ Bool such that for all Y1 ∈ B1, ..., Yn ∈ Bn,

dv((ξ(Y1), ..., ξ(Yn))) = true iff [x1 7→ X1, ..., xm 7→ Xm, y1 7→ Y1, ..., yn 7→ Yn] ∈OP Schema.

Proof. We first apply the function ξ to the schema N OP Schema as follows:[N OP Schema]ξ = Πα1 ∈ (ξ(A1))−, α2 ∈ (ξ(A2))−, ..., αm ∈ (ξ(Am))−·([φ]ξ ⇒ Σγ ∈ (ξ(P (B1 ×B2 × ...×Bn)))−·Π(β1, β2, ..., βn) ∈ ((ξ(B1))− ⊗ (ξ(B2))− ⊗ ...⊗ (ξ(Bn))−)·(β1, β2, ..., βn) ∈ (ξ(P (B1 ×B2 × ...×Bn)))γ ⇔ [ψ]ξ)[(ξ(Ai))αi/xi][(ξ(Bj))βj/yj ]

To achieve the above equality, we used the interpretation of the cartesian productconstructor in type theory (see subsection 2.4). To continue the translation of theschema N OP Schema, we should use the interpretation of the decidable power setconstructor in type theory given in subsection 2.4. We present this interpretationagain here:

1. (ξ(PX))− ∼= (ξ(X))− ⇒ Bool2. (ξ(PX))f ∼= sup(Σβ ∈ (ξ(X))− · fβ = true, λu · (ξ(X))fst(u))


To make the remainder of the proof easier, we use a simple interpretation of theequality 2 above: in type theory, we can consider Σx ∈ A.B as a subset x ∈A |B(x), the set of all elements a in A for which B(a) holds. This subset is thesame as the set Σx ∈ A.B except that the second component (the proof object) ofeach element of Σx ∈ A.B has been removed [55]. In this way, for v ∈ (ξ(X))−, theproposition v ∈ (ξ(PX))f can be replaced by fv = true. Thus, in the current typetheoretical interpretation of N OP Schema, we can replace

(β1, β2, ..., βn) ∈ (ξ(P (B1 ×B2 × ...×Bn)))γbyγ(β1, β2, ..., βn) = true.

Now if we use the recent simplification, and then replace(ξ(P (B1 ×B2 × ...×Bn)))−

by(ξ((B1 ×B2 × ...×Bn)))− ⇒ Bool,

and finally use the interpretation of the cartesian product constructor, the followingequality holds:

[N OP Schema]ξ = Πα1 ∈ (ξ(A1))−, α2 ∈ (ξ(A2))−, ..., αm ∈ (ξ(Am))−·([φ]ξ ⇒ Σγ ∈ ((ξ(B1))− ⊗ (ξ(B2))− ⊗ ...⊗ (ξ(Bn))−) ⇒ Bool·Π(β1, β2, ..., βn) ∈ ((ξ(B1))− ⊗ (ξ(B2))− ⊗ ...⊗ (ξ(Bn))−)·γ(β1, β2, ..., βn) = true⇔ [ψ]ξ)[(ξ(Ai))αi/xi][(ξ(Bj))βj/yj ]

Now we use the following conventions:

1. A′i = (ξ(Ai))− for i : 1..m2. B′

j = (ξ(Bj))− for j : 1..n3. φ′ = [φ]ξ[(ξ(Ai))αi/xi][(ξ(Bj))βj/yj ]

4. ψ′ = [ψ]ξ[(ξ(Ai))αi/xi][(ξ(Bj))βj/yj ]

Therefore, [N OP Schema]ξ is equal to the following type in Martin-Lof’s theoryof types:

Πα1 ∈ A′1, α2 ∈ A′2, ..., αm ∈ A′m · (φ′ ⇒ Σγ ∈ (B′1 ⊗B′

2 ⊗ ...⊗B′n) ⇒ Bool ·

Π(β1, β2, ..., βn) ∈ (B′1⊗B′

2⊗ ...⊗B′n) ·γ(β1, β2, ..., βn)=true ⇔ ψ′)

We can now derive a program from a correctness proof of the above specification.An initial part of such a proof is shown in Fig. 6: The resulting program is:

prog = λ(α1, α2, ..., αm) · λt1 · (dv , λ(β1, β2, ..., βn) · (λq4 · q5, λq6 · q7))For all valuations a1 ∈ A′1, ..., am ∈ A′m of input variables, if there exists some termt1 such that t1 ∈ φ′(a1, ..., am), prog produces a boolean-valued function dv : (B′

1⊗...⊗B′

n) ⇒ Bool . The origin of forming such a function can be found by viewing thecircled Σi in the proof tree (see Fig. 6): using the introduction rule for dependentsum (Σi) in the correctness proof of [N OP Schema]ξ, we must replace γ by afunction from (B′

1⊗ ...⊗B′n) to Bool . By the above discussion and using convention

φ′ = [φ]ξ[(ξ(Ai))αi/xi][(ξ(Bj))βj/yj ], we can say that for all X1 ∈ A1, ..., Xm ∈ Am,if φ(X1, ..., Xm) = true, then prog , when applied to ξ(X1), ..., ξ(Xm), produces aboolean-valued function dv : (ξ(B1) ⊗ ... ⊗ ξ(Bn)) ⇒ Bool . Now we demonstratethat for all Y1 ∈ B1, ..., Yn ∈ Bn,

[x1 7→ X1, ..., xm 7→ Xm, y1 7→ Y1, ..., yn 7→ Yn] ∈ OP Schema iff dv((ξ(Y1), ..., ξ(Yn))) =true.To achieve this goal, we first show that for all valuations b1 ∈ B′

1, ..., bn ∈ B′n of out-

put variables, dv(b1, ..., bn) = true if and only if there exists some term t2 such thatt2 ∈ ψ′(a1, ..., am, b1, ..., bn). The reason is as follows: to construct dv , in the process


Γ ≡ α1∈A′1, α2∈A′2, …, αm∈A′m

prog = λ(α1, α2, …, αm) • t t = (dv, q)

∆ ≡ ∑γ∈(B′1⊗B′2⊗…⊗B′n)⇒Bool. ∏(β1, β2,…, βn) ∈ (B′1⊗B′2⊗…⊗B′n). γ(β1, β2,…, βn) = true ⇔ϕ′

∆1 ≡ ∏(β1, β2,…, βn) ∈ (B′1⊗B′2⊗…⊗B′n). γ(β1, β2,…, βn) = true ⇔ϕ′

Γ1 ≡ Γ, (β1, β2,…, βn) ∈ (B′1⊗B′2⊗…⊗B′n)

q = λ(β1, β2, …, βn) • q1 q1 = (q2, q3)q3 = λq6 • q7q2 = λq4 • q5

∑i

prog ∈ (∏α1∈A′1,α2∈A′2,…,αm∈A′m.(∑γ∈(B′1⊗B′2⊗…⊗B′n)⇒Bool.

∏(β1, β2,…, βn) ∈ (B′1⊗B′2⊗…⊗B′n). γ(β1, β2,…, βn) = true ⇔ ϕ′))

∏iα1∈A′1, α2∈A′2, …, αm∈A′m

Hyp

Γ dv∈(B′1⊗B′2⊗…⊗B′n)⇒Bool Γ q ∈ (∆1[dv/γ])

t ∈ ∆

Γ, (β1, β2,…, βn) ∈ (B′1⊗B′2⊗…⊗B′n) q1 ∈ (dv(β1, β2,…, βn) = true ⇔ϕ′)∏i

⊗iΓ1 q2 ∈ (dv(β1, β2,…, βn) = true ⇒ ϕ′) Γ1 q3 ∈ (ϕ′⇒ dv(β1, β2,…, βn) = true)

⇒iΓ1, q6 ∈ ϕ′ q7 ∈ (dv(β1, β2,…, βn) = true)Γ1 q5 ∈ ϕ′

⇒i, q4 ∈ (dv(β1, β2,…, βn) = true)

Figure 6. Program extraction from the schema N OP Schema

of extracting prog (see the proof tree in Fig. 6), for each valuation (b1, ..., bn) of out-put variables, we must construct two functions λq4 ·q5 and λq6 ·q7. When construct-ing the function λq4 · q5, indeed, we try to prove that q5 ∈ ψ′(a1, ..., am, b1, ..., bn) ifdv(b1, ..., bn) = true. By a similar reasoning, when constructing the function λq6 ·q7,indeed, we try to prove that if q6 ∈ ψ′(a1, ..., am, b1, ..., bn), then dv(b1, ..., bn) =true.

On the other hand, since we have φ(X1, ..., Xm) = true, we can use the mem-bership relation between bindings and schema types, stated in subsection 2.2, andsay that for all Y1 ∈ B1, ..., Yn ∈ Bn, the predicate ψ(X1, ..., Xm, Y1, ..., Yn) holdsiff [x1 7→ X1, ..., xm 7→ Xm, y1 7→ Y1, ..., yn 7→ Yn] ∈ OP Schema. In other words,using convention ψ′ = [ψ]ξ[(ξ(Ai))αi/xi][(ξ(Bj))βj/yj ], we have[x1 7→ X1, ..., xm 7→ Xm, y1 7→ Y1, ..., yn 7→ Yn] ∈ OP Schema iff there exists sometype theoretical term t2 such that t2 ∈ ψ′(ξ(X1), ..., ξ(Xm), ξ(Y1), ..., ξ(Yn)). Nowby this result and also the conclusion of the previous paragraph, we can say thatfor all Y1 ∈ B1, ..., Yn ∈ Bn,

[x1 7→ X1, ..., xm 7→ Xm, y1 7→ Y1, ..., yn 7→ Yn] ∈ OP Schema iff dv((ξ(Y1), ..., ξ(Yn))) =true.In this way, the proof of the theorem terminates.


Theorem 3.1.2 shows that the problem of implicitly specified nondeterminismcould be addressed by indicating all possible outputs directly in the specification. Inthis way, we can obtain all possible outputs for a given input. However, it is not hardto see that in comparison to the initial operation schema, namely, OP Schema, thenew one, namely, N OP Schema, has a longer and more complicated structure.Also, when we write specifications such as N OP Schema, we must take care thatour method to specify nondeterminism is suitable at the same time that we describethe functional properties of the system. Both of these issues become more seriouswhen we need to specify modalities of nondeterminism.

Having some dedicated notations for specifying nondeterminism explicitly inour specifications not only preserves the effects of the initially specified nondeter-minism in finally constructed programs, but also helps the writer of a specifica-tion to concentrate on the functional properties of the problem at the same thats/he brings nondeterminism into her/his specification. This specially facilitatesspecifying modalities of nondeterminism. In subsection 3.2, we introduce a sim-ple nondeterministic construct by which one can write explicitly nondeterministicspecifications in CZ. Our initial approach will be extended in subsection 3.3 tocover modalities of nondeterminism. We give a semantics for all of the new non-deterministic constructs in CZ itself; hence to produce nondeterministic programsfrom specifications which involve new constructs, one can still use the method ofprogram development introduced in section 2.

3.2. Specifying nondeterminism in CZ. We use the notion of multi-schema asa tool to specify nondeterminism explicitly in CZ. A multi-schema is a version ofan operation schema that may include nondeterministic, after state (or output)variables. The word may used in the definition of multi-schemas shows that we willconsider ordinary operation schemas as special cases of multi-schemas involvingno nondeterministic variable. The notion of nondeterministic variables has beenadopted from [8] in which a nondeterministic propositional logic has been developedby introducing nondeterministic, propositional variables. In the proposed logic, anordinary variable can evaluate to only one of the values true and false at eachtime whereas a nondeterministic variable can denote both values true and falsesimultaneously. In general, we can consider a nondeterministic variable as a variableof a type which can be evaluated to a set of values of that type.

Therefore, using nondeterministic variables, the writer of a specification can spec-ify situations where some variables have nondeterministic nature and are allowedto be evaluated to more than one value. The following nondeterministic constructshows how we can declare a nondeterministic variable in CZ (The symbol & comesfrom [8]):

ndvar ∈ &TypeThe above declaration introduces ndvar as a nondeterministic variable of the typeType. From the type checking point of view, nondeterministic variables are thesame as ordinary ones. To emphasize this similarity, we add the following rule,called Nondeterminism, to the type inference rules of CZ17:

17Since this rule is a type checking rule and not a membership definition, we use : instead of

∈.


ndvar : &Typendvar : Type

By the above rule, we consider the type of a nondeterministic variable as sameas the type of the corresponding ordinary variable. This allows us to use thesevariables in specifications for indicating nondeterminism explicitly without changingthe structure of the specification predicates. However, since a nondeterministicvariable can be evaluated to a set of values, it semantically belongs to the powerset of the basic type. Now, it would seem that we can interpret the notion ofmulti-schema in CZ by only replacing instances of &Type by instances of P Type.However, using nondeterministic variables in the declaration part of a schema mayaffect other variables and also the predicate part of the schema. Therefore, whenreplacing nondeterministic variables by set-valued ones, we must propagate requiredchanges to related variables and the predicate part.

Now we are ready to give the interpretation of multi-schemas in CZ. At first, letthe following schema be the general form of multi-schemas:

M Schema ∼= [x1 ∈ A1, x2 ∈ A2, ..., xm ∈ Am, y1 ∈ B1, y2 ∈ B2, ..., yd ∈ Bd,yd+1 ∈ &Bd+1, yd+2 ∈ &Bd+2, ..., yn ∈ &Bn |φ, ψ]

The structure of M Schema is similar to the structure of OP Schema given earlierin this section as the general form of operation schemas, but unlike OP Schema, theschema M Schema involves some nondeterministic, after state (or output) variables,i.e. yd+1, yd+2, ..., yn. Notice that as a special case, all the variables of M Schemamay be ordinary. In other words, as it has been stated at the beginning of this sub-section, we consider ordinary operation schemas as special cases of multi-schemasinvolving no nondeterministic variable. Now, let []D be a function that interpretsmulti-schemas in CZ. The next definition shows how the function []D maps themulti-schema M Schema above to an ordinary operation schema of CZ.

Definition 3.2.1. The interpretation of the multi-schema M Schema in CZ is asfollows:

if none of the variables of M Schema are nondeterministic, then [M Schema]D =M Schema;

otherwise, [M Schema]D ∼= [x1 ∈ A1, x2 ∈ A2, ..., xm ∈ Am, dvar ∈ P (B1×B2×...×Bn) |φ,

∀(y1, y2, ..., yn) ∈ (B1×B2× ...×Bn) · (y1, y2, ..., yn) ∈ dvar ⇔ψ]

The function []D behaves as an identity function when applied to a multi-schemainvolving no nondeterministic variable. Otherwise, it promotes the combination ofafter state and output variables, either nondeterministic or ordinary, to a set (dvar)of all possible combinations of these variables which satisfy the postcondition of theschema. We have combined all previous after state and output variables in a newvariable using the cartesian product of their types. The reason is the same as the onegiven earlier in this section for the schema N OP Schema: if we promote each afterstate and output variable to a separate set-valued variable, the relationship betweenvaluations that make the schema predicates true will disappear. Combining afterstate and output variables in a new variable preserves the relationship betweenthese variables after the interpretation. In subsection 3.3.3, we will show thatthis leads to the singular interpretation of nondeterminism. To obtain the pluralinterpretation of nondeterminism, we will change the current interpretation.


Notice that the interpretation of the multi-schema M Schema in CZ is equivalentto the operation schema N OP Schema given earlier in this section. Therefore,according to theorem 3.1.2, using the notion of multi-schemas and then applyingthe function []D to interpret multi-schemas in CZ guarantees that the final programwill implement all possible behaviors allowed by the initial specification. Moreover,using the notion of multi-schemas to specify nondeterministic situations instead ofspecifying all possible behaviors directly (as we did by the schema N OP Schema)results in shorter and more concrete specifications which are easier to read andwrite. Also, in this way, nondeterminism can come into our specifications withoutchanging their main structures and without decreasing our focus on describing thefunctional properties of the system. The above mentioned benefits will seem to bemore effective in the following subsections when we will extend our toolkit to specifymodalities of nondeterminism and revise the operations of the schema calculus toconsider the new nondeterministic constructs.

Using the notion of multi-schemas, we will rewrite our specification of the sortingproblem in example 10. We will also back to the specification of the concurrentdatabase management system in example 16 after modelling modalities of non-determinism in CZ and introducing a new set of the schema calculus operations.Nevertheless, in the next example, we use our toolkit to specify a small nondeter-ministic problem because its specification results in a simple program allowing usto easily probe the effects of the explicitly specified nondeterminism on the finalprogram. We also construct and compare the programs resulting from the boundedand unbounded interpretations of the nondeterminism involved in the specificationof this problem.Example 8. The following multi-schema specifies a program which produces anatural number that is less than or equal to its input. n? and sc! are the input andoutput of the program, respectively 18:

M GetLE ∼= [n? ∈ N, sc! ∈ &N | true, sc! ≤ n?]To extract a program from M GetLE , we first use the function []D to transform

the multi-schema M GetLE into an ordinary schema in CZ:[M GetLE ]D ∼= [n? ∈ N, dsc ∈ PN | true,∀sc! ∈ N · sc! ∈ dsc ⇔ sc! ≤ n?]We have derived a program from a correctness proof of the above specification

in the Appendix A. The resulting program is:getLE = λα · natrec(α, (λc. if c = 0 then true else false, p),

λx.λg1.(λc. if c = s(x) then true else if c < s(x) then fst(g1)(c) else false, q)),where α is the counterpart of the variable n? in the type theoretical equivalent of[M GetLE ]D (see the Appendix A). p and q are the proof objects ofλc. if c = 0 then true else false andλc. if c = s(x) then true else if c < s(x) then fst(g1)(c) else false,

respectively. natrec is the symbol of recursion on natural numbers defined in sub-section 2.4. We present this definition again here:

18Although this program seems to be very simple and far from applications in the real world,it can simulate many of the situations in which we need to select an alternative from a given

set of possible choices. For example, in a multi programming environment, two or more entities(programs, processes, threads, or expressions) may want to use a common resource (e.g., a lock,an address space, a communication network, or a shared variable) at the same time [9, 56, 61]. Toresolve this competition, one of the entities must be selected nondeterministically. This situation

can be implemented by the current program where sc plays the role of the identifier of the entitythat must be selected from n + 1 given entities.


natrec(0, e, f) = enatrec(s(u), e, f) = f(u,natrec(u, e, f)),where s(u) is the successor of u.By the above discussion, we can conclude that for each α ∈ N , the program

getLE results in a boolean-valued function:getLE (0) = λc. if c = 0 then true else falsegetLE (s(x)) = λc. if c = s(x) then true else if c < s(x) then getLE (x)(c) else false

= λc. if c <= s(x) then true else falsegetLE (0) is a boolean-valued function whose output is true iff it is applied to 0.Also, for α > 0, getLE (α) is a boolean-valued function whose output is true iff itis applied to a value equal to or less than α. Thus, for each α ∈ N , the programgetLE produces a boolean-valued function whose result is true if and only if it isapplied to one of the possible outputs for α. In this way, we can obtain all possibleoutputs for each input. Of course, to gain the outputs, another process is requiredin which the resulting boolean-valued function should be applied to all elements ofits domain.

As it can be realized from example 8 and the proof of theorem 3.1.2, when weinterpret a multi-schema M Schema by the function []D, the resulting specificationyields a program which produces a boolean-valued function for each input. Thisis due to the fact that when we translate CZ specifications into type theoreticalones, instances of the power set constructor, used in [M Schema]D, are replaced byinstances of the type function space with the range Bool ; elements of such instancesare boolean-valued functions. By such functions in place, to gain all possible outputsfor each input, another process is required in which the boolean-valued functionsshould be applied to all elements of their domains. In the following paragraph,we show that for some of the multi-schemas that will be introduced later, we canextract simpler programs; for each input, these programs produce a single sequence,consisting of all possible outputs, instead of a boolean-valued function.

In the process of program development, it is recommended to replace instancesof the power set constructor by instances of the finite power set constructor, andthen refine these new constructs to finite sequences since developers concern onlythose elements of power sets which are finite [38, 57]. Using this idea, we proposeto use the interpretation function []D only for those multi-schemas containing atleast one nondeterministic variable whose set of possible values is infinite. If all thenondeterministic variables of a schema denote finite sets of values, we can replaceinstances of the power set constructor by instances of the type seq (see the typesystem of CZ in subsection 2.2.1). By definition, if the set of possible values ofa nondeterministic variable is infinite, then the resulting nondeterminism is calledunbounded ; otherwise, it is called bounded.

Now, let []BD be a function that interprets multi-schemas with bounded non-determinism in CZ. The next definition shows how this function maps the multi-schema M Schema, defined earlier in this subsection as the general form of multi-schemas, to an ordinary operation schema of CZ, provided that M Schema involvesbounded nondeterminism.

Definition 3.2.2. Suppose that all the nondeterministic variables of the multi-schema M Schema have bounded nondeterminism. The interpretation of M Schemain CZ is as follows:


if none of the variables of M Schema are nondeterministic, then [M Schema]BD =M Schema;

otherwise, [M Schema]BD ∼= [x1 ∈ A1, x2 ∈ A2, ..., xm ∈ Am, dvar ∈ seq(B1 ×B2 × ...×Bn) |φ,

∀(y1, y2, ..., yn) ∈ (B1×B2×...×Bn)·(y1, y2, ..., yn) ∈ dvar ⇔ψ]Like the function []D, []BD behaves as an identity function when applied to a multi-schema having no nondeterministic variable.

Theorem 3.2.3 shows that using the function []BD for interpreting the multi-schema M Schema, which involves bounded nondeterminism, and then applyingour program development method, we can extract a program which preserves theinitial nondeterminism of M Schema. This theorem also demonstrates that using[]BD, instead of []D, will lead to simpler programs.

Theorem 3.2.3. Suppose that all the nondeterministic variables of the multi-schema M Schema involve bounded nondeterminism. Let prog be the programthat is constructed after applying the function ξ to the schema [M Schema]BD

and then proving the correctness of the resulting type theoretical specification. Forall X1 ∈ A1, ..., Xm ∈ Am, if φ(X1, ..., Xm) = true, then prog, when applied toξ(X1), ..., ξ(Xm), produces a sequence dv : List(ξ(B1) ⊗ ... ⊗ ξ(Bn)) such that forall Y1 ∈ B1, ..., Yn ∈ Bn,

(ξ(Y1), ..., ξ(Yn)) ∈ dv iff [x1 7→ X1, ..., xm 7→ Xm, y1 7→ Y1, ..., yn 7→ Yn] ∈M Schema[/&],where M Schema[/&] denotes the result of removing all occurrences of & in M Schemaor rewriting M Schema as an ordinary operation schema.

Proof. we can use an approach similar to the one used for proving theorem 3.1.2.

Now we present the simple example 8 again here. However, for interpreting themulti-schema M GetLE , we use the function []BD instead of []D.Example 9. Consider the multi-schema M GetLE given in example 8. Since foreach n?, the set of possible values of sc! is finite, we can use the function []BD tointerpret M GetLE :

[M GetLE ]BD ∼= [n? ∈ N, dsc ∈ seqN | true,∀sc! ∈ N · sc! ∈ dsc ⇔ sc! ≤ n?]In the Appendix B, we have extracted the following program from the above

specification:getLE = λα · natrec(α, (〈0〉, p), λx.λg1.(〈s(x)〉_ fst(g1), q)),

Recall that _ is the concatenation operator on sequences. By the definition ofnatrec, we can conclude that for each α ∈ N , the program getLE results in asequence of natural numbers:

getLE (0) = 〈0〉getLE (s(x)) = 〈s(x)〉_ getLE (x)

For each α ∈ N , getLE produces the sequence 〈0, 1, ..., α〉 containing all possibleoutputs for α.Both the programs extracted from M GetLE in examples 3.2 and 3.3, provide uswith all possible outputs. However, the former produces a boolean-valued functionfor each input whereas the latter results in a single sequence consisting of all possibleoutputs.


In example 6, we extracted a program from the CZ specification of the sortingproblem. Although the initial specification is nondeterministic, the resulting pro-gram has a deterministic behavior and for each input sequence of ordered pairs,produces one and only one permutation in which the elements are in an increasingorder in terms of their second components. In the next example, we bring nonde-terminism explicitly into the specification of the sorting problem and construct anew program which produces all sorted permutations of the input sequence.Example 10. We replace the schema Sort , given in example 3, by a multi-schemaM Sort in which the output variable out ! is nondeterministic:

M Sort ∼= [Increasing ,Perm, in? ∈ seq(N ×N), out ! ∈ &seq(N ×N) |true, out ! ∈ increasing ∧ (in?, out !) ∈ perm]

Notice that the only difference between two schemas Sort and M Sort is thatthe output variable out ! is nondeterministic in the latter. Since the set of sortedpermutations of a sequence is finite, we can use the function []BD to translate themulti-schema M Sort into an ordinary schema in CZ:

[M Sort ]BD ∼= [Increasing ,Perm, in? ∈ seq(N ×N), dout ∈ seq seq(N ×N) |true,∀out ! ∈ seq(N × N) · out ! ∈ dout ⇔ (out ! ∈ increasing ∧ (in?, out !) ∈

perm)]In the Appendix C, we have derived the following program from a correctness

proof of the above specification:nsort = λα · lrec(α, (〈〈〉〉, r), λa · λx · λh1 · (T Insert(a, fst(h1)), q))

We first give an abstract illustration of the program. The readers interested in de-tails of the program can see them later in this example. This program is a recursivefunction that for each input sequence of ordered pairs, produces all permutations inwhich the elements are in the increasing order in terms of their second components:

nsort : List(N ⊗N) ⇒ List(List(N ⊗N))nsort(〈〉) = 〈〈〉〉nsort(h :: t) = T Insert(h, sort(t))

When the function T Insert applied to an ordered pair n of two natural numbersand a sequence r of sorted sequences, it produces a sequence s that includes allsorted permutations of 〈n〉 _ t for all t ∈ r and not anything else. Formally, thefollowing predicate holds:

(∀u ∈ s · ∃t ∈ r· u is a sorted permutation of 〈n〉_ t)∧(∀t ∈ r · ∀v ∈ (the set of sorted permutations of (〈n〉_ t)) · ∃u ∈ s · u = v)

When proving the correctness proof of the multi-schema M Sort , T Insert is con-structed as follows:

T Insert : (N ⊗N)⊗ List(List(N ⊗N)) ⇒ List(List(N ⊗N))T Insert(n, 〈〉) = 〈〉T Insert(n, h :: t) = D Insert(n, h) _ T Insert(n, t)

Recall the function Insert defined in example 6: for each ordered pair n of twonatural numbers and a sorted sequence s, Insert produces one and only one per-mutation of 〈n〉 _ s whose elements are in the increasing order in terms of theirsecond components. Unlike Insert , the function D Insert , used in the definition ofT Insert above, results in all permutations of 〈n〉 _ s whose elements are in theincreasing order in terms of their second components. The definition of D Insertis as follows:

D Insert : (N ⊗N)⊗ List(N ⊗N) ⇒ List(List(N ⊗N))D Insert(n, 〈〉) = 〈〈n〉〉


D Insert(n, h :: t) = if snd(n) < snd(h) then 〈〈n〉_ (h :: t)〉else if snd(n) > snd(h) then T Concate(h,D Insert(n, t))else 〈〈n〉_ (h :: t)〉_ T Concate(h,D Insert(n, t)),

where for an ordered pair n of two natural numbers and a sequence s whose elementsare themselves sequences, T Concate(n, s) is a sequence constructed by concate-nating n and elements of s: The elements of the resulting sequence are themselvessequences:

T Concate : (N ⊗N)⊗ List(List(N ⊗N)) ⇒ List(List(N ⊗N))T Concate(n, 〈〉) = 〈〉T Concate(n, h :: t) = 〈〈n〉_ h〉_ T Concate(n, t)According to the above discussion, when applied to a sequence α, the program

nsort produces a sequence consisting of all sorted permutations of α whereas theprogram sort , developed in example 6, produces one and only one sorted permuta-tion of α. This is due to the fact that when proving the correctness of [M Sort ]BD,we are to use functions such as D Insert instead of functions such as Insert . Thedifference between these two functions has been mentioned earlier.

A detailed description of the program nsort is as follows: r and q are the proofobjects of 〈〈〉〉 and T Insert(a, fst(h1)), respectively (see the Appendix C). lrec isthe symbol of recursion on lists defined in subsection 2.3. We give this definitionagain here:

lrec(〈〉, e, f) = elrec(h :: t, e, f) = f(h, t, lrec(t, e, f))Thus, the obtained program is a recursive function which results in 〈〈〉〉 for the in-

put α = 〈〉. In the recursive step, the program computes the output T Insert(h,nsort(t))for the input α = h :: t. The definition of T Insert is as follows:

T Insert = λn · λs · lrec(s, 〈〉, λh · λt · λr ·D Insert(n, h) _ r)In the above definition, we have used D Insert defined as follows:

D Insert = λn·λs·lrec(s, 〈〈n〉〉, λh·λt·λr·if snd(n) < snd(h) then 〈〈n〉_ (h :: t)〉else if snd(n) > snd(h) then T Concate(h, r)else〈〈n〉_ (h :: t)〉_ T Concate(h, r))

In the above definition, the function T Concate has been used whose definition isas follows:

T Concate = λn · λs · lrec(s, 〈〉, λh · λt · λr · 〈〈n〉_ h〉_ r)In this subsection, we have introduced a simple approach to specify nondetermin-ism explicitly in CZ. We have shown that using this approach, we can preserve theeffects of the initially specified nondeterminism in final programs. This approachdistinguishes between bounded and unbounded nondeterminism. In the next sub-section, we will extend the current approach to cover loose, strict, erratic, angelic,demonic, singular, and plural nondeterminism.

3.3. Modalities of nondeterminism. In addition to the bounded and unboundednondeterminism, some other modalities of nondeterminism have been so far men-tioned in the literature (for example, see [2, 13, 33, 41, 56, 60, 71]). We first give abrief overview of these modalities of nondeterminism:

• Erratic, angelic, and demonic nondeterminism: an erratic choice is made ina random manner. In other words, an erratic choice corresponds to selectingan alternative regardless of its effect upon establishing a certain postcon-dition, such as termination; angelic choices are made in a way that thepostcondition is established (if possible), while demonic nondeterminism is


resolved so as to avoid establishing the postcondition [11, 13]. For example,a program which implements a telephone exchange examines incoming linesand chooses one that has a defined input (a call coming in) and processesthat call. The choice here is angelic that means undefined-avoiding. Onthe other hand, a flight control system may use demonic choice: in a plane,two computers may calculate the same flight instruction. When both areworking fine, one of their outputs is chosen. If one of the computers stopsworking (making its output undefined), both computers shut themselvesdown (making their combined output undefined) and the pilot has to takeover.

The combination of demonic and angelic nondeterminism can model in-teractions in game-like situations, where a number of agents try to achieve(potentially conflicting) goals by taking turns in making choices. The agentor coalition whose goal we are focusing on is modelled as the angel and theassociated nondeterminism is angelic; the remaining agents are collectivelyconsidered as the demon [13, 41]. The two types of nondeterminism are alsouseful when modelling system-user situations, with the angel modelling theuser side and the demon the system side (because the demonic choice re-flects our uncertainty as to how the execution will proceed). We (the user)do not know which one of the alternatives will actually be chosen by thesystem. Thus, we need to guard against either choice if we want to becertain to achieve some specific final state with our program. Of course,system-user situations can be considered as special cases of game-like situ-ations since the execution of a program can be seen as a game between theuser (angel) and the system (demon).

• Strict and loose nondeterminism: in the strict interpretation of nonde-terminism, we are interested in extracting all possible forms of a speci-fied nondeterministic behavior. Such an interpretation is required to com-pare different implementations of an abstract specification, to preserve thespecified nondeterminism in final nondeterministic programs such as con-current/parallel systems or two player games, or to verify final programsagainst all possible behaviors. In the loose interpretation, however, theexistence of more than one behavior is regarded in the specification stage,but the final implementation is itself deterministic. For example, in thesorting problem, we expect one and only one sorted permutation of theinput sequence when the final program executes. In this case, we have anondeterministic specification whereas the final program is itself determin-istic. This coincides with the loose interpretation of nondeterminism. Ofcourse, in some situations, we may be interested in comparing all sortedpermutations. In these situations, we must use the strict interpretation ofnondeterminism, but to guarantee the deterministic behavior of the finalexecution, we must also use the singular semantics of nondeterminism (Thismodality of nondeterminism will be defined later).

• Bounded and unbounded nondeterminism: if the set of possible choices isan infinite set, then the resulting nondeterminism is unbounded; otherwise,it is bounded.


• Singular and plural nondeterminism: singular and plural nondeterminismcoincide with call-by-value and call-by-name semantics in programming lan-guages, respectively [71]. In the plural semantics, decisions on a same non-deterministic construct are made independently. Thus, they may lead todifferent choices. However, in the singular semantics, same decision is al-ways made in different places with the same nondeterministic construct[70]. Fairness issues can also be discussed in the plural semantics [56]. Forexample, we would expect the drinks machine (see subsection 1.1) to befair in the sense that pressing a button for Either does not always poura cup of tea. A lottery machine that chooses who wins the prize shouldbe more than fair. It should be probabilistically fair and give every ticketthe same chance of winning. An important application of the fair nonde-terminism is to implement concurrent systems, where the operations of anumber of processes are interleaved, and thus must be scheduled by fairscheduling algorithms. For example, consider the CZ specification of aconcurrent database management system (see example 4). If the nondeter-ministic schema AcquireLock will not yield a sub-program that makes itschoices fairly, then the operations of some transactions may be discardedforever.

It seems appropriate to clarify the difference between the loose nonde-terminism and the singular one: in the loose nondeterminism, we are in-terested in extracting one and only one implementation or behavior amongthose specified in the initial specification; no alternative has priority overthe others; indeed, we are satisfied with any of the alternatives. On theother hand, by the singular semantics, we may need to produce and thencompare all possible outputs (the strict nondeterminism instead of the looseone); however, when we select the preferred alternative, we fix it for nextselections. The reason for producing all possible outputs is that the choiceis made in terms of implementation considerations or the programmer inter-ests; such criteria cannot be evaluated in the specification phase, and thusmust be delegated to the implementation phase. Therefore, in contrast tothe loose semantics, in the singular one, there may be certain priorities,but they can be evaluated in the implementation phase; in this phase, how-ever, any of the alternatives taking priority over the others is fixed for nextselections.

In the previous subsection, to specify nondeterministic operations in CZ, weintroduced the notion of multi-schema as an operation schema that may involvenondeterministic variables. We used the operator & to declare nondeterministicvariables. To consider modalities of nondeterminism, we replace this operator bya parametric one &(bu,gp,sl,ead). Like &, the operator &(bu,gp,sl,ead) promotes theordinary (single-valued) nature of the declared variable to its nondeterministic (set-valued) nature, but the subscript of &(bu,gp,sl,ead) is used to distinguish differentmodalities of nondeterminism.

The first component of (bu, gp, sl , ead), bu, denotes bounded or unbounded non-determinism and is instantiated with either b (bounded) or u (unbounded). Thesecond component, gp, indicates singular or plural nondeterminism and is evalu-ated to either g (singular) or p (plural). The third component, sl , corresponds tothe strict or the loose semantics of nondeterminism; one of the values s (strict)


or l (loose) can be assigned to sl . Finally, the fourth component, ead , is used todistinguish erratic, angelic, and demonic nondeterminism, and one of the values e(erratic), a (angelic), or d (demonic) is used in place of it. We can consider thebounded interpretation of nondeterminism as a special case of the unbounded one.Nevertheless, as we have shown in the previous subsection, if the set of possiblechoices is finite, it is more appropriate to specify bounded nondeterminism insteadof the unbounded one since it results in simpler programs.

Before interpreting &(bu,gp,sl,ead), we replace the nondeterministic constructndvar ∈ &Type,

which was presented in the previous subsection to declare a nondeterministic vari-able, by the following one:

ndvar ∈ &(bu,gp,sl,ead)Type,where bu, gp, sl , and ead can be instantiated with any of the elements of the setsb, u, g, p, s, l, and e, a, d, respectively. Also, we replace the type inferencerule

ndvar : &Typendvar : Type

by the following rule:ndvar : &(bu,gp,sl,ead)Type

ndvar : Type

Now we proceed by giving a semantics for the parametric operator &(bu,gp,sl,ead)

in CZ. For convenience, we assume that all the nondeterministic variables, declaredin a multi-schema, denote the same interpretation of nondeterminism. For example,if a nondeterministic variable involves angelic nondeterminism, others cannot in-volve demonic or erratic nondeterminism, or if a nondeterministic variable denotesstrict nondeterminism, others cannot denote loose nondeterminism. To interpretthe parametric operator &(bu,gp,sl,ead), we first give the semantics for different val-ues of the component ead and replace this component by i that means an interpretedcomponent (Thus, we must add i to all the sets b, u, g, p, s, l, and e, a, dintroduced in the previous paragraph when we wanted to define a type inferencerule for &(bu,gp,sl,ead)). Then any of the possible values of sl is interpreted, andthus sl is replaced by i. Finally, we interpret both the components bu and gp si-multaneously, using the mapping functions []D and []BD, defined in subsection 3.2,and two new functions []PD and []PBD which will be introduced in subsection 3.3.3.

Using the above mentioned, step by step approach, in the following subsections,we interpret the operator &(bu,gp,sl,ead) in CZ.

3.3.1. Interpretation of erratic, angelic, and demonic nondeterminism. As we havestated earlier, if a choice is to be made in favor of establishing a postcondition q,we should have angelic choice semantics. Demonic choice, however, is resolved soas to avoid establishing the postcondition. On the other hand, when we use thecombination of angelic and demonic nondeterminism for modelling interactions ingame-like situations, the postcondition q is established if the angel can make itschoices in a way that q is reached, regardless of how the demon makes its choices[13]. In both the above mentioned applications (either using only one of the angelicand demonic nondeterminism or using the combination of them), we can consider


angelic and demonic choices as the best and the worst choices with respect to apostcondition q, respectively.

To implement the above idea, we assume that some score is associated to eachalternative. By an angelic (demonic) choice, we choose one of the alternativeshaving the highest (lowest) score. By an erratic choice, however, we choose one ofthe alternatives regardless of the scores. Example 11 describes a two-player gameand shows how scores can be assigned to alternatives.Example 11. In the Nim game [13], two players take turns in removing one or twomatches from a pile (of x matches). The player to remove the last match loses thegame. The first player is considered as the angel and the other one as the demon.Provided that initially xmod 3 6= 1, the angel can win the game by making surethat xmod 3 = 1 after each of its turns. Therefore, in each turn of the angel, ifxmod 3 = 0 (xmod 3 = 2), it must remove two matches (one match) from the pile.Now we can define a score function sco over the domain 1, 2, which is the set ofpossible choices of the angel:

sco(n) = |n− (xmod 3)| n ∈ 1, 2if xmod 3 = 0, then sco(2) ≥ sco(1); in this case, the alternative 2 (removing twomatches) is the preferred choice. In the other case (xmod 3 = 2), sco(1) ≥ sco(2),and thus it is more appropriate to remove one match from the pile.

Example 11 shows how we can define scores in game-like situations where weuse the combination of angelic and demonic nondeterminism. A similar approachcan be adopted when we use only one of the angelic and demonic nondeterminismfor achieving or avoiding a certain postcondition q (such as termination or non-abortion): we can assign the score one to alternatives satisfying q and the scorezero to alternatives that do not satisfy q. For example, in a program implementinga telephone exchange, we assign the score one to lines that have an incoming calland the score zero to other lines. Similarly, in a flight control system, we assign thescore zero to the undefined outputs and the score one to the others. This solutioncan be used for a well known application of angelic and demonic nondeterminismwhere the non-abortion of programs is considered as the criterion for distinguishingangelic and demonic choices: in such situations, we can treat the abortion of aprogram as an ordinary output and assign the score zero to this output and thescore one to others. For example, consider the following specification:

S1∼= [a? ∈ N, b! ∈ N | a? > 0, b! = a?− 1]

S2∼= [a? ∈ N, b! ∈ N | a? > 1, b! = a?− 2]

S ∼= S1 ∨c S2

For the input a? = 1, the program satisfying S1 returns 0 while the programsatisfying S2 aborts. By the angelic nondeterminism, the program satisfying S mustbehave as the program satisfying S1 . By the demonic nondeterminism, however,this program must behave as the program satisfying S2 . To implement such abehavior, we must first rewrite the above specification by a new one in which theabortion of programs is considered as an ordinary output:

S1∼= [a? ∈ N, b! ∈ N |true, (a? > 0 ∧ b! = a?− 1) ∨ (a? = 0 ∧ b! = abort)]

S2∼= [a? ∈ N, b! ∈ N | true, (a? > 1 ∧ b! = a?− 2) ∨ (a? ≤ 1 ∧ b! = abort)]

S ∼= S1∨cS2∼= [a? ∈ N, b! ∈ N |true, (a? > 0∧b! = a?−1)∨(a? = 0∧b! = abort)∨

(a? > 1 ∧ b! = a?− 2) ∨ (a? ≤ 1 ∧ b! = abort)]Now we assign the score zero to the value abort and the score one to other values.Consider the behavior of the program that satisfies S. When this program is applied


to the input a? = 1, it can select one of the alternatives 0 with the score one andabort with the score zero; by the angelic nondeterminism, it selects the former, andby the demonic nondeterminism, it selects the latter. This result is similar to thatof many literature (See [18], [33], [53], [56], [60], [64], and [72], for example).

Now we interpret the angelic and demonic nondeterminism according to theabove proposed solution. Suppose that the general form of multi-schemas, definedin subsection 3.2, is modified as follows:

M Schema ∼= [x1 ∈ A1, x2 ∈ A2, ..., xm ∈ Am, y1 ∈ B1, y2 ∈ B2, ..., yd ∈ Bd,yd+1 ∈ &(bu,gp,sl,ead)Bd+1, yd+2 ∈ &(bu,gp,sl,ead)Bd+2, ..., yn ∈ &(bu,gp,sl,ead)Bn |φ, ψ],

where some of the after state and output variables of M Schema, i.e. yd+1, yd+2, ..., yn,are nondeterministic. As it has been mentioned earlier, we assume that all thesenondeterministic variables denote the same interpretation of nondeterminism. Wedefine a function []ead which maps the multi-schema M Schema to a multi-schemainvolving some variables declared by &(bu,gp,sl,i).

Definition 3.3.1. If M Schema involves no nondeterministic variable, then [M Schema]ead =M Schema; otherwise, if M Schema involves some nondeterministic variables de-clared by

(1) &(bu,gp,sl,a), then [M Schema]ead is defined as follows:[M Schema]ead ∼= [x1 ∈ A1, x2 ∈ A2, ..., xm ∈ Am,

ay1 ∈ &(bu,gp,sl,i)B1, ay2 ∈ &(bu,gp,sl,i)B2, ..., ayn ∈ &(bu,gp,sl,i)Bn |φ,ψ[ay1/y1][ay2/y2]...[ayn/yn]∧∀(y1, y2, ..., yn) ∈ (B1 × B2 × ... × Bn) · ψ ⇒ sco((y1, y2, ..., yn)) ≤

sco((ay1, ay2, ..., ayn))](2) &(bu,gp,sl,d), then [M Schema]ead is defined as follows:

[M Schema]ead ∼= [x1 ∈ A1, x2 ∈ A2, ..., xm ∈ Am,dy1 ∈ &(bu,gp,sl,i)B1, dy2 ∈ &(bu,gp,sl,i)B2, ..., dyn ∈ &(bu,gp,sl,i)Bn |φ,ψ[dy1/y1][dy2/y2]...[dyn/yn]∧∀(y1, y2, ..., yn) ∈ (B1 × B2 × ... × Bn) · ψ ⇒ sco((y1, y2, ..., yn)) ≥

sco((dy1, dy2, ..., dyn))](3) &(bu,gp,sl,e), then we can easily map M Schema to [M Schema]ead by re-

placing instances of &(bu,gp,sl,e) by instances of &(bu,gp,sl,i):[M Schema]ead ∼= [x1 ∈ A1, x2 ∈ A2, ..., xm ∈ Am, y1 ∈ B1, y2 ∈

B2, ..., yd ∈ Bd,yd+1 ∈ &(bu,gp,sl,i)Bd+1, yd+2 ∈ &(bu,gp,sl,i)Bd+2, ..., yn ∈

&(bu,gp,sl,i)Bn |φ, ψ],

The above interpretation is based on the fact that when making an erraticchoice, we choose one of the alternatives without regarding any of theirparticular properties.

As before, in the above definition, we considered ordinary operation schemas asspecial cases of multi-schemas involving no nondeterministic variable. Therefore,the function []ead behaves as an identity function when applied to an ordinary op-eration schema. The function sco is assumed to return the score of its input. Thus,two combinations (ay1, ay2, ..., ayn) and (dy1, dy2, ..., dyn) of output variables (seedefinition 3.3.1) are choices having the highest and the lowest score, respectively.


Since it is possible that more than one choice have the highest or the lowest score,all variables ay1, ay2, ..., ayn, dy1, dy2, ...,dyn have still the nondeterministic nature and are declared as nondeterministicvariables by using the operator &(bu,gp,sl,i).

If we assume that sco has an intensional definition (for example, see the functionsco in example 11 that has an intensional definition), we can show the conservative-ness of our approach for modelling angelic and demonic nondeterminism. Never-theless, when using angelic and demonic nondeterminism in our specifications, wewant to abstract away from details of how a particular postcondition establishing(or postcondition avoiding) strategy is implemented. In other words, in the speci-fication phase, the writer of a specification is only interested in specifying his/herintention to establish or avoid a certain postcondition q and does not want to knowthe way in which the postcondition is established or avoided; this issue must bedelegated to the implementation phase. Thus, we can treat sco as an abstractfunction in the specification phase and guarantee that our constructive approachfor program development results in programs which select alternatives that havethe highest (or the lowest) score; the scores themselves can be determined in theimplementation phase. For example, a program that satisfies a specification of thetelephone exchange system is guaranteed to select a line having the highest score.In the implementation phase, we assign the score one to lines that have an incomingcall and the score zero to other lines. On the other hand, a program that satisfies aspecification of the flight control system is guaranteed to select an output with thelowest score. In the implementation phase, we assign the score one to the definedoutputs and the score zero to the undefined ones.

For the game-like situations, we offer a solution to determine the function scoin the implementation phase that leads to implementing a winning strategy forthe angel (when such a strategy exists). Our approach is similar to that of [13]which deals with angelic nondeterminism in a refinement calculus: by the winningstrategy, we are given a precondition p and a postcondition q for the angelic choice(For instance, in the Nim game, p ≡ xmod 3 6= 1 and q ≡ xmod 3 = 1). The angelmust select one alternative from n alternatives c1, c2, ..., cn so that the execution ofthe program is transformed from a state where p holds to a state where q holds.We show this goal as follows:p[c := c1, c := c2, ..., c := cn]q,

where c is the (angelic) choice variable that can be instantiated with any of theelements of the set c1, c2, ..., cn.

Now we introduce the following rule which enables us to derive the function sco:

r1 ∧ p[c := c1]q r2 ∧ p[c := c2]q ... rn ∧ p[c := cn]qp[c := c1, c := c2, ..., c := cn]q

The predicates r1, r2, ..., and rn describe the winning strategy for the angel bypartitioning the precondition p into n parts depending on which of the assignmentsc := c1, c := c2, ..., or c := cn can establish q. It can be shown that the existenceof partitioning predicates r1, r2, ..., and rn is guaranteed when the angel has awinning strategy. Discovering such predicates can be reduced to calculating weakest


preconditions 19: We determine r1 as (c := c1).q since the other assignments needto be done only when the first one fails. By a similar reasoning, for 2 ≤ i ≤ n, thefollowing equality holds:ri ≡ ¬(c := c1).q ∧ ... ∧ ¬(c := ci−1).q ∧ (c := ci).q

Now we can define sco as follows:For 1 ≤ i ≤ n, if ri = true then sco(ci) = 1 else sco(ci) = 0

For instance, in example 11, for two alternatives c1 = 1 and c2 = 2, we haver1 ≡ (xmod 3 = 2) and r2 ≡ (xmod 3 = 0), respectively. In this case, sco is thusdefined as follows:

if (xmod 3 = 2) then sco(1) = 1 else sco(1) = 0if (xmod 3 = 0) then sco(2) = 1 else sco(2) = 0In this subsection, we have interpreted the fourth component of the subscript of

&(bu,gp,sl,ead). In the next subsection, we concentrate on the third component, i.e.sl .

3.3.2. Interpretation of strict and loose nondeterminism. In definition 3.3.1, wedefined the function []ead for interpreting the fourth component of the subscriptof &(bu,gp,sl,ead). After using []ead, we have a multi-schema that either involvesno nondeterministic variable or has some nondeterministic variables declared by&(bu,gp,sl,i). In this subsection, we introduce a mapping function []sl which in-terprets the third component of (bu, gp, sl , i). For ordinary operation schemas,this function behaves as an identity function. In other words, for a multi-schemaM Schema that has no nondeterministic variable, [M Schema]sl is equal to M Schemaitself.

Now we explore the result of []sl when applied to a multi-schema that involvessome nondeterministic variables declared by &(bu,gp,sl,i). Consider first the caseof sl = s: both the mapping functions []D and []BD, proposed in subsection 3.2,match the strict interpretation of nondeterminism since they yield programs whichproduce all possible outputs for each input (see theorems 3.1.2 and 3.2.3). Wewill use these functions in subsection 3.3.4 to do the last step of the interpretationof multi-schemas. Thus, if a multi-schema M Schema involves a nondeterministicvariable declared by &(bu,gp,s,i), we are to do nothing; it is sufficient to replace&(bu,gp,s,i) by &(bu,gp,i,i) in order to map M Schema to [M Schema]sl; the laststep of the interpretation will itself implement the strict semantics.

In the case of sl = l, we are to do a simple task again: as shown earlier, con-structed programs from implicitly nondeterministic specifications produce only asingle output for each input. Therefore, the loose interpretation of nondeterminismcan automatically be achieved when we do not specify nondeterminism explicitly.Thus, if a multi-schema M Schema involves a nondeterministic variable declared by&(bu,gp,l,i), we can map M Schema to [M Schema]sl by rewriting M Schema as anordinary operation schema or removing all occurrences of the operator &(bu,gp,l,i)

from M Schema.The next definition formalizes the above discussion.

Definition 3.3.2. Let M Schema be a multi-schema that involves zero or morenondeterministic variables declared by the nondeterministic construct &(bu,gp,sl,i).

19For a statement S and a postcondition q, if σ is a state, then the weakest precondition of S,

that we show as S.q, holds in σ if and only if the execution of S from the state σ is guaranteed toterminate in a final state where q holds


(1) If M Schema involves no nondeterministic variable, then [M Schema]sl =M Schema,

(2) If M Schema involves some nondeterministic variables declared by &(bu,gp,s,i),then

[M Schema]sl = M Schema[&(bu,gp,i,i)/&(bu,gp,s,i)],(3) If M Schema involves some nondeterministic variables declared by &(bu,gp,l,i),

then[M Schema]sl = M Schema[/&(bu,gp,l,i)],

where M Schema[/&(bu,gp,l,i)] denotes the result of removing all occur-rences of &(bu,gp,l,i) in M Schema.

In the next subsection, we will focus upon the second component of the subscriptof &(bu,gp,sl,ead), i.e. gp.

3.3.3. Interpretation of singular and plural nondeterminism. We have two alterna-tive ways to explore the semantics of the singular and plural choices in CZ specifi-cations. At first, we give the interpretation of these modalities of nondeterminismin terms of various occurrences of a nondeterministic variable in a schema: if all oc-currences of a nondeterministic variable are evaluated to a single value, we have thesingular semantics; otherwise, we have the plural one. To clarify this statement, wefocus on the following simple schema, an extension of the schema M GetLE givenin example 8:

M GetLE23 ∼= [n? ∈ N, sc!, a!, b! ∈ &N | true, sc! ≤ n?∧a! = 2∗sc!∧b! = 3∗sc!]The above multi-schema specifies a program which produces a natural number sc!that is less than or equal to its input, i.e. n?. It also produces two other outputsa! and b! which are equal to 2 ∗ sc! and 3 ∗ sc!, respectively. After interpretingM GetLE23 by the function []BD (see definition 3.2.2), the following schema isobtained:

[M GetLE23 ]BD ∼= [n? ∈ N, dscab ∈ seq (N ×N ×N) | true,∀(sc, a, b) ∈ (N ×N ×N) · (sc, a, b) ∈ dscab ⇔ (sc ≤ n?∧a = 2∗ sc ∧ b =

3 ∗ sc)]For n? = in, the resulting program from the above specification produces a sequenceconsisting of in + 1 tuples (sc, 2sc, 3sc), where sc ranges from 0 to in. Notice thateach tuple is related to one of the possible values of the nondeterministic variablesc!. Now we can consider any of these tuples as the final output: if we select thevalue Selsc for sc!, we will be forced to select the values 2 ∗ Selsc and 3 ∗ Selscfor a! and b!, respectively. This means that all occurrences of sc! are evaluatedto a single value, i.e. Selsc. In other words, we have implemented the singularinterpretation of nondeterminism. This is due to the fact that when we interpretthe notion of multi-schemas by the functions []D and []BD, we combine all previousafter state and output variables in a new variable using the cartesian product oftheir types. In this way, the relationship between these variables is preserved afterthe interpretation.

Therefore, to achieve the plural interpretation of nondeterminism, it seems suf-ficient to promote each nondeterministic variable to a distinct set (in unboundednondeterminism) or sequence (in bounded nondeterminism). By this modification,the interpretation of M GetLE23 in CZ is the following schema:

[n? ∈ N, dsc, da, db ∈ seq N | true,∀sc, a, b ∈ N · (sc ∈ dsc ∧ a ∈ da ∧ b ∈ db) ⇔ (sc ≤ n? ∧ a = 2 ∗ sc ∧ b =

3 ∗ sc)]


In the above schema, the possible values of sc!, a!, and b! are specified in threedistinct sequences dsc, da, and db, respectively. For example, for n? = 2, the threedistinct sequences 〈0, 1, 2〉, 〈0, 2, 4〉, and 〈0, 3, 6〉 are produced as possible values ofsc!, a!, and b!, respectively. In the final program, we may select three values 0, 2,and 6 as the preferred values for sc!, a!, and b!, respectively. In other words, thevariable sc! is not evaluated to a same value in each of its occurrences in the initialschema (sc! = 0 in sc! ≤ n?, sc! = 1 in a! = 2 ∗ sc!, and sc! = 2 in b! = 3 ∗ sc!).Such a behavior corresponds to the plural interpretation of nondeterminism. Bythis interpretation, the writer of the specification wants to specify a! as twice anatural number which is less than or equal to n? and b! as the multiplication of 3and a natural number that is less than or equal to n?; there is no need to have anatural number sc! ≤ n? such that a! = 2 ∗ sc! and b! = 3 ∗ sc! simultaneously.

It seems that the above mentioned approach to interpret plural nondeterminismleads to strange consequences in some situations. For example, suppose that wehave the following multi-schema:

M GetSumBelow4 ∼= [a!, b!, sum! ∈ &N | true, a! > 0 ∧ b! > 0 ∧ (a! + b!) <4 ∧ sum! = (a! + b!)]using the plural interpretation of nondeterminism, M GetSumBelow4 is interpretedin CZ as follows:

[da, db, dsum ∈ seq N | true,∀a, b, sum ∈ N ·(a ∈ da ∧ b ∈ db ∧ sum ∈ dsum) ⇔ (a > 0 ∧ b > 0 ∧ (a+ b) < 4 ∧ sum =

(a+ b))]The above schema specifies three distinct sequences 〈1, 2〉, 〈1, 2〉, and 〈2, 3〉 as thepossible values of a!, b!, and sum!, respectively. Now, in the final program, wemay simultaneously select 2 as the preferred value for both a! and b!. It seemsthat, in this way, we have assigned 2 + 2 = 4 to sum! whereas in the specificationphase, we have emphasized that sum! cannot be greater than 3. Do we encountera contradiction? The answer is No. This consequence is not a contradiction; it isonly counter-intuitive. The reason for this is that although we can simultaneouslyselect 2 as the preferred value for both a! and b!, we are only allowed to select avalue for sum! from the sequence 〈2, 3〉; in either case, sum! shall be less than 4.Such a scenario does not conflict with the intention of who has written the schemaM GetSumBelow4 and has been interested in plural nondeterminism. If the writerof this specification has used plural nondeterminism, s/he requires a! and b! as twopositive natural numbers such that when each of them is added by another positivenatural number the result is a number less than 4. Moreover, s/he requires sum!as a positive natural number which is less than 4. S/he him/herself has not forcedany relationship among various evaluations of a!, b!, and sum!.

Now we formalize our current idea to interpret singular and plural nondetermin-ism. According to this idea, we can assign the two functions []D and []BD defined insubsection 3.2 for interpreting only those multi-schemas involving singular nonde-terminism; to consider the plural semantics of nondeterminism, we define two newmapping functions. Recall the general form of multi-schemas given in subsection3.2:

M Schema ∼= [x1 ∈ A1, x2 ∈ A2, ..., xm ∈ Am, y1 ∈ B1, y2 ∈ B2, ..., yd ∈ Bd,yd+1 ∈ &Bd+1, yd+2 ∈ &Bd+2, ..., yn ∈ &Bn |φ, ψ]


Now we define a function []PD that is similar to []D and is intended to interpretmulti-schemas in CZ; unlike []D, the new function []PD interprets multi-schemasaccording to the plural semantics of nondeterminism.

Definition 3.3.3. According to the unbounded and plural semantics of nondeter-minism, the interpretation of the multi-schema M Schema in CZ is as follows:

if none of the variables of M Schema are nondeterministic, then [M Schema]PD =M Schema;

otherwise, [M Schema]PD ∼= [x1 ∈ A1, x2 ∈ A2, ..., xm ∈ Am,dy1 ∈ P B1, dy2 ∈ P B2, ..., dyn ∈ P Bn, |φ,∀y1 ∈ B1, y2 ∈ B2, ..., yd ∈ Bd · (y1 ∈ dy1 ∧ y2 ∈ dy2 ∧ ... ∧ yn ∈

dyn) ⇔ ψ]

Like the function []D, []PD behaves as an identity function when applied to a multi-schema involving no nondeterministic variable. Otherwise, it promotes each afterstate and output variable to a distinct, maximal set of values which satisfy thepostcondition of the schema.

In the next definition, a similar approach is followed to define a function []PBD

which interprets multi-schemas with bounded and plural semantics.

Definition 3.3.4. According to the bounded and plural semantics of nondeter-minism, the interpretation of the multi-schema M Schema in CZ is as follows:

if none of the variables of M Schema are nondeterministic, then [M Schema]PBD =M Schema;

otherwise, [M Schema]PBD ∼= [x1 ∈ A1, x2 ∈ A2, ..., xm ∈ Am,dy1 ∈ seq B1, dy2 ∈ seq B2, ..., dyn ∈ seq Bn, |φ,∀y1 ∈ B1, y2 ∈ B2, ..., yd ∈ Bd · (y1 ∈ dy1 ∧ y2 ∈ dy2 ∧ ... ∧ yn ∈

dyn) ⇔ ψ]

In the next subsection, using four mapping functions []D, []BD, []PD, and []PBD,we will interpret both the first and the second components of (bu, gp, sl , ead) si-multaneously, but before ending this subsection, we should say that our approachto interpret singular and plural semantics has been based on various occurrences ofa nondeterministic variable in a multi-schema. However, we can investigate the se-mantics of these modalities of nondeterminism from another point of view: we canimagine that an operation schema leads to a sub-routine in the final program whichmay be called more than once in an actual execution. This may be due to either thevarious occurrences of the schema in the specification or the presence of the schemain an iteration construct. For example, consider the schema AcquireLock given inexample 4. The corresponding sub-routine of this schema will frequently be calledin the final execution for assigning locks to requesting transactions. Various calls ofa sub-routine lead to various evaluations of the nondeterministic variables existingin the sub-routine or indeed the initial schema.

Now we can define new semantics for singular and plural nondeterminism basedupon the above discussion: by the plural semantics of nondeterminism, in vari-ous calls of a sub-routine, we want a nondeterministic variable to be evaluated todifferent values. For example, in various calls of the sub-routine extracted fromAcquireLock , we expect that it does not select a same transaction among thosewhich ask for a lock and do not conflict with the set of current locks. Moreover, weexpect that this sub-routine has a fair behavior and does not discard a transactionforever. On the other hand, by the singular semantics of nondeterminism, we want


various calls of a subroutine to have a fixed behavior. For example, consider our CZspecification of the sorting problem: we specify and produce all possible behaviorsof this problem. However, in the implementation phase, according to the imple-mentation considerations, such as performance, we may prefer a specific behaviorand want this behavior to occur in all calls of the sub-routine.

The recent interpretation of the singular and plural nondeterminism can be onlyimplemented in the execution phase. In other words, only when the program isexecuted, we can keep track of previous choices, and thus make decisions the sameas the previous ones or different from them. To achieve this goal, the followingfacilities are required:

• The framework used for the formal program development must provide thefinal program with all possible outputs for each input.

• The framework used for the formal program development must notify thefinal program of the specified modality of nondeterminism.

• The target programming language should contain nondeterministic con-structs which allow the final program to implement singular and plural(and even fair) nondeterminism among the supplied alternatives 20.

Fortunately, in our approach to interpret strict nondeterminism, we develop afunctional program that is provided with a collection of all possible outputs foreach input. Now, by the above discussion, we can think of a target functionallanguage which contains nondeterministic constructs implementing singular andplural nondeterminism. The introduction of nondeterministic constructs to func-tional languages and λ-calculus has a long tradition21 [56]. A survey of attemptsto add nondeterminism to λ-calculus and functional languages can be found in[18], [56], and [60]. We give a brief overview of such activities here. in [44], Mc-Carthy has introduced the operator amb to λ-calculus which nondeterministicallychooses between two values. amb behaves according to the angelic interpretationof nondeterminism: between two operands, it selects one that is defined. Hughesand Moran [35] have defined an evaluation semantics for McCarthy’s angelic choicewhich incorporates a fair scheduler to limit the number of selecting one operandwithout the other operand being chosen. In [60], the nondeterministic constructx ::= exp1 u exp2 , which nondeterministically assigns one of the expressions exp1

and exp2 to x, has been added to a typical functional language. Then, erratic,angelic, and demonic interpretations of this construct have been given in termsof the program termination and based on the Plotkin, Hoare, and Smyth powerdomains 22, respectively. Also, both the singular and plural interpretations of theconstruct x ::= exp1 u exp2 have been presented in [60]. In [18], the type free λ-calculus was enriched with singular, plural, angelic, and demonic nondeterminism.The convergence of computations has been the criterion for distinguishing betweenangelic and demonic nondeterminism. In [56], unbounded, erratic, plural, and fairnondeterminism have been studied in λ-calculus.

20For example, we can think of a programming language that always preserve a history of

alternatives that it has so far chosen. In each time, it can then make its choices according to thecurrent history and the initially specified modality of nondeterminism (singular, plural, or fair).

21The extension of functional languages to cover nondeterministic constructs gives rise to someproblems originating from the introduction of non functional features to the functional framework.

To see some problems, refer to [18].22In many literature, power domains have been used to define the semantics of functional

programming languages [59]. For a detailed description of these domains, see [59].


By the above discussion, it seems that we only require in somehow to notify finalprograms of the specified modality of nondeterminism. This forces us to introducesome new nondeterministic constructs in CZ and type theory which distinguishbetween singular and plural nondeterminism. Moreover, the existing interpreta-tion of CZ in type theory must be extended to translate the new nondeterministicconstructs of CZ into their type theoretical counterparts. Finally, some new rulesmust be added to type theory which help us to extract programs from nondeter-ministic type theoretical specifications that contain the initial specified modality ofnondeterminism. Introducing such facilities to CZ and type theory and studyingthe ways in which functional programming languages implement singular, plural,and fair nondeterminism can be considered as a direction for future research.

From this point, we use the first proposed semantics for interpreting singular andplural nondeterminism which is based on various occurrences of a nondeterministicvariable in a multi-schema. Therefore, in the next subsection, using four mappingfunctions []D, []BD, []PD, and []PBD, we will interpret both the first and the secondcomponents of (bu, gp, sl , ead) simultaneously.

3.3.4. Interpretation of bounded and unbounded nondeterminism. After interpret-ing the various values of the third and the fourth components of (bu, gp, sl , ead),we have now either an ordinary schema or a multi-schema involving some nondeter-ministic variables declared by &(bu,gp,i,i). The former case occurs when the initialmulti-schema either has no nondeterministic variable or has some nondeterministicvariables with loose nondeterminism (sl = l); the latter case, however, occurs whenthe initial multi-schema has some nondeterministic variables with strict nondeter-minism (sl = s). Now, let []bu be a function that maps the resulting schema in eachof the above mentioned forms to ordinary schemas in CZ. Obviously, if the resultingschema is a multi-schema with no nondeterministic variable, []bu maps this schemato itself.

Definition 3.3.5 shows how []bu interprets the resulting schema when it involvesa nondeterministic variable declared by &(bu,gp,i,i). In this definition, we use fourmapping functions []D, []BD, []PD, and []PBD that have been introduced earlier.

Definition 3.3.5. If a multi-schema M Schema involves some nondeterministicvariables declared by

(1) &(u,g,i,i), then the following equality holds:[M Schema]bu = [M Schema[&/&(u,g,i,i)]]D

(2) &(b,g,i,i), then the following equality holds:[M Schema]bu = [M Schema[&/&(b,g,i,i)]]BD

(3) &(u,p,i,i), then the following equality holds:[M Schema]bu = [M Schema[&/&(u,p,i,i)]]PD

(4) &(b,p,i,i), then the following equality holds:[M Schema]bu = [M Schema[&/&(b,p,i,i)]]PBD

Recall that []D, []BD, []PD, and []PBD have been defined to interpret unboundedand singular, bounded and singular, unbounded and plural, and finally boundedand plural interpretations of nondeterminism, respectively.

Theorem 3.3.6 shows that using the functions []ead, []sl, and []bu in turn for in-terpreting a multi-schema and then applying our program development method,


we can extract a program which behaves according to the modalities of nondeter-minism involved in the initial schema. In this theorem, we use the multi-schemaM Schema, defined earlier in this subsection as the general form of multi-schemas:

M Schema ∼= [x1 ∈ A1, x2 ∈ A2, ..., xm ∈ Am, y1 ∈ B1, y2 ∈ B2, ..., yd ∈ Bd,yd+1 ∈ &(bu,gp,sl,ead)Bd+1, yd+2 ∈ &(bu,gp,sl,ead)Bd+2, ..., yn ∈ &(bu,gp,sl,ead)Bn |φ, ψ],

where some of the after state and output variables of M Schema, i.e. yd+1, yd+2, ..., yn,are nondeterministic.

Theorem 3.3.6. Let prog be the program that is constructed after applying thefunction ξ to the schema [[[M Schema]ead]sl]bu and then proving the correctnessof the resulting type theoretical specification. For all X1 ∈ A1, ..., Xm ∈ Am, ifφ(X1, ..., Xm) = true, then

(1) if M Schema has no nondeterministic variable or has some nondeterminis-tic variables declared by &(bu,gp,l,ead), then prog, when applied to ξ(X1), ..., ξ(Xm),produces one and only one valuation ξ(Y1), ..., ξ(Yn) of output variables suchthat(a) IsBinding(Y1, ..., Yn) if M Schema has no nondeterministic variable.(b) IsPosOut(Y1, ..., Yn, ead) if M Schema has some nondeterministic vari-

ables.(2) if M Schema has some nondeterministic variables declared by &(b,g,s,ead),

then prog, when applied to ξ(X1), ..., ξ(Xm), produces a sequence dv : List(ξ(B1)⊗... ⊗ ξ(Bn)) such that for all Y1 ∈ B1, ..., Yn ∈ Bn, (ξ(Y1), ..., ξ(Yn)) ∈ dviff IsPosOut(Y1, ..., Yn, ead).

(3) if M Schema has some nondeterministic variables declared by &(u,g,s,ead),then prog, when applied to ξ(X1), ..., ξ(Xm), produces a boolean-valued func-tion dv : (ξ(B1)⊗...⊗ξ(Bn)) ⇒ Bool such that for all Y1 ∈ B1, ..., Yn ∈ Bn,dv((ξ(Y1), ..., ξ(Yn))) = true iff IsPosOut(Y1, ..., Yn, ead).

(4) if M Schema has some nondeterministic variables declared by &(b,p,s,ead),then prog, when applied to ξ(X1), ..., ξ(Xm), produces n sequences dv1 :List(ξ(B1)), ..., dvn : List(ξ(Bn)) such that for all Y1 ∈ B1, ..., Yn ∈ Bn,ξ(Y1) ∈ dv1 ∧ ... ∧ ξ(Yn) ∈ dvn iff IsPosOut(Y1, ..., Yn, ead).

(5) if M Schema has some nondeterministic variables declared by &(u,p,s,ead),then prog, when applied to ξ(X1), ..., ξ(Xm), produces n boolean-valued func-tions dv1 : ξ(B1) ⇒ Bool , ..., dvn : ξ(Bn) ⇒ Bool such that for all Y1 ∈B1, ..., Yn ∈ Bn, dv1(ξ(Y1)) = true∧...∧dvn(ξ(Yn)) = true iff IsPosOut(Y1, ..., Yn, ead).

where

• IsBinding(Y1, ..., Yn) ≡ [x1 7→ X1, ..., xm 7→ Xm, y1 7→ Y1, ..., yn 7→ Yn] ∈M Schema[/&(bu,gp,sl,ead)], where M Schema[/&(bu,gp,sl,ead)] denotes the

result of removing all occurrences of &(bu,gp,sl,ead) in M Schema.• IsBest(Y1, ..., Yn) ≡ ∀Z1 ∈ B1, ..., Zn ∈ Bn·

IsBinding(Z1, ..., Zn) ⇒ sco((ξ(Y1), ..., ξ(Yn))) ≥ sco((ξ(Z1), ..., ξ(Zn)))• IsWorst(Y1, ..., Yn) ≡ ∀Z1 ∈ B1, ..., Zn ∈ Bn·

IsBinding(Z1, ..., Zn) ⇒ sco((ξ(Y1), ..., ξ(Yn))) ≤ sco((ξ(Z1), ..., ξ(Zn)))• IsPosOut(Y1, ..., Yn, ead) ≡ IsBinding(Y1, ..., Yn)∧

(ead = e ∨ (IsBest(Y1, ..., Yn) ∧ ead = a) ∨ (IsWorst(Y1, ..., Yn) ∧ead = d))


Proof. Although the proof is long, its general approach is obvious: For each of thecases 1-5 above and in terms of the value of ead , involved in M Schema, we canuse the functions []ead (see definition 3.3.1), []sl (see definition 3.3.2), and []bu (seedefinition 3.3.5) in turn to transform M Schema into an ordinary schema in CZ.Then we can apply an approach similar to the one used for proving theorem 3.1.2;we do not give the straightforward but tedious details of the proof here.

In the following two examples, it will be shown how we can use the interpretationfunction [[[]ead]sl]bu in order to interpret multi-schemas in CZ. In the first example,we specify a typical problem of nondeterminism, the eight queens problem.Example 12. The following multi-schema specifies the eight queens problem inwhich we must place a number (q) of queens on a chess board such that none ofthem is able to capture the others:

M Arrange ∼= [q? ∈ N, s! ∈ &(b,g,s,e)seq(N8 ×N8) |true,#s! = q ∧ (∀x, y ∈ N · (x 6= y ∧ x ≤ q ∧ y ≤ q) ⇒ ((s!(x).1 6= s!(y).1)∧ (s!(x).2 6=

s!(y).2)∧(s!(x).1 + s!(x).2 6= s!(y).1 + s!(y).2) ∧ (s!(x).1 + s!(y).2 6= s!(x).2 + s!(y).1)))]

Using &(b,g,s,e) to declare the nondeterministic variable s! shows that we are in-terested in producing all arrangements of q queens for each q? (sl = s). Also, forselecting one of the alternatives, there is no criterion to consider (ead = e). Finally,for each q?, the set of possible arrangements of q queens is finite (bu = b). SinceM Arrange involves only one nondeterministic variable, there is no difference be-tween using the singular semantics of nondeterminism (gp = g) and using the pluralone (gp = p) here; according to the solution that has been given for interpretingthese modalities of nondeterminism, both semantics yield the same program.

Now we interpret the multi-schema M Arrange in CZ as follows:[[[M Arrange]ead]sl]bu ∼= [q? ∈ N, ds ∈ seq seq(N8 × N8) | true,∀s! ∈ seq(N8 ×

N8) · s! ∈ ds ⇔(#s! = q∧ (∀x, y ∈ N · (x 6= y∧x ≤ q∧y ≤ q) ⇒ ((s!(x).1 6= s!(y).1)∧ (s!(x).2 6=

s!(y).2)∧(s!(x).1 + s!(x).2 6= s!(y).1 + s!(y).2) ∧ (s!(x).1 + s!(y).2 6= s!(x).2 + s!(y).1))))]

For each q?, the extracted program from the above operation schema produces allvalid arrangements of q? queens on a chess board.

In [27], using angelic and demonic choice semantics, we presented a generaltemplate for the specification and development of two player games in type theory.The next example shows how our Z-style formalism, presented in this section, canbe used for the formal specification and development of any two player game, suchas the Nim game described in example 11.Example 13. In each step of a two player game, a set of choices of a type T existsfrom which one of the players should select an element. The following multi-schemaspecifies our player’s choice:

M OurPlayer ∼= [rc? ∈ seqT, sc! ∈ &(b,g,l,a)T | rc? 6= 〈〉, sc! ∈ rc?]rc? is the set of possible choices, and sc! is the element that will be selected by ourplayer. Using &(b,g,l,a) to declare the nondeterministic variable sc! shows that ourplayer is interested in selecting a single (sl = l) alternative having the highest score(ead = a) from a finite set (bu = b) of possible alternatives. By the reasoning givenin the previous example, we use the singular semantics of nondeterminism (gp = g)here.

We interpret the multi-schema M OurPlayer in CZ as follows:


[[[M OurPlayer ]ead]sl]bu ∼= [rc? ∈ seqT, asc ∈ T | rc? 6= 〈〉, asc ∈ rc?∧(∀sc ∈ T · sc ∈ rc? ⇒ sco(sc) ≤ sco(asc))]

In the Appendix D, we have shown that the program satisfying [[[M OurPlayer ]ead]sl]bu

selects an element with the highest score from a set of possible choices, providedthat this set is non-empty; otherwise, the program aborts.

In this section, we have proposed to use multi-schemas instead of conventional op-eration schemas in order to specify nondeterminism in CZ. However, the operationsof the schema calculus (see subsection 2.2) will no longer work on multi-schemas.Therefore, in the next subsection, the schema calculus operations of CZ will beredefined to consider nondeterministic constructs involved in multi-schemas.

3.4. The nondeterministic schema calculus. The schema calculus operationsof CZ will no longer work on multi-schemas. For example, recall example 13 inwhich we specified our player’s choice in a general two player game as follows:

M OurPlayer ∼= [rc? ∈ seqT, sc! ∈ &(b,g,l,a)T | rc? 6= 〈〉, sc! ∈ rc?],where rc? is the set of possible choices, and sc! is the element that will be selectedby our player. The operation specified by the multi-schema M OurPlayer is nottotal23; M OurPlayer yields a program that aborts for input 〈〉 (see the AppendixD). We rewrite the previous specification to describe a total operation:

Report ::= OK |No Choice ExistsM P OurPlayer ∼= [rc? ∈ seqT, sc! ∈ &(b,g,l,a)T, r! ∈ Report | rc? 6= 〈〉, sc! ∈

rc? ∧ r! = OK ]Exception ∼= [rc? ∈ seqT, r! ∈ Report | rc? = 〈〉, r! = No Choice Exists]

The above specification can describe a total operation by applying a disjunctionbetween two operation schemas M P OurPlayer and Exception, but the existingoperator for disjunction, i.e. ∨c, is not defined on multi-schemas; hence, it seemsthat we should first interpret M P OurPlayer as an ordinary operation schemaand then apply a disjunction. The interpretation of M P OurPlayer in CZ is asfollows:

[[[M P OurPlayer ]ead]sl]bu ∼= [rc? ∈ seqT, asc ∈ T, ar ∈ Report | rc? 6= 〈〉,asc ∈ rc? ∧ ar = OK∧

(∀(sc, r) ∈ (T × Report) · (sc ∈ rc? ∧ r = OK ) ⇒ sco((sc, r)) ≤sco((asc, ar)))]Two schemas [[[M P OurPlayer ]ead]sl]bu and Exception are type compatible, andthus we can apply the operator ∨c to them. However, in the resulting schema, thereis no relationship between the variable r! coming from Exception and the variablear coming from [[[M P OurPlayer ]ead]sl]bu whereas both variables denote the sameoutput. This problem is due to the renaming of the variable r! of M P OurPlayerforced by the definition of the function []ead (see definition 3.3.1). It seems that wecan easily solve the problem by applying a slight change to the definition of []ead

such that we avoid renaming of output and after sate variables. However, we willencounter another problem if we require all of the possible choices with the highestscore. In this case, we must use the strict semantics of nondeterminism rather thanthe loose one in the schema M P OurPlayer . This causes the output variable r!

23If an operation schema places no constraints upon the state of the system beforehand, thenwe say that the operation it describes is total. Otherwise, the operation is said to be partial. Theeffect of a partial operation may be undefined for some combinations of before states and inputs.

Here, undefindness means that the schema tells us nothing about the result, or the resulting statecould be any state of the system[75].


existing in M P OurPlayer to be combined with the other variable, i.e. sc!, andthe resulting variable to be promoted into a sequence. In this way, the relationshipbetween two variables r! existing in Exception and M P OurPlayer will be lost.

Similar problems occur when we apply the other operators of the schema calcu-lus to schemas which have been obtained from the interpretation of multi-schemas.Therefore, we redefine the schema calculus operations of CZ to consider nondeter-ministic constructs involved in multi-schemas. In subsection 2.2, we defined theoperators ∧c, ∨c, ∃c, ∀c, and ;c for the CZ schema calculus operations Conjunction,Disjunction, Existential Quantifier, Universal Quantifier, and Sequential Composi-tion, respectively. Here, we define a new collection of operators consisting of ∧nc,∨nc, ∃nc, ∀nc, and ;nc

24 instead of the previous ones and interpret them in CZ. Asin CZ, the application of Negation to an operation schema and thus a multi-schemais undefined. Thus, we do not consider any new operator for it. Also, we assumeall schemas are in their normalized form (see subsection 2.2). We first present asemantics for the operators ∧nc and ∨nc.

3.4.1. The conjunction and disjunction over multi-schemas. The following defini-tion plays an important role to give a semantics for the operators ∧nc and ∨nc:

Definition 3.4.1. Two multi-schemas are nondeterminism compatible iff each afterstate and output variable common to two multi-schemas either is not nondetermin-istic in at least one of the schemas or is nondeterministic with the same modalityof nondeterminism in both of them.

In other words, the above definition states that two multi-schemas are not non-determinism compatible iff there exists at least one after state or output variablecommon to two schemas that is nondeterministic in both of them but with thedifferent modalities of nondeterminism.

The next definition gives a semantics for the new operators ∧nc and ∨nc. Theseoperators can be applied to ordinary operation schemas as special cases of multi-schemas. However, Both operators must be applied to schemas which are typecompatible (see subsection 2.2) and nondeterminism compatible. Otherwise, theresult will be undefined. Notice that when we use at least one of the operationsof the nondeterministic schema calculus, such as ∧nc and ∨nc, in a specification,we must interpret these operations according to the next definition and the otherdefinitions presented in this subsection before transporting any instances of multi-schemas into ordinary ones in CZ. The importance of such a constraint will bejustified later in this subsection.

Definition 3.4.2. Let M Schema1∼= [d1 |φ1, ψ1] and M Schema2

∼= [d2 |φ2, ψ2]be two multi-schemas. Then we have:

M Schema1 ∧nc M Schema2∼= [d1,n d2 |φ1 ∧ φ2, ψ1 ∧ ψ2]

M Schema1 ∨nc M Schema2∼= [d1,n d2 |φ1 ∨ φ2, (φ1 ∧ ψ1) ∨ (φ2 ∧ ψ2)],

where d1,n d2 is a special version of merging d1 and d2: if there exists a variable thatis nondeterministic in one of the declarations d1 and d2 and ordinary in the otherone, we use the nondeterministic version of the variable in d1,n d2. Since we have as-sumed that M Schema1 and M Schema2 are type compatible and nondeterminismcompatible, this union makes sense.

24The subscript nc used in the new operators denotes nondeterministic and constructive.


To give a semantics for ∧nc and ∨nc, we have used an approach similar to theone used in [47] to define the semantics of ∧c and ∨c except that we have applieda special version of merging. Thus, in a similar way, we can prove that the givensemantics are sound. In the next example, we apply the new operator ∨nc toschemas M P OurPlayer and Exception defined earlier at the beginning of thissubsection.Example 14. By the following specification, we describe the total version of theoperation specified in example 13:

Report ::= OK |No Choice ExistsM P OurPlayer ∼= [rc? ∈ seqT, sc! ∈ &(b,g,l,a)T, r! ∈ Report | rc? 6= 〈〉, sc! ∈

rc? ∧ r! = OK ]Exception ∼= [rc? ∈ seqT, r! ∈ Report | rc? = 〈〉, r! = No Choice Exists]M T OurPlayer ∼= M P OurPlayer ∨nc Exception

In the above specification, two schemas M P OurPlayer and Exception are typecompatible and nondeterminism compatible. By the semantics of ∨nc, we have:

M T OurPlayer ∼= [rc? ∈ seqT, sc! ∈ &(b,g,l,a)T, r! ∈ Report | true,(rc? 6= 〈〉 ∧ sc! ∈ rc? ∧ r! = OK ) ∨ (rc? = 〈〉 ∧ r! = No Choice Exists)]

We interpret the multi-schema M T OurPlayer as follows:[[[M T OurPlayer ]ead]sl]bu = [rc? ∈ seqT, asc ∈ T, ar ∈ Report | true,((rc? 6= 〈〉 ∧ asc ∈ rc? ∧ ar = OK ) ∨ (rc? = 〈〉 ∧ ar = No Choice Exists))∧(∀(sc, r) ∈ (T × Report) · ((rc? 6= 〈〉 ∧ sc ∈ rc? ∧ r = OK ) ∨ (rc? = 〈〉 ∧ r =

No Choice Exists))⇒ sco((sc, r)) ≤ sco((asc, ar)))]

The above specification results in a program that for rc? = 〈〉 reports No Choice Exists;for rc? 6= 〈〉 however, it returns an element of rc? with the highest score and reportsOK .

As it has been mentioned earlier, when we use at least one of the operationsof the nondeterministic schema calculus in a specification, we must first applythese operations and then transport any instances of multi-schemas into ordinaryones in CZ. The importance of such a constraint can easily be explored in theabove example: suppose that we interpret the multi-schema M P OurPlayer beforeapplying the operator ∨nc between it and the schema Exception. In this way, therelationship between two instances of the variable r! is removed. The importanceof the above issue can also be seen in the subsequent examples of this subsectionwhen we use other operations of the schema calculus.

After giving a semantics for the operators ∧nc and ∨nc, we now interpret theoperators ∃nc and ∀nc in CZ.

3.4.2. The existential and universal quantifiers over multi-schemas. To give a se-mantics for the operators ∃nc and ∀nc, we distinguish between situations in whichthe set of hidden variables does not contain nondeterministic variables with angelicor demonic nondeterminism and situations in which there exists at least one non-deterministic variable with angelic or demonic nondeterminism in the set of hiddenvariables:

(1) We first consider situations in which the set of hidden variables containonly either ordinary variables or nondeterministic ones with erratic nonde-terminism. Exploring the semantics of ∃nc and ∀nc in such situations seemsto be more convenient: when we hide an ordinary variable or a variable witherratic nondeterminism by ∀nc, we want to show that for all valuations of


this variable, a postcondition must be established, and when we hide such avariable by ∃nc, we want to show that a postcondition must be establishedfor at least one valuation of this variable. By a simple example, we showthat the semantics of the existing operators ∃c and ∀c are sufficient to in-terpret the new operators ∃nc and ∀nc: consider the following specification:

Report ::= OK |Not ExistsM P Get2L ∼= [x? ∈ N, y!, z! ∈ &(b,g,s,e)N, r! ∈ Report |x? > 0,

y! < x? ∧ z! = 2 ∗ y! ∧ r! = OK ]Exception ∼= [x? ∈ N, r! ∈ Report |x? = 0, r! = Not Exists]M T Get2L ∼= M P Get2L ∨nc Exception

The multi-schema M T Get2L specifies an operation which reports an errorwhen applied to 0. Otherwise, it reports OK in addition to producing twooutputs y! and z! that the former is less than the operation input, andthe latter is twice the former. Now, consider three sample scenarios: 1.When we hide y! by ∃nc, we still want to specify all even numbers z! suchthat z!/2 < x?. To achieve this goal, it is enough to use the semanticsof current operator for existential quantifier, i.e. ∃c, since in this way, thenondeterministic nature of z! will not be lost, and we can still gain allpossible values of z!; 2. When we hide both y! and z! by ∃nc, we only wantto report OK or Not Exists in terms of the value of x?. The same as theprevious case, we can use the semantics of ∃c. We will lose nothing; 3.Finally, when we hide r! by ∃nc, we want to specify all possible values (ifpossible) of y! and z! without reporting anything. Again, the semantics of∃c is sufficient. It can now be concluded that when we use an existentialquantifier to hide ordinary variables or nondeterministic ones with erraticnondeterminism, we can apply the semantics of the existing operator ∃c

regardless of the nondeterministic nature of the schema variables.Applying ∀nc to the multi-schema M T Get2L seems to be artificial.

However, we can reason about ∀nc similar to what we did in the previousparagraph for ∃nc. The next definition formalizes the above discussion.

Definition 3.4.3. Let M Schema ∼= [d |φ, ψ] be a multi-schema, and uh

be the set of hidden variables containing only ordinary variables or nonde-terministic ones with erratic nondeterminism. Then we have:

∃ncuh·M Schema ∼= ∃cuh[/&(bu,gp,sl,ead)]·[d−uh, uh[/&(bu,gp,sl,ead)] |φ, ψ]∀ncuh·M Schema ∼= ∀cuh[/&(bu,gp,sl,ead)]·[d−uh, uh[/&(bu,gp,sl,ead)] |φ, ψ],

where d − uh is the set of declarations which are in d and not in uh,and A[/&(bu,gp,sl,ead)] denotes the result of removing all occurrences of&(bu,gp,sl,ead) in A.

According to the above definition, before applying the existing semanticsof existential quantifier and universal quantifier of CZ, we transform non-deterministic variables, that are being hidden, to their ordinary versions.

(2) Now consider situations in which the set of hidden variables contains at leastone nondeterministic variable with angelic or demonic nondeterminism. Forthis case, we explore the semantics of ∃nc and ∀nc by a familiar example.In the following, we have slightly changed the specification of our player’schoice given in example 14:

Report ::= OK |No Choice Exists


M P OurPlayer ∼= [rc? ∈ seqN, sc1 !, sc2 ! ∈ &(b,g,l,a)N, r! ∈ Report | rc? 6=〈〉,

sc1 ! ∈ rc? ∧ sc2 ! = 2 ∗ sc1 ! ∧ r! = OK ]Exception ∼= [rc? ∈ seqN, r! ∈ Report | rc? = 〈〉, r! = No Choice Exists]M T OurPlayer ∼= M P OurPlayer ∨nc Exception

In the new specification, we have replaced the general type T by the setof natural numbers. Also, in addition to specifying an alternative sc1 !with the highest score as an output, we have specified sc2 ! = 2 ∗ sc1 !as another output. Now, assume that we apply an existential quantifierto M T OurPlayer . Consider the following scenario: when we hide sc1 !by the existential quantifier, we still want to specify an even number sc2 !such that sc2 !/2 is an alternative with the highest score. If we first hidesc1 !, we cannot then achieve the above mentioned goal since scores havebeen defined in terms of sc1 !. On the other hand, if we first interpret theangelic nondeterminism, we loose sc1 ! since it is renamed. It would evenbe combined with other output variables and promoted to a sequence ofvalues if we used the strict interpretation of nondeterminism rather thanthe loose one; in this way, it is impossible to hide sc1 !.

A similar scenario occurs when we use the universal quantifier. There-fore, it seems that nondeterministic variables must be hidden at the sametime that we interpret the angelic and demonic nondeterminism. The nextdefinition formalizes this conclusion for angelic nondeterminism. A similardefinition can be given for the demonic one. The form of the next definitionis close to the form of the part 1 of definition 3.3.1; however, it also involvesthe interpretation of quantifiers.

Definition 3.4.4. Let M Schema be a multi-schema having the followingstructure:

M Schema ∼= [x1 ∈ A1, ..., xbh ∈ Abh , xbh+1 ∈ Abh+1, ..., xm ∈ Am,y1 ∈ B1, ..., yah ∈ Bah , yah+1 ∈ Bah+1, ..., yd ∈ Bd,yd+1 ∈ &(bu,gp,sl,a)Bd+1, ..., ydah ∈ &(bu,gp,sl,a)Bdah ,

ydah+1 ∈ &(bu,gp,sl,a)Bdah+1, ..., yn ∈ &(bu,gp,sl,a)Bn |φ, ψ]25,where some of the before state and input variables, i.e. xbh+1, ..., xm

(bh ≤ m), some of the ordinary, after state and output variables, i.e.yah+1, ..., yd (ah ≤ d), and some of the nondeterministic, after state andoutput variables, i.e. ydah+1, ..., yn (d ≤ dah ≤ n) are in the set of hiddenvariables, i.e. uh; uh contains at least one nondeterministic variable (withangelic nondeterminism). In other words, dah < n. Now we have:(a) ∃ncuh ·M Schema ∼= [x1 ∈ A1, ..., xbh ∈ Abh ,

ay1 ∈ &(bu,gp,sl,i)B1, ..., ayah ∈ &(bu,gp,sl,i)Bah ,ayd+1 ∈ &(bu,gp,sl,i)Bd+1, ..., aydah ∈ &(bu,gp,sl,i)Bdah |∃uh[/&(bu,gp,sl,a)]·φ,∃uh[/&(bu,gp,sl,a)]·φ∧(ψ[ay1/y1]...[ayah/yah ][ayd+1/yd+1]...[aydah/ydah ]∧(∀(z1, z2, ..., zn) ∈ (B1 ×B2 × ...×Bn) · ψ[z1/y1]...[zn/yn] ⇒sco((z1, z2, ..., zn)) ≤ sco((ay1, ..., ayah , yah+1, ..., yd, ayd+1, ..., aydah , ydah+1, ..., yn))))]

(b) ∀ncuh ·M Schema ∼= [x1 ∈ A1, ..., xbh ∈ Abh ,

25Notice that the general form of multi-schemas, used in definition 3.3.1, has been modified

slightly here: we distinguish between those nondeterministic variables that are being hidden andthe others.


ay1 ∈ &(bu,gp,sl,i)B1, ..., ayah ∈ &(bu,gp,sl,i)Bah ,ayd+1 ∈ &(bu,gp,sl,i)Bd+1, ..., aydah ∈ &(bu,gp,sl,i)Bdah |∀uh[/&(bu,gp,sl,a)]·φ,∀uh[/&(bu,gp,sl,a)]·(ψ[ay1/y1]...[ayah/yah ][ayd+1/yd+1]...[aydah/ydah ]∧(∀(z1, z2, ..., zn) ∈ (B1 ×B2 × ...×Bn) · ψ[z1/y1]...[zn/yn] ⇒sco((z1, z2, ..., zn)) ≤ sco((ay1, ..., ayah , yah+1, ..., yd, ayd+1, ..., aydah , ydah+1, ..., yn))))],

where A[/&(bu,gp,sl,a)] denotes the result of removing all occurrences of&(bu,gp,sl,a) in A.

The above definition shows how we can interpret the quantification overmulti-schemas at the same time that we replace nondeterministic variablesby their versions declared by &(bu,gp,sl,i).

Now we apply ∃nc to the multi-schema M T OurPlayer given earlier,and then interpret it in CZ:∃ncsc1! ∈ N ·M T OurPlayer ∼=∃ncsc1 ! ∈ N · [rc? ∈ seqN, sc1 !, sc2 ! ∈ &(b,g,l,a)N, r! ∈ Report | true,(rc? 6= 〈〉 ∧ sc1 ! ∈ rc? ∧ sc2 ! = 2 ∗ sc1 ! ∧ r! = OK ) ∨ (rc? = 〈〉 ∧ r! =

No Choice Exists)] ∼=[rc? ∈ seqN, asc2 ∈ N, ar ∈ Report | true,∃sc1 ! ∈ N · ((rc? 6= 〈〉 ∧ sc1 ! ∈ rc? ∧ asc2 = 2 ∗ sc1 ! ∧ ar = OK )∨(rc? = 〈〉 ∧ ar = No Choice Exists))∧(∀(z1, z2, z3) ∈ (N×N×Report) ·((rc? 6= 〈〉∧z1 ∈ rc?∧z2 = 2∗z1 ∧z3 =

OK )∨(rc? = 〈〉∧z3 = No Choice Exists)) ⇒ sco((z1, z2, z3)) ≤ sco((sc1 !, asc2, ar)))]

The above specification results in a program that for rc? = 〈〉 reportsNo Choice Exists; for rc? 6= 〈〉, this program reports OK and returns aneven number sc2 such that sc2/2 is an element of rc? with the highestscore.

Now we define a semantics for the last operation of the new set of the schemacalculus operations, i.e. ;nc.

3.4.3. The sequential composition between multi-schemas. To define a semantics forS1 ;nc S2, we must first consider a special case in which S1 has at least one nonde-terministic variable, but S2 is an ordinary schema, i.e., it has no nondeterministicvariable. For instance, consider the following simple specification in CZ:

GetLessThan ∼= [x ∈ N,x′ ∈ &(b,g,s,a)N | true, x′ ≤ x]

GetSquare ∼= [x, x′ ∈ N | true, x

′= x ∗ x]

GetSquare is a deterministic schema, and thus we have written it without using non-deterministic variables; however, when using GetLessThan;nc GetSquare, we wantto specify an operation that returns a set of all possible natural numbers each ofwhose members is the square of a number equal to or less than the operation input.We can reason about this fact from another point of view: If we wrote GetLessThanin the original CZ without using nondeterministic variables, then by definition 3.1.1,the following schema would be a nondeterministic schema.

GetLessThan;c GetSquare ∼= [x, x′ ∈ N | true,∃x′′ ∈ N · x′′ ≤ x ∧ x′

= x′′ ∗ x′′

]By the above discussion, when S1 is a multi-schema having at least one nondeter-ministic variable, and S2 is an ordinary schema, before interpreting S1;nc S2, wemust replace the after state and output variables of S2 by their nondeterministic


versions using the instance of the nondeterministic operator &(bu,gp,sl,ead) involvedin S1.

Now we introduce our method to interpret S1;nc S2 in CZ. We first investigatehow the modalities of nondeterminism involved in S1 are propagated through thesequential composition: by S1 ;nc S2, we want to state that there exists some valuesof the after state and output variables of S1 (or the before state and input variablesof S2) by which the postconditions of S2 are established, provided that the precon-ditions of S1 hold (To achieve this goal, we apply an existential quantifier before thepredicates of S1 and S2 which quantifies over the after state and output variablesof S1 and then hide these variables from the resulting specification). In this way,the only modalities of nondeterminism that seems to affect the sequential composi-tion are angelic and demonic nondeterminism; by using the existential quantifier inthe predicate part of the final schema, other modalities of nondeterminism becomeneutral.

Using the angelic (demonic) modality of nondeterminism in S1, we want to statethat there exists some values of the after state and output variables of S1 that havethe highest (lowest) score among possible values of these variables and result inestablishing the postconditions of S2, provided that the preconditions of S1 hold.The next definition summarizes the above discussion.

Definition 3.4.5. Let S1∼= [db

1, da1 |φ1, ψ1] and S2

∼= [db2, d

a2 |φ2, ψ2] be two multi-

schemas, where db (da) denotes the set of declarations of before state and input(after state and output) variables. Now we have:

(1) If the modality of the nondeterminism involved in S1 is erratic, then:S1 ;nc S2

∼= S1[/&bu,gp,sl,e ] ;c S2, where A[/&bu,gp,sl,e ] denotes the resultof removing all occurrences of &bu,gp,sl,e in A.

(2) If the modality of the nondeterminism involved in S1 is angelic, then:S1 ;nc S2

∼= [db1, d

a2 |φ1,∃da

1 [′′/ ][/&bu,gp,sl,e ] · (ψ1[

′′/ a] ∧ φ2[

′′/ b] ∧

ψ2[′′/ b])∧

(∀da1 [

′′′/ ]·(ψ1[

′′′/ a]∧φ2[

′′′/ b]∧ψ2[

′′′/ b]) ⇒ sco(da

1 [′′/ ]) ≥ sco(da

1 [′′′/ ]))],

where A[′′/ ] and A[

′′′/ ] denote the result of substituting all variables

of A by their versions ending with ′′ and ′′′, respectively. Also, A[′′/ a]

(A[′′/ b]) and A[

′′′/ a] (A[

′′′/ b]) correspond to replacing after state and

output (before state and input) variables of A by their versions ending with′′ and ′′′, respectively.

(3) If the modality of the nondeterminism involved in S1 is demonic, then:S1 ;nc S2

∼= [db1, d

a2 |φ1,∃da

1 [′′/ ][/&bu,gp,sl,e ] · (ψ1[

′′/ a] ∧ φ2[

′′/ b] ∧

ψ2[′′/ b])∧

(∀da1 [

′′′/ ]·(ψ1[

′′′/ a]∧φ2[

′′′/ b]∧ψ2[

′′′/ b]) ⇒ sco(da

1 [′′/ ]) ≤ sco(da

1 [′′′/ ]))]

As before, for the composition to be defined, both schemas must refer to the samestate: for any primed component in S1, there must be an unprimed component ofthe same name in S2. Also, we assume that for any output variable in S1, thereis an input variable of the same name in S2. In the above definition, the modalityof the nondeterminism involved in S1 determines the form of the interpretation ofS1 ;nc S2. Notice that, as reasoned earlier, when S1 is a multi-schema having atleast one nondeterministic variable, and S2 is an ordinary schema, before using theabove defined interpretations, we must replace the after state and output variables


of S2 by their nondeterministic versions using the instance of the nondeterministicoperator &(bu,gp,sl,ead) involved in S1.

In the next example, we extend the problem specified in example 14 and give anew specification of it using the operator ;nc.Example 15. In example 14, we have given a specification of our player’s choice ina general two player game. Now we rewrite this specification to specify a sequentialcomposition of our player’s choice and our opponent’s choice:

Report ::= OK |No Choice ExistsGame ∼= [rc ∈ seqT ]

The state schema Game is written to specify states of the game, where rc is theset of possible choices in each state. Having the schema Game, we slightly changethe previous specification of our player’s choice as follows:

M P OurPlayer ∼= [∆Game, sc! ∈ &(b,g,l,a)T, r! ∈ Report | rc 6= 〈〉,sc! ∈ rc ∧ rc′ = f(rc, sc!) ∧ r! = OK ]

Similarly, we can specify our opponents’s choice as follows:M P OurOpponent ∼= [∆Game, sc! ∈ &(b,g,l,d)T, r! ∈ Report | rc 6= 〈〉,

sc! ∈ rc ∧ rc′ = f(rc, sc!) ∧ r! = OK ]In the above two schemas, rc′ = f(rc, sc!) indicates that the set of possible choicesin the after state, rc′, is obtained by a mapping f of this set in the before state ,rc, and the current selected alternative, sc!. To specify a total operation, we usethe following operation schema:

Exception ∼= [ΞGame, r! ∈ Report | rc = 〈〉, r! = No Choice Exists]Now we give the final specification as follows:

Game Round ∼= (M P OurPlayer ∨nc Exception) ;nc (M P OurOpponent ∨nc

Exception)Using the semantics of ∨nc, we have:

Game Round ∼= [∆Game, sc! ∈ &(b,g,l,a)T, r! ∈ Report | true,(rc 6= 〈〉∧sc! ∈ rc∧rc′ = f(rc, sc!)∧r! = OK )∨(rc = 〈〉∧r! = No Choice Exists)] ;nc

[∆Game, sc! ∈ &(b,g,l,d)T, r! ∈ Report | true,(rc 6= 〈〉∧sc! ∈ rc∧rc′ = f(rc, sc!)∧r! = OK )∨(rc = 〈〉∧r! = No Choice Exists)]

Since the modality of the nondeterminism involved in the first operand of ;nc aboveis angelic, we use the case 2 of definition 3.4.5 to interpret ;nc:

Game Round ∼= [rc ∈ seqT, rc′ ∈ seqT, sc! ∈ &(b,g,l,d)T, r! ∈ Report | true,∃rc′′ ∈ seqT, sc′′ ∈ T, r′′ ∈ Report ·(((rc 6= 〈〉 ∧ sc′′ ∈ rc ∧ rc′′ = f(rc, sc′′) ∧ r′′ = OK ) ∨ (rc = 〈〉 ∧ r′′ =

No Choice Exists)) ∧ ((rc′′ 6= 〈〉 ∧ sc! ∈ rc′′ ∧ rc′ = f(rc′′, sc!) ∧ r! = OK ) ∨ (rc′′ =〈〉 ∧ r! = No Choice Exists)))∧

(∀rc′′′ ∈ seqT, sc′′′ ∈ T, r′′′ ∈ Report ·(((rc 6= 〈〉 ∧ sc′′′ ∈ rc ∧ rc′′′ = f(rc, sc′′′) ∧ r′′′ = OK ) ∨ (rc = 〈〉 ∧ r′′′ =

No Choice Exists))∧ ((rc′′′ 6= 〈〉∧sc! ∈ rc′′′∧rc′ = f(rc′′′, sc!)∧r! = OK )∨ (rc′′′ =〈〉 ∧ r! = No Choice Exists)))⇒ sco(rc′′, sc′′, r′′) ≥ sco(rc′′′, sc′′′, r′′′))]

Now we obtain the final specification in CZ by interpreting the nondeterministicconstruct &(b,g,l,d) used in the above schema. In the following schema, we use ψ asa shorthand for the postcondition of the above schema:

Game Round ∼= [rc ∈ seqT, drc ∈ seqT, dsc ∈ T, dr ∈ Report | true,ψ[drc/rc′][dsc/sc!][dr/r !] ∧ (∀(rc, sc, r) ∈ (seqT × T × Report)·ψ[rc/rc′][sc/sc!][r/r !] ⇒ sco((drc, dsc, dr)) ≤ sco((rc, sc, r)))]


The above specification results in a program that first provides an element of rcwith the highest score for our player and then provides an element with the lowestscore for our opponent, provided that rc has at least two elements. If rc has lessthan two elements, the program reports No Choice Exists.

In the next subsection, we apply the new formalism to a familiar problem, thestrict 2PL algorithm whose both informal and formal specifications were givenearlier in examples 1.2 and 2.2, respectively. In this way, we demonstrate thatour formalism can be considered as a starting point for specifying and developingconcurrent systems. We also dedicate few pages to show how we can verify theresulting specification. Notice that we will not intend to give special solutions forspecifying and verifying concurrent systems. Indeed, it is out of the main focus ofthe paper, i.e. nondeterminism. Therefore, we will give a brief illustration of ourideas and delegate most of the details to other work.

3.5. Case study - the strict 2PL method. In example 4, we specified the strict2PL algorithm for concurrency control in database management systems. Althoughthe problem being specified was nondeterministic, this was not indicated by thespecification explicitly. As we have shown in this section, after deriving a programfrom a correctness proof of such a specification, only one of the possible behaviorswill appear in the final program. In the next example, using the notion of multi-schemas and the new operations of the schema calculus, we revise the previousspecification of the strict 2PL method to address the above mentioned issue.Example 16. We replace the operation schema AcquireLock , written in example4, By a new multi-schema M AcquireLock :

M AcquireLock ∼= [∆CCDB , transId ! ∈ &(b,p,s,e)N | true,transId ! ∈ dom activeTransactions∧((transId ! C runningTransactions) ∩ conflictLock(lockBase) = ∅)∧(lockBase ′.locks = lockBase.locks∪[transId 7→ transId !, command 7→ FirstCommand(runningTransactions.transId !),

dataItem 7→ FirstDataItem(runningTransactions.transId !)])]In the new schema, the only thing that is modified is replacing the output variable

transId ! by its nondeterministic version. Notice that we have declared transId ! as anondeterministic variable with the plural modality of nondeterminism. The reasonwas given in subsection 3.3.3 when we were trying to interpret the singular andplural nondeterminism in CZ: according to the second approach for interpretingthese modalities of nondeterminism, we expect that in various calls of the sub-routine extracted from M AcquireLock , it does not select a same transaction amongthose which ask for a lock and do not conflict with the set of current locks. Ofcourse, as we have emphasized in subsection 3.3.3, such an interpretation can onlybe implemented in the final program.

Using the new operations of the schema calculus, the final specification is asfollows:

M STwoPL ∼= M AcquireLock ;nc (Read ∨nc Write ∨nc Commit ∨nc Abort)Assume that the disjunctions between four multi-schemas Read , Write, Commit ,and Abort result in a multi-schema called RWCA. This schema specifies the taskdone by one of the operations read, write, commit, or abort in terms of the firstcommand of the input transaction identified by transId?. As we have discussedearlier, since M AcquireLock has a nondeterministic variable, and RWCA has nonondeterministic variable, before interpreting M AcquireLock ;nc RWCA, we must


redeclare the after state and output variables of RWCA using the nondeterministicoperator &(b,p,s,e) involved in M AcquireLock . Now, using the part 1 of definition3.4.5 to interpret the sequential composition and then applying each of the func-tions []ead, []sl, and []bu in turn yield an operation schema specifying all possibleoperations that can be done in a state of the system.

The notion of nondeterminism has an important role when we want to state thesemantics of concurrent processes: concurrency is usually modelled by the nonde-terministic interleaving of atomic operations [23]. Evans in a series of his papers(for example, [21], [22], and [23]) has tried to model such a semantics of concur-rency in the Z notation. He describes the concurrent behavior of a system in termsof its allowable computations, i.e. sequences of state changes, that result from theinterleaved execution of concurrent operations.

In example 16, we have given a formal specification of the strict 2PL methodfor controlling concurrency in a database management system. Our approach relieson specifying nondeterminism explicitly whereas Evans has not given a specificmethod to support nondeterminism; an Evans’s specification of a concurrent systemis implicitly nondeterministic and yields a program that is provided with only one ofthe possible interleaved executions of concurrent processes. On the other hand, incomparison to the work of Evans, the main drawback of our approach is as follows:we explicitly specify all possible choices that can be made in a state. For instance,in example 16, we explicitly specified all possible transactions that can acquire alock or in other words, all possible operations that can be done in a state. However,we modelled the action of only one operation in a state. More precisely, we didnot model the interleaving of atomic operations read, write, commit, and abort thatleads to a valid computation.

Capturing the ideas stated by Evans, we can easily extend our approach tomodel the nondeterministic interleaving of atomic operations. To achieve this goal,we discard the previous specification of the database management system writtenin example 16 and formalize the behavior of the system as a history of state changesresulting from the repeated application of the schema STwoPL given in example 4:

CCDBBehavior ∼= [stateChange ∈ seqCCDB | true, ∀n ∈ N · n > 0 ∧ n <

#stateChange ⇒ [CCDB 7→ stateChange.n,CCDB′ 7→ stateChange.(n + 1)] ∈

STwoPL]Briefly, the above schema specifies a computation as a valid sequence of systemstates iff for every two successive steps, they are related by the schema STwoPL.To solve the problem of Evans’s approach and thus obtain all possible computa-tions in the final program, it is sufficient to rewrite the schema CCDBBehavior as amulti-schema in which the variable stateChange has been replaced by its nondeter-ministic version having strict nondeterminism. In the above specification, we havenot forced fairness for computations. This issue can be addressed easily by addingrelated constraints to the predicate part of CCDBBehavior . The details of such amodelling can be delegated to another research. Notice that since we have giventhe semantics of all new nondeterministic constructs and new operations of theschema calculus in CZ itself, we can use the constructive framework, introduced insection 2, to develop a program from the new specification of the concurrent data-base management system. We do not develop such a program here. Nevertheless,theorem 3.3.6 guarantees that this program is provided with a sequence including


all possible interleaved executions of the concurrent transactions. This is the mainadvantage of our approach to that of Evans.

Besides specifying concurrent systems, there is a related field to explore ap-proaches for verifying formal specifications of concurrent systems. In [21] and [22],Evans has presented a set of inference rules for formally proving safety and live-ness26 properties of Z specifications of concurrent systems. The rules are based onassertional verification techniques but are implemented in an emerging deductivecalculus for Z, called W 27. In the assertional approach, safety and liveness prop-erties are proved by examining the effect of individual operations on the systemstate.

The logic used by Evans is based on proofs of the form DOp ` P (s) ⇒ Q(s′),

where DOp is a deterministic operation schema, and s is the state schema of thesystem, respectively. P (s) and Q(s) are both predicates over variables of s. Q(s

′)

is obtained from Q(s) by replacing variables of s by their primed versions. DOp `P (s) ⇒ Q(s

′) states that if DOp is applied to a state s in which the predicate P

holds, then predicate Q will hold after the application of DOp. An essential partof the logic is the fairness assumption that any operation whose preconditions aresatisfied by the current state of the system will eventually be executed. Safety andliveness properties are proved simply by showing that some or all the operationsin the system will result in the desired properties becoming true. As a simpleexample, suppose that a concurrent system has a deterministic operation Op forwhich Op ` true ⇒ Q(s

′) holds. It can be claimed at any point during the execution

of the system that Q will eventually hold. This is because operation Op will beexecuted eventually (by the fairness assumption) and thereby establish Q.

Most properties one may wish to prove of a concurrent system can be expressedusing proofs of the above mentioned form. However, it is cumbersome to do so allthe time; hence, in [21] and [22], a number of commonly used inference rules havebeen defined in terms of these proofs. For example, safety properties have beenexpressed by the inference rule unless interpreted in Z as follows: For any specifi-cation S, where Op1, ...,Opn represent all the possible deterministic operations ofS, then:

Op1 ` P (s) ∧ ¬Q(s) ⇒ P (s′) ∨Q(s

′) ... Opn ` P (s) ∧ ¬Q(s) ⇒ P (s

′) ∨Q(s

′)

P unless QThis states that if the system is in a state that satisfies P and ¬Q, then after theapplication of any of the operations in the system either P will remain true or Q willbecome true. Besides the above rule, two concepts stable predicate and invariantare also useful here. A stable predicate remains true once it has become true, whilean invariant is always true during the lifetime of the system. Both of the conceptsare formally defined using unless:P unless false ⇔ P is stable((initilization schema ` P (s

′)) ∧ P is stable) ⇔ P is invariant

To prove that a property always holds during the execution of the system, it issufficient to use the unless rule and the above definitions to show that the property

26A safety property is expressed in terms of an invariant, i.e. a property that must alwayshold during the execution of the system, whilst a liveness property asserts that a property will

eventually become true.27See [74] for full details.


is an invariant; there is no need to prove that the property holds in all system statesexisting in a computation.

Now we apply the above mentioned rule and definitions to our CZ specificationof the concurrent database management system given in example 4. When definingthe schema LockBase to specify the set of existing locks, we considered an invariantfor it indicating that it never contains conflicting locks at each time. Suppose thatwe have not defined such a constraint. Then, the following safety property must beproved:

SafeLockBase(CCDB) ∼= ∀x, y ∈ lockBase.locks · (x.dataItem = y.dataItem ⇒(x.transId = y.transId ∨ (x.command = Read ∧ y.command =

Read)))SafeLockBase(CCDB) is a predicate over the variable lockBase of the state schemaCCDB . To show that the predicate SafeLockBase is an invariant, we must provethe following conjunction (Recall that, in this way, there is no need to showSafeLockBase holds in all system states existing in the sequence stateChange, de-clared in the schema CCDBBehavior):

1. CCDB Init ` SafeLockBase(CCDB′)28 ∧

2. SafeLockBase is stable

The predicate part of the schema CCDB Init demonstrates that lockBase′.locks =

∅; it simply proves the first conjunct of the above conjunction. By the unless rule,the second conjunct can be proved if we show that all the following predicates hold:

3. AcquireLock ` SafeLockBase(CCDB) ⇒ SafeLockBase(CCDB′)

4. Read ` SafeLockBase(CCDB) ⇒ SafeLockBase(CCDB′)

5. Write ` SafeLockBase(CCDB) ⇒ SafeLockBase(CCDB′)

6. Commit ` SafeLockBase(CCDB) ⇒ SafeLockBase(CCDB′)

7. Abort ` SafeLockBase(CCDB) ⇒ SafeLockBase(CCDB′)

Fortunately, all the operation schemas Read , Write, Commit , and Abort are deter-ministic. Moreover, there are straightforward proofs to show the correctness of thecases 4-7 above. However, AcquireLock is nondeterministic, and thus Evans’s rulescannot be applied to it; suppose that we try to use such rules: We must show thatthe following predicate holds:

AcquireLock ` (∀x, y ∈ lockBase.locks · (x.dataItem = y.dataItem ⇒(x.transId = y.transId ∨ (x.command = Read ∧ y.command =

Read)))) ⇒(∀x, y ∈ lockBase ′.locks · (x.dataItem = y.dataItem ⇒

(x.transId = y.transId∨(x.command = Read∧y.command = Read))))By the definition of AcquireLock (see example 4), we have:

(lockBase ′.locks = lockBase.locks∪[transId 7→ transId !, command 7→ FirstCommand(runningTransactions.transId !),

dataItem 7→ FirstDataItem(runningTransactions.transId !)])]transId ! has a nondeterministic nature and does not refer to a single transaction; weonly know that it corresponds to an active transaction whose first operation doesnot conflict with the current set of locks. Indeed, this has been the main reason forignoring nondeterministic operations (at least in a formal form) in Evans’s rules.

28SafeLockBase(CCDB′) is obtained from SafeLockBase(CCDB) by replacing variables of

CCDB by their primed versions.


Using the notion of multi-schemas and applying a slight change to the Evans’sbasic rule, i.e. Op ` P (s) ⇒ Q(s

′), we can simply extend his work to cover non-

deterministic operations: recall the general form of multi-schemas given in section3:

M Schema ∼= [x1 ∈ A1, x2 ∈ A2, ..., xm ∈ Am, y1 ∈ B1, y2 ∈ B2, ..., yd ∈ Bd,yd+1 ∈ &Bd+1, yd+2 ∈ &Bd+2, ..., yn ∈ &Bn |φ, ψ],

where the after state and output variables yd+1, yd+2, ..., yn are nondeterministic.Now, for the multi-schema M Schema, we change the Evans’s basic form of proofs,i.e. M Schema ` P (s) ⇒ Q(s

′), to the new one:

M Schema ` P (s) ⇒ (∀(y1, y2, ..., yn) ∈ (B1 ×B2 × ...×Bn) · (ψ ⇒ Q(s′)))

The above form of proof states that if a multi-schema M Schema is applied to astate s in which the predicate P holds, then predicate Q will hold, for all possiblevalues of the after state and output variables of M Schema, after the applicationof this schema. As before, we consider ordinary operation schemas as special casesof multi-schemas having no nondeterministic variable; hence, we can apply the newform of proof to ordinary operation schemas.

Similar to the change we have applied to the Evans’s basic rule, we must changeall his rules, such as the unless rule. Having the new set of rules, we can replace theordinary schema AcquireLock by its corresponding multi-schema, M AcquireLock ,and show that the predicate

M AcquireLock ` (∀x, y ∈ lockBase.locks · (x.dataItem = y.dataItem ⇒(x.transId = y.transId ∨ (x.command = Read ∧ y.command = Read)))) ⇒(∀(transId !, dataBase

′, lockBase

′, activeTransactions

′, runningTransactions

′, localDBs

′) ∈

(N×DataBase×LockBase×seq Transaction×seq Transaction×seq DataBase)·(ψ ⇒(∀x, y ∈ lockBase.locks · (x.dataItem = y.dataItem ⇒

(x.transId = y.transId ∨ (x.command = Read ∧ y.command = Read))))))holds (ψ is the postcondition of M AcquireLock) instead of showing the correctnessof the following predicate:

AcquireLock ` (∀x, y ∈ lockBase.locks · (x.dataItem = y.dataItem ⇒(x.transId = y.transId ∨ (x.command = Read ∧ y.command =

Read)))) ⇒(∀x, y ∈ lockBase ′.locks · (x.dataItem = y.dataItem ⇒

(x.transId = y.transId∨(x.command = Read∧y.command = Read))))The correctness of the new predicate can easily be proved using the definitionof M AcquireLock (see example 16). In the above approach, we considered theoperator & instead of &(bu,gp,sl,ead) whereas the latter is the improved version ofthe former and regards the modalities of nondeterminism. The extension of ourapproach to cover modalities of nondeterminism is straightforward. however, thedetails of such an extension is out of the scope of this paper and is considered as adirection for future research.

Evans has provided several rules to prove liveness properties. Like rules relatedto safety properties, these rules are based on deterministic operations. To covernondeterministic operations, we can apply changes to these rules, similar to whatwe did for the rules related to safety properties: it is sufficient to demonstrate thatall (or for some cases, a number of) possible values of nondeterministic variablessatisfy the required inference rules. Exploring the details of this idea and applyingit to a real application can be an interesting topic in continuing this work. Forexample, as a case study, we can specify a deadlock free algorithm for controlling


concurrency in a database management system (instead of the strict 2PL methodthat is deadlock prone) and show the deadlock freedom of transactions, a livenessproperty of the system.

4. Conclusions and future work

The notion of nondeterminism has been studied in computer science since itsearly days; the use of this notion in algorithms [14, 24], imperative programminglanguages [19], and abstract data types [32, 64] are but a few examples. In thefield of formal program development, many authors have so far investigated non-determinism in various refinement calculi. In [51], demonic nondeterminism hasbeen introduced into a refinement calculus by constructing a weakest preconditionsemantics for imperative specifications and programs that holds good even whenexpressions may be nondeterministic. In [72], Ward defined a nondeterministic re-finement calculus. He first added some (set theoretical) specification constructs toa functional language. Then, he defined a number of nondeterministic constructsin the specification language for modelling erratic, angelic, and demonic choices.Finally, a set of refinement rules were proposed to support refining specificationsto nondeterministic functional programs. Most of the existing approaches to dealwith nondeterminism in refinement calculi refine nondeterministic specifications bydecreasing demonic choices or increasing angelic ones [2, 13, 52]. In [13], however,two methods have been proposed to refine nondeterministic specifications by re-ducing angelic nondeterminism into demonic one or pure determinism. A surveyon studying nondeterminism in refinement calculi can be found in [52].

In this paper, we investigated the notion of nondeterminism in a constructiveframework for formal program development. The development of programs in thisframework begins by writing specifications in the CZ formal language. CZ is aZ-style notation which benefits from a constructive underlying theory allowing usto investigate the notion of nondeterminism from the formal program developmentpoint of view. In the paper, we first showed that without specifying nondetermin-ism explicitly, the effects of the nondeterminism involved in initial specificationswill not be preserved in final programs. We then introduced the notions of multi-schemas and nondeterministic variables into CZ to specify bounded, unbounded,loose, strict, erratic, angelic, demonic, singular, and plural modalities of nondeter-minism. Our approach to the angelic and demonic nondeterminism covers game-likesituations in which the combination of both modalities of nondeterminism are usedto model conflicting agents. For distinguishing singular and plural nondeterminism,we used a semantics that can be implemented in the specification phase. We finallymodified the schema calculus operations of CZ to be definable on multi-schemas.Using the new constructs, we can specify usual applications of nondeterminism, suchas concurrency, by concentrating only on the functional properties of the systembeing specified. Also, since the semantics of the new nondeterministic constructshave been given in CZ itself, using the existing interpretation of CZ in Martin-Lof’stheory of types [47, 48], we can derive proper programs from our initial nondeter-ministic specifications. To continue the current research or improve its results, weintroduce the following directions for future work:

(1) There are some attempts to translate Z specifications into specifications inrefinement calculi (For example, see [36] and [73]). Since our definitionscan be modified slightly to be used in the Z notation, a direction for future


research can be to extend an existing interpretation of Z in a refinementcalculus in order to map nondeterministic specifications of Z to their coun-terparts in the refinement calculus.

(2) In the paper, we have given a solution to translate schemas of CZ into sometypes in type theory. Our solution is rather primitive and does not cover theschema calculus operations of CZ. By extending the current translation tointerpret the schema calculus in Martin-Lof’s theory of types, we obtain analternative semantics for the schema calculus, based on type theory ratherthan set theory. In a related work [29], Henson and Reeves have introduceda logic for the schema calculus of Z. This logic has been constructed withinthe specification logic ZC which is a constructive, typed set theory basedupon the notion of schema type. The language of ZC is associated with

1. rules for determining the types of terms,2. rules for determining that propositions are well-formed, and3. rules of inference [30].

Henson and Reeves have also interpreted ZC in a constructive theory ofintensional types and operations called τ . τ is a generalization of Beeson’sξON [4].

(3) Another interesting topic in continuing this research could be studying un-derspecification in the process of formal program development. When de-veloping a software system in a number of refinement steps, we are ofteninterested in specifying the functionality of the system not uniquely butonly with respect to some required properties. Later in the developmentprocess, we may add more properties whenever we find this appropriate.Then we speak of underspecification [69]. Underspecification correspondsto choices between deterministic models while nondeterminism correspondsto choices within a nondeterministic model. This conceptual difference be-tween underspecification and nondeterminism does not contradict the factthat both arise as natural abstraction mechanisms and sometimes may besupported by similar modelling techniques. Especially, the refinement con-cepts for underspecification and nondeterminism are rather similar [69].

In the refinement method, underspecification can be modelled by de-monic nondeterminism or indeed demon’s arbitrariness: when a specifica-tion specifies less, it may yield a program that satisfies the specification butis still not what is wanted. By the refinement steps, we move from moreabstract to more concrete specifications in order to achieve a program thatis wanted or remove the chance for developing unwanted programs. Thiscorresponds to the well known treatment of demonic nondeterminism invarious refinement calculi [13]: decreasing demonic nondeterminism or de-mon’s arbitrariness makes a specification more refined.

(4) Another direction for future research is to provide nondeterministic con-structs with choice probabilities such that one can associate a selectionprobability to each choice and probe the effects of these probabilities onextracted programs. Nondeterminism and probability are different, al-though related, phenomena. In various approaches to model probabilityin concurrent systems, nondeterministic behavior has been substituted byprobabilistic one in which the different types of behaviors are quantifiedwith probabilities [68]. Nevertheless, it is sometimes necessary to provide


operators that allow us to deal with nondeterminism, but, at the same time,taking into account the probabilistic aspects: in the process of modellinga concurrent system, we sometimes find nondeterministic behaviors thatcan be quantified (for instance, the failing probability of a faulty commu-nication channel), whereas on other occasions, nondeterministic behaviorscannot be quantified (for instance, relative speed between two processes).

However, some problems arise when we want to model computations inwhich both nondeterminism and probability are present [12]. In [49], it hasbeen shown how to build denotational models to support both nondeter-ministic choice and probabilistic choice simultaneously, so that the laws fornondeterministic choice and for probabilistic choice that one expects to holdactually are valid. Both notions of probability and nondeterminism havealso been studied in sequential programming by several publications of theProgramming Research Group at the University of Oxford. For instance, in[45], McIver and Morgan have extended probabilistic predicate transform-ers, introduced in [37] as a logic for imperative probabilistic programming,to include demonic, angelic, and unbounded nondeterminism.

References

[1] Aczel, P.: The Type Theoretical Interpretation of Constructive Set Theory: Inductive Defi-

nitions, Logic, Methodology and Philosophy of Science VII, Elsevier Science Publishers B.V.,

l986, 17-49.[2] Back, R. J. R., von Wright, J.: Interpreting Nondeterminism in the Refinement Calculus,

Proc. the BCS-FACS 7th Refinement workshop, 1996.

[3] Backus, J.: Can Programming be Liberated from von Neumann Style? A Functional Styleand Its Algebra of Programs, Communication of the ACM, 21(8), 1978, 613-635.

[4] Beeson, M.: Foundations of Constructive Mathematics, Springer-Verlag, 1985.

[5] Bergstra, J. A., Klop, J. W.: Algebra of Communicating Processes, in: Mathematics andComputer Science, CWI Monographs, 1, North-Holland, Amsterdam, l986, 89-138.

[6] Bishop, E.: Foundations of Constructive Analysis, McGraw-Hill, 1967.

[7] Bishop, E., Bridges, D.: Constructive Analysis, Springer-Verlag, 1985.[8] Blass, A., Gurevich, Y.: The Logic of Choice, Journal of Symbolic Logic, 65(3), 2000.

[9] Broy, M.: A Theory for Nondeterminism, Parallelism, Communication, and Concurrency,Theoretical Computer Science, 45(1), 1986, 1-61.

[10] Burstall, R., McKinna, J.: Deliverables: A Categorical Approach to Program Development inType Theory, Laboratory for the Foundations of Computer Science, University of Edinburgh,Technical Report ECS-LFCS-92-242, 1992.

[11] Cavalcanti, A., Woodcock, J.: Angelic Nondeterminism and Unifying Theories of Program-

ming (Extended Version), Department of Computer Science, University of Kent, TechnicalReport No. 13-04, 2004.

[12] Cazorla, D., Cuartero, F., Valero, V., Pelayo, F. L.: Algebraic Theory of Probabilistic and

Nondeterministic Processes, Technical Report DIAB-01-01-19, Department of Computer Sci-ence, University of Castilla-La Mancha, Spain, 2001.

[13] Celiku, O., von Wright, J.: Correctness and Refinement of Dually Nondeterministic Pro-grams, TUCS Technical Reports, No. 516, 2003.

[14] Chen, J., Friesen, D. K. , Jia, W., Kanj, I. A.: Using Nondeterminism to Design Efficient

Deterministic Algorithms, FSTTCS 2001, LNCS 2245, 2001, 120-131.[15] Cooke, J.: Formal Methods - Mathematics, Theory, Recipes or What?, The Computer Jour-

nal, 35(5), 1992, 419-423.

[16] Dahl, D. J., Dijkstra, E. W., Hoare, C. A. R.: Structured Programming, Academic Press,New York, 1972.

[17] Date, C. J.: An Introduction to Database Systems, Eighth Edition, Addison Wesley, 2003.

[18] Dezani-Ciancaglini, M., Liguoro, U., Piperno, A.: A Filter Model for Concurrent-Calculus,SIAM Journal on Computing, 27(5), 1998.


[19] Dijkstra, E. W.: A Discipline of Programming, Prentice Hall, 1976.[20] Diller, A.: Z and Introduction to Formal Methods, John Wiley and Sons, 1992.

[21] Evans, A. S.: Specifying and Verifying Concurrent Systems Using Z, Proc. FME’94: Indus-

trial Benefit of Formal Methods, Springer-Verlag, 1994, 366-380.[22] Evans, A. S.: An Assertional Verification Method for Z Specifications of Concurent Systems,

Proc. ISCIS XI, Turkey, 1996.[23] Evans, A. S.: An Imoroved Recipe for Specifying Reactive Systems in Z, in ZUM ’97: Z

Formal Specification Notation. Proc. 11th Internationa Conference of Z Users., Springer-

Verlag, 1997, 275-294.[24] Floyd, R. W.: Nondeterministic Alghorithms, Journal of the ACM, Volume 14, 1967, 636-644.

[25] Haghighi, H., Mirian-Hosseinabadi, S. H.: Nondeterminism in Martin-Lof’s Theory of Types,

Proc. 10th Annual CSI Computer Conference (CSICC 2005), Tehran, Iran, 2005.[26] Haghighi, H., Mirian-Hosseinabadi, S. H.: An Approach to Nondeterminism in Translation of

CZ Set Theory into Martin-Lof’s Theory of Types, Proc. of the IPM International Workshop

of Foundations of Software Engineering (FSEN 2005), ENTCS 159, 2006.[27] Haghighi, H., Mirian-Hosseinabadi, S. H.: Formal Development of Two Player Games: A Con-

structive Approach, Proc. 12th Annual CSI Computer Conference (CSICC 2007), Tehran,

Iran, 2007.[28] Hayes, I. J., Jones, C. B.: Specifications Are Not (Necessarily) Executable, Software Engi-

neering Journal, 1989.[29] Henson, M. C., Reeves, S.: A Logic for the Schema Calculus, Proc. 11th International Con-

ference of Z Users on the Z Formal Specification Notation, Springer-Verlag, 1998, 172-191.

[30] Henson, M. C., Reeves, S.: Revising Z: Semantics and Logic, Formal Aspects of Computing,1(3), 1998.

[31] Henson, M. C., Reeves, S.: A Logic for Schema-based Program Development, Formal Aspects

of Computing, 15(1), 2003.[32] Hesselink, W. H.: A Mathematical Approach to Nondeterminism in Data Types, ACM Trans-

action on Programming Languages and Systems, 10(1), 1988, 87-117.

[33] Hesselink, W. H.: Modalities of Nondeterminacy, Springer-Verlag, 1991.[34] Hoare, C. A. R.: Communicating Sequential Processes, Prentice Hall International Ltd.,

Englewood Cliffs, NJ, 1985.

[35] Hughes, J., Moran, A. K.: Making Choices Lazily, Functional Programming and ComputerArchitecture, ACM Press, 1995, 108119.

[36] King, S.: Z and the Refinement Calculus, Proc. VDM’90, LNCS 428, Springer-Verlag, 1990,164-188.

[37] Kozen, D.: Semantics of Probabilistic Programs, Journal of Computer and System Sciences,

Volume 22, 1981, 328-350.[38] Lano, K.: The B Language and Method: A Guide to Practical Formal Development, FACIT

Series, 1996.

[39] Luo, Z.: A Unifying Theory of Dependent Types: The Schematic Approach, in: logicalFoundations of Computer Science, Springer-Verlag, 1992.

[40] Maharaj, S.: Encoding Z-style Schemas in Type Theory, Proc. workshop on Types for Proofs

and Programs, Nijmegen, 1993, 238-262.[41] Martin, C. E., Curtis, S. A.: Modelling Nondeterminism, Proc. Mathematics of Program

Construction conference, Lecture Notes in Computer Science, number 3125, 2004, 228-251.

[42] Martin-Lof, P.: An Intuitionistic Theory of Types: Predicative Part, Proc. Logic Colloquium73 (H.E. Rose, J.C. Sheperdson, Eds.), North Holland, 1975, 73-118.

[43] Martin-Lof, P.: Constructive Mathematics and Computer Programming, In Mathematical

Logic and Programming Languages, (C.A.R. Hoare, J.C. Sheperdson, Eds.), Prentice Hall,1985, 167-184.

[44] McCarthy, J.: ”Towards a Mathematical Theory of Computation”, Proc. IFIP Congress 62,1963, 21-28.

[45] McIver, A., Morgan, C.: Demonic, Angelic and Unbounded Probabilistic Choices in Sequen-

tial Programs, Acta Informatica, 37(4/5), 32001, 329-354.[46] Milner, R.: Communication and Concurrency, International Series in Computer Science,

Prentice Hall, 1989.[47] Mirian-Hosseinabadi, S. H.: Constructive Z, PhD Thesis, Department of Computer Science,

University of Essex, UK, 1997.


[48] Mirian-Hosseinabadi, S. H., Turner, R.: Constructive Z, Journal of Logic Computation, 7(96-48), 1997, 49-70.

[49] Mislovea, M., Ouaknineb, J., Worrella, J.: Axioms for Probability and Nondeterminism,

Electronic Notes in Theoretical Computer Science 96 (2004), Elsevier Press, 2004, 7-28.[50] Morgan, C.: Programming from Specifications, Prentice Hall, 1990.

[51] Morris, J. M.: Non-deterministic Expressions and Predicate Transformers, Information Pro-cessing Letters 61, Elsevier Science Publishers B.V., l997, 241-246.

[52] Morris, J. M., Bunkenburg, A.: Partiality and Nondeterminacy in Program Proofs, Formal

Aspects of Computing, 3(1), 1999.[53] Mousavi, M. R.: Nondeterminism in Set Theoretic Formal Specifications: A Constructive

Approach, MSC Thesis, Department of Computer Engineering, Sharif University of Technol-

ogy, Tehran, Iran, 2001.[54] Myhill, J.: Constructive Set Theory, The Journal of Symbolic Logic, 40(3), 1975, 347-382.

[55] Nordstrom, B., Petersson, K., Smith, J. M.: Programming in Martin-Lof ’s Type Theory: An

Introduction, Oxford University Press, 1990.[56] Pitcher, C. S.: Functional Programming and Erratic Non-determinism, PhD Thesis, Trinity

College, Oxford University Computing Laboratory, 2001.

[57] Potter, B., Sinclair, J., Till, D.: An Introduction to Formal Specification and Z, PrenticeHall, 1991.

[58] Pressman, R. S.: Software Engineering: A Practitioners Approach, McGraw-Hill, UK, 1994.[59] Scott, D., Gunter, C.: Semantic Domains and Denotational Semantics, Hand Book of The-

oretical Computer Science, Elsevier Science Publisher, l997, 633-674.

[60] Søndergaard, H., Sestoft, P.: Non-determinism in Functional Languages, The ComputerJournal, 35(5), 1992, 514-523.

[61] Spiliopoulou, E.: Concurrent and Distributed Functional Systems, PhD Thesis, Department

of Computer Science, University of Bristol, 1999.[62] Spivey, J. M.: Understanding Z: A Specification Language and its Formal Semantics, Cam-

bridge University Press, 1988.

[63] Spivey, J. M.: The Z Notation: A Reference Manual, Prentice Hall, 1989.[64] Subrahmanyam, P. A.: Nondeterminism in Abstract Data Types, in: Automata, Languages,

and programming, 8th Colloquium, LNCS, Volume 115, 1981, 148-164.

[65] Thompson, S. J.: Type Theory and Functional Programming, Addison Wesley, 1991.[66] Troelstra, A. S., VanDalen, D.: Constructivism in Mathematics, North Holand Studies in

Logic, Volume 121, 1988.[67] Turner, R.: Constructive Foundation of Functional Languages, McGraw-Hill, 1991.

[68] Varacca, D.: Probability, Nondeterminism and Concurrency: Two Denotational Models

for Probabilistic Computation, PhD Thesis, Department of Computer Science, Universityof Aarhus, Denmark, 2003.

[69] Walicki, M., Broy, M.: Structured Specifications and Implementation of Nondeterminstic

Data Types, Nordic Journal of Computing, 2(3), 1995, 358-395.[70] Walicki, M., Meldal, S.: Algebraic Approaches to Nondeterminism: An Overview, ACM

Computing Surveys, 29(1), 1997, 30-81.

[71] Walicki, M., Meldal, S.: Singular and Plural Nondeterministic Parameters, SIAM J. Com-put., 26(4), 1997, 991-1005.

[72] Ward, N. T. E.: A Refinement Calculus for Nondeterministic Expressions, PhD Thesis,

Department of Computer Science, University of Queensland, Australia, 1994.[73] Woodcock, J.: ”An Introduction to Refinement in Z, Proc. VDM’91, LNCS 552, Springer-

Verlag, Volume 2, 1991, 96-117.

[74] Woodcock, J., Brien, S. M.: W: A Logic for Z, Workshops in Computing, Springer-Verlag,1992, 77-96.

[75] Woodcock, J., Davies, J.: Using Z, Specifications, Refinement and Proof, Prentice Hall, 1996.


Appendix AProgram extraction from [M GetLE ]D

We apply the extended version of the function ξ to the schema [M GetLE ]D stepby step; the result will be a type in Martin-Lof’s theory of types:

[[M GetLE ]D]ξ = (Πα ∈ (ξ(N))− · Σγ ∈ (ξ(PN))−·[∀sc! ∈ N · sc! ∈ dsc ⇔ sc! ≤ n?]ξ)[(ξ(N))α/n?][(ξ(PN))γ/dsc]

= (Πα ∈ (ξ(N))− · Σγ ∈ (ξ(PN))− ·Πβ ∈ (ξ(N))−·[sc! ∈ dsc ⇔ sc! ≤ n?]ξ)[(ξ(N))α/n?][(ξ(PN))γ/dsc][(ξ(N))β/sc!]

According to the interpretation of the set of natural numbers and the decidablepower set constructor in [47] and also the fact that α, β, and γ are themselveselements of V , the following equality is obtained:

[[M GetLE ]D]ξ = Πα ∈ N · Σγ ∈ N ⇒ Bool ·Πβ ∈ N · γ(β)=true ⇔ β ≤α,where β ≤α is an abbreviation for Σρ · β + ρ=α. Now we derive a program from acorrectness proof of the resulting type theoretical specification. An initial part ofsuch a proof is shown here:

A ≡ ∑γ∈N ⇒ Bool • ∏β∈N • γ(β) = true ⇔ β ≤ αB ≡ ∏β∈N • γ(β) = true ⇔ β ≤ αΓ ≡ α∈N, x∈N, g1∈A[x/α]

getLE = λα • t t = natrec(α, u, f)u = (z, p) f = λx. gg = λg1. g2 g2 = (v, q)Γ α∈N, x∈N, g1∈A[x/α]

Hyp

z = (λc. if c=0 then true else false)v = (λc. if c=s(x) then true

else if c<s(x) then fst(g1)(c)

Hypα∈N z = (λc. if c=0 then true else false)

yp

α∈N v = (λc if c=s(x) then true else if c<s(x)Hyp

else false)

∑iα∈N z∈(N⇒Bool)

Hypα∈N p∈B[0/α][z/γ]

α∈N v = (λc. if c=s(x) then true else if c<s(x) then fst(g1)(c) else false)

α∈N u∈A[0/α]

Γ

Hypq∈B[s(x)/α][v/γ]Γv∈(N⇒Bool)

Nfα∈N, x∈N, g1∈A[x/α]

∑iΓ q∈B[s(x)/α][v/γ]Γv∈(N⇒Bool)

N N g∈(A[x/α] ⇒A[s(x)/α])⇒i

g2∈A[s(x)/α]

Neα∈N α∈N

assN typeu∈A[0/α] f∈(∏x∈N • A[x/α] ⇒A[s(x)/α])α∈N α∈N

∏iα∈N, x∈N g∈(A[x/α] ⇒A[s(x)/α])

getLE ∈ (∏α∈N • ∑γ∈N ⇒ Bool • ∏β∈N • γ(β) = true ⇔ β ≤ α)∏iα∈N t∈ANe

Figure 7. Program extraction from the operation schema [M GetLE ]D


Appendix BProgram extraction from [M GetLE ]BD

We apply the extended version of ξ to the schema [M GetLE ]BD step by step; theresult will be a type in Martin-Lof’s theory of types:

[[M GetLE ]BD]ξ = (Πα ∈ (ξ(N))− · Σγ ∈ (ξ(seqN))−·[∀sc! ∈ N · sc! ∈ dsc ⇔ sc! ≤ n?]ξ)[(ξ(N))α/n?][(ξ(seqN))γ/dsc]

= (Πα ∈ (ξ(N))− · Σγ ∈ (ξ(seqN))− ·Πβ ∈ (ξ(N))−·[sc! ∈ dsc ⇔ sc! ≤ n?]ξ)[(ξ(N))α/n?][(ξ(seqN))γ/dsc][(ξ(N))β/sc!]

According to the interpretation of the set of natural numbers and sequences in [47]and also the fact that α, β, and γ are themselves elements of V , the followingequality is obtained:

[[M GetLE ]BD]ξ = Πα ∈ N · Σγ ∈ List(N) ·Πβ ∈ N · β∈γ ⇔ β ≤α,where β ≤α is an abbreviation for Σρ · β + ρ=α. Now we derive a program from acorrectness proof of the resulting type theoretical specification. An initial part ofsuch a proof is shown here:

A ≡ ∑γ∈List(N) • ∏β∈N • β ∈ γ ⇔ β ≤ αB ≡ ∏β∈N • β ∈ γ ⇔ β ≤ αΓ ≡ α∈N, x∈N, g1∈A[x/α]

getLE = λα • t t = natrec(α, u, f)u = (z, p) z = ⟨0⟩f = λx. g g = λg1. g2Γ α∈N, x∈N, g1∈A[x/α]

Hypg2 = (v, q) v = ⟨s(x)⟩ ^ fst(g1)

Hyp

α∈N z = ⟨0⟩

α∈N head(v) = s(x)Hyp

α∈N tail(v) = fst(g1)

Hyp

N A[0/ ]∑i

α∈N z∈List(N)

ypα∈N p∈B[0/α][z/γ]

α∈N u∈A[0/α]

∑iΓ

Hypq∈B[s(x)/α][v/γ]Γv∈List(N)

N typeNf

α∈N, x∈N, g1∈A[x/α] ∑i

∏iα∈N, x∈N g∈(A[x/α] ⇒A[s(x)/α])

⇒ig2∈A[s(x)/α]

Neα∈N α∈N

assypu∈A[0/α]α∈N f∈(∏x∈N • A[x/α] ⇒A[s(x)/α])α∈N

∏i,

getLE ∈ (∏α∈N • ∑γ∈List(N) • ∏β∈N • β ∈ γ ⇔ β ≤ α)∏i

α∈N t∈A

Figure 8. Program extraction from the operation schema [M GetLE ]BD


Appendix CProgram extraction from [M Sort ]BD

We use the extended version of the function ξ to translate the operation schema[M Sort ]BD. As in example 6, for convenience, we do not translate two schemasIncreasing and Perm which are included in the schema [M Sort ]BD.

[[M Sort ]BD]ξ = Πα ∈ (ξ(seq(N ×N)))− · Σγ ∈ (ξ(seq seq(N ×N)))−·([∀out ! ∈ seq(N ×N) · out ! ∈ dout ⇔ (out ! ∈ increasing ∧ (in?, out !) ∈ perm)]ξ)[(ξ(seq(N×N)))α/in?][(ξ(seq seq(N×N)))γ/dout]

= Πα ∈ (ξ(seq(N ×N)))− ·Σγ ∈ (ξ(seq seq(N ×N)))− ·Πβ ∈ (ξ(seq(N ×N)))−·([out ! ∈ dout ⇔ (out ! ∈ increasing ∧ (in?, out !) ∈ perm)]ξ)[(ξ(seq(N×N)))α/in?][(ξ(seq seq(N×N)))γ/dout][(ξ(seq(N×N)))β/out!]

By the interpretation of the set of natural numbers, the cartesian product construc-tor, and sequences in [47] and also the fact that α, β, and γ are themselves elementsof V , the following equality holds:

[[M Sort ]BD]ξ = Πα ∈ List(N⊗N)·Σγ ∈ List(List(N⊗N))·Πβ ∈ List(N⊗N)·β∈γ ⇔ (β ∈ ξ(increasing)⊗ (α, β) ∈ ξ(perm))

We can now derive a program from a correctness proof of the resulting type theo-retical specification. An initial part of such a proof is shown in Fig. 9. In the prooftree, we have used two conventions IN = ξ(increasing) and P = ξ(perm).


T = N ⊗ N

A ≡ ∑γ∈List(List(T)) • ∏β∈List(T) • β∈γ ⇔ (β∈IN ⊗ (α, β)∈P)

B ≡ ∏β∈List(T) • β∈γ ⇔ (β∈IN ⊗ (α, β)∈P)

nsort = λα • t t = lrec(α, u, f)

u = (z, r) z = ⟨⟨⟩⟩ r = λβ • s

s = (s1, s2) f = λa • g g = λx • h

C ≡ β∈γ ⇔ (β∈IN ⊗ (α, β)∈P)

D ≡ β∈IN ⊗ (α, β)∈P

Γ ≡ α∈List(T)

h = λh1 • h2 h2 = (v, q) q = λβ • m

v = T_Insert(a, fst(h1))T_Insert = λn • λs • lrec(s, ⟨⟩, λh • λt • λr • D_Insert(n, h)^r)Γ ≡ α∈List(T)

Ψ ≡ α∈List(T), β∈List(T) D_Insert = λn • λs • lrec(s, ⟨⟨n⟩⟩, λh • λt • λr •if snd(n) < snd(h) then ⟨⟨n⟩^(h::t)⟩ else if snd(n) > snd(h) then T_Concate(h, r) else ⟨⟨n⟩^(h::t)⟩^T_Concate(h, r))T_Concate = λn • λs • lrec(s, ⟨⟩, λh • λt • λr • ⟨⟨n⟩^h⟩^r)

Δ ≡ α∈List(T), a∈T, x∈List(T), h1∈A[x/α]Hyp Hyp

s1∈(β∈z ⇒ D[⟨⟩/α][z/γ])Ψ s2∈(D[⟨⟩/α][z/γ] ⇒ β∈z)Ψv = T_Insert(a, fst(h1))

Hyp

Δ

Γ z = ⟨⟨⟩⟩ Γ z = ⟨⟨⟩⟩

∑

Hyp

bΓ ⟨⟨⟩⟩∈List(List(T)) Γ z = ⟨⟨⟩⟩

Hyp

v∈List(List(T)) Δ Δ q∈B[a::x/α][v/β]∏i

s∈C[⟨⟩/α][z/γ]Ψ⊗i ∏i

Δ, β∈List(T) m∈C[a::x/α][v/β]

Γ

T tα∈List(T), a∈T, x∈List(T)

∏

α∈List(T), a∈T, x∈List(T), h2∈A[a::x/α]⇒i

h1∈A[x/α]∑i

z∈List(List(T)) r∈B[⟨⟩/α][z/γ]Γsub

h∈(A[x/α]⇒A[a::x/α])

∏i

⊗fN type N type

assList(T) type

Listf

u∈A[⟨⟩/α] α∈List(T)

T type

α∈List(T) f∈(∏a∈T•∏x∈List(T)•A[x/α]⇒A[a::x/α])α∈List(T)∏i

α∈List(T), a∈T g∈(∏x∈List(T)•A[x/α]⇒A[a::x/α])∏i

∑i

α∈List(T)

nsort ∈ (∏α∈List(T) • ∑γ∈List(List(T)) • ∏β∈List(T) • β∈γ ⇔ (β∈IN ⊗ (α, β)∈P))∏i

Listet∈Aα∈List(T)

Figure 9. Program extraction from the multi-schema M Sort


Appendix DProgram extraction from [[[M OurPlayer ]ead]sl]bu

If we apply the extended version of the function ξ to the schema [[[M OurPlayer ]ead]sl]bu,the following specification will be obtained in Martin-Lof’s theory of types:

Πα ∈ List(T ′) · (I[List(T ′), α, 〈〉] ⇒ Ω) ⇒ Σγ ∈ T ′ · γ∈α ⊗ (Πβ ∈ T ′ · β∈α ⇒sco(β)≤sco(γ)),where T ′ = (ξ(T ))−, and b ≤ a is an abbreviation for Σc · b + c = a. We can nowderive a program from a correctness proof of the resulting specification. An initialpart of such a proof is shown in Fig. 10. A complete proof similar to the onerequired here is given in [27].A simplified form of the extracted program is:

ourplayer = λα · lrec(α, abort ,λa·λx·λh1·(if fst(h1) = abort then a else if sco(a) ≥ sco(fst(h1)) then a else fst(h1), q))

This program is a recursive function that selects an element with the highest scorefrom a non-empty sequence. For the empty sequence, the program aborts:

ourplayer(〈〉) = abortourplayer(h :: t) = if ourplayer(t) = abort then h

else if sco(h) ≥ sco(ourplayer(t)) then h else ourplayer(t)

Software Quality Research Laboratory, Computer Engineering Department, Sharif

University of Technology, Tehran, IranE-mail address: [email protected], [email protected]


A ≡ (I[List(T’), α, ⟨⟩] ⇒Ω) ⇒∑γ ∈ T’ • γ ∈ α ⊗ (∏β ∈ T’ • β ∈ α ⇒ sco(β) ≤ sco(γ))

B ≡ ∑γ ∈ T’ • γ ∈ α ⊗ (∏β ∈ T’ • β ∈ α ⇒ sco(β) ≤ sco(γ))

C ≡ I[List(T’) α ⟨⟩] ⇒Ω

ourplayer = λα • t t = lrec(α, u, f)

u = λu1 • u2 u2 = abort B[⟨⟩/α] u3

u3 = u1 u4 u4 = r(⟨⟩) f = λa • gg = λx • h h = λh1 • h2 h2 = λh3 • h4

C ≡ I[List(T ), α, ⟨⟩] ⇒Ω

D ≡ ∏β ∈ T’ • β ∈ α ⇒ sco(β) ≤ sco(γ)h4 = (v, q) q = (q1, q2)

v = if fst(h1) = abort then a else if sco(a)≥sco(fst(h1)) then a else fst(h1)

α∈List(T’), u1∈C[⟨⟩/α]Γ ≡ α∈List(T ), u1∈C[⟨⟩/α] Γ

Listi1

Δ ≡ α∈List(T’), a∈T’, x∈List(T’), h1∈A[x/α], h3∈C[a::x/α]

Hyp

Hyp

sco(a) ≤ sco(v)

Hyp

sco(fst(h1)) ≤ sco(v)

Γ u1∈C[⟨⟩/α] Γ u4∈I[List(T’), ⟨⟩, ⟨⟩] ⇒e

ass Ii⟨⟩∈List(T’)

Listi1

Δ v∈T’

Hyp

Δ q∈(v ∈ a::x ⊗ D[a::x/α][v/γ])⊗i

Δ q1∈(v ∈ a::x) Δ q2∈D[a::x/α][v/γ]

Hyp

u2∈B[⟨⟩/α] α∈List(T’), u1∈C[⟨⟩/α] Ωe

u3∈Ωα∈List(T’), u1∈C[⟨⟩/α]

α∈List(T’), a∈T’, x∈List(T’), h2∈A[a::x/α]h1∈A[x/α]

α∈List(T’), a∈T’, x∈List(T’), h4∈B[a::x/α]⇒i

h1∈A[x/α], h3∈C[a::x/α]∑i

List(T’) typeListf

T’ typeα∈List(T’), a∈T’ g∈(∏x∈List(T’)•A[x/α]⇒A[a::x/α])

α∈List(T’), a∈T’, x∈List(T’)∏i

h∈(A[x/α]⇒A[a::x/α])⇒i

Liste

assList(T ) type

u∈A[⟨⟩/α]

t∈Aα∈List(T’)

α∈List(T’)α∈List(T’) α∈List(T’)⇒i

f∈(∏a∈T’•∏x∈List(T’)•A[x/α]⇒A[a::x/α])α∈List(T’)∏i

( )

ourplayer ∈ (∏α ∈ List(T’) • (I[List(T’), α, ⟨⟩] ⇒Ω) ⇒∑γ ∈ T’ • γ ∈+ α ⊗ (∏β ∈ T’ • β ∈ α ⇒ sco(β) ≤ sco(γ)))

∏i

( )

Figure 10. Program extraction from the multi-schema M OurPlayer

ce.sharif.educe.sharif.edu/~mirian/accepted paper/sqrl-001.pdf · nondeterminism in constructive z...

Documents