This book is about computer programs that can perform automated reasoning. I interpret ‘reasoning’ quite narrowly: the emphasis is on formal deductive inference rather than, for example, poker playing or medical diagnosis. On the other hand I interpret ‘automated’ broadly, to include interactive arrangements where a human being and machine reason together, and I'm always conscious of the applications of deductive reasoning to real world problems. Indeed, as well as being inherently fascinating, the subject is deriving increasing importance from its industrial applications.

This book is intended as a first introduction to the field, and also to logical reasoning itself. No previous knowledge of mathematical logic is assumed, although readers will inevitably find some prior experience of mathematics and of computer programming (especially in a functional language like OCaml, F#, Standard ML, Haskell or LISP) invaluable. In contrast to the many specialist texts on the subject, this book aims at a broad and balanced general introduction, and has two special characteristics.

• Pure logic and automated theorem proving are explained in a closely intertwined manner. Results in logic are developed with an eye to their role in automated theorem proving, and wherever possible are developed in an explicitly computational way.

• Automated theorem proving methods are explained with reference to actual concrete implementations, which readers can experiment with if they have convenient access to a computer. All code is written in the high-level functional language OCaml.

Although this organization is open to question, I adopted it after careful consideration, and extensive experimentation with alternatives. A more detailed self-justification follows, but most readers will want to skip straight to the main content, starting with ‘How to read this book’ on page xvi.

Our efforts so far have been aimed at making the computer prove theorems completely automatically. But the scope of fully automatic methods, subject to any remotely realistic limitations on computing power, covers only a very small part of present-day mathematics. Here we develop an alternative: an interactive proof assistant that can help to precisely state and formalize a proof, while still dealing with some boring details automatically. Moreover, to ensure its reliability, we design the proof assistant based on a very simple logical kernel.

Human-oriented methods

We've devoted quite a lot of energy to making computers prove statements completely automatically. The methods we've implemented are fairly powerful and can do some kinds of proofs better than (most) people. Still, the enormously complicated chains of logical reasoning in many fields of mathematics are seldom likely to be discovered in a reasonable amount of time by systematic algorithms like those we've presented. In practice, human mathematicians find these chains of reasoning using a mixture of intuition, experimentation with specific instances, analogy with or extrapolation from related results, dramatic generalization of the context (e.g. the use of complexanalytic methods in number theory) and of course pure luck – see Lakatos (1976), Polya (1954) and Schoenfeld (1985) for varied attempts to subject the process of mathematical discovery to methodological analysis. It's probably true to say that very few human mathematicians approach the task of proving theorems with methods like those we have developed.

One natural reaction to the limitations of systematic algorithmic methods is to try to design computer programs that reason in a more human-like style.

So far, the code we've lookedat has been split-phase andruns in tasks (synchronous). This programming model is sufficient for almost all application-level code. High-performance applications and low-level device drivers sometimes require additional functionality and concurrency models. This chapter describes two such additional mechanisms: asynchronous code and resource locks. Asynchronous code is a feature of the nesC language, while resource locks are a set of TinyOS components and mechanisms.

Asynchronous code

Tasks allow software components to emulate the split-phase behavior of hardware. But they have much greater utility than that. They also provide a mechanism to manage preemption in the system. Because tasks run atomically with respect to one another, code that runs only in tasks can be rather simple: there's no danger of another execution suddenly taking over and modifying data under you. However, interrupts do exactly that: they interrupt the current execution and start running preemptively.

The async keyword

As we saw in Chapter 5, nesC distinguishes between synchronous (sync) and asynchronous (async) code. Commands and events that can run preemptively from interrupt handlers (and therefore asynchronously with regards to tasks), must be labeled with the async keyword, both in the interface where the command or event is declared and in the module where the command or event is implemented. As a result, an async command or event, or a function reachable from an async command or event can only call or signal async commands and events (nesC will tell you when you break this rule). This rule means that it's clear from looking at an interface or module which code is synchronous and which is asynchronous.

This book provides an in-depth introduction to writing nesC code for the TinyOS 2.0 operating system. While it goes into greater depth than the TinyOS tutorials on this subject, there are several topics that are outside its scope, such as the structure and implementation of radio stacks or existing TinyOS libraries. It focuses on how to write nesC code, and explains the concepts and reasons behind many of the nesC and TinyOS design decisions. If you are interested in a brief introduction to TinyOS programming, then you should probably start with the tutorials. If you're interested in details on particular TinyOS subsystems you should probably consult TEPs (TinyOS Enhancement Proposals), which detail the corresponding design considerations, interfaces, andcomponents. Both of these can be foundin the doc/html directory of a TinyOS distribution.

While some of the contents of this book are useful for 1.x versions of TinyOS, they do have several differences from TinyOS 2.0 which can lead to different programming practices. If in doubt, referring to the TEP on the subject is probably the best bet, as TEPs often discuss in detail the differences between 1.x and 2.0.

For someone who has experience with C or C++, writing simple nesC programs is fairly straightforward: all you need to do is implement one or two modules and wire them together. The difficulty (and intellectual challenge) comes when building larger applications. The code inside TinyOS modules is fairly analogous to C coding, but configurations – which stitch together components – are not.

Most of this book is about positive results: certain logical problems can in principle be automated. Here we consider the limits of automation, showing that algorithms in the usual sense cannot exist for certain logical problems. In particular we show that pure first-order logic is not decidable, and that the theory of natural numbers with addition and multiplication is, in a precise sense, nowhere near decidable. In making our way to these results, we prove Gödel's famous first incompleteness theorem.

Hilbert's programme

The idea of mechanizing reasoning fascinated people long before computers. Specific questions about the scope and limits of mechanization were investigated systematically in the early part of the twentieth century, largely due to the influence of Hilbert's programme to place mathematics on firm foundations. To appreciate the full cultural significance of the results that follow, it's worth examining the intellectual ferment over the foundations of mathematics that made these questions so significant at the time.

At various points in history, mathematicians have become concerned over apparent problems in the accepted foundations of their subject. For example, the Pythagoreans tried to base mathematics just on the rational numbers, and so were disturbed by the discovery that √2 must be irrational. Subsequently, the apparently self-contradictory treatment of infinitesimals in Newton and Leibniz's calculus disturbed many (Berkeley 1734), as later did the use of complex numbers and the discovery of non-Euclidean geometries. Later still, when the theory of infinite sets began to be pursued for its own sake and generalized, mainly by Cantor, renewed foundational worries appeared.

This chapter shows how to build a PC application that talks to motes. As we saw in Section 6.4, a PC typically interacts with a mote network by exchanging packets with a distinguished base station mote (occasionally, several motes) over a serial connection (Figure 6.2, page 95). The PC code in this chapter is written in Java, using the Java libraries and tools distributed with TinyOS. TinyOS also includes libraries and tool support for other languages (e.g. C). Please refer to the TinyOS documentation for more information on these other languages. The TinyOS Java code for communicating with motes is found under the net.tinyos package.

Basics

At the most basic level, PCs and motes exchange packets that are simply sequences of bytes, using a protocol inspired by, but not identical to, RFC 1663 [24] (more details on the protocol can be found in TEP 113 [7]). This packet exchange is not fully reliable: the integrity of packets is ensured by the use of a CRC, but invalid packets are simply dropped. Furthermore:

• Packets sent from a PC to a mote are acknowledged by the mote (but there is no retry if no acknowledge is received) – this prevents the PC from overloading the mote with packets.

• Packets sent from a mote to a PC are not acknowledged.

While it is possible to write mote communication code by reading and writing the raw bytes in packets, this approach is tedious and error-prone. Furthermore, any changes to the packet layout (e.g. adding a new field, changing the value of a constant used in the packets) requires corresponding changes throughout the code.

We study propositional logic in detail, defining its formal syntax in OCaml together with parsing and printing support. We discuss some of the key propositional algorithms and prove the compactness theorem, as well as indicating the surprisingly rich applications of propositional theorem proving.

The syntax of propositional logic

Propositional logic is a modern version of Boole's algebra of propositions as presented in Section 1.4. It involves expressions called formulas that are intended to represent propositions, i.e. assertions that may be considered true or false. These formulas can be built from constants ‘true’ and ‘false’ and some basic atomic propositions (atoms) using various logical connectives (‘not’, ‘and’, ‘or’, etc.). The atomic propositions are like variables in ordinary algebra, and we sometimes refer to them as propositional variables or Boolean variables. As the word ‘atomic’ suggests, we do not analyze their internal structure; that will be considered when we treat first-order logic in the next chapter.

Representation in OCaml

We represent propositional formulas using an OCaml datatype by analogy with the type of expressions in Section 1.6. We allow the ‘constant’ propositions False and True and atomic formulas Atom p, and can build up formulas from them using the unary operator Not and the binary connectives And, Or, Imp (‘implies’) and Iff (‘if and only if’). We defer a discussion of the exact meanings of these connectives, and deal first with immediate practicalities.

The underlying set of atomic propositions is largely arbitrary, although for some purposes it's important that it be infinite, to avoid a limit on the complexity of formulas we can consider. In abstract treatments it's common just to index the primitive propositions by number.