To save content items to your account,
please confirm that you agree to abide by our usage policies.
If this is the first time you use this feature, you will be asked to authorise Cambridge Core to connect with your account.
Find out more about saving content to .
To save content items to your Kindle, first ensure no-reply@cambridge.org
is added to your Approved Personal Document E-mail List under your Personal Document Settings
on the Manage Your Content and Devices page of your Amazon account. Then enter the ‘name’ part
of your Kindle email address below.
Find out more about saving to your Kindle.
Note you can select to save to either the @free.kindle.com or @kindle.com variations.
‘@free.kindle.com’ emails are free but can only be saved to your device when it is connected to wi-fi.
‘@kindle.com’ emails can be delivered even when you are not connected to wi-fi, but note that service fees apply.
The key feature of a system of qualified types that distinguishes it from other systems based solely on parametric polymorphism is the use of a language of predicates to describe sets of types (or more generally, relations between types). Exactly which sets of types and relations are useful will (of course) vary from one application to another and it does not seem appropriate to base a general theory on any particular choice. Our solution, outlined in this chapter, is to work in a framework where the properties of a (largely unspecified) language of predicates are described in terms of an entailment relation that is expected to satisfy a few simple laws. In this way, we are able to treat the choice of a language of predicates as a parameter for each of the type systems described in subsequent chapters. This approach also has the advantage that it enables us to investigate how the properties of particular type systems are affected by properties of the underlying systems of predicates.
The basic notation for predicates and entailment is outlined in Section 2.1. The remaining sections illustrate this general framework with applications to: Haskell-style type classes (Section 2.2), subtyping (Section 2.3) and extensible records (Section 2.4). Although we consider each of these examples independently, this work opens up the possibility of combining elements of each in a single concrete programming language.
Basic definitions
For much of this thesis we deal with an abstract language of predicates on types.
Many programming languages rely on the use of a system of types to distinguish between different kinds of value. This in turn is used to identify two classes of program; those which are well-typed and accepted by the type system, and those that it rejects. Many different kinds of type system have been considered but, in each case, the principal benefits are the same:
The ability to detect program errors at compile time: A type discipline can often help to detect simple program errors such as passing an inappropriate number of parameters to a function.
Improved performance: If, by means of the type system, it is possible to ensure that the result of a particular calculation will always be of a certain type, then it is possible to omit the corresponding runtime checks that would otherwise be needed before using that value. The resulting program will typically be slightly shorter and faster.
Documentation: The types of the values defined in a program are often useful as a simple form of documentation. Indeed, in some situations, just knowing the type of an object can be enough to deduce properties about its behaviour (Wadler, 1989).
The main disadvantage is that no effective type system is complete; there will always be programs that are rejected by the type system, even though they would have produced welldefined results if executed without consideration of the types of the terms involved.
This kind of rather highflown speculation is an essential part of my job. Without some capacity for it I could not have qualified as a Mobile, and I received formal training in it on Hain, where they dignify it with the title of Farfetching.
Ursula K. LeGuin, The Left Hand of Darkness (1969)
This final chapter has two purposes. A few topics not considered earlier are discussed briefly; usually there is a central problem which has served as a focus for research. Then there is a list of assorted problems in other areas, and some recommended reading for further investigation of some of the main subdivisions of combinatorics.
Computational complexity
This topic belongs to theoretical computer science; but many of the problems of greatest importance are of a combinatorial nature. In the first half of this century, it was realised that some well-posed problems cannot be solved by any mechanical procedure. Subsequently, interest turned to those which may be solvable in principle, but for which a solution may be difficult in practice, because of the length of time or amount of resources required. To discuss this, we want a measure of how hard, computationally, it is to solve a problem. The main difficulty here lies in defining the terms!
Problems.
Problems we may want to solve are of many kinds: anything from factorising a large number to solving a system of differential equations to predict tomorrow's weather. In practice, we usually have one specific problem to solve; but, in order to do mathematics, we must consider a class of problems.