Program Derivation by Correctness Enhacements

Relative correctness is the property of a program to be more-correct than another program with respect to a given specification. Among the many properties of relative correctness, that which we found most intriguing is the property that program P' refines program P if and only if P' is more-correct than P with respect to any specification. This inspires us to reconsider program derivation by successive refinements: each step of this process mandates that we transform a program P into a program P' that refines P, i.e. P' is more-correct than P with respect to any specification. This raises the question: why should we want to make P' more-correct than P with respect to any specification, when we only have to satisfy specification R? In this paper, we discuss a process of program derivation that replaces traditional sequence of refinement-based correctness-preserving transformations starting from specification R by a sequence of relative correctness-based correctness-enhancing transformations starting from abort.Comment: In Proceedings Refine'15, arXiv:1606.0134

Program Repair by Stepwise Correctness Enhancement

Relative correctness is the property of a program to be more-correct than another with respect to a given specification. Whereas the traditional definition of (absolute) correctness divides candidate program into two classes (correct, and incorrect), relative correctness arranges candidate programs on the richer structure of a partial ordering. In other venues we discuss the impact of relative correctness on program derivation, and on program verification. In this paper, we discuss the impact of relative correctness on program testing; specifically, we argue that when we remove a fault from a program, we ought to test the new program for relative correctness over the old program, rather than for absolute correctness. We present analytical arguments to support our position, as well as an empirical argument in the form of a small program whose faults are removed in a stepwise manner as its relative correctness rises with each fault removal until we obtain a correct program.Comment: In Proceedings PrePost 2016, arXiv:1605.0809

Functional Big-step Semantics

When doing an interactive proof about a piece of software, it is important that the underlying programming language’s semantics does not make the proof unnecessarily difficult or unwieldy. Both smallstep and big-step semantics are commonly used, and the latter is typically given by an inductively defined relation. In this paper, we consider an alternative: using a recursive function akin to an interpreter for the language. The advantages include a better induction theorem, less duplication, accessibility to ordinary functional programmers, and the ease of doing symbolic simulation in proofs via rewriting. We believe that this style of semantics is well suited for compiler verification, including proofs of divergence preservation. We do not claim the invention of this style of semantics: our contribution here is to clarify its value, and to explain how it supports several language features that might appear to require a relational or small-step approach. We illustrate the technique on a simple imperative language with C-like for-loops and a break statement, and compare it to a variety of other approaches. We also provide ML and lambda-calculus based examples to illustrate its generality

Flexible refinement

To help make refinement more usable in practice we introduce a general, flexible model of refinement. This is defined in terms of what contexts an entity can appear in, and what observations can be made of it in those contexts. Our general model is expressed in terms of an operational semantics, and by exploiting the well-known isomorphism between state-based relational semantics and event-based labelled transition semantics we were able to take particular models from both the state- and event-based literature, reflect on them and gradually evolve our general model. We are also able to view our general model both as a testing semantics and as a logical theory with refinement as implication. Our general model can used as a bridge between different particular special models and using this bridge we compare the definition of determinism found in different special models. We do this because the reduction of nondeterminism underpins many definitions of refinement found in a variety of special models. To our surprise we find that the definition of determinism commonly used in the process algebra literature to be at odds with determinism as defined in other special models. In order to rectify this situation we return to the intuitions expressed by Milner in CCS and by formalising these intuitions we are able to define determinism in process algebra in such a way that it no longer at odds with the definitions we have taken from other special models. Using our abstract definition of determinism we are able to construct a new model, interactive branching programs, that is an implementable subset of process algebra. Later in the chapter we show explicitly how five special models, taken from the literature, are instances of our general model. This is done simply by fixing the sets of contexts and observations involved. Next we define vertical refinement on our general model. Vertical refinement can be seen both as a generalisation of what, in the literature, has been called action refinement or non-atomic refinement. Alternatively, by viewing a layer as a logical theory, vertical refinement is a theory morphism, formalised as a Galois connection. By constructing a vertical refinement between broadcast processes and interactive branching programs we can see how interactive branching programs can be implemented on a platform providing broadcast communication. But we have been unable to extend this theory morphism to implement all of process algebra using broadcast communication. Upon investigation we show the problem arises with the examples that caused the problem with the definition of determinism on process algebra. Finally we illustrate the usefulness of our flexible general model by formally developing a single entity that contains events that use handshake communication and events that use broadcast communication