Eric C. R. Hehner

A practical theory of programming

Programs are predicates, programming is proving, and termination is timing.

Predicative programming Part II

Programs are given a new semantics with the merit that a specification written as a first-order predicate can be refined, step by step, to a program via the rules of Predicate Calculus. The semantics allows a free mixture of predicate and programming notations, and manipulation of programs.

do considered od: A contribution to the programming calculus

SummaryThe utility of repetitive constructs is challenged. Recursive refinement is claimed to be semantically as simple, and superior for programming ease and clarity. Some programming examples are offered to support this claim. The relation between the semantics of predicate transformers and “least fixed point” semantics is presented.

A methodology for programming with concurrency: An informal presentation

Abstract In this methodology, programming problems which can be specified by an input/output assertion pair are solved in two steps: 1. (1) Refinement of a correct program that can be implemented sequentially. 2. (2) Declaration of program properties, so-called semantic relations, that allow relaxations in the sequencing of the refinements operations (e.g., concurrency). Formal properties of refinements comprise semantics (input/output characteristics) and (sequential) execution time. Declarations of semantic relations preserve the semantics but may improve the execution time of a refinement. The consequences are: 1. (a) The concurrency in a program is deduced from its formal semantics. Semantic correctness is not based on concurrency but precedes it. 2. (b) Concurrency is a property not of programs but of executions. Programs do not contain concurrent commands, only suggestions (declarations) of concurrency. 3. (c) The declaration of too much concurrency is impossible. Programs do not contain primitives for synchronization or mutual exclusion. 4. (d) Proofs of parallel correctness are stepwise without auxiliary variables. 5. (e) Freedom from deadlock and starvation is implicit without recourse to an authority outside the program, e.g., a fair scheduler.

Termination is Timing

Termination is treated as a special case of timing, with the result that the logic of programming is simplified and generalized.

Real-time programming

Abstract We try to say what constitues real-time programming by looking at some examples. We also comment on the kind of communication primitives that aid this programming, and the kind of formal semantics that is required.

Formalization of Time and Space

Abstract. Time and space limitations can be specified, and proven, in exactly the same way as functionality. Proofs of time bounds, both implementation-independent and real-time, and of space requirements, both worst-case and average-case, are given in complete detail.

A more complete model of communicating processes

Abstract A previous paper by Hoare gives axioms and proof rules for communicating processes that provide a calculus of total correctness. This paper gives explicit definitions of communicating processes as predicates. The former axioms and proof rules become theorems, proved using the explicit definitions. The defining predicates are more powerful than the proof rules for reasoning about processes, but less often useful for their construction. An implementation of the processes using partial recursive functions is given.

Probabilistic Predicative Programming

This paper shows how probabilistic reasoning can be applied to the predicative style of programming.

A probability perspective

This paper draws together four perspectives that contribute to a new understanding of probability and solving problems involving probability. The first is the Subjective Bayesian perspective that probability is affected by one’s knowledge, and that it is updated as one’s knowledge changes. The main criticism of the Bayesian perspective is the problem of assigning prior probabilities; this problem disappears with our Information Theory perspective, in which we take the bold new step of equating probability with information. The main point of the paper is that the formal perspective (formalize, calculate, unformalize) is beneficial to solving probability problems. And finally, the programmer’s perspective provides us with a suitable formalism. To illustrate the benefits of these perspectives, we completely solve the hitherto open problem of the two envelopes.