Scholarly article on topic 'An Approach to Nondeterminism in Translation of CZ Set Theory into Martin-Löf 's Theory of Types'

An Approach to Nondeterminism in Translation of CZ Set Theory into Martin-Löf 's Theory of Types Academic research paper on "Computer and information sciences"

CC BY-NC-ND
0
0
Share paper
Keywords
{"formal program development" / "nondeterminism in CZ language" / "nondeterminism in Martin-Löf's theory of types" / "translation of CZ set theory into Martin-Löf's theory of types"}

Abstract of research paper on Computer and information sciences, author of scientific article — Hassan Haghighi, Seyyed Hassan Mirian Hosseinabadi

Abstract Due to the high level of abstraction involved in formal specification of software systems, nondeterminism comes as an inevitable part of formal specifications. Therefore, support for nondeterminism should be provisioned in developing programs from their formal specifications. In this paper, an existing translation of CZ set theory into Martin-Löf's theory of types is extended to consider nondeterministic specifications in CZ language.

Academic research paper on topic "An Approach to Nondeterminism in Translation of CZ Set Theory into Martin-Löf 's Theory of Types"

Electronic Notes in Theoretical Computer

www.elsevier.com/locate/entcs

An Approach to Nondeterminism in Translation of CZ Set Theory into Martin-Lof's Theory of Types

Hassan Haghighi1

Department of Computer Engineering Sharif University of Technology Tehran, Iran

Seyyed Hassan Mirian Hosseinabadi2

Department of Computer Engineering Sharif University of Technology Tehran, Iran

Abstract

Due to the high level of abstraction involved in formal specification of software systems, nondeterminism comes as an inevitable part of formal specifications. Therefore, support for nondeterminism should be provisioned in developing programs from their formal specifications. In this paper, an existing translation of CZ set theory into Martin-Lof's theory of types is extended to consider nondeterministic specifications in CZ language.

Keywords: formal program development, nondeterminism in CZ language, nondeterminism in Martin-Lof's theory of types, translation of CZ set theory into Martin-Lof's theory of types

1 Introduction

Developing programs in the traditional style has long been criticized: It is not a good vehicle for developing reliable software systems [3]. The only method, in this style, to demonstrate that the program works successfully and meets

1 Email: haghighi@ce. sharif . edu

2 Email: mirian@sharif.edu

Available online at www.sciencedirect.com

SCIENCE DIRECT«

Electronic Notes in Theoretical Computer Science 159 (2006) 117-

1571-0661/$ - see front matter © 2006 Elsevier B.V. All rights reserved. doi:10.1016/j.entcs.2005.12.065

the specification is program testing. It is known that the testing process, which is the last step of the programming stage, does not guarantee that a program is correct and only detects situations in which it does not work [13]. For this, testing must be complete in covering every possible operational situation. For real systems, this is either expensive or impossible to achieve [10].

The use of mathematics in software development is the solution that formal methods propose to increase the level of reliability and correctness of software systems [37]. Formal methods can be used in any stage of software development from the initial statement of a customer's requirements, to system implementation and verification. A logical deduction in [22] shows the necessity of using formal methods in software engineering.

Having specified a problem formally, the question is how a program can be developed so as to guarantee that it meets the requirements. Several approaches have been proposed to develop programs from their formal specifications, one of which is the method of deriving programs from the correctness proofs of formal specifications based upon constructive mathematics [30].

Martin-Lof's theory of types is a constructive formalism that is well suited as a theory for program construction, since it is possible to express both specifications and programs within the same formalism. Furthermore, the proof rules of this theory can be used to drive a correct program from a specification as well as to verify that a given program has a certain property [35]. However, its infrastructure for the organization and manipulation of specifications is rather meager. In contrary, Z [38] is an excellent specification notation but it is comparatively weak in terms of its program development facilities. To employ the facilities of Z as a specification medium and ideas of constructive type theory for program development, [30] provides an interpretation of CZ, a constructive version of the Z notation, in Martin-Lof's theory of types.

1.1 Nondeterminism and program development

The concepts of nondeterminism and nondeterminacy have found their way into computing science since its early days; the use of nondeterminism in algorithms [15,9], abstract data types [40,16] and imperative programming languages [12] are but a few examples. The notion of nondeterminism arises naturally in describing concurrent systems when timing or scheduling information is unavailable or difficult to calculate [7,36]. Various approaches to the theory and specification of such systems, for instance, CCS [29], CSP [21] and ACP [5], include the phenomenon of nondeterminism.

Nondeterminism is also a natural concept in describing sequential programs, either as a means of indicating a "don't care" attitude as to which among a number of computational paths will actually be utilized in a par-

ticular computation [46] or as a means of increasing the level of abstraction [16]. Abstraction is one of the most important benefits of formal specifications. It enables us to specify computer systems without paying attention to implementation details.

Different types of nondeterministic constructs and their semantics have been defined in the literature [17,39,45]. Three major classifications are:

• Singular and plural nondeterminism: Singular and plural nondeterminism coincide with call-by-value and call-by-name semantics in programming languages [46]. In plural nondeterministic semantics, decisions regarding nondeterminism on a same structure are made independently. However, in singular semantics always same decision is made in different places using same nondeterminate structure [45]. Fairness issues could be also discussed in plural semantics [36].

• Strict and loose nondeterminism: In the strict interpretation of nondeter-minacy, one wants that all possible outputs of a program to be produced. Such an interpretation is required to compare different implementations of a specification or to verify all possible outputs for an input. In the loose interpretation, however, the existence of more than one output for each input is only regarded in the specification stage. The final implementation itself should be deterministic; i.e. the implementation mechanism always produces a single output for each input.

• Erratic, angelic and demonic nondeterminism: Termination of a program may depend on the choices made in the nondeterministic construct. If a nondeterministic choice is made regardless of its impact on termination, it is called erratic. On contrary, if the choice is to be made in favor of termination (if possible), we should have angelic or demonic choice semantics. The prerequisite of angelic choice is that at least one of the possibilities results in termination of the program. In terms of Dijkstra's correctness criteria, this corresponds to partial correctness [14,11]; in the demonic interpretation, however, all the possibilities should result in termination. In terms of Dijkstra's correctness criteria, this corresponds to total correctness [14,11]; however, the angelic and demonic interpretations of nondeterminacy can be generalized to other properties. Angelic nondeterminism occurs when the choice is made by an angel. It is assumed that an angel will choose the best possible outcome. Demonic nondeterminism occurs when the choice is made by a demon. No assumption can be made about the choice made by a demon. For example, in a two player game the choices of our player could be modeled by angelic nondeterminism and those of our opponent by demonic nondeterminism [28]. Based upon this general definition, in [17], with some property such as termination in mind, whenever this property

should be satisfiable by at least one of the possibilities, nondeterminism will be angelic, and if all the possibilities should satisfy this property, the nondeterminism will be demonic.

Having implicit nondeterminism in formal specifications introduces problems in constructing executable specifications [20], and makes the process of program development a questionable task [30]: As shown in [18], after developing programs from such specifications, only one of the possible states appears in these programs. In this way, possibility of comparing different implementations of a specification and choosing one of them in the implementation phase will be eliminated. Also plural (and fair) nondeterminism cannot be implemented and we cannot specify the other modalities of nondeterminacy such as the angelic and demonic ones in the specification phase.

Hence, appropriate notations and semantics should be developed in formal methods to facilitate modeling nondeterminism in specifications. The syntactic notations for modeling nondeterministic semantics are called non-determinate constructs. Using such constructs not only solves the problem of implicit nondeterminism in program development, but also provides a clearer view of nondeterminism in both specifications and extracted programs. Based on this idea, nondeterminate constructs have been added to different formal specification languages. A survey on these activities can be found in [18].

In [32], some basic notations, called multi- and power-schema, were added to Z formal language to help explicit specification of nondeterminate constructs. Also, in [18], an approach for using nondeterminate constructs in Martin-Lof's theory of types was presented and deterministic semantics for these constructs were defined. In this paper, the work done in [30] is extended to map nondeterminate constructs in [32] to their counterparts in [18] directly.

In section 2 the approaches of [30], [32] and [18] are summarized to give a better understanding of future discussions. An extension of [30] to consider nondeterminism is proposed in section 3. In this section we show that this extension is equivalent to the interpretation of CZ nondeterminate constructs in [32], such that both methods result in equivalent programs. The last section is devoted to the conclusions and directions for future work.

2 Preliminaries

In this section, first, the constructive set theory CZ is given. Then we explain Martin-Lof's theory of types. The interpretation of CZ in Martin-Lof's theory of types [30] is discussed in subsection 2.3. In subsection 2.4, we recall an approach to add nondeterminate constructs to CZ specification language [32]. Finally we mention the way, in which nondeterminate constructs can be

defined in Martin-Löf's theory of types [18]. 2.1 Constructive Z (CZ)

Set theory is the foundation of mathematics, and all mathematical concepts are defined in terms of the primitive notion of set and membership. In axiomatic set theory a few simple axioms about these primitive notations are formulated and the basic set theoretic principles are captured from them.

Constructive set theory (CST) originated with Myhill's paper [34]. It is a possible framework for the formalization of Bishop's constructive mathematics [4]. Aczel in [1] gave the description of a system (CZF) of the constructive set theory that is very close to Myhill's system. In fact, it is essentially an extension of CST and a subsystem of the classical set theory ZF.

We use CZ [30], which is a weaker version of CZF, as a basis for our Z-like specification language. The logic and language of CZ set theory are the same as those of CZF. All proof rules of the classical set theory ZF can be used in CZ except the rule of classical negation, which has to be avoided because of the absence of the law of excluded middle. The axioms are those of CZF except the collection axioms. Also a new axiom concerning the Cartesian product set constructor is added. In the following, we list some set theoretic axioms of CZ and discuss them:

Extensionality: VxVy ■ (x = y o (Vz ■ z G x o z G y)) Empty set: 3xVy ■ — (y G x) Pairing: VxVy3z ■ x G z A y G z Union: Vx3zVy G xVu G y ■ u G z Infinity: 3xVy ■ y G x o y = 0V3u G x ■ y = {u} Decidable power set: Vx3zVy ■ y G z o y Q x Cartesian product: VxVy3z ■ Vu G xVv G y ■ (u, v) G z The first axiom, Extensionality, states: If two sets have exactly the same members then they are equal. The Empty set axiom guarantees the existence of empty set. All other sets are made from the empty set, and according to the Extensionality axiom, this set is unique. The Pairing axiom expresses that for every two sets there is a set that they can belong to and there is nothing else in it. The Union axiom is defined to build a set from the members of other sets. The infinity axiom guarantees the existence of infinite sets. The relationship y Q x indicates that y is a decidable subset of x, and is defined as follows:

Definition 2.1 Let y C x. Then y is a decidable subset of x iff Vu G x ■ u G y V —(u G y)

The Decidable power set is the most important difference from the classical counterpart. In the classical theory the power set is not restricted: any kind of subset is permitted, not just the decidable sets. Of course, if the law of excluded middle is in place, then every subset is decidable. Once again, this goes further than the constructive strictures imposed in the theory CZF. In CZF, power set is not tinkered with; it admits arbitrary subsets into the power set. CZ only permits those which can be constructed in the sense that we can determine their membership relative to their superset. Intuitively, the decidable subsets can be identified with finite routines which test for membership. This is more in keeping with constructive scruples which reject the Power set axiom in its traditional form because of its extreme impredicativity.

The usual way of defining the Cartesian product of two sets, in presence of power set, is as follows:

x x y = {z e P(P(x u y))|3u e x3v e y • z = (u, v)} Since the decidable version of power set is used, it is not sensible to use this definition and it is necessary to add Cartesian product of two sets as an axiom.

By Restricted separation axiom, it is possible to define any subset of a set which satisfies the formula . The demand that be restricted, in the Restricted separation axiom, shows that CZ follows the strictures of intuitionism more carefully and only permits restricted formula to determine subsets. The Foundation axiom in ZF is the only axiom of this theory which implies the law of excluded middle, and thus has been replaced with the axiom of Set induction.

What is suggested in [30] to specify programs is a notation very close to the Z notation with all mathematical toolkits of Z. The only thing that is changed is the underlying theory, namely, Z to CZ. Specially, the process of replacing instances of power set by decidable ones is equivalent to the process of determining whether specifications specify decidable problems or not. In other words, the existence of such a characteristic function for the specified set guarantees the existence of the program corresponding to the specification of that set.

2.2 Martin-Löf 's theory of types

Constructive type theory was originally developed as a symbolism for the precise codification of constructive mathematics by Per Martin-Löf [27]. MartinLöf theory of types is an appropriate formalism for program construction since it is possible to express both specifications and programs within the same formalism. Furthermore, the proof rules of this theory can be used to drive a correct program from a specification as well as to verify that a given program has a certain property [35]. As a programming language, type theory is

comparable to typed functional languages, such as ML and Haskell, since its expressions are based upon a version of A — ca/cu/us. The relation between type theory and functional programming has been investigated by Thompson in [41].

Unlike most other formalizations of mathematics, type theory is not based on first-order predicate logic; instead, predicate logic is interpreted within type theory through the correspondence between propositions and sets (types). A proposition is interpreted as a set whose elements represent the proofs of the proposition. In other words, each proposition is the type of its proofs. So, logical operations are identified with the appropriate type forming operations in line with the constructive meaning of logical operations. Moreover, a set can be viewed as a problem description, and the elements of the set are possible programs or algorithms that solve the problem. Hence, in type theory, specifications can be expressed by mathematical propositions, and program development process consists of functional specification of problem, by giving its type, and then constructing an object of that type, using the inference rules of the logic. This object of the type, if exists, can be viewed as a program which satisfies the specification.

The fundamental notions of type theory are type and element of a given type, say A. A type is well defined if we understand what it means to be an object of that type. Suppose now that A and B are types. then:

• The form A ^ B is the type of function Ax ■ y [x] such that y[x] e B for x e A. This form is the type theoretic equivalent of the proposition A ^ B.

• The form A ® B is the type of pairs, (x, y) such that x e A and y e B. if z is the ordered pair (x, y) then fst(z) and snd(z) will be the two components x and y respectively. This form is the type theoretic equivalent of the proposition A A B.

• The form A 0 B is a type called disjoint union of the two types. It is the type of objects of the form l(x) with x e A or r(y) with y e B. This form is the type theoretic equivalent of the proposition A V B.

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

• For each nonnegative integer n, There exists a type Nn with precisely the n objects 1, 2,..., n. Actually, it would suffice to introduce N0 and N^ because, for n > 1, we may define Nn to be the disjoint union of N with itself n times. N0 is the empty type or the type theoretic equivalent of the proposition Q (absurdity). For n > 1, Nn is equivalent to the proposition True.

• The form Пх G A.B, is the type of functions which take an arbitrary object x of type A into an object of type B [x]. This type is a dependent type, called dependent product. Dependent type is a type expression which describes different sets of objects depending on the value taken by a variable appearing in the type expression. To define these new forms of type, it is useful to define a family of types over a type A. Such a family of types is a function Ax.B[x] that assigns a type B[x] to each x G A. The equivalent proposition of Пх G A.B is Vx G A.B[x].

• The form Ex G A.B, is the type of pairs (x, y) where x and y are elements of types A and B[x], respectively. This type is a dependent type, called dependent sum. The equivalent proposition of Ex G A.B is 3x G A.B[x].

In the constructive type theory, the major step in program development is finding an object of the type which represents the specification. This task can be done via the construction of proofs. It has to be shown that the specification can be met. The inference rules in type theory are presented in Gentzen's natural deduction style. There are two types of inference rules, introduction and elimination, for each type constructor, which correspond to the introduction and elimination rules of natural deduction systems for predicate logic. In addition, type theory has formation and computation rules. The formation rules are necessary because the property of being a type is not decidable. The computation rules define the computational meaning of the type constructors.

Several formulations of type theory have been proposed; however, in this paper, we use the intensional type theory which has been strengthened with two types U (universe) and W (well-founded). Intensional means that the judgmental equality is understood as definitional equality. Thus, equality is decidable. The existence of intensional equality is a prerequisite for automatic program construction within type theory. The type U is called the universe and its elements are types together with the reflection principle. Roughly speaking, this principle says that whatever we are used to doing with types can be done inside the universe U.W is the type former for tree inductive types: The form Wx G A.B is the type of elements denoted by sup(x, f), where x G A and f is a function from B[x] to Wx G A.B. An important property of the type W is that we can always, for each element Wx G A.B recover the set a G A and the corresponding mapping a~ G B[a] ^ Wx G A.B, such that a = sup^, a~).

2.3 Interpretation of CZ in Martin-Löf's theory of types

To give a constructive meaning to the set theoretical notions of CZ, [30] justified its interpretation into Martin-Lof's theory of types. Informally, the idea behind the interpretation is to find a constructive version of the classical iterative notion of sets.

In order to interpret the language of set theory, it is necessary to have a type (set) which can be used as the universe of sets and the model for CZ. The intention is to build a model v =< V, e, = >

of CZ in Martin-Lof's theory of types. In this model each set is associated with a pair consisting of a base type together with a family of types, its elements. This is furnished as follows: V = Wx e U.x

Where U is the universe and W is the type former for tree inductive types. It is necessary to distinguish between = and e on the one hand, which are primitive symbols in type theory, and = and e, which will be defined as the type theoretic interpretation of = and e from CZ, respectively.

Now we show what the interpretation of well-formed formulae and atomic formulae are in type theory. Let £ be assignment function which assigns elements of V to the variables of the language of CZ. The following equalities give the results of applying this function to some elements of CZ: [Q]? = Q

[x = yk =£ (x)=£ (y)

[x e yk = £(x)e£(y)

№ A ^ = [^ <g>

№ v ^ = [^ ©

[<£ ^ Vk = ^ [^k

[Vx g y ■ ^ = na g (£(y)) ■ [^]i[(i(y))-Q/x] [3x G y ■ ^ = Sa G (£(y))■ [^]i[(i(y))-«/x]

Finally, according to the future discussions in this paper, we show the interpretation of some set theoretic axioms of CZ:

Cartesian product: (a x P) = a ® pT, (a x P)~(a, b) = (a~a, P~b) Decidable power set: P(a)" = a" ^ Boo/ , P(a)~/ = sup(SP e a" ■ /P=True, Au ■ a~/st(u))

Infinity: aT = N , a~n = (n, 0, y+)

2.4 Explicit nondeterminism in CZ

In [32], possibility of several after state valuations for a single before state binding in an operation schema was regarded as a clear notion of nondeter-minism in CZ(Z). Therefore, Nondeterministic CZ(Z) specifications were defined as follows

Definition 2.2 An operation schema is nondeterministic iff there exists a single set of values of before state (or input) variables that with two or more different sets of values of after state (or output) variables can satisfy schema predicates. Specification of a system is nondeterministic iff there exists at least one nondeterministic operation schema that is defined on its state schema.

Then multi-schema was defined as a tool to specify nondeterminism explicitly.

Definition 2.3 A multi-schema is a version of an operation schema with non-deterministic after state (or output) variables.

The following nondeterminate construct, shows the definition of a nonde-terministic variable3 in CZ: ndvar G 5Type

By nondeterministic variable, we mean a variable that can have more than one value in each state. In other words, the nature of nondeterministic variable is equivalent to the power set of the basic type. This definition will help making nondeterminism in operation schemas explicit by providing set of possible after states in their declaration part. To mean this concept, if a multi-schema has the form Schema = [declaration¡preconditions, postconditions] 4 , and the set of its nondeterministic variables is shown by declaration" , the interpretation of Schema in CZ is as follows: [Forall ndVar G declaration" :

declaration [var G PType/ndVar G 5Type] ¡preconditions, Vvar G Type ■ var G ndVar о postconditions]

In the above schema, the notation of nondeterminism (nondeterministic variable) was replaced by power set, and universal quantifier was applied to

3 The idea of nondeterministic variable and its symbol (5) has been adopted from [2].

4 In this form, the predicate part of an operation schema is divided into two parts, namely, preconditions and postconditions. Both the predicates together describe the relation between schema variables. Having explicit preconditions and postconditions is one of the major differences between CZ and Z. The correctness of a specification can be proved easier when preconditions are specified explicitly. Moreover, this style encourages us to prove the well-formedness theorem (i.e., the precondition must guarantee the existence of a final state satisfying the postcondition) [30]. The explicit pre- and post-conditions have also been suggested by other researchers; for example see [6].

possible values. Therefore, nondeterministic variable was transformed to a maximal set of deterministic values, which could satisfy the postconditions of the specification.

But to define multi-schema, there is a problem associated with schemas containing more than one after state (output) variable; the problem is that if we promote each after-state (output) variable to its power type and place a universal quantifier in front of the schema postconditions to contain all possible values, the relationship between valuations that make the schema predicates true will disappear. To overcome this problem, we can combine all previous after state (output) variables in a new variable using Cartesian product of their types and then apply the nondeterminism operator for multi-schema.

In [32], two symbols □ and ♦ were used to model demonic and angelic non-determinism, respectively. These nondeterminate constructs were interpreted as follows:

Definition 2.4 Let

Schema = [dec/aration^preconditionsi^ , postconditions^ and

Schema2 = [dec/aration2|preconditions2, postconditions2] be two operation schemas in CZ. Then: Schemai □Schema = [declaration U dec/aration21 preconditions;! Л preconditions^ postcondition^ V postconditions2] Schema OSchema2 = [declaration U declaration1 preconditionsi V preconditions2, postconditionsi V postconditions2]

2.5 Explicit nondeterminism in Martin-Löf's theory of types

In [18], a general form of a specification of an operation in type theory has been introduced as follows:

nui G Ai, U2 G A2,..., Un G An • (ф ^ Evi G Bi, V2 G B2,..., vrn G Bm • , where ф and ф are the pre- and postconditions of the operation, respectively. Also, Ui(i:1..n) are input variables and Vj(j:1..m) are output variables. Thus according to works done in [32] and [2], nondeterministic variables have been defined to express nondeterminism in a specification explicitly. The following nondeterministic construct, shows the definition of a nondeterministic variable in type theory: ndvar G 5Type

With the power set of a type Type in type theory, e.g., in the form of PType, if at least one of the variables Vj(j:1..n) in the general form is nonde-terministic, the meaning of this proposition can be defined as follows:

П-ui G Ai, u G A2,..., Un G An • (ф ^ SndV G P(Bi © B2 © ... © Bm) • n(vi, V2, ..., Vm) G (Bi © B2 © ... © Bm) • (Vi, V2, ..., Vm) G ndV О

In the above proposition (type), the notation of nondeterminism (nondeter-ministic variable) was replaced by power set, and dependent product was applied to possible values. Therefore, nondeterministic variable was transformed to a maximal set of deterministic values, which could satisfy the postcondition of the specification. Since an output variable can satisfy the postcondition of the specification along with the other output variables, a Cartesian product is applied to these variables to preserve the relationship among them after the mentioned transformation.

Adding the power set concept to type theory involves complications which are represented in [18]; however, in order to introduce constructive set theory CZ in [30], subset and power set semantics were replaced by decidable versions, and then in the process of translating CZ into type theory, the decidable power set was transformed to a set of Boolean-valued functions, as follows: PS = S ^ Boo/

Using such an interpretation of power sets, the meaning of the general form of a specification in type theory could be transformed as follows:

nui G Ai, u2 G A2,..., un G An• (ф ^ SndV G (Bi©B2©...©Bm) ^ Boo/• n(vi,v2, ...,vm) G (Bi © B2 ©... © Bm) • I[Boo/,ndV(vi,v2,..., vm), True] О

The output of a program which is extracted from a specification in the form of proposition (3) is a Boolean-valued function. Hence, to gain all the possible outputs, another process is required in which the resulted function should be applied to all the elements of its domain. On the other hand, it has been proposed to replace instances of P by instances of F (finite power set) and then to refine them to finite sequences, in the process of program development [24], since people concern only those elements of P which are finite and as a result decidable. Hence, the specifications in form (3) can be seen as follows:

nui G Ai,u2 G A2,..., un G An • (ф ^ SndV G List(Bi © B2 © ... © Bm) • n(vi, V2, ..., Vm) G (Bi © B2 © ... © Bm) • InLiSt((vi, V2, ..., Vm), ndV) О

In the above proposition, /nList((vi,v2,,vm),ndV), indicates the existence of (vi, v2,..., vm) in sequence ndV, and is defined recursively as follows (П is absurdity, and x G type and / G List (type)): In/ist(x, /) = (I[List(type), /, <>] ^ П) ©(/[type, x, head(/)] © In/ist(x, tai/(/)))

In [19], we applied modifications to the above approach to consider modalities of nondeterminacy. To be consistent with [32], we only recall the angelic and demonic interpretations of nondeterminacy in type theory. A major difference between type theory and common typed functional languages is that

the evaluation of a program, extracted from a type theory specification, always terminates [35]; however, the angelic and demonic interpretations of nondeterminacy can be generalized to other properties. It is possible that evaluation of an extracted program in type theory aborts without producing any output, when its input does not satisfy the precondition of a specification. Hence, aborting of a program can be seen as a certain property to distinguish demonic and angelic nondeterminism.

Erratic nondeterminism corresponds to the simple concept of free choice, and then can be defined by applying a © to given specifications. We can specify angelic and demonic nondeterminacy explicitly in type theory as follows:

Definition 2.5 If Si and S2 are specifications of two operations in type theory, S1nS2 (S1^S2) indicates the demonic (angelic) nondeterministic choice between S1 and S2.

In [19] we concentrated on the relationship between relational semantics and predicate transformer semantics and concluded that the angelic nonde-terministic choice between the specifications

nai G Ai, a2 G A2,..., an G An ■ (0i ^ Sbi e Bi, 62 G B2,..., bm G Bm ■ ^1) and

nci G Ci, C2 G C2,..., ck G Ck ■ (02 ^ Sdi G Di, d2 G D2,..., d, e D, ■ ^2) yields the following specification:

nai G Ai, a2 G A2,..., an G An, ci G Ci, C2 G C2,..., Ck G Ck ■ (0i © 02 ^ Sbi G Bi, 62 G B2,..., bm G Bm, di G Di, d2 G D2,..., dj e D, ■ Vi © ^2)

In a similar way, the demonic nondeterministic choice between the above stated specifications results in the following specification:

nai G Ai, a2 G A2,..., an G An, Ci G Ci, C2 G C2,..., Ck G Ck ■ (0i © 02 ^ Sbi G Bi, b2 G B2,..., bm G Bm, di G Di, d2 G D2,..., dj G Dj ■ ^i © ^2)

In the next section the translation in [30] will be extended to cover new (nondeterminate) constructs in CZ.

3 Translation of nondeterminism

In this section we improve the translation of CZ set theory into Martin-Lof's theory of types by mapping CZ nondeterminate constructs to their counterparts in type theory. We show that this extension is equivalent to the interpretation of nondeterminism in CZ [32].

3.1 Extending the assignment function £

In subsection 2.3 we reviewed the assignment function £ which assigned elements of a model V in type theory to the formulae of CZ. Fortunately, non-determinate constructs 5, □ and ♦ , have been defined in type theory [18,19], similar to what have been introduced in [32]. Hence, it seems that we can easily extend £ to translate nondeterminate constructs; however, to show the power of new mechanism and also the equivalence between our approach and that of [32], we should consider another issue.

In [30], Mirian provided a framework to translate sets, intuisionistic expressions and axioms of CZ, but he did not give any solution to map schema calculus as a distinctive feature of CZ specification language. In [26], some methods have been investigated to transport the schema calculus to the type theory UTT 5 [25]. Firstly, a direct encoding of schemas as E-types has been proposed. This initial solution turns out to be unsatisfactory because encoding the operations of the schema calculus requires the ability to perform computations on the syntax of schemas, so [26] has developed methods in which this syntax can be also represented. These methods involve some complications in comparison to the initial approach. Therefore, we assume that all the operations of the schema calculus which occur in a specification should be applied before we begin the translation.

According to the above discussion, we employ the first idea of [26] to translate schemas into some types in type theory. In this way, if S is an operation schema, we can extend the function £ to map it to an element of model V, as follows:

[S]« = nai £ (£(Ai)), «2 £ (£(A2))...,a„ £ (£(A„))r■ ([0]« ^ Eft £

(£(Bi)),ft2 £ (£(B2)); £ (£(Bm))- M«)[(«(Ai))~ai/xi][(«(Bj))/%/yj]

, where 0 and ^ are the pre- and postconditions of S, respectively. Also, Xi(i:1..n) are input (or before sate) variables and y (j:1..m) are output (or after state) variables. With the definition of function £ and its recent extension, we can conclude the following equality:

[S]« = [Vxi £ Ai, X2 £ A2,..., xn £ A„ ■ (0 ^ 3yi £ Bi, y2 £ £2,..., ym £ Bm ■ ^)]«

Let us now define a straightforward extension of the assignment function £ to translate nondeterminate constructs 5, □ and ♦ into type theory. If Si and S2 are two schemas in a CZ specification, the following equalities are valid: [x £ 5y]« = £(x)££(y) [Si^k = [Si]« [SiOS2 ]« = [Si]« 0[S2k

5 Unifying Theory of Dependent Types

In example 3.1, we show the power of the new framework to extract a program from a given specification in CZ. This specification contains a non-determinate construct and the extracted program from it will produce all possible results for each input.

Example 3.1 The following operation schema in CZ specifies an operation by which for each natural number x, a number less than or equal to it, is computed. In this specification y! is a nondeterministic variable: [S] ^ [x? G N,y! G ¿N|y! < x?]

To extract a program from the above specification, we apply the extended function £ to the schema S step by step. The result of these applications is a type in Martin-Lof's theory of types:

[Sk = Па G (£(N))• SP G ¿(£(N))• [y! < x?]*W)W*W)W»H = (Па G (£(N))• Se G ¿(£(N))• £(y!)<£(x?))[(i(N)Wx?] [(€(n)Wy!] = Па G (£(N))• Se G ¿(£(N))• £((£(N))£)<£((£(N))a) = Па G (£(N))• Se G ¿(£(N))• (£(N))в<(£(N))а

According to the interpretation of natural numbers in [30] and also the fact that а and в are two elements of V, the following equality is resulted: [Sk = Па G N • Se G ¿N • в< а

With the semantics of nondeterministic variable in type theory [18], the following equalities can be concluded:

[S]^ = Па G N • SndV G (N ^ Boo/) • Пв G N • I[Boo/, ndV(в), True] О в < а

[S^ = Па G N • SndV G List(N) • Пв G N • /n/ist^, ndV) О в<а We consider the second equality and then extract a program from the correctness proof of the resulted specification. The obtained program is Аа • рпт(а, (< 0 >,p), (Ax • Ac • (< S(x) fst(c), q))). p and q are correctness proofs of z = 0 and v = S(x) ^ fst(c), respectively. The extracted program results in sequence < 0 > for а = 0. Also, in the recursive step (computing the output for а = S(x)), the result is equal to < S(x) fst(c). ^ is the symbol of concatenation of two sequences and fst(c) is the output for а = x. Hence, this program produces a sequence consisting of all possible results for each а G N.

If we use the first equality, the following program will be extracted: Аа • рпт(а, ((Ab if b = 0 then true else /a/se),p), (Ax• Ac• ((Ab if b = S(x) then true else if b < S(x) then /st(c)(b) else /а/se), q)))

In this program, the result for each а G N, is a Boolean-valued function. The output of this function is true iff its input is one of the possible results. As we mentioned before, in order to gain actual outputs, another process is required.

In the next subsection, we will show that the approach of this paper is equivalent to the interpretation of nondeterminate constructs in CZ [32].

3.2 Preserving the interpretation of nondeterminism in CZ

We prove that the use of the extended version of the assignment function £ does not change the semantics of nondeterminate constructs in CZ. Theorem 3.2, asserts this fact about nondeterministic variables:

Theorem 3.2 Let S be a schema in CZ specification language which contains at least a nondeterministic variable. If M' is a specification (type) that is obtained from translating S by £ and then interpreting nondeterministic variable in type theory and M" is another specification (type) that is obtained from interpreting nondeterministic variable in CZ and then translating the resulted specification by £, two specifications M' and M" are equivalent.

Proof. If at least one of the input (or before state) variables of S is nondeter-ministic, encoding of this schema in type theory and then interpreting nonde-terministic construct yields to the following specification (M') in Martin-Löf's theory of types:

nai G (£(Ai)), «2 G (£(A2)),..., an G (£(An))• ([Фк ^ EndV G ((£(Bi))® (£ (B2)) ® ... ® (£ (Bm))) ^ Boo/ • П(вь в2, ..., в m) G ((£(Bi))® (£№))( ... (g) (£(Bm))) • I[Boo/,ndV(ei,e2, ...,em),True] о [фк), where ф and ф are the pre- and postconditions of S, respectively. Also, Xj(i:1..n) are input (or before sate) variables and yj(j:1..m) are output (or after state) variables. Now, if the nondeterminate construct in nondeterministic schema S is translated into its semantics in CZ, according to the discussions in 2.4, the following schema can be resulted.

[S'] = [xi G Ai,X2 G A2,..., Xn G An, ndV G P(Bi x B2 x ... x Bm)| Ф, V(yi, У2, ..., ym) G (Bi x B2 x ... x Bm) • (yi, У2, ..., Ут) G ndV О ф] The application of the function £ to the schema S' results in the specification M" in type theory, as follows:

[S'k = nai G (£(Ai)) «2 G (£(A2))...,an G (£(An)) • ([Фк ^ E7 G (£(P(Bi x B2 x ... x Bm)))• n(ei,e2,...,em) G ((£(Bi))g (£(B2))g ... g (£ (Bm))) • (ei ,e2,...,em)(É(£P (Bi x B2 x ... x Bm )))~Y О [фк)

In the above translation, we used the interpretation of Cartesian product in [30]. To proceed with the translation of the schema S', we should use the interpretation of (decidable) power set in [30]. This interpretation is repeated in the following:

(Pa) ^ a" ^ Boo/ , (Pa)/ = sup (Ев G a" • /в= True, Au • afst(u)) Using the interpretation of Ex G A • B in Martin-Löf's theory of types,

we can simplify the semantics of (PaJ/. With this interpretation, Ex e A ■ B is equal to a subset of a set A whose elements satisfy a property B. Hence, vG(Pa)~/ can be realized as /v = True. According to the mentioned interpretation of power set, the following equality holds:

[S']« = nai G (£(Ai)), a2 G (£(A2))-,..., an G (£(An)) ■ ([0]« ^ Ey G ((£ (Bi)) © (£ (B2)) © ... © (i(Bm))) ^ Boo/ ■ n(A,&,...,£m) G ((£ (Bi)) © (i(B2))© ... © (i(Bm))) ■ Y(A, ft, ..., ^m)^TrUe O [1]«)

Therefore, [S']« is equal to M' and the proof is completed. □

Now we state and prove a similar theorem for nondeterminate constructs □ and ♦:

Theorem 3.3 Let S be a schema in CZ whose pre- and postconditions are 0 and p, respectively. Also, Xi(i:1..n) are input (or before sate) variables and y, (j:1..m) are output (or after state) variables of S. In a similar notation, Let S' be a schema in CZ whose pre- and postconditions are 0' and p', respectively. Also, Xi(i:1..n') are input (or before sate) variables and yj(j:1..m') are output (or after state) variables of S'. We can assert the following equalities: [S ♦S']« = [S]«0[S']«

Proof. According to the interpretation of nondeterminate construct ♦ in 2.4, the following equality is valid:

[S♦S']« = [[Xi G Ai,X2 G A2,...,Xn G An,yi G Bi,y2 G B2,...,ym G Bm,xi G A'i,x/2 G A2,...,xn',yi G Bi,y2 G B2,...,ym' G Bm' G An'|0 V 0',1 V

Also, with the definition of the assignment function £, we conclude the following equality:

[S♦S']« = nai G (£(Ai)) a2 G (£(A2))",..., an G (£(An))ai G (£(Ai))^G

(£(A2)r,...,an' G (£(An'))■ ([0]«© [0']« ^ Eft G (£(Bi))ft e (£(B2)) G (£(Bm)), # G (£(Bi)), $ G (£(B2)),..., G (£(Bm'))■ [1]« © [i]«)

Finally, we can use the semantics of the nondeterminate construct ♦ in 2.5 and assert that [S♦S']« = [S]«♦[S']«. In a similar way, we can conclude a similar fact about the nondeterminate construct □. □

4 Conclusions and future work

In this paper, we extended an existing translation of CZ set theory into Martin-Lof's theory of types to consider nondeterminism in CZ specifications. In the new framework we can map nondeterminate constructs in CZ [32] to their counterparts in type theory. As proved in subsection 3.2, this mapping pre-

served the interpretation of nondeterminate constructs in [32]. In other words, both approaches result in equivalent programs. Since we have introduced other modalities of nondeterminacy in Martin-Lof's theory of types [19], this paper can be generalized to consider these interpretations of nondeterminism. Another direction for future research can be to provide angelic and demonic choice semantics with choice probabilities. In this view, one can associate a selection probability to each choice [42] and probe the effects of these probabilities on extracted programs. In [33], a simple calculus for both nondeterministic and probabilistic choice has been studied.

In [30], Mirian provided a framework to translate sets, intuisionistic expressions and axioms of CZ, but he did not give any solution to map schema calculus as a distinctive feature of CZ specification language. In this paper, we assumed that all the operations of the schema calculus which occur in a specification should be applied before we begin the translation, and then we employed the first idea of [26] to translate schemas into some types in type theory. This solution is rather primitive and does not cover the schema calculus of CZ. By extending the current framework to interpret the schema calculus in Martin-Lof's theory of types, we obtain an alternative semantics for the schema calculus, based on type theory rather than set theory. As a related work, Henson and Reeves in [23] introduced a logic for the schema calculus of Z. This was constructed within the specification logic ZC, which is a constructive and intensional interpretation for the specification language Z.

The translation of CZ into type theory can be aroused when we use the method of deriving programs from the correctness proofs of formal specifications. Therefore, a direction for future research can be to develop programs from nondeterministic specifications in other formal development methods such as animation and refinement. As a related work, Ward in [43] defined a nondeterministic refinement calculus. In his approach, he added (set theoretic) specification constructs to a functional language. Also, nondeterministic choice operators were added to specification language. Then, a set of refinement rules were proposed to support refining the specification to a nondeter-ministic functional language program. Also in [8] and [31], nondeterminism has been considered in refinement calculus.

Another interesting topic in continuing this research could be studying un-derspecification in the process of formal program development. When developing a software system in a number of refinement steps, we are often interested in specifying the functionality of system not uniquely but only with respect to some required properties. Later in the development process, we may add more properties, whenever we find this appropriate. Then, we speak of under-specification [44]. Underspecification corresponds to choices between models,

while nondeterminism corresponds to choices within one model [42]. This conceptual difference between underspecification and nondeterminism does not contradict the fact that both arise as natural abstraction mechanisms, and sometimes may be supported by similar modeling techniques. Especially, the refinement concepts for underspecification and nondeterminism are rather similar [44].

References

[1] Aczel, P., The Type Theoretic Interpretation of Constructive Set Theory: Inductive Definitions, Logic, Methodology and Philosophy of Science VII, Elsevier Science Publishers B.V., pp. 17-49, 1986.

[2] Blass, A., and Y. Gurevich, The Logic of Choice, Journal of Symbolic Logic, 65(3), 2000.

[3] Backus, J., Can Programming be Liberated from von Neumann Style? A Functional Style and Its Algebra of Programs, Communication of the ACM, 21(8), pp. 613-635, 1978.

[4] Bishop, E., "Foundations of Constructive Analysis", McGraw-Hill, 1967.

[5] Bergstra, J. A., and J. W. Klop, Algebra of Communicating Processes, in Mathematics and Computer Science, CWI Monographs, 1, North-Holland, Amsterdam, pp. 89-138, l986.

[6] Burstall, R., and J. McKinna, Deliverables: A Categorical Approach to Program Development in Type Theory, Laboratory for the Foundations of Computer Science, University of Edinburgh, Technical Report ECS-LFCS-92-242, 1992.

[7] Broy, M., A theory for Nondeterminism, Parallelism,, Communication, and Concurrency, Theoretical Computer Science, 45(1), pp. 1-61, 1986.

[8] Back, R.J.R., and J. von Wright, Interpreting Nondeterminism in the Refinement Calculus, In the Proceedings of the BCS-FACS 7th Refinement Workshop, 1996.

[9] Chen, J., D. K. Friesen, W. Jia and I. A. Kanj, Using Nondeterminism to Design Efficient Deterministic Algorithms, FSTTCS 2001, LNCS 2245, pp. 120-131, 2001.

10] Cooke, J., Formal Methods - Mathematics, Theory, Recipes or What?, The Computer Journal, 35(5), pp. 419-423, 1992.

11] Cavalcanti, A., and J. Woodcock, Angelic Nondeterminism and Unifying Theories of Programming (Extended Version), Department of Computer Science, University of Kent, Technical Report No. 13-04, 2004.

12] Dijkstra, E. W., "A Discipline of Programming", Prentice Hall, 1976.

13] Dahl, D. J., E. W. Dijkstra and C. A. R. Hoare, "Structured Programming", Academic Press, New York, 1972.

14] Dezani-Ciancaglini, M., U. Liguoro and A. Piperno, A Filter Model for Concurrent-Calculus, SIAM Journal on Computing, 27(5), 1998.

15] Floyd, R. W., Nondeterministic Alghorithms, Journal of the ACM, Volume 14, pp. 636-644, 1967.

16] Hesselink, W. H., A Mathematical Approach to Nondeterminism in Data Types, ACM Transaction on Programming Languages and Systems, 10(1), pp. 87-117, 1988.

17] Hesselink, W. H., "Modalities of Nondeterminacy", Springer-Verlag, 1991.

[18] Haghighi, H., S. H. Mirian-Hosseinabadi, Nondeterminism in Martin-Lof's Theory of Types, In Farsi, In the Proceedings of the 10th Annual CSI Computer Conference (CSICC 2005), Tehran, Iran, 2004.

[19] Haghighi, H., S. H. Mirian-Hosseinabadi, Modalities of Nondeterminacy in Martin-Löf's Theory of Types, In Farsi, In the Proceedings of the 10th Annual CSI Computer Conference (CSICC 2005), Tehran, Iran, 2004.

[20] Hayes, I. J., and C. B. Jones, Specifications Are Not (Necessarily) Executable, Software Engineering Journal, 1989.

[21] Hoare, C. A. R., "Communicating Sequential Processes", Prentice-Hall International Ltd., Englewood Cliffs, NJ, 1985.

[22] Holloway, C. M., Why Engineers Should Consider Formal Methods, In the Proceedings of the 16th AIAA/IEEE Digital Avionice Systems Conference, Volume 1, pp. 16-22, 1997.

[23] Henson, M. C., and S. Reeves, A Logic for the Schema Calculus, In the Proceedings of the 11th International Conference of Z Users on the Z Formal Specification Notation, Springer-Verlag, pp. 172-191, 1998.

[24] Lano, K., "The B Language and Method: A Guide to Practical Formal Development", FACIT Series, 1996.

[25] Luo, Z., A Unifying Theory of Dependent Types: The Schematic Approach, In Logical Foundations of Computer Science, Springer-Verlag, 1992.

[26] Marahaj, S., Encoding Z-style Schemas in Type Theory, In the Proceedings of Workshop on Types for Proofs and Programs, Nijmegen, pp. 238-262, 1993.

[27] Martin-Löf, P., An Intuitionistic Theory of Types: Predicative Part, In the Proceedings of Logic Colloquium 73, H.E. Rose and J.C. Sheperdson (Editors), North Holland, pp. 73-118, 1975.

[28] Martin, C. E., and S. A. Curtis, Modelling Nondeterminism, Department of Computing, Oxford Brooks University, UK, 2004.

[29] Milner, R., "Communication and Concurrency", International Series in Computer Science, Prentice Hall, 1989.

[30] Mirian-Hosseinabadi, S. H., "Constructive Z", PhD Thesis, Department of Computer Science, University of Essex, UK, 1997.

[31] Morris, J. M., Non-deterministic Expressions and Predicate Transformers, Information Processing Letters 61, Elsevier Science Publishers B.V., pp. 241-246, l997.

[32] Mousavi, M. R., "Making Nondeterminism Explicit in CZ", In Farsi, MSC Thesis, Department of Computer Engineering, Sharif University of Technology, Tehran, Iran, 2001.

[33] Mislove, M., J. Ouaknine and J. Worrell, Axioms for Probability and Nondeterminism, Electronic Notes in Theoretical Computer Science 96 (2004), pp. 7-28, Elsevier Press, 2004.

[34] Myhill, J., Constructive Set Theory, The Journal of Symbolic Logic, 40(3), pp. 347-382, 1975.

[35] Nordstrom, B., and K. Petersson, "Programming in Martin-Lof's Type Theory: An Introduction", Oxford University Press, 1990.

[36] Pitcher, C. S., "Functional Programming and Erratic Non-determinism", PhD Thesis, Trinity College, Oxford University Computing Laboratory, 2001.

[37] Pressman, R. S., "Software Engineering: A Practitioners Approach", McGraw-Hill, UK, 1994.

[38] Spivey, J. M., "The Z Notation: A Reference Manual", Prentice-Hall, 1989.

[39] S0ndergaard, H., and P. Sestoft, Non-determinism in Functional Languages, The Computer Journal, 35(5), pp. 514-523, 1992.

[40] Subrahmanyam, P. A., Nondeterminism in Abstract Data Types, In Automata, Languages, and programming, 8th Colloquium, LNCS, Volume 115, pp. 148-164, 1981.

[41] Thompson, S. J., Type Theory and Functional Programming, Addison-Wesley, 1991.

[42] Turetayev, D., Nondeterminism in Stochastic Modeling, Formal Methods and Tools Group, University of Twente, Netherlands, 2003.

[43] Ward, N. T. E., "A Refinement Calculus for Nondeterministic Expressions", PhD Thesis, Department of Computer Science, University of Queensland, Australia, 1994.

[44] Walicki, M., and M. Broy, Structured Specifications and Implementation of Nondeterminstic Data Types, Nordic Journal of Computing, 2(3), pp. 358-395, 1995.

[45] Walicki, M., and S. Meldal, Algebraic Approaches to Nondeterminism: An Overview, ACM Computing Surveys, 29(1), pp. 30-81, 1997.

[46] Walicki, M., and S. Meldal, Singular and Plural Nondeterministic Parameters, SIAM J. Comput., 26(4), pp. 991-1005, 1997.