Investigating Miraculous Specifications

In order to use expressions as the basis of a specification language, we admit undefinedness, and introduce nondeterminism through the use of a choice operator. We extend expressiveness of the language by allowing choice from a set of values. Such a set could be infinite, giving unbounded non-determinism, or it could be empty, producing miracles. In this paper we treat the miraculous specification, examining its uses and highlighting related problems. In particular, we find that miracles promote the possibility of specification in parts, and piecewise refinement. However, their undesirable properties mean that we must limit their use. A biased choice operator is introduced as a method of totalising miraculous expressions. Finally, the formation of miraculous functions is considered with reference to their use and manipulation.


Introduction
The subject matter for this paper has grown out of research carried out into the area of a refinement calculus for expressions [5].The calculus could be used in a number of ways: to extend the imperative refinement calculus by allowing specification and refinement using more abstract expressions; to provide the basis for a calculus to allow the development of imperative programs from specification expressions; or to provide the basis of a framework for the formal development of functional programs from specifications.The calculus parallels the work of Back [1], Morris [9,10] and Morgan [8] on the refinement calculus for imperative programs.
We take the view that a refinement calculus consists of a specification language, which contains a programming language as sublanguage, a refinement relation between specifications, and a set of laws to allow the formal development of programs from specifications.
In order to extend the expressiveness of a language of expressions, which may include integer, boolean, product and function expressions, as well as sets, bags and sequences, it is not uncommon to add a choice operator for nondeterminism.Sondergaard and Sestoft, in their paper [15], examine various forms of non-determinism in functional languages.In [5] we admit both undefined expressions and non-deterministic expressions using a bottom (undefined) value and a choice operator respectively.Our choice operator is unusual, however, since as well as being erratic, it can be used to choose elements from infinite sets.Moreover, we decided not to restrict its use to non-empty sets.Choice from an empty set, known as a miracle, is what is described in this paper.
The remainder of the paper is set out as follows: section 2 describes in more detail what is meant by undefinedness, non-determinism and refinement, as applied to expressions.It also describes the specification expression, which allows us to choose a value from a set.Section 3 shows how miracles are formed, and how they can be used for partial specifications and piecewise refinement.Section 4 examines the problems associated with miracles, and how their occurrences can be controlled.Section 5 shows how partial functions are formed and explores their uses, including the structuring of specifications.

Background
The specification language of the refinement calculus is described in detail in [5] using a set of axioms.In this paper we give an informal description of some of the more unusual features of the language, omitting axioms, except those 3rd Northern Formal Methods Workshop, 1998 necessary for the explanation of miraculous expressions.We begin with a treatment of undefined expressions, and then move onto non-deterministic expressions and specification expressions.Finally, we treat the refinement relation, and describe what it means for one expression to refine another.

Undefinedness
where, if the first disjunct is true, the second must be undefined.The first expression states the property that for any integer n, either n is zero, or n=n = 1 .The second states a property of sequences, that either a sequence is empty, or it is composed of its head and its tail.Undefined expressions are unavoidable, the problem lies in how to handle them.This problem is well documented, with various suggestions for its treatment, in e.g.[4,7].
We make the decision to handle undefinedness explicitly.In order to allow reasoning about such expressions, we augment each type T with a special value '? T ', usually pronounced "bottom", which represents the undefined value of type T. For example, we say that the result of the evaluation of the expression 4=0 is ?Z .We shall drop the subscript in '? T ' if the type T is clear from the context, or is irrelevant.The undefined expression ?T will also be used to represent a "don't care" value, where the specifier doesn't care about the result.This is in keeping with the treatments of [12,16].
We now need to consider how expressions behave when their constituents are possibly undefined.In most cases it is appropriate to enforce strictness, i.e. an operator will yield ? when applied to ?. So, for example, the expression 4=0 + 3 is undefined, as is the expression 0=0 = 1 .
However, we do want to have the ability to reason about undefined expressions.For example, it is desirable that the two quantified expressions above should hold.Enforcing strictness of the boolean operators would result in these being undefined.This leads us to new versions of the disjunction and conjunction operators which are symmetric and which satisfy the equivalences: for arbitrary (possibly undefined) logical expression X.It is possible to give formal rules to define these extended operators.We will also use other non-strict operators, including equivalence and refinement v.
One issue which arises when considering possibly undefined expressions is that of monotonicity.An operation op is monotonic with respect to an ordering v if, for any expressions E and F with E v F, we have E 0 v F 0 , where E 0 and F 0 are the results of applying op to E and F respectively.The new versions of conjunction and disjunction retain monotonicity (with respect to the definedness ordering) and are equivalent to their 2-valued counterparts when terms are well-defined.Other non-strict operators, including equivalence which is essential for reasoning within the language, are non-monotonic.This operator allows us to assert such equivalences as 4=0 ?Z .
In order to distinguish undefined terms in specifications, a non-strict, non-monotonic operator is introduced.For any expression E of any type, E is True if E is well-defined, and False otherwise.Clearly : ?T holds for any type T. A selection of axioms concerning can be found in appendix A.

Non-Determinism
To allow greater flexibility and to increase abstractness in specifications, we introduce the possibility of non-determinism in expressions.In a non-deterministic expression, any one of a number of possible outcomes is acceptable.For example, a familiar non-deterministic specification is to search a sequence for the index of a particular value.If the value occurs more than once in the sequence, it doesn't matter whether the first, the last, or any other occurrence of that value is found.
We admit non-determinism by introducing the choice operator ' '.For E and F expressions of the same type T, the expression E F, also of type T, denotes the non-deterministic choice between the two expressions.Evaluation of E F could result in the evaluation of E or the evaluation of F, but we don't know or care which.Choice enjoys the properties of commutativity, associativity and idempotency.
Non-determinism is often modelled in terms of sets of possible outcomes.For example, the expression 3 has one possible outcome, namely the value 3. The expression p 4, on the other hand, has two possible outcomes, the elements of the set f,2; 2g.The set of possible outcomes of an expression E F, then, contains the possible outcomes of expression E and the possible outcomes of expression F.
Facilitating non-determinism in the expression language is not a simple matter of just introducing the choice operator .We also need to consider how other operators of the language behave in the presence of non-deterministic operands.Most operators, such as integer addition, distribute over choice.So, for example, 3 4 + 7 10 1 1 .A few operators, such as equivalence, refinement and some of the boolean operators, do not distribute.
We must also consider the definedness properties of a possibly non-deterministic expression E F. In terms of sets of possible outcomes, the undefined integer ?Z has f? Z g as its set of possible outcomes, while the expression 3 ?Z is modelled by f3; ?Z g.However, we say that both expressions are undefined.We make the decision that E F should hold only when both E and F are well-defined, E ^ F. This means that : E F holds if either E or F has ?as a possible outcome.So, ? is False, as is 3 ?.In contrast, 3 4 is True, as is 3.
If an expression E yields a single, well-defined outcome, then we say that E is proper and we write E. For example, 3 is True, while ?, 3 ?and 3 4are all False.When all expressions are proper, the specification language reduces to the normal, everyday expressions involving familiar types such as integers, booleans, tuples, functions etc. Intuitively, it should be clear that if an expression is proper E, then it is well-defined E. Some axioms concerning can be found in appendix A.

Specification Expressions
We introduce a new operation on sets called generalised choice and write this =.It is based on using the choice operator with reduce for sets.If S is a non-empty, possibly infinite set of type P T, then the expression =S has type T and can be interpreted as 'choose any element of S'.For example =f3; 4; 5; 6g 3 4 5 6 Expressions of the form =S are termed specification expressions [16].Notice that we do not restrict specification expressions to choice over a finite set.Thus we may form the expression =Z which means 'choose any integer'.
The expressive power of the generalised choice operator is realised when it is used with set comprehensions.An initial specification can be given by defining the properties required of a solution using a predicate P say, forming the set of all elements which satisfy that property fx 2 T : P xg, and then using = to choose any one of those elements.Provided it can be proven that there is a solution, i.e. 9 x 2 T P, then the set fx 2 T : P xg is non-empty, and the specification is given as =fx 2 T : P xg which may, of course, be a non-deterministic expression.For example =fx 2 Z : 0 6 x : 2 xg Any even natural =fs 2 P Z : s = 1 0 g Any integer set with exactly 10 elements 3rd Northern Formal Methods Workshop, 1998

Refinement
Informally, for an expression E to be refined by an expression F, written E v F, it should be the case that every possible 'evaluation' of F is also a possible 'evaluation' of E, or is better defined than some possible 'evaluation' of E. So, a specification is refined by reducing non-determinism or by increasing definedness.For example, we expect the following refinements to hold The first two examples are simple cases of reducing non-determinacy, while the third example reduces non-determinacy within the body of a function.The last example reduces non-determinacy, but also increases definedness since the function on the left gives an undefined result for any negative integer, while that on the right is defined for every integer.
In terms of sets of possible evaluations, expression E is refined by expression F iff everything in the set of evaluations of F is better defined than something in the set of possible evaluations of E. This intuitive notion is exactly the Smyth ordering for sets, as described in [14].The formal semantics of refinement, as described in [5], is based on this Smyth ordering.
We advocate the process of program development by stepwise refinement, starting with an initial specification S 0 and building a sequence of specifications S 0 v S 1 v : : : v S n so that each S i , for 1 6 i 6 n is an acceptable replacement for S i,1 , and S n is a program.Since the aim is to derive programs in steps, it is required that the refinement relation is transitive.Then, from a sequence of refinements of the form S 0 v S 1 v : : : v S n , we can conclude that S n is a correct implementation of the initial specification S 0 .In fact, refinement is a pre-order, since every specification refines itself.In general, a refinement relation need not be anti-symmetric.In fact our relation is not since, for example, we have the refinements 2 ?v ??v 2 ?
In the first case, the refinement is obtained by reducing non-determinism, while in the second definedness is increased.However, the two expressions are not equivalent.
As well as refinements proceeding stepwise, it is also important that refinement can occur piecewise.This means that an expression may be refined by refining one, or more, subexpressions, This states exactly the property that G must be monotonic (with respect to refinement) at the position x where the refined subexpression occurs.Refinement can occur only in monotonic positions.
The refinement relation is defined in [5] using six axioms, which are listed in appendix A.

Introducing Miracles
In section 2.3 we introduced the specification expression, of the form =S for S a non-empty, possibly infinite set.
Miracles occur when we ask the question, what is meant by =fg?
We introduce an identity for choice, which we give the fictitious value , pronounced "top".So, we have that E E for any expression E. From our observations about sets of possible values, and interpreting choice as the union of such sets, it must follow that corresponds to the empty set of possible values.
Since choice now has an identity, it follows from the rules for reduce that =f g .We notice that is distinct from ?, and so it must be well-defined .But is not a proper value, so we assert : .3rd Northern Formal Methods Workshop, 1998 Since the set of possible outcomes of the expression is empty, and so a subset of every set, it follows that refines every expression, i.e.E v for arbitrary expression E. This means that cannot be implemented; if it could, the programmer would have a very simple job.This is why is referred to as a miracle.
The miraculous expression on its own is not a useful specification, and so we want to avoid its use.For example, we do not want to form the specification =S unless we can prove that S is non-empty.Such a proof is a burden on the specifier.Further, given an initial specification expression E, there is nothing to stop the developer from overrefining E, perhaps in a sequence of steps, to the miraculous specification, thereby resulting in something which is unimplementable.
So, in introducing , we have introduced a problem.However, has its uses, which we explore next, and so we are reluctant to throw it away.Instead we will consider, in section 4, how to handle it safely, and without placing any additional burden on the specifier or implementor.

Potentially Partial Expressions
We define a total expression to be one which has a non-empty set of possible outcomes.Otherwise, if the expression has no possible outcomes, not even the undefined outcome, we say that it is partial.We say that an expression of the form =S is potentially partial, since it may 'evaluate' to , in the case where S is empty.
We introduce the concept of a guarded expression.The intuitive meaning of an expression P !E, where P is a boolean expression called the guard, is such that: if P is True then P !E E; if P is False then P !E ; and otherwise P !E ? .The axioms are, with E : T, True !E E False !E : P P !E ?T These axioms have been formed to facilitate case-based reasoning.To prove something about an expression P !E it is convenient to consider three cases, P True, P False and : P.
Since an expression of the form P !E may 'evaluate' to , guarded expressions are potentially partial.Guarded expressions are used to form alternation expressions.An alternation expression is of the form P 1 !E 1 : : : P n !E n .Any guard P i which evaluates to False has the result that the guarded expression P i !E i effectively disappears from the alternation.If all the guards are proper, then the alternation is such that some expression E j for which the corresponding guard P j evaluates to True will be chosen and evaluated.For example, the alternation x 0 !'+' x 6 0 !',' will evaluate to '+' if the integer x is positive, to ',' if x is negative, and to either '+' or ',' if x is 0.An alternation expression is potentially partial, since all guards may be False.
Alternation expressions allow the facility for specification in parts because each 'case' of a specification can be considered in isolation, giving a guarded expression, and then combined using choice to form an alternation.When a particular case does not apply, for example when x 0 does not apply in the above expression, the partial expression x 0 !'+' 'disappears' from the specification, i.e. '+' is no longer a possible evaluation.This is based on the fact that is the identity for choice.
Moreover, since is monotonic with respect to the refinement operator, each guarded expression can be refined in isolation, resulting in piecewise refinement for each 'case' of the specification.
Experience with the Z specification language has shown that it is a useful feature to allow a specification to be constructed in parts.Partial specifications mean that a single aspect of the problem can be focussed upon in isolation, and the complete specification obtained by assembling the parts.The beauty of guarded expressions is that they can be easily combined using choice.We return to this theme in section 5.1 when we consider partial functions.
We now examine how we can ensure that a complete specification is total.

Managing Miracles
Although the introduction of brings great expressive power to the language and greatly facilitates the piecewise refinement of expressions, it is nonetheless a very dangerous expression, as explained in section 3.
The solution is to control occurrences of potentially partial expressions so that every specification of the language, whether an initial specification or one calculated by refinement from a previous specification, is total (though it may contain partial sub-expressions).
We first show how potentially partial expressions can be recognised syntactically, and then show how restrictions can be imposed to ensure that every specification is a total expression.

Recognising Potentially Partial Expressions
Potentially partial expressions can occur in exactly 2 possible ways: from a generalised choice, =S from a guarded expression, P !E In the first case, the expression =S is partial when S is the empty set; in the second case, the expression P !E is partial when P is False.There are no other constructs where partiality might be created.All other language constructs are total.So, it is only in the cases of generalised choice and guarding where we need to be concerned about the possible introduction of the miraculous expression .Both of these cases are recognisable syntactically.
Potentially partial expressions are defined as the smallest subset of expressions satisfying Expressions of the form =S are potentially partial.
Expressions of the form P !E are potentially partial.
If E is potentially partial then so is E F, for arbitrary F.

Restricting the Syntax
We don't want to eliminate potentially partial expressions completely.We've seen that guarded expressions are very useful when used with choice to form alternation expressions.Generalised choice expressions are also extremely useful specification tools.We do, however, intend to ensure that potentially partial expressions are never used directly with operators (other than choice), constructors or function application.None of these can create partiality, but they would propagate it.What is required is a way of 'totalising' potentially partial expressions, i.e. transform them into total expressions, so that they can be used freely in specifications.We introduce a new operator, biased choice , which always chooses F is equivalent to F. Biased choice is associative and idempotent, but not commutative.It is strict in its left argument and distributes over choice to the right.We have the axioms Most importantly, the expression E F is guaranteed to be total if F is.This means that given a potentially partial expression, such as P !E, it can be 'totalised' by combining it with a total 'alternative' F, giving an expresson of the form P !E F. We now give the extra restrictions placed on expressions of the specification language.The use of potentially partial expressions is such that they may only be: 3rd Northern Formal Methods Workshop, 1998 operands of -thus forming a new potentially partial expression; the left operand of -thus forming a total expression; operands of , v, and -thus forming total expressions.

Partial Functions
Consider what happens when we allow abstraction over guarded expressions to form partial functions, of the form fun x 2 T : B ! E where E is typically a large expression.
Note the distinction between a total function and a total expression.A function expression can be total, while still being a partial function, i.e. its body is potentially partial.Such functions are total expressions and, as such, there is no restriction on where they may occur, subject to typing conditions.Now consider the application of a partial function to some argument for which a result has not been specified in the function body.According to the axioms of the language which govern function application, the result is the value .So, for example, the result of the application is and thus the expression is not total.
This example illustrates that, although in order to form the expression f e, representing the application of function f to argument e, both f and e must be total, it is possible that the new expression f e is not total.
The result of allowing such applications is that a new form of potentially partial expression has been admitted, that of a function application.Rather than complicating specifications by requiring that all expressions of the form f e are totalised, we instead insist that all functions occurring within an expression are total functions.
We now consider how partial functions can be used.

Structuring Large Specifications
During the construction of a specification we claim that it is useful to allow an abstraction over a non-total expression, i.e. the formation of a partial function, with the intention that it be combined with other, possibly partial, functions at a later stage.In the same way that partial expressions are used for small specifications, partial functions are a useful concept in the language because they permit large specifications to be constructed in parts, with separation of concerns a major issue.
The intention is that a specification is written describing a result in a certain, perhaps error-free, case, generally of the form fun x 2 T : G ! E where E is typically a large expression.The "error" case is described separately, perhaps of the form fun x 2 T : :G !F. These two partial functions should be combined to form a new specification given by fun x 2 T : G ! E :G !F. For example, the searching function for sequences of type SeqT could be written as fun S 2 SeqT; x 2 T : =fi 2 f 0::S , 1g : This is a partial function since it yields if the given x does not occur in the sequence.It could be made into a total function by combining it, for example, with a function which returns a default error value if the given value x does not occur in the sequence.The Z specification language [13] permits the construction of specifications by combining schemas, which can be compared to partial functions.In a Z specification it is usual to combine schemas for partial specifications using schema disjunction.We propose a similar method for combining partial functions.
3rd Northern Formal Methods Workshop, 1998 Investigating Miraculous Specifications

Combining Partial Functions
Our aim is to define an operator _ which will take two partial functions and combine them such that fun x 2 T : E _ fun x 2 T : F fun x 2 T : E F Since the formation and combination of partial functions appears to be a purely syntactic notion, it makes sense that the definition of _ should also be syntactic.Restrictions to occurrences of _ are that it is used only with function types.The functions must be of the form fun x 2 T : E, or a choice between functions of this form.The two defining rules for _ are, therefore fun x 2 T : E _ fun x 2 T : Taking the union of two partial functions yields another partial function.We define another version of union, a biased union, which can be used to obtain a total function.A function f g when applied to an argument e will result in f e if it is total and otherwise ge.The definition is purely syntactic, with the defining rules given by fun x 2 T : E fun x 2 T : Commutativity does not hold, in general, for .Moreover, does not left-distribute over choice, which is why the left argument of may not be a choice between functions.We see that a function f g is guaranteed to be a total function if g is.Thus, the biased union can be used to form total functions.

Manipulating Partial Functions
We have suggested the use of partial functions as a means to construct a specification piecewise, so that the partial functions can be combined to form a complete specification.However, we may also want to manipulate partial functions.This means allowing certain higher-order functions to be applied to potentially partial functions.
In general, partial functions are not permitted as arguments to higher-order functions, for the reason that this might introduce partiality into a specification.For example, let sqrt be the partial function x Now what should be the result of mapping f over a set of integers which may contain negative elements?The answer is not clear.
However, we propose a class of higher-order functions which may be applied to partial functions, and for which the resulting application is guaranteed to be total.Consider a higher-order function which takes two arguments, a possibly partial function f of type Z !Z and a string (sequence of characters) s.The result is a total function of type Z !Z String which behaves in the following way: when applied to an argument x, if f x is total then it returns the pair consisting of the value f x and the string 'ok', otherwise it returns the pair 0; s.The specification can be expressed by totalise = fun f 2 Z !Z; s 2 String : fun x 2 Z : f zerox; x 2 dom f !'ok' s where zero = fun x 2 Z : 0 , and the function dom, when applied to a partial function f , returns the set of values for which f has been specified.Notice that the 'totalise' function, being a total function, can now be used to totalise a partial function.Without the possibility of having partial functions, we could not specify this higher-order function.

Conclusions
The distinction between possibly undefined and possibly partial expressions is not usually so explicit.We have treated partiality as the dual of undefinedness, with respect to choice, i.e. is the identity of choice, while ? is (almost) the zero for choice.The concept of partial expressions is useful since specifications can be built in parts, while each part may be manipulated and refined as a complete unit.However, since partial expressions are not implementable, we found it necessary to control the occurrences of potentially partial expressions in specifications.This led to the introduction of the biased choice operator in order to totalise specifications.Unfortunately, is not monotonic with respect to refinement, in general, which causes some problems.It would be more elegant to treat partiality in the same unrestricted way that we have treated undefinedness.
We extended the concept of partial expressions to partial functions, which can be used purely as a syntactic device to structure specifications.The use of partial functions is demonstrated in [5] with a specification of a printing control system.
The specification language has been given a semantics based on sets, with powerdomain theory used to give a meaning to recursive functions.

Some Comparisons
There are many possible alternatives to the treatment of undefined expressions, as illustrated by the work of Cliff Jones in the area of handling partial functions [4,7].For example, the approach taken in the Z specification language [13] is to avoid function application entirely by treating functions as relations.This has the advantage that it would also handle non-determinism quite easily.The disadvantage is that this approach leads to more complicated formulations of properties, making specifications more difficult to write.We further note that the specification expression could be written in Z using the -expression, and relaxing the rules forcing deterministic results.
The approach we take to treat the undefined value explicitly, using an extension of classical logic, is similar to the approach used in the logic of partial functions (LPF) used for reasoning about specifications in VDM [2].However, our implication is defined differently, and is reflexive.Further, while LPF is three-valued, our logic also deals with non-deterministic values.
Both Morris [11] and Bunkenburg [3] use a logic where terms may be non-deterministic.The choice operator in this treatment is demonic, making ?a zero for choice.The choice operator in our treatment is erratic.

A A Selection of Axioms
Axioms for and For v a value, x a variable identifier, T a type and E any expression: v x : ?T

E E E E
These axioms state that: all proper values and all variable expressions are proper (and hence well-defined); for every type T, ?T is not defined; every expression that is proper is necessarily well-defined; and it is always determined whether an expression is proper or well-defined.

Axioms for
For E, F and G expressions of the same type: Investigating Miraculous Specifications These axioms state that: choice is idempotent, symmetric and associative; the expression E F is proper whenever E and F are proper and equivalent expressions; the expression E F is well-defined exactly when both E and F are well-defined.
Axioms for Operators over Integers For improper terms, all of the operators over integers are strict and distribute over choice.
For one of +; ,; ; = ; mod; u,t, , with E, F and G integer expressions: The last axiom is an equivalence when is one of +; ,; ; u,t, .Attempts to divide by zero result in undefined terms.For one of =; mod, and with F, E F E ^ F ^F 6 = 0 Refinement Axioms The refinement relation is transitive for E, F and G expressions of the same type.
The general refinement axiom is where E and F are expressions of the same type.When E and F belong to a simple type, this is an equivalence, and may be used as the definition of refinement.
For function domains, with f and g functions of the same type, and f and g, f v g 8x : T j f x v g x When refining non-deterministic expressions, with E, F and G expressions of the same type, S a set expression of type P T, and with G, E and S we have the axioms We assert that top is the unique most-refined specification, v E E for E any expression.