1. DEPARTMENT OF COMPUTER SCIENCE
Mechanising Programs in
Isabelle/HOL
Author:
Ankit Verma
Supervisor:
Frank Zeyda
September 14, 2011
Number of Words: 20631
Using command: wc -w
2. Abstract
The Unifying Theories of Programming(UTP) is a mathematical notation based framework
that embodies a set of common basic concepts and properties shared between many program-
ming languages. The UTP has been embedded into a theorem prover called ProofPower-Z.
The project examines the current mechanisation in ProofPower-Z and generates translational
ideas to convert it into equivalent concepts of another theorem prover called Isabelle/HOL,
by analysing the language of ProofPower-Z, i.e. Z language, and language of Isabelle/HOL.
The project discusses various inconsistencies and design issues involved in the translation
exercise. The translated mechanisation in Isabelle/HOL is evaluated on various elementary
UTP laws and mathematical theorems. The partial mechanisation of UTP in Isabelle/HOL
was obtained as a result for this project.
3. Acknowledgments
I would like to thank my supervisor, Frank Zeyda, for his invaluable direction and discussion
throughout this project. I would like to extend my appreciation for his constant feedback
and encouraging behaviour.
Also, I would like to thank my parents for their endless love and motivation. Finally, my
friend Isha Arora for her consistent encouragement and motivation at times of stress.
i
7. The complexity of programming languages in which the programs are written nowadays
is growing inevitably both in scale and functionality. The study of the computer science
branch involves studying various different languages, of different computational paradigms,
and their respective syntax and semantics which can be quite cumbersome. There are a
vast number of programming languages that have been invented and many more languages
are still to come. This requires us to formulate a framework that deals with the concept of
unifying theories of programming. A coherent structure that is a collection of all the basic
concepts and properties that are in common to all programming languages and methods.
Such a framework is Unifying Theories of Programming (UTP).
A framework that embeds in itself the basic concepts and features of programming lan-
guages and paradigm is the Unifying Theories of Programming [9]. It is a general mathe-
matical notation that does not restrain itself to one particular programming language but
provides a common principle that stands for all. As this framework is a common platform
for defining concepts of programming languages in general, it becomes utter important for
it to be correct and reliable. A way of achieving such high level of correctness and reliability
incurs with the use of formal methods.
Formal methods is a kind of technique that makes use of mathematically-based ap-
proaches for specification and verification of a system. Though this does not guarantee
a system to be error free, but it makes it easier to specify a system as a set of mathematical
concepts and thus reducing the probability of errors. One such formal methods based lan-
guage that is used severely in software engineering industry is the Z notation, which is based
on set theory and predicate calculus. A formal specification language like Z with its own
syntax and semantics is used to define the properties and states of a system, in our project
it is the UTP. Once the specification of a system has been defined properly, it is essential for
the properties to be verified. Verification of specifications is generally done using theorem
provers. Theorem proving can be in parts automated, but due to the inherent complexity is
still mostly an interactive process.
Theorem provers are tools that are used for formal specification verification using au-
tomated reasoning. These are softwares that provide interactive interfaces for users to col-
laborate with machines and perform proving. In this project we deal with a mechanisation
which in other words is a formalization of the semantics of UTP in formal language Z. Dif-
ferent definitions has been used to deep embed the semantics of UTP in Z. And to reason
about the programs in UTP, a theorem called ProofPower-Z[16] has been used. UTP , as
already discussed above, is a common platform that holds common properties and concepts
for different languages, so a mechanisation of UTP will provide us with mechanical support
for any language that has UTP as its fundamental basis.
The ProofPower theories namely utp-lang-value, utp-lang-expr, utp-lang-var and utp-
alpha captures the fundamental language definitions and semantic model of UTP. As a part
2
8. of this project’s objectives, these ProofPower-Z theories needs to be translated into equivalent
concepts and language of another theorem prover called Isabelle/HOL [19]. This is important
from project’s perspective as Isabelle/HOL has many powerful features for automated proof
support of theories which enables us to reason automatically about various properties of the
UTP.
1.1 Objectives
The major objective of this project is to translate the current embedding of UTP in ProofPower-
Z into Isabelle/HOL and analyze both embeddings and the proof support offered by both
theorem provers. One of the limitations of ProofPower-Z is its lower automation for proofs
which can be overcome by this translation in Isabelle/HOL, which has a high level of auto-
mated proof support. This should be done keeping the semantical meaning of UTP theories
intact. Few concrete objectives of the project have been pointed out below.
• To begin with I need to understand the concept of UTP and understand the parts
of its current implementation expressed in the Z language as ProofPower-Z theories
named above. The translation of the ProofPower-Z theories under consideration have
already been mentioned above. These theories will cover various concepts of the UTP
namely; type system(values) of UTP, variables, expressions, bindings and alphabetised
predicates.
• After we have built up the basic knowledge about UTP, we will need to understand
the language and tool Isabelle/HOL.
• Once I have understood UTP theories expressed in ProofPower-Z and the Isabelle/HOL
theorem prover, I will need to translate these theories into equivalent concept within
the language of Isabelle/HOL. I need to make sure that the theories in Isabelle/HOL
are free from any type and syntax error. The translational approach carried out is
shallow embedding which only considers the semantical meaning of the Z constructs
and embed them into the meta-language of ISABELLE/HOL. This translation will
provide us with an insight for general translational issues and procedures to deal with
these issues.
• Next, we evaluate and validate the translation of the given ProofPower-Z theories,
done by performing proofs about various elementary laws defined by UTP predicates.
1.2 Report Outline
This project report contains the following chapters.
Chapter 2 Literature Review: This chapter discusses the literature knowledge that was
gathered in order to understand various concepts that formed the crux of the project
such as UTP, theorem proving, mechanisation of the UTP and so on.
3
9. Chapter 3 Requirements: An insight about the main objectives of the project. This chapter
illustrates the requirements of the project in detail. Here, step wise discussion has
been provided about the targets of the project and the underlying concepts of these
requirements.
Chapter 4 Analysis: This chapter discusses the major analysis task carried out in order to
understand various constructs of the language of theorem provers from-which (Z) and
to-which (Isabelle/HOL) the translation had to be done. Also shown in this chapter is
the general relation and transitional notion of common concepts and constructs.
Chapter 5 Design: Here, we will present our design for some part of the mechanisation of
UTP in Isabelle/HOL. And also a detailed explanation of the proposed model of UTP
in Isabelle/HOL is given in this section.
Chapter 6 Evaluation: In this chapter, we validate some parts of the mechanisation that we
have proposed by carrying out some elementary proofs about UTP predicates, values
and expressions.
Chapter 7 Conclusion and Further Work: Lastly, we conclude with the overall experience
of the project containing pros and cons of the translation along with future work.
4
11. 2.1 Theories of Programming
There is no single programming language that can cater for all needs. Every other day, there
is an improvement in almost all programming paradigms, including functional, imperative,
logic and parallel programming. To define a programming language, it is necessary to decide
on syntax. Do we use y := 1 or y = 1 , to denote an assignment? What conventions do
we follow for naming variables? But syntax alone cannot suffice to capture a paradigm as
it does not handle the behaviour and correctness feature of a program. So apart from syn-
tax, another vital factor contributing to a well-defined programming language is semantics.
Two languages can have the same syntax, but they can have different semantics. Generally,
semantics define the behaviour and meaning of a programming language and its notations.
A number of theories of programming have been proposed in order to define semantics of
various languages. Semantics are defined in terms of mathematical notations and theories.
Semantics is written and defined, generally, in one of the following 3 styles: denotational,
axiomatic or operational. There also exists other varied styles as well, few being action,
algebraic, and predicate transformer semantics.
The denotational style describes program behaviour in the form of various mathematical
objects. It comprises of mathematical definitions of the notations of a language. This ap-
proach defines a program in context of its observable behaviour and properties, as contained
in its specification. These definitions can be built formally and in isolation from other no-
tations. It is an abstract form of semantic style approach as compared to operational style
(discussed later). One of the various styles supported by Unifying Theories of Programming
(UTP) is this approach.
A kind of denotational semantic is Predicate Transformer semantics by Edsger W. Dijk-
stra described in his paper ”Guarded commands, nondeterminacy and formal derivation of
programs”. Weakest Precondition is the most used form of Predicate transformer semantic.
The weakest precondition (wp) calculus for program correctness that makes use of predicate
transformers. According to it, an assertion R is said to be weaker than assertion P if the
truth of P implies the truth of R, written P ⇒ R. For Example, x > 3 is weaker than x = 9.
According to Hoare logic [9] (an axiomatic semantic, discussed below), if we are able to
find the weakest precondition w that satisfies the Hoare triple w{Q}r , then every stronger
precondition must also satisfy the assertion made. If Q is a program and R is a post condition
then the corresponding weakest precondition would be denoted by wp(Q, R) . On the other
hand, Operational Semantics approach is more concrete than denotational in a way that it
describes the execution of the program as a step-wise procedure on some abstract machine
or automata. Operational semantics describes how a legitimate program is interpreted as
series of calculated steps. The most essential feature of a program is to execute automatically
and the results obtained should satisfy the specification prescribed. Thus, it is operational
semantic that shows the relation between a program and its possible outputs [9]. Axiomatic
6
12. semantics generally follows the concept of proving the correctness of a program using purely
static analysis of the text of the program itself. An application of axiomatic semantics is
to consider assertions as program specifications from which the program code itself can be
derived. Hoare logic (Axiomatic Semantic) is another theory of program correctness. The
Hoare triple P{Q}R asserts the correctness of program Q against the specification with
precondition P and post condition R. It states that if P is true in some initial state and
its Q terminates, then R will hold in final state [8]. Consider the following example of an
assignment: x := y. In this assignment, x is an identifier for a variable and y is an expres-
sion of a programming language possibly containing x. So any assertion say ,P(x), which is
expected to be true for the value of x after the assignment has been made must also have
been true for the value of the expression y, taken before the assignment is made, i.e. with
the old value of x. So, if after the assignment P(x) is expected to be true, and then P(y)
must be true before the assignment [8].
The ability to reason about the correctness of a program is a significant attribute of Hoare
logic. A correct program can be derived given the intentions of the user are described pre-
cisely by assertions about the values of variables at the end of the execution of the program.
A program is called as partially correct with respect to a precondition and a postcondition
when it begins with values that make the precondition true, and the final values make the
postcondition true when the program halts (if ever). If it can also be shown that the program
terminates when started with values satisfying the precondition, the program is called totally
correct. Hoare logic only proves partial correctness and total correctness can be proved by
extending it with a while rule (i.e. to prove the termination of a program by introduction of
a term known as loop variant, whose value firmly decreases with respect to a relation during
each iteration).
2.2 The Unified Theories of Programming
2.2.1 General Principle and Fundamental Concepts
The fundamental idea behind the Unifying Theories of Programming (UTP) revolves around
the study of various programming languages and their semantic descriptions and building
a set of common basic concepts and properties shared between those programming meth-
ods and languages. Once the basic outlay for arbitrary programming languages has been
established, concrete theories can be defined for a specific group of languages. The changes
mentioned above can be made in the form of adding or modifying existing theories, program
operators etc. by using healthiness conditions (as discussed later). Special attention is given
to render every possible feature in the simplest possible manner and in isolation from each
other, as to avoid any ambiguity in their understandings. The UTP makes use of mathe-
matical notations and logic to carry out the specification, design and implementation of any
program [9].
7
13. 2.2.2 Alphabetised Predicates and Relations
The framework of UTP is based on the concept of alphabetised predicates and relations.
The predicates in UTP are generally referred as alphabetised predicates. These predicates
describe the observable properties of program execution. In UTP, a program or a specification
is characterized by relations that describe the observations that can be made for behaviour
of the program [5]. The UTP adopts alphabetised relational calculus i.e. all the components
of the semantic models are represented by relations over a given alphabet. Specifications,
designs and programs are defined by any relational theory whose variables include initial and
final (or intermediate) observation. For an instance, the predicate P = x > x + 1 captures
a relation specifying that the output value (of x), x (dashed), increases the initial value (of
x), x (undashed) by more than 1. For any predicate, there exists an alphabet which contains
all the variables which occur free in the predicate. So the alphabet of predicate P, apart
from x and x , may also contain other variables say, y, y , z and z and is represented as
αP = {x, x , y, y , z, z }. Further, there are specific alphabets for input and output observed
values known as in αP and out αP respectively, obtained by applying the in and out
operators to the alphabet. These represent the initial and final values, respectively. The
variables used in an alphabet can be program variables, as discussed above, or some special
auxiliary variables. For instance okay and okay are Boolean variables used to represent the
initialization and termination of a program, respectively.
2.2.3 UTP Operators
Specifications are represented in the form of alphabetised predicates and operators are used
to combine these expressions. Few of the standard operators are as follows:
Table 1 : Standard UTP operators
Operator Syntax Caveat
Assignment x :=A e A = {x, x , y, y , z, z ..}
Sequential Composition P; Q outαP = inαP = {x }
Conditional P b Q αP = αQ ,also αb ⊆ αP
Non-Determinism P Q αP = αQ
Skip A A = {x, x }
Variable Declaration var x {x, x } ⊆ A
Variable Undeclaration end x {x, x } ⊆ A
Parallelism P M Q αP ∩ αQ = ∅
The above table mentions some standard core operators of UTP with their respective
syntax. The first one is assignment operator which is represented in general format of
x :=A e where e is any expression, x is a variable and A is the alphabet. So the above
assignment assigns value of expression e to the variable x. All other variables that are
not mentioned in the assignment remain unchanged in the alphabet A. The sequential
composition operator ; shows the sequence of computation of two predicates. So a sequential
8
14. composition P; S describes an execution of a program where P is executed first and the
final state of P is taken as the initial state for Q and then Q is started. Here, P and Q
are predicates defining behaviour of two different programs. The Conditional operator is
important from the perspective of providing programs with ability to choose between two
alternate processes on the basis of some testable condition. If P and Q are two predicates
describing two alternate behaviours of a program and b is any condition, then the conditional
operator P b Q states that a program will behave like P if the condition b is true or else like
Q if it is false. A more commonly used form for it is if b then P else Q. Non-determinism
is simply described as disjunction of predicates. P Q stands for a program which can be
executed by executing either of P or Q, but without any certainty on which one will execute.
Also, it is necessary for non-determinism that the alphabet of both operands should be the
same i.e. for the above example, αP = αQ. Skip ( A) is an operator that leaves the
state of the variables in the alphabet A unchanged. But it is significant for reasoning about
programs [9]. Declaration and Undeclaration are used to define the scope of a variable.
var x is a declaration defining the beginning of the scope of a variable x. And contrarily,
end x is used to undeclare x and mark the end of variable x’s scope. Scope of a variable,
say x, is the fragment of program, say Q, in which that variable is used and is defined as
varx; Q; endx. General parallelism in UTP is given by ternary operator (P M Q). It is
used to show execution of two processes (P and Q) or programs with disjoint alphabets and
M is a merge operation which describes the way in which observations from these processes
are merged to give an observation of their parallel execution.
2.2.4 UTP Theories
The theories of design after its specification is a way of restricting it to support the concept
of non-termination. Non-termination of programs is not observed by mere relations over
the program variables. Thus, here, in theory of design we use some extra Boolean variables
okay and okay to deal with this problem. okay records an observation that the program
has started and okay records the observation that the program has terminated. A design in
practice is considered as a pair of predicates. One is called assumption, say P, and another
known as its commitment, say Q. An assumption is something which is assumed to be
true when the program is instantiated whereas a commitment is something which should be
true when the program terminates. These predicates help in defining the behaviour of the
program in a singular predicate, which is as follows:
(P Q) =df (okay ∧ P) ⇒ (okay ∧ Q)
The notation P Q symbolizes deduction; Q can be validly deduced from P. Apart from
the above mentioned definition (P Q) for design, a set of four, much restricted, equations
are made. These equations are known as healthiness conditions. These classify a much more
restricted set of predicates satisfying these conditions and rendering a predicate true. The
first healthiness condition (H 1) ensures that no predicate makes an assumption about the
behaviour of a program (initial or final values) until and unless the program has already
9
15. started. This condition is R = (okay ⇒ R). Any predicate satisfying H 1 are assumed to
already satisfy the left zero law for true. The left zero law for true is true;P = true, where
P is a relation. The second healthiness condition guarantees the fact that non-termination
is an unwanted state and no specification can satisfy it if the specification requires non-
termination. This condition is R[false/okay ] ⇒ [R[true/okay ] ; stating that a specification
satisfying H 2 cannot exist, if that specification requires non-termination. The notation of
type P[e/x], as used in H 2, denotes the result of substituting e in place of x in a predicate
P. So any predicate satisfying H 1 and H 2 healthiness condition is a design, satisfying the
form (okay ∧ P) ⇒ (okay ∧ Q).
Overall, UTP provides a common platform for semantics of different programming paradigms
using alphabetised predicates and the set of healthiness conditions. The generality of the
UTP makes it easy to extend the current set of functional operators with some new operators
performing customized operations as described in their respective predicates. Adding new
theories is also an advantage of UTP. New theories can be added to existing theories by
extending with tailored healthiness conditions.
2.2.5 Refinement
As already mentioned, refinement is an important part of UTP. Refinement captures the
idea that behaviour of a concrete specification(implementation or a program) can also be
a behaviour of some abstract specification. So, refinement represents formal correctness of
an implementation or a program from the perspective of an abstract specification. For an
instance, given a specification
S = x = x + 1 ∨ x = x − 1
and a program, P = x := x − 1
we say, the specification S = x = x + y ∨ x = x − y is refined by a program P= x =
x −y. The symbol used to represent refinement is . Thus for the above refinement, we will
write S P. The program (P) is a stronger predicate of the specification (S). Refinement
is nothing but simply logical implication. The above refinement is represented in form of
implication as [P ⇒ S]. The ”[. . .]”’ brackets stand for universal quantification, quantifying
variables used in the alphabet of the predicate of the argument.
Correctness is an important feature in UTP. It captures any satisfying observation made
in an implemented program should also satisfy its corresponding specification. An obser-
vation is any satisfying value leading to desired output in the form of proper execution of
program. A satisfying value, here, can be any set of values for variables of a predicate. These
observations are recorded in a scientific theory in the form of mathematical predicates. These
predicates contain those variables that are relevant to that observation. Refinement calculus
is an integrated part of UTP, used for proving the correctness, by comparing the implemen-
tation with the initial specified behaviour. One of UTP’s main purposes is to construct,
10
16. compare and connect theories for a variety of modeling, specification and programming lan-
guages.
2.3 Automatic Theorem Proving
2.3.1 Theorem Proving in General
This section will detail about Automatic Theorem Proving, in general, and its applicability.
Automatic theorem proving is a branch of computer science that deals with programming
computers to aid the proof of formal assertions or mathematical theorems. This can be
done fully automatic or with some variation from human assistance. ATP’s (Automated
Theorem Provers) are programs which makes use of mathematical logics and on the basis of
some described rules and axioms, are capable of proving mathematical theorems. Logics,by
computing certain axioms and rules, can help in analyzing program behaviour. It analyses
programs thoroughly and helps in finding design, specification and implementation errors in
the initial stages of development. Use of mechanical systems, which reduces the probability
of human errors, to prove problems makes theorem proving reliable. A number of theorem
provers have been developed some being Isabelle [19], PVS (Prototype Verification System)
[2], Coq [7], Proofpower [16] and many more.
2.3.2 Higher-Order Logic (HOL)
Higher-Order Logic(HOL) is an extension of First-Order Logic (FOL) which is distinguished
from it by having an extension of quantifiers and stronger semantics. HOL is much more
expressive on the basis of its semantics but its model-theory types are less well-behaved from
FOL. In first order logic, only quantification over individuals is allowed while it has well-
formed categories for functions, individuals ( variables or constants ) and predicates. On
the other hand, HOL takes as arguments both individual and predicate symbols. The more
natural representation of higher-order quantification is considered in HOL in comparison
to encoding done in a multi-sorted logic setting, which includes two sorts where one is for
individuals and the other for predicates over individuals [18].
Church’s “Simple Theory of Types” is used as a typing approach in HOL where,the type ι
is used to denote the set of first-order individuals, and the type o is used to denote the sort
of booleans, {true,false}. Functional types are constructed such that if σ and τ are types,
then functions of type σ to objects of type τ have the type σ → τ. Similarly, a function from
individuals to the booleans is of type ι → o. Typed expressions are built by application
(if M is of type σ → τ and N is of type σ, then their application (M N) is of type τ) and
abstraction (if x is a variable of type σ and M is of type τ, then the abstraction λ x.M is
of type σ → τ ). The constants ∧, ∨ and ⊂ ,of type o → o → o, and ¬ ,of type o → o,
are introduced to add Propositional connectives. Expressions such as (∧MN ) are generally
written in the more usual infix notation M ∧ N .
11
17. In the general semantics of HOL, higher-order formulas over domains are included in each
interpretation over standard type. For instance, if some set of individuals are quantified,
then they may only range over a subset of the power set of individuals. HOL, with these
semantics, is a stronger logic than FOL which has all the model-theoretic properties of FOL
and captures the notion of a complete and sound proof-system inherited from FOL.
2.3.3 ProofPower-Z
ProofPower [16] is a theorem prover based on higher-order logic(HOL) which has been im-
plemented using Standard ML of New jersey (SML-NJ). The standard for implementing
ProofPower has been revised with some extensions offered by SML-NJ. These extensions
were storing the state of an ML and programmable control over the compiler’s input and
output streams. These extensions were used to achieve features such as secure theory hier-
archy, extension of the character set accepted in the metalanguage (ML) by including apt
logical and mathematical notations and inclusion of facilities for quotation of object expres-
sions and printing values representing such expressions.
ProofPower-Z supports the Z notation as well as shallowly embeds its semantics. It ex-
tends ProofPower-HOL, and the ProofPower Z language is an approximate extension of
the Z language. ProofPower provides document preparation facilities for LATEXdocuments.
ProofPower manages a theory database in which details about formal specifications and their
related proofs are stored. It provides facility of syntax and type checking of specifications in
Z and HOL. Other analysis features provided by ProofPower-Z are precondition calculation,
domain checking and general theorem proving. In general, theories in ProofPower, like other
theorem provers as well, contains the following information:
• Definitions of new types, functions, theorems or constants.
• Theorems in general are a set of contextual description describing the scope in which
the theorem is derivable and can be used for further proofs.
• Proof Contexts contains a set of all resources required for theorem proving. It
comprises of predefined theories and theories required for further proving proofs.
2.3.4 Isabelle/HOL
Isabelle/HOL is a HOL based theorem prover which is a specialized form of Isabelle for
HOL. Isabelle, in general, is a generic system for implementing formal specifications and
their proofs [19]. It can be used as a verification and specification system. Implementation
of Isabelle is in Standard ML. An extended version of Isabelle is Isabelle/Isar which hides
almost all of the implementation language.
12
18. Few of the features provided by Isabelle/HOL include recursive functions, recursive datatypes,
inductively defined sets, axiomatic type classes and type and constant definitions. Apart from
these features, Isabelle also generates LATEXsources from theory files (with an extension of
.thy). Specifications in Isabelle are written as theories. Theories are just like modules in
any language, comprising of named collections of types, theorems and constants, which can
be, for example, functions. The body of a theory comprises of declarations, definitions and
proofs. These represent newly introduced types, functions, constants and so on. Isabelle has
a theory called Main which is a collection of basic predefined theories like the basic logic,
lists, sets and many more. A theory also consists of types, terms and formulae of HOL. Basic
types in Isabelle/HOL are bool, nat and list. Further more, types can be defined by the user
as needed. Terms in HOL are formed by applying functions to arguments. And formulae are
terms of type bool. Variables in Isabelle are of three types namely free, bound and schematic
or unknown variables. Schematic or unknown variables should always start with the charac-
ter ?. Schematic variables, in general, are free variables with a difference that they can be
instantiated to another term at the time of the proof process [19]. Isabelle/HOL’s concept
of type classes allows sets of various types in a single class. These types must satisfy any
property, if specified, for this class. Type classes in Isabelle/HOL provides an important
feature, overloading. This allows us to specify multiple definitions for a single constant. For
instance, a binary operator , multiply, can be redefined to be applicable on a particular class
only and only types of this class can be instantiated with this new definition.
ProofPower use Church’s simple type theory extended with the Hindley-Milner decidable
polymorphic type discipline whereas Isabelle/HOL further extends this with Haskell-style
type-classes in order to manage overloading and for proper structuring theory developments.
2.4 Mechanisation Of The UTP
2.4.1 Mechanisation of the UTP in ProofPower-Z
This section discusses the mechanisation of the UTP in ProofPower-Z and includes explana-
tions of various constructs in it. The concept of combining various programming paradigms
given by Hoare and He in their paper, Unifying Theories of Programming, has been used to
mechanise part of the UTP in a theorem prover, ProofPower-Z [21]. As discussed earlier,
ProofPower-Z is an extension of ProofPower-HOL supporting Z, so Z can be used as the
defining language for expressing the semantic model of UTP.
Now, we will discuss the semantic encoding of UTP in ProofPower-Z. The mechanisation
that we are considering for translating to Isabelle/HOL is “ Mechanisation of the UTP and
Circus” [4]. The ProofPower-Z theories described in this mechanisation relates closely to
actual definition of concepts of UTP. Moreover, the complexity level of this mechanisation is
lower and construct definitions are easier to understand as compared to other mechanisation
13
19. like “Unifying Theories in Isabelle/HOL”[5]. The reason behind opting for ProofPower-
Z mechanisation has been its embedding approach for the UTP. This mechanisation uses
the deep embedding which captures both the syntax as well as the semantics of the UTP
framework. ProofPower-Z theory utp lang describes the syntax and semantics of values and
expressions. An element of a free type, VALUE, can be an integer, a boolean, a real number,
channel strings, a set of values, a pair of values, a sequence of values or a special value called
Sync. Sync is a value used in synchronizing data exchange.
VALUE ::= Int(Z) | Bool(B) | Real(R) | Channel(STRING) | Set FVALUE | Pair(VALUE×
VALUE) | Seq(seq VALUE) | Sync
The inverse value constructors of the above defined value constructors IntOf , BoolOf , RealOf
and so on are also introduced. In the current implementation in ProofPower-Z, they are rep-
resented as.
IntOf = (Int∼
)
BoolOf = (Bool∼
)
RealOf = (Real∼
)
ChannelOf = (Channel∼
)
SetOf = (Set∼
)
PairOf = (Pair∼
)
SeqOf = (Seq∼
)
Apart from these, we also introduce concrete sets type like INT VAL, BOOL VAL, REAL VAL
and so on to refer to values of corresponding types. These have been modeled in Z using set
comprehension concept. These appear in ProofPower-Z theories as follows.
INT VAL = {n : Z • Int(n)}
BOOL VAL = {Bool(true), Bool(false)}
REAL VAL = {r : R • Real(r)}
CHANNEL VAL = {n : seq S • Channel(n)}
SET VAL = {s : PVALUE • Set(s)}
14
20. PAIR VAL = {v1, v2 : VALUE • Pair(v1, v2)}
SEQ VAL = {s : seq VALUE • Seq(s)}
The embedding of expressions is also represented by a free type, EXPRESSION . An el-
ement of EXPRESSION can be a value, a variable, a relation, or a unary or a binary
function application.
EXPRESSION ::= Val(VALUE) | Var(VAR)
| Fun1(UNARY FUN × EXPRESSION )
| Fun2(BINARY FUN × EXPRESSION × EXPRESSION )
| Rel(REL × EXPRESSION × EXPRESSION )
The set REL is a set of relations between values and represents relation types VALUE ↔
VALUE. The set of unary functions is modeled for functions of type VALUE → VALUE.
And similarly, the set of binary functions is modeled for functions of type VALUE ×
VALUE → VALUE defining partial function from pair of values to values. For instance, to
encode for difference of two integers 5 and 3, we need a function fun −V , which is of type
BINARY FUN and the encoding would be Fun2(( −V ), Val(Int(5), Val(Int(3)). These
operator functions definitions deal only with values. Arithematic operators over values have
been embedded in ProofPower-Z in axiomatic definition form as
+V : INT VAL × INT VAL → INT VAL
∀ n1, n2 : Z • Int(n1) +V Int(n2) = Int(n1 + n2)
−V : INT VAL × INT VAL → INT VAL
∀ n1, n2 : Z • Int(n1) −V Int(n2) = Int(n1 − n2)
∗V : INT VAL × INT VAL → INT VAL
∀ n1, n2 : Z • Int(n1) ∗V Int(n2) = Int(n1 ∗ n2)
divV : INT VAL × INT VAL → INT VAL
∀ n1, n2 : Z • Int(n1) divV Int(n2) = Int(n1 div n2)
modV : INT VAL × INT VAL → INT VAL
∀ n1, n2 : Z • Int(n1) modV Int(n2) = Int(n1 mod n2)
15
21. There are two important operations that apply to expressions, FV (e) and Eval(b, e).
The first one when applied over an expression e infers all the free variables in it. The second
one evaluates an expression e with respect to a binding b. A binding as discussed below, is
an association between a subset of variables with values. A well defined evaluation requires
a binding b to associate every free variable in expression e with a value. And then the type
of this value should conform to the type of operators occurring in that expression. Here, b
is a BINDING. A BINDING is defined as
| BINDING = {b : VAR → VALUE | (∀ n : dom b • b n ∈ n.type)}
where b is a BINDING characterize by a partial function of type VAR → VALUE ;
a subset of variables associated with values that render a predicate true. And all sets of
such bindings are introduced as a set, BINDINGS. The restriction in the above definition
of BINDING requires it to be well-typed, i.e. the type of a variable in the domain of a
BINDING(n) should be equal to its type defined for that variable. This will become more
clear with the definition of a variable below. In this model, variables are defined as a schema
comprising of name, dashes, subscript and type as its fields.
VAR
name : STRING;
dashes : N;
subscript : SUBSCRIPT;
type : TYPE;
In the above representation, SUBSCRIPT is a new datatype which can either be an element
of Sub, a constructor function of integer type, or SubNone i.e. without any subscript. Also,
type is of type TYPE which are modeled as non-empty subsets of VALUE.
Every alphabet is of type ALPHABET = FVAR. Also, every relation has an alphabet
of such type which further contains input and output alphabets ( inα and outα) which
holds undashed and dashed variables, respectively. Also, defined in this mechanisation are
homogeneous and composable alphabets. An alphabet is known as homogeneous if for every
undashed variable n it holds, n ∈ a ⇔ dash n ∈ a. And a pair of alphabet (a1, a2) is
composable if for every undashed variable n, n ∈ a1 ⇔ undash n ∈ a2.
Next, we have mechanisation of alphabetised predicates. This is modeled as a Z type
ALPHA PREDICATE in this mechanisation. A predicate in the UTP, in general, is a
pair of two elements. First, being its alphabet and the second, being a set of all the bindings
that satisfy the UTP predicate. The restriction on it is that the domain of bindings should
be equal to its alphabet
| ALPHA PREDICATE = {a : ALPHABET; bs : BINDINGS | (∀ b : bs • dom b = a)}
16
22. There are a number of predicate operators that are applicable on alphabetised predicates
defined above. Alphabet extension( ⊕P ) is a function used to extend the alphabet of an
ALPHA PREDICATE with another ALPHABET. The values of the new variables are left
unconstrained. An alphabet extension is defined as
⊕P : ALPHA PREDICATE × ALPHABET → ALPHA PREDICATE
∀ p : ALPHA PREDICATE; a : ALPHABET•
p ⊕P a = (p.1 ∪ a, {b : BINDING | dom b = p.1 ∪ a ∧ (p.1 b) ∈ p.2})
Similarly a restriction can be made over an ALPHA PREDICATE to exclude an ALPHABET
from it. This definition is known as alphabet restriction and is given as
P : ALPHA PREDICATE × ALPHABET → ALPHA PREDICATE
∀ p : ALPHA PREDICATE; a : ALPHABET•
p P a = (p.1 a, { b : p.2 • a − b})
A conjunction is represented as an union of the alphabets and an intersection over the
extended set of bindings of a relation.
∧P : ALPHA PREDICATE × ALPHA PREDICATE → ALPHA PREDICATE
∀ p1, p2 : ALPHA PREDICATE•
p1 ∧P p2 = (p1.1 ∪ p2.1, (p1 ⊕P p2.1).2 ∩ (p2 ⊕P p1.1).2)
Similarly the disjunction operation is also applicable, except the difference that the output
result here is an union of the extended set of bindings.
∨P : ALPHA PREDICATE × ALPHA PREDICATE → ALPHA PREDICATE
∀ p1, p2 : ALPHA PREDICATE•
p1 ∨P p2 = (p1.1 ∪ p2.1, (p1 ⊕P p2.1).2 ∪ (p2 ⊕P p1.1).2)
Apart from the above defined logical connectives, other few logical connectives also exist.
TrueR is a construct that represents truth. When this is applied over an alphabet a, TrueR a,
represents the pair with alphabet a and all the bindings with the domain of a. Similarly
another logical connective construct FalseR is constructed which captures the notion that
nothing can satisfy false. Thus the second element of this construct is an empty set. Nega-
tion and implication are also a part of UTP’s logical connectives.
The ProofPower-Z definitions described above so far are largely the part of the theories
that we are considering to mechanise in Isabelle/HOL. These definitions capture the large
part of UTP’s essence. In the next section, Conclusion, we evaluate this mechanisation on
various grounds.
17
23. 2.5 Conclusion
The Mechanisation of UTP in ProofPower-Z[21] has followed an approach of deep embed-
ding. In this approach the syntax as well as semantics of the alphabetised predicates, which
is the foundation of UTP, has been embedded in the host language, Z. This approach en-
ables us to introduce new predicate combinators or operators if we need to introduce some
specific kind of combinations. Moreover, the representation of syntax of various constructs
in UTP[9] concepts relates very closely to the language aspects of Z. Thus making the un-
derstanding of these concepts much more clearer. There also exists a mechanisation of UTP
in Isabelle/HOL called “Unifying Theories in Isabelle/HOL”[5]. This mechanisation, in con-
trast to the mechanisation in ProofPower-Z, makes use of shallow embedding to embed the
semantics of part of UTP theories in Isabelle/HOL. Due to this approach we cannot proof
about various rules and properties of UTP, which is an important requirement of this project.
There are a couple of limitations of the current implementation in ProofPower-Z as well. The
domain VALUE limits the cardinality of the sets to be finite in order to keep the recursive
definitions well-founded. Thus not allowing to reason about various in-built theorems about
sets. Also, the presentation of alphabet is untyped, that is there is no direct association
between a variable defining its type. But even after some of its limitations, mechanisation
in ProofPower-Z is a better embedding of UTP which also embeds its syntax in itself, such
that we can reason about UTP laws.
18
25. We have already mentioned the major objectives of the project in the introduction sec-
tion. But this section throws some more light on what lies beyond those objectives. The
requirements of the project are mentioned below.
3.1 Basic Requirements
• We need to translate the mechanisation of the UTP theories in ProofPower-Z and
embed it into the logic of Isabelle/HOL. We need to make sure that the translation
done in Isabelle/HOL is type and syntactically correct. Moreover, the theories written
in Isabelle/HOL should parse and be accepted by the system. It is necessary that all
definitions or theories which are translated into Isabelle/HOL, they carry the same
semantical meaning and notion as that in the ProofPower-Z mechanisation. For this
purpose, we need do the proofs of the mechanised constructs in Isabelle/HOL. These
will be carried out in the evaluation section.
• Evaluation of the theories constructed in Isabelle/HOL representing the mechanisation
of UTP in ProofPower-Z should be done. This requirement involves formulating and
running various proofs about the constructed definitions of the theories written in
Isabelle/HOL. These proofs can be any simple formula satisfying a predicate or any
elementary law of UTP.
• One important requirement of the project is to compare the current implementation of
the UTP mechanisation model with the one to-be-implemented of Isabelle/HOL. It is
an important observation for the project differentiating the two mechanisation as well
as the theorem provers on the basis of their efficiency in terms of proofs.
3.2 Research Requirements
Besides some of the requirements mentioned above, we have some research requirements as
well.
• We need to explore and learn about the theorem prover Isabelle/HOL and its powerful
automatic proof support. This further includes comparing it with the theorem prover
ProofPower-Z on the basis of various other feature support apart from proving.
• Another research requirement is to explore the current mechanisation of UTP in
ProofPower-Z. This requires to study the mechanisation and understand the model
for UTP. Further, we need to look out for any inconsistency or alternative for any
definition in the model of UTP in ProofPower-Z.
20
26. 3.3 Methodology
The translational strategy we will adopt for this project is shallow translation. Here, we
will mechanise various constructs of Z language into equivalent Isabelle/HOL concepts and
language in a way that the semantics of the object language is maintained. We will then
capture the semantical notion of the definitions in ProofPower-Z embedding of UTP into
Isabelle/HOL. This translation will require writing definitions in Isabelle/HOL which are
syntactically and type correct. The next chapter analyses the various concepts of Z and
Isabelle/HOL language. And, then discusses the possible translations of Z concepts into
equivalent features and concepts available in Isabelle/HOL.
21
28. In this chapter, we will discuss in detail about the Z language and its representation,
HOL and its syntax and semantics and the comparison of both languages on the basis of
various constructs and definitional procedures.
4.1 The Z Language
Z is a formal language that uses mathematical notations to describe the specifications of a
software system. Specifications refer to abstract information about the system to be im-
plemented. By abstract information, we mean that the specification defines what a task or
system performs and not how it performs it. A specification comprises of schema and other
definitions that model elements of the system and some constraints over them. The seman-
tics of a Z specification is expressed in terms of values for the elements defined, given they
are in consistency with the constraints over them. Also, Z notation is based upon set theory
which involves standard set operators, cartesian product, power sets and set comprehension
[13]. A schema in Z is used to specify structures in systems and also system properties.
One of the characteristics of Z is its type system. The notion behind the type system is
that it can be checked automatically for well-formedness of every object in a specification. Z
with its strong structuring mechanism and in combination with natural language is capable
of generating formal specifications of a system and also reason about them. These specifi-
cations can be further constrained and thus refined into more strict specification, closer to
real implementation.
Z is not a formal method instead it is a formal specification notation that is formulated
to be expressive and understandable by humans rather than being executable by computers
[10]. However, in context to this project the usage of Z language is made as a means for
defining the semantics of the UTP rather than a software modeling technique. Defining the
semantics of UTP in Z has made the understanding of the basic model of UTP much clear.
This in return provides us with a general framework for UTP which can be further utilized
in modeling systems at various levels.
4.1.1 Syntax and Semantics
This section illustrates the description of all mathematical objects that are relevant to
ProofPower-Z mechanisation to express a specification. It describes definitions of basic lan-
guage constructs and its usage rules. This is necessary from the perspective of making the
understanding of the model for UTP presented in the current mechanisation in ProofPower-Z
as clear as possible. Below is the descriptions of all the basic definitions and constructs of Z
used in the parts of the existing UTP mechanisation that we consider.
23
29. Basic In-built Operators
• Logical Operators in Z are
1. ∧ - conjunction, and of two predicates.
2. ∨ - disjunction, or of two predicates.
3. ¬ - negation, not of a predicate.
4. ⇔ - equivalence, P ⇔ Q, if both P and Q can be proved from each other.
5. ⇒ - implication, P ⇒ Q, if P is true then Q cannot be false.
• Equality is denoted by =. For example, x = y
• Quantification Below is the abbreviation form of quantifiers with their respective Z
notation and syntax.
1. For All : ∀ x : type | pred • expr
2. There Exists : ∃ x : type | pred • expr
Sets
Sets in Z are always typed i.e. free from the paradox; sets need to be of the higher types
than its members. All standard set operators are applicable on sets in Z and are discussed
below.
• Enumerated Sets are represented as enumeration of elements of same type. For ex-
ample
S = {1, 2, 3, 4, 5} represents the set consisting of number 1 to 5.
• Set comprehension in Z is represented in the following form
{x : type | pred(x) • expr(x)}
It means, the set of values according to an expressions over a bound variable x for
which a predicate holds and whose value is evaluated on the basis of an expression.
• Operators on Sets
1. ∈ - element-of operator, represents an object as an element of a set
24
30. 2. ⊂ - subset operator, represents a set as a subset of another set of same type.
3. × - cartesian product operator,
4. P - power set operator, P S represents a collection of all possible subsets of a set
S, including empty set as well.
5. ∪ - union operator, P ∪ Q represents a collection of all the elements in set P and
Q, given both are of same type.
6. ∩ - intersection operator, P ∩ Q represents all those elements that are common
in both sets P and Q, given both are of same type.
7. - set difference operator,P Q, represents all those elements in P which are not
elements of Q.
Types
• Basic type Basic types in Z represent given sets of a specification. For example, a
company comprising of a number of employees may have a basic type of person as
[PERSON ]
• Free Type The free type definition defines an object as a collection of constants,
constructor functions or recursively defined structures all together as a single type.
For instance
SUCCESS ::= Yes | No | MayBe
defines SUCCESS as a type of exactly three constraints Yes, No and MayBe. A free
type definition can also comprise of constants and constructor functions together.
Tree ::= leaf | node Tree × Tree
The above free type definition defines a Tree as a type of constant leaf or a a node of
product or pair type Tree × Tree.
• Set types A set of objects itself is an object of set type, P T, if its elements or objects
have the same type as of T. For instance, a set of integers
S = {1, 2, 3, 4, 5}
is of type P Z, where Z is a set of all integers. A set type, such as above, is considered
just as a set expression rather than a maximal.
25
31. • Cartesian product types If an element, a, is of type S and another element, b, of
type T then an ordered pair of (a, b) becomes and element of cartesian product type
S × T. This is the same for n number of objects. A tuple with n many objects is
called as an n-tuple. An n-tuple in Z , (a1, a2, ..., an), is of a cartesian product type
A1 × A2, ..., ×An.
• Schema types For two elements a and b of type S and T respectively and two
unique identifiers p and q, there exists a binding x = |p → a, q → b| which is an
object of schema type |p : s; q : u| . A component x.p or x.q corresponds to elements
a or b respectively. A schema type is basically a collection of various other types or
components. We can call it as a composite type. An example of a simple schema type is
SchemaDef
a : Z
b : STRING
A selection operator “ . ” is used to refer to any specific component of a schema. So
any object, O, of type SchemaDef can have a command O.a or O.b to refer to its
specific component.
Variable and its Scope
If a variable is introduced in a construct like lambda expressions, quantifications, schema
and so on, it can range over types or set types.
a : Z
n : FNAMES
Variables can be global or local, introduced by use of quantifiers.
Relations
Relations are denoted with the notation A ↔ B which means the set of all binary relations
between sets A and B. This, in general, is also considered as the power set P(A × B), a
subset of A × B ordered pairs [17].
A ↔ B = P(A × B)
Basic Operations that can be applied to a relation
1. dom - This operation gives all values in the domain of a relation that validly applies
to a given argument. The domain over a relation R is defined as
dom R = {p : A; q : B | p → q ∈ R • p}
26
32. 2. ran R - This operation ,just like operator dom, gives values in the range of a relation
that validly applies to a given argument. The range over a relation R is defined as
ran R = {p : A; q : B | p → q ∈ R • q}
In the above representation of Domain and Range of a relation, notation p→q expresses
an ordered pair (p, q).
3. Restriction and Anti-Restrictions
Restriction and Anti-Restrictions ranges over domain and range of a relation.
Domain Restriction on relation R over its domain set A is given as A R, it relates
an element p of a set A with element q of set B, if and only if, p relates to q in relation
R and is a member of set A. It is defined as
A R = {p : S; q : T | p → q ∈ R ∧ p ∈ A • p → q}
Domain Anti-Restriction, a counterpart of domain restriction, on relation R over
its domain set A is given as A − R, it relates an element p of a set A with element q
of set B, if and only if, p relates to q in relation R and is not a member of set A. It
is defined as
A − R = {p : S; q : T | p → q ∈ R ∧ p ∈ A • p → q}
Range Restriction on relation R over its range set B is given as R B, it relates an
element p of a set A with element q of set B, if and only if, p relates to q in relation
R and q is a member of set B. It is defined as
R B = {p : S; q : T | p → q ∈ R ∧ q ∈ B • p → q}
Range Anti-Restriction,a counterpart of range restriction, on relation R over its
range set B is given as R − B, it relates an element p of a set A with element q of set
B, if and only if, p relates to q in relation R and q is not a member of set B. It is
defined as
R − B = {p : S; q : T | p → q ∈ R ∧ q ∈ B • p → q}
4. Relational Inverse of a relation is written as relation name followed by the inverse
symbol ∼
, which states that an element q is related to p in a relation R∼
, if and only
if, there exists a relation R where p is related to q. The general representation of
relational inverse is
27
33. R∼
= {p : A; q : B | p → q ∈ R • q → p}
5. Relational Composition is applied over two relations. If there are two relations
R : A × B and R : B × C then their relational composition R o
9 R relates an element
a of set A with element c of set C, if and only if, there exists an element b in set B
that is related to an element a in relation R and also to an element c in relation R .
R o
9 R = {p : A; q : B; r : C | p → q ∈ R ∧ q → r ∈ R • p → r}
Another notation of relational composition is R ◦ R
6. Relational Image is a property of a relation that when applied over a relation,
restricts the domain set of relation to a particular subset of the domain and gives the
corresponding set of element in the range to which some of the elements of the subset
are related. So if a relation drives tells us which driver uses which vehicle, then the
relational image on it can be given as
drives(| John, Michael |) = {ferrari, alpha romeo, beetle}
This representation will give a set of all cars that are either driven by John or Michael.
In short, a relational image can be considered as a domain restricted to a subset of a
relation.
Functions
Functions are special form of relations. As relations and functions in Z are treated similarly,
thus all the operations applied to relations are applicable to functions as well. Functions, in
general, are of two types. A function A → B is total, if the domain of the function related
to elements in B is whole of the set A.
A → B = {R : A → B | dom R = A}
Second type of functions are called partial functions, A → B, which maps one element from
A to at most one element in B. This means if one element from the left side is mapped to
two elements on right then the two elements on right should be same.
{R : A ↔ B | ∀ a : A; b1, b2 : B • (a, b1) ∧ (a, b2) ⇒ b1 = b2}
Three basic properties of functions are as follows:
1. Injectivity is the property of a function which implies that an element from the
domain of a function should be mapped exactly to one element of the range of that
function. In other words it can be called as a One −to −One function. Total injection
can be represented as A B and similarly partial injection as A B.
28
34. 2. Surjectivity is the property of a function which implies that range of a function is
whole of the target set. So, say, for a function F : A → B, range should be ran F = B.
Total surjection can be represented as A →→ B and similarly partial surjection as
A →→ B.
3. Bijectivity is the property of a function which satisfies both of the above properties,
i.e., injectivity and surjectivity. In other words, no two elements in the domain should
be mapped to same element in the range and all of the target set should be the range
of that function. Total bijection can be represented as A → B.
Definition
Objects can be defined in Z in following three styles:
1. Type Declarations , as already discussed, is the simplest way of declaring an object
as a set or a basic type. For example, [NAME] introduces a new given basic type.
2. Abbreviation is another form of introducing a new object. As the name suggests,
the object is introduced as an abbreviation for an existing type. So an abbreviation
person == people introduces a new object person which has same type and values as
the expression people.
3. Axiomatic Definition defines a variable and can optionally put a constraint on the
values it takes. In general, an axiomatic definition is of the following form:
Object Declarations
Constraining Predicates
where an object is introduced in declaration and constraints over its values are made
in the predicates. For example, the axiomatic definition
n : N
∀ a : N • n = a + 5
defines a new variable n which which increments the given natural number by 5.
In the next section we discuss, notions about Isabelle/HOL’s syntax and semantics.
4. Generic Definition in Z is a generic form of axiomatic definition in which we can
define a whole family of global constants, which is parameterized by some given set.
A generic definition.
[Name]
a : Name
p
29
35. defines a constant of type NAME, satisfying the predicate p. The value x whenever
used should always be of the given type, in this case of type NAME.
5. Schema definition in Z can be of the following general forms.
SchemaName
Declarations
Predicate1, Predicate2....
or it can take the form where we assume that the predicate part is “true”.
SchemaName
Declarations
So this section provided us with the basic foundation about the concepts and syntax notion
of various constructs of Z language. Further in the next section, we will discuss the syntac-
tical notions and features of Isabelle/HOL and compare their common features in the later
sections.
4.2 Isabelle/HOL Syntactic Notions and Features
Isabelle, as discussed, is a theorem prover that supports various object logics. Higher-Order
Logic is one of the logics that Isabelle supports. HOL is an expressive foundation for math-
ematical concepts and functional programming. First Order Logic allows quantifications of
single variables or individuals but not predicates. FOL, with its quantifiers, is an extension
of basic propositional logic. HOL on the other hand extends FOL by incorporating quantifi-
cation over even higher or complex types like functions, relations, and so on. Isabelle/HOL
is an instantiation of Church’s higher-order logic [1] and its syntax for its basic constructs
are discussed below.
4.2.1 Syntax and Semantics
Theories in Isabelle
The top-level construct in Isabelle is known as a theory. Theories are named collections of
types, functions and theorems. A theory has a general syntax .
theory Name
imports P1...Pn
begin
declarations, definitions, theorems, proofs, ...
end
30
36. The above definition introduces a new theory called Name. It makes use of predefined or
parent theories P1...Pn. So anything defined in the parent theories is automatically inherited
or is visible in this theory. The body of the theory can comprise of some new declarations,
definitions, theorems and proofs.
Types and Terms in Isabelle/HOL
• Base types There are many base types in Isabelle/HOL, in particular nat and bool,
i.e., type of natural numbers and the type of boolean values, respectively.
• Type Constructors in Isabelle are of many forms. In particular, type list representing
the type of lists. An empty list is given as []. A list x # xs is a list with its first element
being x (head) and the rest xs as tail. Also, there is a type set, the type of sets. These
are used as postfix in type declaration as Name set or Name list corresponding to a
set of names or a list of names.
• Numerical Types Isabelle has numerical types such as int, the type of integers and
real, the type of real numbers.
• Functional Types A Functional type in Isabelle is represented as ⇒. A type τ1 ⇒ τ2
represents a total function type. In HOL, functions are always total.
• Type variables are denoted by a, b and so on. It is similar to functional program-
ming language ML in this context. Type variables in Isabelle/HOL can be instantiated
with other types. For instance, a list instantiates a variable as of type constructor
list, a ⇒ b is a total function type constructor.
• HOL Pair or Product type It defines ordered pairs with syntax (a, b) of type
τ1 × τ2, given a and b are of types τ1 and τ2 respectively. Relations in Isabelle/HOL
are considered as a set of product types.
• Record type Isabelle/HOL has a unique type for supporting the notion of having a
single type which further comprises of various other types as its fields. A record is
basically a tuple comprising of n fields. The order of these fields are significant. And if
there are two records with same field names then they can be accessed by using their
qualified name. A record has a feature of getting extended with some new fields as
well. The general syntax for a record is
record Name =
field1 :: τ1
field2 :: τ2
fieldn :: τn
• Terms in Isabelle can be of one of the following forms
31
37. Term ::= var | con |?var | (λ x.Term) | (Term Term) | (Term :: τ)
It can be a variable, constant, schematic variable(discussed later), function abstraction
(λ −abstraction), function application (e.g. f b is the function f over an argument b)
or as a term restricted to a type (e.g. t :: ‘a ⇒ ‘b). Terms in Isabelle should always
be well-typed. Isabelle has a property of inferring the type of every variable in a term.
This is known as type inference.
4.2.2 Type Definitions in Isabelle/HOL
Datatype
In HOL, most of the applications comprises of datatypes. The format of a datatype definition
is of the form
datatype (α1, ..., αn)t = C1 "τ1" | ... | Cn "τn"
where αn are the type variables that are optional parameters, t is the name of the datatype
being introduced, Cn are the constructor names with their corresponding types, τn. A nam-
ing restriction on constructor names requires them to start with a capitalized letter.
A recursive datatype definition in Isabelle/HOL can be given using the same construct.
For an example,
datatype tree = Node "nat" | Edge "tree list"
defines a new datatype tree that has a numbers of nodes, of natural number type, and edges
of type list of trees.
Type Synonyms
Type Synonym is a method of introducing an abbreviation for an existing type or a complex
type. Type synonyms cannot be recursive in nature. We make use of the types command
to define a new type synonym. The general format of the types command is
types newname = τ
The above definition introduces a new synonym, newname, for the type, τ. This construct
does not define a new datatype of its own rather makes use of predefined types or complex
types to make a new type. The main purpose behind using this is to improve readability of
Isabelle theories [19].
32
38. Type Declaration
The most trivial and pure way of introducing a new type is a type declaration. The typedecl
command is used to introduce a new type.
typedecl newtype
The typedecl command merely introduces a new type but does not define it. To define it,
we make use of typedef command which defines the new type, evenset, as
typedef evenset = "{2, 4, 6, 8, 10}"
This new type set comprises of the first five even natural numbers.
4.2.3 Variables in Isabelle/HOL
Isabelle/HOL comprises of three kinds of variables.
1. Free variables
2. Bound variables
3. Schematic variables
The first two variables stands for their usual meaning. A free variable is an unspecified
variable that can be substituted later in some expression. Whereas, the same becomes a
bound variable if being limited to some kind of quantification. The third and special kind
of variable that Isabelle/HOL introduces is a schematic variable or sometimes called as an
unknown variable. Logically a free and a schematic variable are equivalent but with a differ-
ence that schematic variables can be instantiated to some term at the time of running proofs.
Whenever there is some mathematical theorem written in a specification, say x = y + z, it
gets transformed in the form ?x =?y+?z. An unknown or a schematic variable is always
prefixed with the special character ?. An important feature of these variables is that they
are automatically instantiated arbitrarily by Isabelle when used in any proof.
4.2.4 Quantifiers and Descriptive Operators
Quantifiers
Isabelle/HOL supports basic quantifiers such as universal and existential quantifiers. The
general syntax for a universal quantifier, ALL, pronounced as “forall” is ∀ x.p or the existen-
tial quantifier,EX , pronounced as “there exists” is ∃ x.p. Symbols used for these quantifiers
are ∀ and ∃ which are just syntactic sugars for ALL and EX , respectively. These have been
explained later in detail in the analysis section.
33
39. Description Operators
HOL has two description operators. The first one is a definite description operator. This
operator makes the predicate hold only for one unique value as a result for a given formula
and return an arbitrary value for rest of the cases. This operator is formed by formalizing
the word “the”, that stands for only one unique value. The general syntax of this operator
is given as
THE x.P x
Isabelle uses the symbol THE to formalize the definite operator. It stands for a value x such
that P(x) is true and there exists exactly one x that satisfies P.
The other operator is indefinite operator. It is different from definite operator from the
perspective that there is no need of a unique solution but collection of some values that
satisfy a given predicate. This operator is denoted by Hilbert’s choice operator ε. Indefinite
operator formalizes the word “some” in the following way
SOME x.P x
It denotes a value x such that P(x) is true, provided at least one exists.
4.2.5 Sets and Set Comprehension in Isabelle/HOL
Set comprehension in Isabelle/HOL is of the form {x.P}. It is a collection of all those x
that satisfies the predicate P. A general syntax of set comprehension is explained through
the following example.
{s.a b.a ∈ odd ∧ b ∈ even ∧ s = a + b}
In the above set comprehension, s is a set that contains sum of an odd and an even number.
Quantification over sets can be universal or existential. Apart from this, various set oper-
ations are applicable on sets. An union operation over two sets is given as A ∪ B and an
element belonging to set A or B can be given as c ∈ A ∪ B.
Similarly, an intersection operation is also applicable. An intersection over sets is repre-
sented as A ∩ B and an element that is an element of set A as well as set B is given as
c ∈ A ∩ B. Set difference operation is also applicable by forming an intersection between a
set and a complement of another set.
There is a predicate called finite in Isabelle/HOL that encapsulates the idea of holding
all finite sets. This is necessary from the perspective of making a finite set type. But sets
cannot be used as an arbitrary type in a datatype definition. This is due to a well-known
inconsistency that has been elaborated upon later.
34
40. 4.2.6 Relations and their Properties
Relations are considered as a set of pairs. And we have already discussed the pair or product
type in Isabelle/HOL which is given as (τ ×τ). Now, say, to define a relation drives between
two sets, drivers and vehicles, can be represented in Isabelle/HOL as
types drives = "(drivers × vehicles)" set
Operations applicable to sets are also applicable to relations like union and intersection. Few
other properties of relations are as follows
Composition of two relations is possible and is given by A ◦ B. It states that if there is
a pair (x, y) in relation A and a pair (y, z) in relation B, then there also exists a relation
having pair (x, z) in it.
Inverse or converse of a relation which interchange the domain and range of a relation is
given as
((John, Rover) ∈ drives) = ((Rover, John) ∈ drives−1
)
Another operation that can be applied to relations is image. The image of a set under a
relation provides us with all the corresponding values of that set in the range of that relation.
The symbolic representation of an image is r D. Here, a relation has been denoted as r
and D is the domain set.
Apart from the above mention operations domain and range of a relation can be obtained
by using the usual functions Domain and Range as a prefix to a relation.
4.2.7 Definitions of Functions in Isabelle/HOL
Definition
As, we have already discussed, functions in HOL are always total. This leads to the require-
ment of termination. As explained, non-termination can be harmful and lead to inconsis-
tency. Thus to deal with this issue Isabelle/HOL supports different definitional constructs
that can be used to define a non-recursive, recursive or well-defined definitions or functions.
A simple non-recursive function can be defined using the definition construct in the follow-
ing way
definition RectArea = "nat ⇒ nat ⇒ nat"
where "RectArea x y = (x ∗ y)"
The above function defines RectArea as a function that takes two natural numbers as input
and whose output is a natural number that is the product of the input numbers.
35
41. Primrec
The other method used for defining functions is the primrec construct. The keyword prim-
rec abbreviates primitive recursion. This has a similar syntax as that of definition with a
little difference that it incorporates the idea of defining a recursive function. Moreover,
primrec has automatic proof support for its defined theorems unlike definitions. Primrec
does not need to tell the Isabelle prover to make use of any definitions in its proofs; instead
it does it automatically. An example of definition by primrec is
primrec reverse = "list ⇒ list ⇒ list"
where "reverse [] = []"
| "reverse (x # xs) = (reverse xs) @ (x # [])"
The above recursive definition defines a function reverse over the type constructors of a
list type to make reverse of a list. The # in the above definition signifies an operation that
adds an element to the front of the list. We have assumed that ”@” is a function that has
been defined before this definition as a function of appending lists.
Though these two constructs are the most commonly used constructs for defining functions,
there exists some other constructs as well. In cases of defining a total recursive functions, we
can make use of a construct fun. This construct is largely used for arbitrary total functions
definitions. And its termination is done automatically by the prover, though there are also
provisions for users to supply user-defined termination proofs. It is proved automatically as
its arguments are reduced for every recursive call.
All of the above concepts of Isabelle/HOL largely cover its dynamics. We are now equipped
to discuss the the translational exercise of embedding Z theories into Isabelle/HOL’s the-
ories. The following section discusses the basic translation rules that can be considered in
doing so. The translation technique used in formalizing the given ProofPower-Z theories is
shallow translation. We have tried to capture the notion of some concepts of the Z language
and identify them with the HOL logic.
4.3 Interpreting ProofPower-Z Theories in Isabelle/HOL
So far we have presented constructs of Z and Isabelle/HOL. Here, we present the analysis
on translation of Z constructs into constructs of Isabelle/HOL, with the aim to capture the
exact semantics of the Z constructs. The following sections will illustrate an embedding of
basic Z constructs like types, definitions, relations, functions, schema, free types, quantifiers,
and so on, into constructs of Isabelle/HOL using its own language. Various problems and
issues experienced during these translations will also be explained thoroughly, some of them
along with their possible solutions.
36
42. 4.3.1 Free Type Definition
To begin with, we consider a free type definition in ProofPower-Z. A free type definition
Tree, for example, defines a binary tree with its element either being a leaf or a branching
point.
Tree ::= leaf (N) | branch(Tree × Tree)
A free type definition, as shown above, can generally be represented in Isabelle/HOL as
a general HOL datatype definition:
datatype Tree = leaf "int" | branch "Tree × Tree"
which defines a recursive datatype Tree which comprises of a type constructor leaf , of
type int, and branch, of a pair type Tree ×Tree. Similarly, Isabelle/HOL accepts other types
like real numbers, booleans, sequences, strings and more. But when it comes to an arbitrary
set type over Tree, Isabelle/HOL does not accept it. This happens because if we allow
arbitrary sets over the defined type in a free type definition, it gives rise to an inconsistency.
This inconsistency has been explained in detail by Michael Spivey in his paper on “The
Consistency Theorem for Free Type Definitions in ” [17]. It explains that there may be
no constructor functions in such a free type definition for any axiomatic descriptions that
satisfy its axioms. Thus, to deal with this issue we need to make the sets restricted to being
finite. Now, the problem faced in making a finite set type was that there was no straight
translation that we came across. One possible partial solution is to define a finite set type
constructor independent of the free type definition. This can be written in Isabelle/HOL as
typedef FiniteSet = {s . finite s }
The typedef command defines a new type FiniteSet which is a finite set type. The predefined
predicate finite holds of all finite sets. But this cannot define a finite set type constructor in
a free type definition. This is due to the face that we cannot define general arbitrary types
in a free type definition. Also another possible solution can be to make use of finite set type
using the Quotient Examples package placed in HOL folder under the Isabelle installation.
This package defines a theory called Fset.thy that can be used to define a finite set datatype.
But in our translation we could not define a finite set datatype using a free type definition.
4.3.2 Definitions
Definitions in Z notation can be of various forms namely declaration, abbreviation or ax-
iomatic definition. On the other, hand to accommodate translation of definitions from Z
into Isabelle/HOL, Isabelle/HOL offers definitions on two levels: namely types and terms.
Those on type levels are considered as type synonyms and those on term level are called
definitions. In general, a type declaration in Z may be represented as
37
43. [Person]
which declares a new basic type called Person. Now, in Isabelle/HOL a declaration, as
above, can simply be written as
typedecl Person
The command typedecl merely introduces a new type without defining it. An abbreviation
in Z
Employee = Person
introduces a new constant Employee for Person. The newly introduced name Employee is
a global constant throughout the specification that will have the same type and value as
Person. And similarly in Isabelle/HOL the command constdefs is used to declare a con-
stant without defining it. The following is an equivalent translation for the above described
abbreviation.
constdefs Employee :: "Person"
An axiomatic definition is used to introduce an object with a constraint over it that holds for
that object throughout the specification. Following is an example of axiomatic definition in Z
Limit : N
Limit ≤ 65535
It defines a constant Limit as a natural number which restricts it being less than or equal to
65535. An equivalent definition of the above axiomatic definition in Isabelle/HOL is given
by using definition keyword in its form as
definition Limit :: "nat set"
where "Limit = {n .n ≤ 65535}"
The definition keyword can be considered as the declaration part where as a statement
written after the keyword where as a predicate defining the constraint. In a definition, we
define the type of the definition introduced after double colon “::”.
A schema definition encapsulates the idea of defining a commonly used concept in a formal
specification under one construct called a schema. A schema type is a record over various
types of components. For example, a schema
INFO
name : STRING
age : N
citizen : country
38
44. defines a schema named INFO that comprises of various fields namely name, age and citizen.
A citizen is of type country which has to be declared as a type somewhere else in the specifi-
cation. A similar construct is available in Isabelle/HOL that is a collection of n fields which is
somewhat like an n-tuple but with a difference that its fields have names as well. It is called
as record. An advantage of using records is that it can be extended with new fields very eas-
ily. A schema represented as above can be translated in Isabelle/HOL as the following record
record INFO =
name :: string
age :: nat
citizen :: country
Z supports various logical schema operators like conjunction, disjunction, negation, implica-
tion, quantification and composition. For instant, a conjunction(∧) of two schemas A and B,
may generate a third schema , C, which will have declaration part from both of the schemas
and will have the predicate as a conjunction of the two predicates of the schemas A and
B. the combining parts of the schema should be of the same type or else the schema would
be undefined. On the other hand, we do not have such operations available on records in
Isabelle/HOL which makes it difficult to explain specifications in Isabelle/HOL in the form
of a state that can be achieved by combining two or more other states(records).
4.3.3 Set Comprehension
A set comprehension in Z, as already explained, is of the form {x : type | pred(x) • expr(x)}
which means, a set of all values of some expression expr(x) in which a free variable x satis-
fies some predicate pred(x). Whereas, in Isabelle/HOL a set comprehension is of the format
{x.P}, which expresses the set of all elements that satisfy the predicate P. If we compare
both notations, we can clearly make out the difference i.e. the absence of an expression in
the Isabelle/HOL definition for set comprehension.
The challenge faced was in interpreting an expression (in a set comprehension) in Z into
an equivalent meaning predicate of set comprehension in HOL. One drawback of set com-
prehension in Isabelle is that it hides the true form of the expression by using its existential
quantifiers. Absence of the expression term in a set comprehension in Isabelle/HOL makes
it difficult in embedding a set comprehension in Z into Isabelle/HOL. In general, a solution
for it can involve introducing an extra variable that can equally express the meaning of an
expression in set comprehension in Z as a predicate in Isabelle/HOL’s definition of set com-
prehension.A set comprehension representing a set of natural numbers greater than 1 and
less than 100 can be given in Z as
Num = {n : N • n ≥ 1 ∧ n ≤ 100}
Num is a natural numbers greater than 1 but less than 100. This set can be made in
Isabelle/HOL as
39
45. definition Num :: "nat set"
where "Num = {s. ∃ n.s = n ∧ n ≥ 1 ∧ n ≤ 100}"
4.3.4 Relations and Functions
A relation in Z is a set of ordered pairs which is a subset of the cartesian product. For an
example R is a relation between two sets A and B. It can be represented as A ↔ B which is
equal to a power set of their cartesian product, i.e. P(A × B). A transition of relation from
Z in Isabelle/HOL looks like types Rel = "(A × B) set".
In Z, functions and relations are treated similarly. Functions are considered as special
relations that have some particular property. And, according to this property relation is
functional at every element in its domain. All operations applicable on relations are also
applicable on functions given the relation has been declared as a function beforehand. Func-
tions in Z, as already discussed, can be total or partial. But in Isabelle/HOL, functions are
always total, represented by the type as ⇒. There is no direct method of translating the
partial functionality into Isabelle/HOL. To include the functionality of a partial function in
Isabelle/HOL, we make use of relations and put constraints over it to behave like a partial
function. To illustrate our embedding technique, let us consider a partial function in Z,
Partial, between two sets A and B. It is given as A → B. Translating this partial function
in Isabelle/HOL comprises of two steps. Firstly, we define the required partial function HOL
type as a relation.
types Partial = ("A × B") set
Once we have a relation, then we make it a well-defined relation(possessing the partial func-
tion property) by imposing a constraint over it. This is done as follows
definition WF Partial :: "Partial set"
where "WF Partial = {s :: Partial . single valued s}"
WF Partial includes all well-defined functions, that is all relations having partial function-
ality. We make use of a special property of relation given by function single valued over a
relation. This function single valued is a part of the Isabelle/HOL predefined theory based
on relations. It imposes the condition that if a pair (x, y) ∈ R and another pair (x, z) ∈ R
then y = z. In other words, if a pair mapping x to y belongs to a relation R and another
pair mapping x to z belongs to the same relation then it is implied that elements y and z
should be same. It makes sure that an element in domain is mapped to exactly one element
in range.
One thing we mentioned is that functions in HOL are always total. This means that the
“Domain” function cannot be applied on functions as all the elements of the domain are
mapped. This is another issue that needed to be dealt with. To restrict domain of a func-
tion, we need to create a new definition that performs similar actions like the “Domain”
40
46. function. Consider a relation drives between drivers and vehicles. This will be defined in
Isabelle/HOL as
types drives = "(drivers × vehicles)" set
The above is a relation, now to make it a function that is not total or we can say a partial
function, we can make use of the just discussed idea of using single valued keyword. Now
if we want to have only that vehicle which a particular driver drives, then we will have to
define a new application in Isabelle/HOL that will operate on a relation and a subset of its
domain. In this case, the subset would only be one element. This idea reminds us of a similar
concept known as “relational image”; which when applied over a relation and some subset
of its domain, gives all the elements in the range to which it is mapped to. So to define this
new application we will have to make use of relational image functionality of Isabelle/HOL
over the relation drives and its domain drivers. But this would give all the vehicles to which
a particular driver is mapped to. We have assumed that the above relation will be defined
as a partial function later on, i.e. will have only one driver mapped to one vehicle. Thus to
constraint the output of a relational image to have only one value as a output, in our case
only one vehicle for one driver, we can make use of the definite operator THE. Thus the
overall definitional construct in Isabelle/HOL would appear as
definition NewApplication :: "drives ⇒ drivers ⇒ vehicles"
where NewApplication drive driver = (THE x.x ∈ drive {driver})"
So the above application provides us with one unique vehicle per driver.
We have observed that a definition construct can be used in places where we define a
non recursive definition. A restriction on use of definition construct is that every free variable
that occurs on the right hand side of the definition must have its occurrence on the left hand
side as well or Isabelle would complain about it. Also from the point of view of proofs, defini-
tions does not have automatic proof support as compared to its other counterparts discussed
later. In place where we need to define a recursive definition, using definition construct
may lead to inconsistencies. This is because of the logic of total functions in HOL, i.e. the
termination requirement is essential. For instance, a recursive function, f (n) = f (n) + 1,
defined by using keyword definition will give rise to inconsistency by leading to 0 = 1 by
subtracting f (n) from both sides [19].
To deal with recursive definitions, Isabelle/HOL provides richer definitional constructs such
as primrec. The format of primrec has already been discussed in the previous section.
The advantage of using primrec over definition construct is that a primrec function def-
inition is converted into a non recursive definition from which its recursive equations are
automatically proved. Apart from primrec, fun, recdef and inductive commands works
very similarly to it. Whereas in Z, recursion is not allowed except in free-type definitions,
which makes it easier to describe a recursive structure.
41
47. 4.3.5 Quantifiers
Quantifications in Z has the following syntax [13]:
∀ a : r | c • p
∃ a : r | c • p
where
• The bound variable is denoted by a
• The range of x is denoted by r
• A constraint is denoted by c
• A predicate is denoted by p
As shown in the above definitions a quantifier can be of two kinds. One is the existential
quantifier, ∃, and the other universal quantifier ∀. An existential quantification , ∃ a : r | c•p
, states that “there exists an x in a satisfying c, such that p”. In existential quantification,
the constraint behaves as a conjunction. On the other hand, an universal quantification ,
∀ a : r | c • p , states that “for all x in a satisfying c, given p holds”. In universal quantifi-
cation the constraint plays the role of an implication.
But in Isabelle/HOL, the general form of quantifiers is much more concise and is given
as
∀ x.p
∃ x.p
where a quantifier can be either ∀ or ∃. Here, x is a variable and p is a predicate. So a
universal quantifier takes the form of ∀ x.p and can be pronounced as “for all x, p holds”.
Similarly an existential quantification is of the form, ∃ x : p, stating “there exists an x,
such that p”. Type inference is an important property in quantification of Isabelle/HOL,
which automatically computes the type of variables in a term unlike in Z where we need to
explicitly mention the type of every variable in a quantification. Translating a quantification
from Z into Isabelle/HOL involves writing the constraint part as a part of a predicate in
Isabelle/HOL.
Apart from the above mentioned quantifiers, there is another universal quantifier which is
a part of Isabelle framework and not the HOL logic. It is logically equivalent to its HOL logic
counterpart ∀ but it operates at meta level.It basically expresses the notion of an arbitrary
value.
42
48. 4.3.6 Lambda Expressions
The lambda expression in Z language has the following format
λ declaration | constraint • result
which represents a function that associates an object introduced by the declaration and
satisfying the constraint to the expression result [13]. To elaborate on the translational
constraint and syntactic difference between Z and Isabelle/HOL for lambda expressions, lets
consider an example. The function increment could be defined as
increment : N → N
increment = λ n : N • n + 1
which increments any given natural number by 1. The lambda expression or abstraction
in Isabelle/HOL has the format λ x. result. It is a function that takes an argument x as
an input and returns, result as the output. The function increment can be translated to a
similar looking expression in Isabelle/HOL as
definition increment :: "nat ⇒ nat"
where "increment = (λ n.n + 1)"
In our translation, there is not much use of lambda expressions but a possible transitional
hindrance can be the absence of constraint part from Isabelle/HOL’s definition for lambda
expressions. To translate which we may need to define another construct that includes the
condition imposed by the constraint. In context to our translation, the mechanisation of
the UTP in ProofPower-Z defines the BINDING where domain of a function is constraint.
It was quite difficult to translate this constraint of restricting the domain of a function as
functions in HOL are always total. To deal with this issue we had to introduce another
function that treats a function as a relation. This has been discussed in detail in the design
section.
4.3.7 Conclusion
This section provided us with details of the concepts lying behind the two languages under
consideration, i.e. the Z language and the language of Isabelle/HOL. Thus, an analysis
of these concepts and constructs gave us an insight on the various differences between the
representation
43
50. This chapter discusses the proposed mechanisation of various concepts and constructs
of the mechanisation of the UTP in ProofPower-Z theories into concepts and constructs
of Isabelle/HOL. The following sections contain step-by-step shallow translation of these
constructs into its definitions in Isabelle/HOL.
5.1 Mechanisation of Values
To begin with we first consider the types of values allowed in the current mechanisation
of UTP. This is contained in the free type definition of VALUE which captures the value
types that can be taken by the variables. As already discussed, it consists of a number of
type constructors Int(Z), Bool(B) and so on,as well as constructors for complex type such
as pairs and sets. The free type definition in Z was modeled in Isabelle using general form
of a datatype definition in HOL, which has been discussed in the previous chapter. The
modeling of VALUE has been presented in Isabelle/HOL in the following form
datatype VALUE = IntVal "int"
| BoolVal "bool"
| RealVal "real"
| Sync
| ChannelVal "string"
| PairVal "VALUE × VALUE"
| SeqVal "VALUE list"
In the above definition, IntVal, BoolVal, RealVal and so on are corresponding type con-
structors for Int(Z), Bool(B), Real(R) and so on, of the mechanisation under consideration.
The type of the sequence constructor, SeqVal, has been defined as a list of VALUE. The
above definition is not complete as it is missing the SetVal type constructor that is of arbi-
trary set type. It has already been discussed in the above section that Isabelle/HOL does
not accept the arbitrary set type in a free type definition.
Next we modeled the TYPE definition. It is the power set which includes all subset of
the above VALUE set”. the above VALUE set, excluding the empty set. In Z, it is de-
fined as a simple abbreviation whereas in HOL it is introduced as a type synonym first
and then the constraint over it, that it should not contain the empty set, is introduced in
WF TYPE(our abbreviation for a well-formed TYPE ). WF TYPE is defined using the
definitional construct, definition, as discussed in previous section. The type definition in
Isabelle/HOL looks like
types TYPE = "VALUE set"
definition WF TYPE :: "TYPE set"
where "WF TYPE = {s . s = {}}"
45
51. The inverse of the above defined value constructors are specified next. There are two possi-
ble ways of doing this translation. One is by simply defining the inverse value constructors
IntOf , BoolOf and so on by using definition construct and defining the inverse property by
making use of the inv keyword which is an equivalent of the ∼
keyword-inverse of a relation,
in Z notation. The one that we have opted is making use of keyword primrec instead of
definition, which helps in defining a recursive function as already discussed in the previous
chapter. This is because of the automatic proof support benefits from primrec which makes
it a better option than defining the inverse of the value constructors. The following are the
translated inverse constructors
primrec IntOf :: "VALUE ⇒ int"
where "IntOf (IntVal n) = n"
primrec BoolOf :: "VALUE ⇒ bool"
where "BoolOf (BoolVal n) = n"
primrec RealOf :: "VALUE ⇒ real"
where "RealOf (RealVal n) = n"
primrec ChannelOf :: "VALUE ⇒ string"
where "ChannelOf (ChannelVal n) = n"
primrec PairOf :: "VALUE ⇒ VALUE ⇒ VALUE"
where "PairOf (PairVal n) = n"
primrec SeqOf :: "VALUE ⇒ VALUE list"
where "SeqOf (SeqVal n) = n"
The above definitions captures the notion of obtaining an inverse of the value construc-
tors defined before them. So the definition "IntOf (IntVal n) = n", simply inverses the
operation IntVal, which takes an integer(n) and turns it into a value, and thus returning us
the same integer(n). The rest of the inverse constructors operate in the similar way. The use
of definition construct in the above definition leads to an error, as the definition construct
does not accept extra arguments on any side of the definition.
5.2 Mechanisation of Concrete Types
Concrete types are used to define sets of a particular type. In ProofPower theories, these
have been represented using the concept of set comprehension. These particular type sets
46
