Abstract not found

This paper traces the important steps in the history --up to around 1990-- of research on reasoning about programs. The main focus is on sequential imperative programs but some comments are made on concurrency. Initially, researchers focussed on ways of verifying that a program satisfies its specification (or that two programs were equivalent). Over time it became clear that post facto verification is only practical for small programs and attention turned to verification methods which support the development of programs; for larger programs it is necessary to exploit a notation of compositionality. Coping with concurrent algorithms is much more challenging -- this and other extensions are considered briefly. The main thesis of this paper is that the idea of reasoning about programs has been around since they were first written; the search has been to find tractable methods.

Building semantic models that account for various kinds of indirect reference has traditionally been a difficult problem. Indirect reference can appear in many guises, such as heap pointers, higher-order functions, object references, and shared-memory mutexes. We give a general method to construct models containing indirect reference by presenting a “theory of indirection”. Our method can be applied in a wide variety of settings and uses only simple, elementary mathematics. In addition to various forms of indirect reference, the resulting models support powerful features such as impredicative quantification and equirecursion; moreover they are compatible with the kind of powerful substructural accounting required to model (higher-order) separation logic. In contrast to previous work, our model is easy to apply to new settings and has a simple axiomatization, which is complete in the sense that all models of it are isomorphic. Our proofs are machine-checked in Coq.

This paper traces the important steps in the history --up to around 1990-- of research on reasoning about programs. The main focus is on sequential imperative programs but some comments are made on concurrency. Initially, researchers focussed on ways of verifying that a program satifies its specification (or that two programs were equivalent). Over time it has become clear that post facto verification is only practical for small programs and attention turned to verification methods which support the development of programs; for larger programs it is necesary to exploit a notion of composability.

Abstract. We present a Coq formalization of constructive ω-cpos (extending earlier work by Paulin-Mohring) up to and including the inverselimit construction of solutions to mixed-variance recursive domain equations, and the existence of invariant relations on those solutions. We then define operational and denotational semantics for both a simplytyped CBV language with recursion and an untyped CBV language, and establish soundness and adequacy results in each case. 1

The signature and logical calculus of the algebraic specification language Spectrum are formalized in the generic language Deva. This language is designed to express formal methods as well as proofs of propositions about the objects of such methods and the relations between them. This work is understood as a first step towards a formalization of the software development methodology induced by specifying software in Spectrum. This work has been funded by the German Ministry of Research and Technology as part of the project KORSO under contract 01 IS 203 C9. I thank Martin Beyer, Maritta Heisel, and Matthias Weber for constructive comments on several drafts of this paper. Florian Kammuller checked the entire formalization and developed the example given in the appendix with the Deva support system. Contents 1 Introduction 3 2 Two Brief Language Descriptions 3 2.1 The Algebraic Specification Language Spectrum : : : : : : : : : : : : : : : : : : 3 2.2 The Generic Language Deva : : : :...

We present a formalism independent approach to the design of tools supporting the application of formal methods in software development. It consists of a concept to represent problem solving knowledge, called strategies, and a generic architecture showing how to implement tools for strategy-based development. A prototype system for program synthesis called IOSS is described in some detail. It demonstrates the practicality of the approach. Acknowledgment. We would like to thank Balachander Krishnamurthy for comments on this work. Contents 1 Introduction 2 2 Representing Software Engineering Knowledge by Strategies 5 2.1 An Example: Synthesis of Divide-And-Conquer Algorithms : : : : : : : : : : : 6 2.2 The Structure of Strategies : : : : : : : : : : : : : : : : : : : : : : : : : : : : 7 3 The System Architecture 10 3.1 Overview of the Architecture : : : : : : : : : : : : : : : : : : : : : : : : : : : 10 3.2 Example: Mergesort Revisited : : : : : : : : : : : : : : : : : : : : : : : :...

Oasis, de l’INRIA à Sophia-Antipolis, mais aussi de bien plus loin. Un travail de recherche de ce type est avant tout un travail d’équipe, et le soutien de tous, au quotidien dans les affres d’une soumission d’article ou de proposition de projet, ou au hasard des rencontres dans une conférence à l’autre bout du monde, fait de nous un peu plus qu’un chercheur solitaire en tête à tête avec son ordinateur. J’ai aujourd’hui une pensée particulière pour Isabelle Attali qui avait créé notre équipe, avait su lui insuffler une dynamique remarquable, et nous a quitté tragiquement en décembre 2004. Mes remerciements vont aussi aux doctorants, qui ont eu une place centrale dans ce travail, Didier, Valérie chez Meije, Tomás, Rabéa, Antonio chez Oasis, mais aussi à tous les étudiants qui ont apporté leur brique à notre édifice, leur enthousiasme et leur convivialité. C’est avec grand plaisir que je remercie très sincèrement mes rapporteurs et tous les membres de mon jury d’Habilitation, pour ce temps précieux qu’ils ont bien voulu consacrer à l’évaluation de mes travaux.

Why do some programming languages fail and others succeed? What does the answer tell us about programming language design, implementation, and principles? To help answer these and other questions, we argue for a sociologicallygrounded programming language theory: socio-PLT. Researchers in the social sciences have studied adoption in many contexts. We show how their findings are applicable to programming language design. For example, many programming language features provide benefits that programmers cannot directly or immediately observe and therefore may not find compelling. From clean water to safe sex, the health community has long examined how to surmount similar observability barriers. We use such results from outside of programming language theory to frame a research agenda that should help us understand the social foundations of languages. Finally, we examine implications of our approach, such as for the design space of language features and the assessment of scientific research into programming languages. 1.