scispace - formally typeset
Search or ask a question

Showing papers on "Program transformation published in 1984"


Journal ArticleDOI
TL;DR: An approach called Draco to the construction of software systems from reusable software parts is discussed, concerned with the reuse of analysis and design information in addition to programming language code.
Abstract: This paper discusses an approach called Draco to the construction of software systems from reusable software parts. In particular we are concerned with the reuse of analysis and design information in addition to programming language code. The goal of the work on Draco has been to increase the productivity of software specialists in the construction of similar systems. The particular approach we have taken is to organize reusable software components by problem area or domain. Statements of programs in these specialized domains are then optimized by source-to-source program transformations and refined into other domains. The problems of maintaining the representational consistency of the developing program and producing efficient practical programs are discussed. Some examples from a prototype system are also given.

407 citations


Journal ArticleDOI
TL;DR: Three new ideas that seem especially useful in supporting parameterized programming are introduced: theories, which declare global properties of program modules and interfaces; views, which connect theories with program modules in an elegant way; and module expressions, a kind of general structured program transformation which produces new modules by modifying and combining existing modules.
Abstract: Parameterized programming is a powerful technique for the reliable reuse of software. In this technique, modules are parameterized over very general interfaces that describe what properties of an environment are required for the module to work correctly. Reusability is enhanced by the flexibility of the parameterization mechanism proposed here. Reliability is further enhanced by permitting interface requirements to include more than purely syntactic information. This paper introduces three new ideas that seem especially useful in supporting parameterized programming: 1) theories, which declare global properties of program modules and interfaces; 2) views, which connect theories with program modules in an elegant way; and 3) module expressions, a kind of general structured program transformation which produces new modules by modifying and combining existing modules. Although these ideas are illustrated with some simple examples in the OBJ programming language, they should also be taken as proposals for an Ada1 library system, for adding modules to Prolog, and as considerations for future language design efforts. OBJ is an ultra-high level programming language, based upon rewrite rules, that incorporates these ideas, and many others from modern programming methodology.

225 citations


Journal ArticleDOI
TL;DR: The transformation makes essential use of lazy evaluation and local recursion to build a circular program that, on one pass over the structure, determines the effects of the individual traversals and then combines them.
Abstract: This paper describes a technique for transforming functional programs that repeatedly traverse a data structure into more efficient alternatives that do not. The transformation makes essential use of lazy evaluation and local recursion (such as provided by letrec, or its equivalent) to build a circular program that, on one pass over the structure, determines the effects of the individual traversals and then combines them.

159 citations


Journal ArticleDOI
TL;DR: A practical application of the transformational approach to program reuse based on this strategy has a measure of elegance and is also practical-the resulting Fortran program is 25 percent faster than its compiled LISP counterpart, even without extensive optimization.
Abstract: How can a program written in pure applicative LISP be reused in a Fortran environment? One answer is by automatically transforming it from LISP into Fortran. In this paper we discuss a practical application of this technique-one that yields an efficient Fortran program. We view this process as an example of abstract programming, in which the LISP program constitutes an abstract specification for the Fortran version. The idea of strategy-a strategy for getting from LISP to Fortran-is basic to designing and applying the transformations. One strategic insight is that the task is easier if the LISP program is converted to ``recursive'' Fortran, and then the recursive Fortran program is converted to nonrecursive standard Fortran. Another strategic insight is that much of the task can be accomplished by converting the program from one canonical form to another. Developing a strategy also involves making various implementation decisions. One advantage of program transformation methodology is that it exposes such decisions for examination and review. Another is that it enables optimizations to be detected and implemented easily. Once a strategy has been discovered, it can be implemented by means of rewrite-rule transformations using the TAMPR program transformation system. The transformational approach to program reuse based on this strategy has a measure of elegance. It is also practical-the resulting Fortran program is 25 percent faster than its compiled LISP counterpart, even without extensive optimization.

98 citations


Proceedings ArticleDOI
06 Aug 1984
TL;DR: A method for deriving efficient iterative programs by transformation from recursive equation specifications, which enables us to introduce linear recursive functions, instead of the general recursive ones occurring in program specifications.
Abstract: We present a method for deriving efficient iterative programs by transformation from recursive equation specifications. It consists of two phases: i) the transformation of general recursive programs into linear recursive ones, and ii) the transformation of linear recursive programs into iterative ones.In the first phase we apply the “tupling strategy” studied in [BUD77, Pet77], and implicitly used by other authors in the area of program transformation. That strategy enables us to introduce linear recursive functions, instead of the general recursive ones occurring in program specifications.In the second phase we apply known methods for transforming linear recursion into iteration (avoiding the use of stacks) [WaS73], and equivalence results between recursive schemas and flowchart schemas.Through various examples we show how the breaking of the transformation process into the above mentioned phases allows the derivation of efficient iterative algorithms.Those examples include challenges by Prof. E. Dijkstra and other authors. Through our method we were also able to improve some recent results for eliminating redundant calls in recursive programs [Coh83].

64 citations


Journal ArticleDOI
TL;DR: A methodology and supporting programming environment that provide for reuse of abstract programs and the use of the methodology in the setting of rapid prototyping and custom tailoring is discussed.
Abstract: We describe a methodology and supporting programming environment that provide for reuse of abstract programs. Abstract programs are written using notations and constructs natural to the problem domain in a language realized by syntactic extension of a base language. Program transformations are employed to refine an abstract program into its concrete counterpart. We discuss the use of the methodology in the setting of rapid prototyping and custom tailoring.

57 citations


BookDOI
01 Aug 1984
TL;DR: Data types: Feather: I can see how to use abstract data types for things like sets, but not for many of the problem areas I'm interested in, and I find it hard to place the boundaries of abstract data type for some domains.
Abstract: data types: Feather: I can see how to use abstract data types for things like sets, (Jleues and so on, but not for many of the problem areas I'm interested in. If I want to model "sitting in a chair", is "sittir.g" an operation of the abstract data 1;Ype chair? I find it hard to place the boundaries of abstract data 1;ypes for some domains. Data bases: Jackson: You cannot model an interesting real world in a database schema. What Ripken (in [Ripken II]) is trying to do is ask his client to describe the problem or some kind of solution to it by naming entities, possibly naming relations among them and giving various attributes like version numbers. He is engaged in an activity \>Alich consists of various actions and events. You could piece them together, some by hand, some by mochine, there is a history of all these events. All I'm saying is that there is a time dimension \\hich cannot be captured in that way. You are trying to capture this in a database schema. You have no way to succeed, you shouldn't be trying. An example: A database record or tuple or \\hatever seems to me a very bad surrogate for an employee. What is bad about it is that the systems of interest have a real world in which orderings of events in time are very important. It's very difficult to express orderings of events in time in a database. Of course you can write down constraints among different values etc. but it's a very indirect, unnatural, and, I suspect, error-prone way of doing it. That's the worst point. Of course when you come to implement the system, you will end up with some sort of database record. This record is the set of local variables of the process together with some updating routine which m~ be the inverted form* of the original program text for the process; or, if it's been dismembered*, it m~ be a number of distinct updating routines, m~e one for each event type or some other grouping of them. But I regard that as implementation. The identification of the processes is primary. Whether the process corresponds to an enti1;y is a different question altogether. We've really stopped using the word enti1;y in JSO* because it now seems clear that \\hat we really want to do is simply talk about events. And then, \>Alen you describe orderings of events, you find it necessary to write down a number of different grammars to describe the different orderings. Each grammar corresponds not so much to a class of entities as to a class of roles. So if e.g. we are talking about a motorcar factory where people \\ho are employed have preferential treatment as customers, then \\hen you write down the events in \\hich such a person can be involved, you'll find that they wJ1l fall into 00 probably intersecting sets, those which are attributable to the role of the person as an employee, and those which are attributable to the role of the person as a purchaser of motorcars under a preferential scheme. It's those two structures which may have common actions, common events, that one has to focus on rather than trying to say \\hat the entities are. Jackson system design*: Feather: So to take your (M. Jockson's) example of insurance. How do you capture a limitation, say, that the insurance company can only insure a total value of twenty billion pounds?

53 citations


Journal ArticleDOI
TL;DR: The language OCCAM describes the structure of a system of connected microcomputers and its formal semantics allows a program to be read either as a set of commands or as a predicate in an extension of the predicate calculus.

39 citations


Proceedings ArticleDOI
06 Aug 1984
TL;DR: This paper proposes a set of valid equations and discusses how convergent rewriting systems can be generated using REVE, and presents sets of rules presented here are convergent (i.e. finitely terminating and confluent) rewriting systems.
Abstract: In this paper, we are interested in the application of program transformation for minimizing the number of intermediary sequences used in iterative programs. We shall use the FP language for presenting programs. The transformation rules are based on the algebra of functional programs. In contrast to the other systems of rules for program transformation, sets of rules presented here are convergent (i.e. finitely terminating and confluent) rewriting systems. These rewriting systems are the result of the Knuth-Bendix procedure applied to a set of equations. The equations are valided by the algebra of functional programs. We use the implementation of the Knuth-Bendix procedure in the system REVE. If REVE is applied to a set of equations and if it does not fail, then it returns a convergent rewriting set of rules. With such a rewriting system, the task of transforming a program is reduced to rewrite it until we get its normal form. Thus we propose a set of valid equations and we discuss how convergent rewriting systems can be generated using REVE.

23 citations


Book ChapterDOI
01 Jan 1984
TL;DR: You have written a moderately large applicative Lisp program (3200 lines, 56 functions) that is thoroughly debugged and has been in use for several years, and it is decided to make that system available as part of a larger package for which Fortran has been chosen as the transportable implementation language.
Abstract: You have written a moderately large applicative Lisp program (3200 lines, 56 functions). It is thoroughly debugged and has been in use for several years. You have received numerous requests for the system of which the program is a part. You have decided to make that system available as part of a larger package for which Fortran has been chosen as the transportable implementation language. The program must run compiled in order for its use to be practical. What do you do?

9 citations


Book
01 Jan 1984
TL;DR: A Systematics of Software Engineering: Structure, Terminology, and Classification of techniques for Program Construction: The Project CIP.- Specification and Transformation: Automated Implementation
Abstract: I: Digest of the Discussions.- 0. Introduction: What Industry Needs - What Research Offers.- 1. Life Cycle Models and Programming Environments.- 1.1 Life Cycle.- 1.2 Programming Environments.- 2. Management & Organization.- 2.1 Quality and Productivity.- 2.1.1 What is "Quality"?.- 2.1.2 How Do We Measure Quality?.- 2.1.3 How Do We Measure Productivity?.- 2.2 Management of Software Development.- 2.2.1 Methods.- 2.2.2 The Role of Domain Knowledge.- 2.2.3 Programmers' Expertise.- 2.3 Maintenance and Version Management.- 3. Formal Methods In Program Development.- 3.1 The Role of Abstraction and (Mathematical) Notation.- 3.2 What Can Be Formally Specified?.- 3.2.1 Expression of Constraints.- 3.2.2 Performance Requirements.- 3.2.3 "Niceness" Properties.- 3.3 Programming as a Formal Activity.- 4. Software Specification.- 4.1 Specifications as a Contract.- 4.2 Real-World Modelling and Requirements Engineering.- 4.2.1 Open vs. Closed Systems.- 4.2.2 Requirements Engineering and Transformations.- 4.3 Equivalence of Specifications.- 4.3.1 Transitions Between Informal and Formal Specifications.- 4.3.2 Changes of Specifications.- 4.4 Methodology of Specification.- 4.4.1 Top-down vs. Bottom-up and Other Dichotomies.- 4.4.2 The Influence of Existing Environments.- 4.4.3 The Role of Design Decisions.- 4.4.4 Impact on Implementations.- 4.4.5 Incomplete Specification vs. Overspecification.- 4.5 Specification Tools and Languages.- 4.5.1 Adequacy of Specification Languages.- 4.5.2 A Need For Several Specification Languages.- 4.5.3 Partially Formalized Specifications.- 4.5.4 Exception Handling.- 4.5.5 The Impact of Semantics.- 5. Program Development by Transformations.- 5.1 Usage of Transformations.- 5.1.1 Understanding and Explaining Algorithms.- 5.1.2 Transformation and Documentation.- 5.1.3 Families of Programs.- 5.1.4 Transformations and Compilers.- 5.2 Language (Independence of Transformations.- 5.2.1 "Transformational" vs. "Active" Programming.- 5.3 Transformation Systems.- 5.3.1 Performance of Transformation Systems.- 5.3.2 Size of Rule Bases.- 5.4 Development Strategies.- 5.5 Managerial Problems of Transformational Programming.- 6. Acceptance of Formal Methods.- 6.1 Range of Application of Formal Methods.- 6.2 Impact on Quality and Productivity.- 6.2.1 Effect of Good and Bad Products.- 6.2.2 Expected Impact of Formal Methods.- 6.3 Social Aspects: Education.- 6.4 How Can Formal Methods Be Brought to Industry?.- 7. Outlook.- 8. Conclusion.- II: Position Statements and Papers.- Coherent Development Methods in an Industrial High-Level Language Environment.- A Systematics of Software Engineering: Structure, Terminology, and Classification of Techniques.- Assessment of Software Quality.- Measuring Software Technology (together with D. N. Card, V. E. Church, G. Page, F. E. McGarry).- Organizational Means to Increase Software Quality.- The Role of Configuration Management.- Understanding and Expressing Software Construction.- Structure-Oriented Programing.- Algebraic Methods for Program Construction: The Project CIP.- Specification and Transformation: Automated Implementation.- Algebraic Techniques for Program Specification.- Verification of Processes Using Program Transformation.- Exception Handling: Formal Specification and Systematic Program Construction (together with M. Bidoit, B. Biebow, C. Gresse, G. Guiho).- Programming with Continuations (together with Ch. T. Haynes, E. Kohlbecker).- Inferential Techniques for Program Development.- Lisp to Fortran - Program Transformation Applied.- Language Comparison by Source-to-Source Translation.- The CIP Transformation System.- Transformation-Based Software Development.- Supercompilers.- Software Development and Inferential Programming.- Program Transformation in the ALICE Project.- From Geological Knowledge to Computational Relationships: A Case Study of the Expertise of Programing (together with R. D. Duffey II).- List of Participants Glossary.

Book ChapterDOI
01 Jan 1984
TL;DR: The theoretical fundamentals of a “transformational calculus” are developed and it is demonstrated that this programming technique may be used to produce software for various kinds of hardware architectures.
Abstract: The principles and potentials of transformational program development are outlined by a few simple examples. It is demonstrated that this programming technique may be used to produce software for various kinds of hardware architectures. Based on observations made with these examples, the theoretical fundamentals of a “transformational calculus” are developed. The considerations aim at the clarification of notions such as “transformation rule”, “applicability condition”, or “axiomatic rule”. Some brief comments on transformation systems and rule bases round off the discussion.

Journal Article
TL;DR: In this article, a transformation algorithm that transforms equational programs into logic programs is proposed, which introduces the notions of data abstraction and computation strategies into logic programming languages, and it has been shown that the algorithm transforms any equational program into an equal or more powerful logic program.

Book ChapterDOI
01 Apr 1984
TL;DR: It is argued that the foremost means of achieving improvement is to significantly expand the role of the computer in the process, and advocate program transformation as a development methodology within which to introduce such computer support.
Abstract: The primary aim of our ISI research group1 is to improve the software development process. We contend that the foremost means of achieving improvement is to significantly expand the role of the computer in the process, and advocate program transformation as a development methodology within which to introduce such computer support. As evidenced by the other contributions in this volume, we are not alone in this belief.

Book ChapterDOI
01 Jan 1984
TL;DR: The types of transformation and transformation system being developed and how they relate to the overall ALICE project are introduced.
Abstract: The ALICE project being conducted in the Department of Computing at Imperial College is aimed at developing a complete programming environment based around the use of declarative languages. All levels of such an environment are being considered ranging from the use of declarative languages for specification purposes to the construction of a highly parallel graph reduction machine (ALICE, Applicative Language Idealised Computing Engine, herself) from specialised VLSI components, Darlington et al [1981], The heart of the program development system will be a meta-language transformation system and the long term goal is to make all program development formally based and completely machine checked. In this paper we briefly introduce the types of transformation and transformation system being developed and how they relate to the overall ALICE project.

Journal ArticleDOI
TL;DR: The scheduling algorithms have been synthesised using program transformation techniques to create three well-known scheduling algorithms starting from a common high level definition.

Akihiko Koga1
01 Jan 1984
TL;DR: In this paper, a theory for automatic program transformation with tupling technique is constructed and a problem to find a tuple for transformation of a recursive program written in the language is formulated.
Abstract: In this paper, we construct a theory for an automatic program transformation with tupling technique. We introduce a purely applicative programming language and formalize a problem to find a tuple for transformation of a recursive program written in the language. We discuss the transformation scheme with the tuple given as the solution to the problem and show that the execution efficiency will be improved by the new scheme. Under a certain constraint, we describe the method to find a tuple for a given program.

Book ChapterDOI
01 Jan 1984
TL;DR: If the authors look at the rapid progress in computer applications with all these low-priced and powerful micro computers and signal processors, there can see a clear trend towards distributed systems, where many autonomous (often small) computers work together somehow to perform a given processing task.
Abstract: If we look at the rapid progress in computer applications with all these low-priced and powerful micro computers and signal processors, we can see a clear trend towards distributed systems, where many autonomous (often small) computers work together somehow to perform a given processing task, for example in plant control, communication systems, radar tracking etc. Logically, such systems are by very nature composed of a set of parallel interacting processes and the decomposition of the system software into processes, the specification of processes and systems and their verification are important topics.

Book ChapterDOI
13 Dec 1984
TL;DR: This paper introduces two operators to extend FP so that it supports committed and uncommitted nondeterminism, and specifies the semantics of these operators under both strict and lenient evaluation strategies.
Abstract: Linguistic support of parallelism and program transformation systems both implicitly involve nondeterminism. As a result, referentially transparent languages are insufficiently expressive for these applications unless they are augmented with nondeterministic operators. This paper introduces two operators to extend FP so that it supports committed and uncommitted nondeterminism, and specifies the semantics of these operators under both strict and lenient evaluation strategies. Equational models for the four resulting systems are given individually, and two of these are merged into a combined model which supports both forms of nondeterminism under lenient evaluation. Finally, the applicability to program transformation problems is discussed.