Co-Developing Programs and Their Proof of Correctness

The ability to verify and reason about programs was one of the main goals behind the design and development of Lucid. In fact, from its very inception Lucid was intended to be not just a programming language, but also a formal system in which program specifications and correctness proofs could be expressed as well. Our goal was a formal programming system in which programs for “realistically” complicated problems could be proved correct with only a realistic amount of effort. The nonprocedural nature of Lucid and its mathematical semantics led naturally to a reasoning technique where properties proved of variables and functions (assertions) are true throughout the where clauses in which the variables and functions are defined, and are not just thought of as being true at particular points where they are “attached” (as would be the case in the usual verification technique for procedural programs). In that respect, Lucid verification is like verification of functional programs. The assertions proved for Lucid, however, have the basic simplicity of the assertions proved in the procedural case, and the proofs are very similar. We will illustrate the differences by using a very simple program for computing integer square roots. We will express it in an imperative language, in a functional language, and in Lucid and show how verification would be performed for each language using the different techniques. In all three techniques, we will use the following terminology from the procedural approach, namely that the precondition is a restriction on the inputs of a program and the postcondition is a desired property of the outputs of the program, assuming that the inputs satisfied the precondition.

machine, defining what each must do to attain a goal. Several points are discussed: the use of techniques in analytical redundancy and their place as analogues in administrative control for conventional techniques in physical control; the use of redundant computer systems to protect against hardware faults; the necessity to prove properties of software used in redundant hardware, because software faults are common modes across redundant hardware; and some issues in choosing a programming language for provable control software. Because proof of correctness is costly, it should be used only where necessary. This report concludes that the degree of reliability needed by the plant model used in analytic redundancy protection need not be nearly as reliable as the mechanism to detect discrepancy between plant and model.

Dataflow languages allow the specification of reactive systems by mutually recursive stream equations, functions, and boolean activation conditions called clocks. Lustre and Scade are dataflow languages for programming embedded systems. Dataflow programs are compiled by a succession of passes. This article focuses on the normalization pass which rewrites programs into the simpler form required for code generation. Vélus is a compiler from a normalized form of Lustre to CompCert’s Clight language. Its specification in the Coq interactive theorem prover includes an end-to-end correctness proof that the values prescribed by the dataflow semantics of source programs are produced by executions of generated assembly code. We describe how to extend Vélus with a normalization pass and to allow subsampled node inputs and outputs. We propose semantic definitions for the unrestricted language, divide normalization into three steps to facilitate proofs, adapt the clock type system to handle richer node definitions, and extend the end-to-end correctness theorem to incorporate the new features. The proofs require reasoning about the relation between static clock annotations and the presence and absence of values in the dynamic semantics. The generalization of node inputs requires adding a compiler pass to ensure the initialization of variables passed in function calls.

We present a deadlock monitoring algodrithm for Ada tasking programs which is based on transforming the source program. The transformations introduce a new task called the monitor, which receives information from all other tasks about their tasking activities. The monitor detects deadlocks consisting of circular entry calls as well as some noncircular blocking situations. The correctness of the program transformations is formulated and proved using an operational state graph model of tasking. The main issue in the correctness proof is to show that the deadlock monitor algorithm works correctly without having simultaneous information about the state of the program. In the course of this work, we have developed some useful techniques for programming tasking applications, such as a method for uniformly introducing task identifiers. We argue that the ease of finding and justifying program transformations is a good test of the generality and uniformity of a programming language. The complexity of the full Ada language makes it difficult to safely apply transformational methods to arbitrary programs. We discuss several problems with the current semantics of Ada's tasks.

This paper proves correctness of Nöcker's method of strictness analysis, implemented in the Clean compiler, which is an effective way for strictness analysis in lazy functional languages based on their operational semantics. We improve upon the work Clark, Hankin and Hunt did on the correctness of the abstract reduction rules in two aspects. Our correctness proof is based on a functional core language and a contextual semantics, thus proving a wider range of strictness-based optimizations as correct, and our method fully considers the cycle detection rules, which contribute to the strength of Nöcker's strictness analysis. Our algorithm SAL is a reformulation of Nöcker's strictness analysis algorithm in a functional core language LR. This is a higher order call-by-need lambda calculus with case , constructors, letrec , and seq , which is extended during strictness analysis by set constants like Top or Inf , denoting sets of expressions, which indicate different evaluation demands. It is also possible to define new set constants by recursive equations with a greatest fixpoint semantics. The operational semantics of LR is a small-step semantics. Equality of expressions is defined by a contextual semantics that observes termination of expressions. Basically, SAL is a nontermination checker. The proof of its correctness and hence of Nöcker's strictness analysis is based mainly on an exact analysis of the lengths of evaluations, i.e., normal-order reduction sequences to WHNF. The main measure being the number of “essential” reductions in evaluations. Our tools and results provide new insights into call-by-need lambda calculi, the role of sharing in functional programming languages, and into strictness analysis in general. The correctness result provides a foundation for Nöcker's strictness analysis in Clean, and also for its use in Haskell.

A recent „mathematical” approach to the semantics of programming languages is extended to allow for quasi-parallel execution of processes. A notion of „action” is proposed as a formalization of the kind of process involved, and various ways of action composition are studied. The relevance of the approach for applications in the areas of language design, language description, and proof of program correctness is indicated.

Much work has been done towards characterizing the semantics of block structured programming languages using the lambda calculus [ 2 ] . Johnston [ 3 ] recently introduced a cell-based approach, called the contour model, for specifying the execution semantics of such languages. This paper relates the two approaches by giving a contour model evaluator for compiled lambda expressions. Section 2 gives the basic definitions needed from the lambda calculus to make the paper self-contained. Section 3 defines the Contour Model Lambda Calculus Machine (CMLCM). Unfortunately publication limitations preclude some worked examples which would greatly aid the reader's understanding. They will be provided in the talk itself and in an expanded version of this paper for the Tutorial Conference on Semantic Models of Computation. Section 4 outlines the structure of the proof of the CMLCM's correctness. And Section 5 is a set of concluding remarks on the significance of the CMLCM.

There is a large gap between the specification of type systems and the implementation of their type checkers, which impedes reasoning about the soundness of the type checker with respect to the specification. A vision to close this gap is to automatically obtain type checkers from declarative programming language specifications. This moves the burden of proving correctness from a case-by-case basis for concrete languages to a single correctness proof for the specification language. This vision is obstructed by an aspect common to all programming languages: name resolution. Naming and scoping are pervasive and complex aspects of the static semantics of programming languages. Implementations of type checkers for languages with name binding features such as modules, imports, classes, and inheritance interleave collection of binding information (i.e., declarations, scoping structure, and imports) and querying that information. This requires scheduling those two aspects in such a way that query answers are stable—i.e., they are computed only after all relevant binding structure has been collected. Type checkers for concrete languages accomplish stability using language-specific knowledge about the type system. In this paper we give a language-independent characterization of necessary and sufficient conditions to guarantee stability of name and type queries during type checking in terms of critical edges in an incomplete scope graph . We use critical edges to give a formal small-step operational semantics to a declarative specification language for type systems, that achieves soundness by delaying queries that may depend on missing information. This yields type checkers for the specified languages that are sound by construction—i.e., they schedule queries so that the answers are stable, and only accept programs that are name- and type-correct according to the declarative language specification. We implement this approach, and evaluate it against specifications of a small module and record language, as well as subsets of Java and Scala.

Almost every programming language’s syntax includes a notion of binder and corresponding bound occurrences, along with the accompanying notions of α-equivalence, capture avoiding substitution, typing contexts, runtime environments, and so on. In the past, implementing and reasoning about programming languages required careful handling to maintain the correct behaviour of bound variables. Modern programming languages include features that enable constraints like scope safety to be expressed in types. Nevertheless, the programmer is still forced to write the same boilerplate over again for each new implementation of a scope safe operation (e.g., renaming, substitution, desugaring, printing, etc.), and then again for correctness proofs. We present an expressive universe of syntaxes with binding and demonstrate how to (1) implement scope safe traversals once and for all by generic programming; and (2) how to derive properties of these traversals by generic proving. Our universe description, generic traversals and proofs, and our examples have all been formalised in Agda and are available in the accompanying material. NB. we recommend printing the paper in colour to benefit from syntax highlighting in code fragments.

The next generation visual programming technology (VTR), which uses so-called R-charts (ISO/IEC 8631) is defined here. R-charts - are being the oriented graphs loaded through the arcs. The main difference of VTR is its simplicity and single graphic form of the program writing during its entire life cycle, which ensures new principles of design, debugging, visual and compact (by more than one order) writing compared to writing in existing programming languages (PL). Due to its simplicity, it is acceptable to broad circle of the specialists, but not only to the programmers. Graphic paradigm of VTR is set, which is based on a single graphical shell for all existing PLs without goto, if, for, while, break, labels, brackets: begin-end, {-} etc. Evidentiary, linguistic, parallel, three- and multidimensional programming is introduced for controlling and computing systems. Colour is used extensively for writing of graphic programs. It is integrated well with available programming systems. At present, graphic programming VTR is realized in the environment Qt Creator C++ (www.glushkov.org). This allowed carrying out justified analysis of VTR advantages in comparison with traditional technologies that use modern PLs, UML, and OOP.

Formal modelling languages play a key role in the development of software since they enable users to prove correctness of system properties, in particular critical systems such as transportation systems. However, there is still not a clear understanding on how to map a formal model to a specific programming language. In order to propose a solution, this paper presents a source-to-source mapping between Event-B models and Eiffel programs, therefore enabling the proof of correctness of certain system properties via Design-by-Contract (natively supported by Eiffel), while still making use of all features of O-O programming.

Proceedings of the 13th international conference on Modularity

We present a new type system for verifying the security of reference implementations of cryptographic protocols written in a core functional programming language. The type system combines prior work on refinement types, with union, intersection, and polymorphic types, and with the novel ability to reason statically about the disjointness of types. The increased expressivity enables the analysis of important protocol classes that were previously out of scope for the type-based analyses of reference protocol implementations. In particular, our types can statically characterize: (i) more usages of asymmetric cryptography, such as signatures of private data and encryptions of authenticated data; (ii) authenticity and integrity properties achieved by showing knowledge of secret data; (iii) applications based on zero-knowledge proofs. The type system comes with a mechanized proof of correctness and an efficient type-checker.

There is an extensive literature about refactorings of object-oriented programs, and many refactoring tools for the Java programming language. However, except for a few studies, in practice it is difficult to find precise formal specifications of the preconditions and mechanisms of automated refactorings. Moreover, there is usually no formal proof that a refactoring is correct, i.e., that it preserves the behavior of the program. We present an equational semantics based approach to Java refactoring. Specifically, we use an executable Java formal semantics in the Maude language to: (i) formally specify three useful Java refactorings; and (ii) give detailed proofs of correctness for two of those refactorings, showing that they are behavior-preserving transformations. Besides the obvious benefits of providing rigorous specifications for refactoring tool builders and rigorous correctness guarantees, our approach has the additional advantage of its executability: our formal refactoring specifications can be used directly to refactor Java programs and yield a provably correct Java refactoring tool.

Navigation algorithms are fundamental for mobile robots. While the correctness of the algorithms is important, it is equally important that they do not fail because of bugs in their implementation. Yet, even widely-used robot navigation code lacks proofs of correctness or credible coverage reports from testing. Robot software developers usually point towards the cost of manual verification or lack of automated tools that would handle their code. We demonstrate that the choice of programming language is essential both for finding bugs in the code and for proving their absence. Our re-implementation of three robot navigation algorithms in SPARK revealed bugs that for years have not been detected in their original code in C/C++. For one of the implementations we demonstrate that it is free from run-time errors. Our code and results are available online to encourage uptake by the robot software developers community.