We present an overview of the program transformation methodology, focusing our attention on the so-called `rules + strategies' approach in the case of functional and logic programs. The paper is intended to offer an introduction to the subject. The various techniques we present are illustrated via simple examples. A preliminary version of this report has been published in: Moller, B., Partsch, H., and Schuman, S. (eds.): Formal Program Development. Lecture Notes in Computer Science 755, Springer Verlag (1993) 263--304. Also published in: ACM Computing Surveys, Vol 28, No. 2, June 1996. 3 1 Introduction The program transformation approach to the development of programs has first been advocated by [Burstall-Darlington 77], although the basic ideas were already presented in previous papers by the same authors [Darlington 72, Burstall-Darlington 75]. In that approach the task of writing a correct and efficient program is realized in two phases: the first phase consists in writing an in...

Research in dependent type theories [M-L71a] has, in the past, concentrated on its use in the presentation of theorems and theorem-proving. This thesis is concerned mainly with the exploitation of the computational aspects of type theory for programming, in a context where the properties of programs may readily be specified and established. In particular, it develops technology for programming with dependent inductive families of datatypes and proving those programs correct. It demonstrates the considerable advantage to be gained by indexing data structures with pertinent characteristic information whose soundness is ensured by typechecking, rather than human effort. Type theory traditionally presents safe and terminating computation on inductive datatypes by means of elimination rules which serve as induction principles and, via their associated reduction behaviour, recursion operators [Dyb91]. In the programming language arena, these appear somewhat cumbersome and give rise to unappealing code, complicated by the inevitable interaction between case analysis on dependent types and equational reasoning on their indices which must appear explicitly in the terms. Thierry Coquand’s proposal [Coq92] to equip type theory directly with the kind of

ion. A common form of transformation, which is easily justified by appealing to reversibility, is abstraction. The abstraction transformation lifts some instances of subexpressions from the right-hand sides of a set of definitions and replaces them with function calls for some new functions. The abstraction process can be used in conjunction with a call-by-need implementation to avoid repeated evaluation of subexpressions. A well-known example is Hughes' supercombinator abstraction [Hughes 1982]. Another form of abstraction which is common in program transformation is syntactic generalization in which an expression e is replaced by a function call g e 1 : : : e n , where g is a new function defined by g x 1 : : : xn \Delta = e 0 , such that e j e 0 f e 1 : : : e n= x 1 : : : xn g. General statements about abstractions and their correctness are notationally rather complex. In practice we have found it is easier to appeal to a reversibility argument on a case-by-case basis than...

ion of the Specification Borrowing a saying of Einstein's, I maintain that specifications should be as abstract as possible, but not more abstract. I see three limitations to the degree of abstraction. First, a specification as an adequate formalization of the requirements cannot be more abstract than the requirements themselves. If a specific algorithm is required, this algorithm must be specified. This argument applies as well to non-functional requirements constraining possible implementations. Some constraints can appear as comments in specifications, e.g. the requirement that a specific language should be used for the implementation. Other constraints, however, must be concretely specified, e.g. the requirement that the future software system has to adhere to the data structures of a given interface. The second limitation to abstraction arises when we make formal specifications executable. Even if the degree of abstraction of the data structures and the algorithms stays the same,...

data types are facilitated in Godel by its type and module systems. Thus, in order to describe the meta-programming facilities of Godel, a brief account of these systems is given. Each constant, function, predicate, and proposition in a Godel program must be specified by a language declaration. The type of a variable is not declared but inferred from its context within a particular program statement. To illustrate the type system, we give the language declarations that would be required for the program in Figure 1. BASE Name. CONSTANT Tom, Jerry : Name. PREDICATE Chase : Name * Name; Cat, Mouse : Name. Note that the declaration beginning BASE indicates that Name is a base type. In the statement Chase(x,y) !- Cat(x) & Mouse(y). the variables x and y are inferred to be of type Name. Polymorphic types can also be defined in Godel. They are constructed from the base types, type variables called parameters, and type constructors. Each constructor has an arity 1 attached to it. As an...

Abstract not found

ion Selection Specialization P1/A1 Pn/An S1/G 1 Sn/G n S/G P/A 8 Abstraction For each program P i (i=1, ... , n) we identify a program schema S i which describes P i abstractly. This abstraction generates a set of substitutions q i for schema variables. The same abstraction leads from the literals A i to the abstract literals G i . In short, the abstraction step replaces each term P i /A i by its abstraction S i /G i , and we have P i /A i = S i q i /G i q i . Selection Transformation schemata transform the set of abstract terms {S 1 /G 1 , ... , S n /G n } into an abstract term S/G, i.e. a transformation schema is defined as {S 1 /G 1 , ... , S n /G n, S/G}. In general there are several transformation schemata which have {S 1 /G 1 , ... , S n /G n } as input. We select the transformation schema which generates a desired output program schema S together with an abstract literal G. Specialization We apply the substitution q = q 1 ... q n to S/G to get the transformed pr...

We propose a transformation system for Constraint Logic Programming (CLP) programs and modules. The framework is inspired by the one of Tamaki and Sato for pure logic programs [37]. However, the use of CLP allows us to introduce some new operations such as splitting and constraint replacement. We provide two sets of applicability conditions. The first one guarantees that the original and the transformed programs have the same computational behaviour, in terms of answer constraints. The second set contains more restrictive conditions that ensure compositionality: we prove that under these conditions the original and the transformed modules have the same answer constraints also when they are composed with other modules. This result is proved by first introducing a new formulation, in terms of trees, of a resultants semantics for CLP. As corollaries we obtain the correctness of both the modular and the non-modular system w.r.t. the least model semantics. AMS Subject Classification (1991)...

Abstract not found

The goal of program transformation is to improve efficiency while preserving meaning. One of the best known transformation techniques is Burstall and Darlington's unfold-fold method. Unfortunately the unfold-fold method itself guarantees neither improvement in efficiency nor total-correctness. The correctness problem for unfold-fold is an instance of a strictly more general problem: transformation by locally equivalence-preserving steps does not necessarily preserve (global) equivalence. This paper presents a condition for the total correctness of transformations on recursive programs, which, for the first time, deals with higher-order functional languages (both strict and non-strict) including lazy data structures. The main technical result is an improvement theorem which says that if the local transformation steps are guided by certain optimisation concerns (a fairly natural condition for a transformation), then correctness of the transformation follows. The improvement theorem make...