Table Of ContentFoundations of Programming
Jacques Arsac
Ecole Normale Supérieure
Paris, France
Translated by Fraser Duncan
1985
ACADEMIC PRESS
(Harcourt Brace Jovanovich, Publishers)
London Orlando San Diego New York
Toronto Montreal Sydney Tokyo
,
Copyright © 1985 by Academic Press Inc. (London) Ltd.
ALL RIGHTS RESERVED.
NO PART OF THIS PUBLICATION MAY BE REPRODUCED OR
TRANSMITTED IN ANY FORM OR BY ANY MEANS, ELECTRONIC
OR MECHANICAL, INCLUDING PHOTOCOPY, RECORDING, OR
ANY INFORMATION STORAGE AND RETRIEVAL SYSTEM, WITHOUT
PERMISSION IN WRITING FROM THE PUBLISHER.
ACADEMIC PRESS INC. (LONDON) LTD.
24-28 Oval Road
LONDON NW1 7DX
United States Edition published by
ACADEMIC PRESS, INC.
Orlando, Florida 32887
British Library Cataloguing in Publication Data
Arsac, Jacques
Foundations of programming.-(APIC studies
in data processing)
1. Electronic digital computers-Programming
I. Title II. Les bases de la programmation.
English III. Series
000.64’2 QA76.6
Library of Congress Cataloging in Publication Data
Arsac, Jacques.
Foundations of programming.
(A.P.I.C. studies in data processing)
Translation of: Les bases de la programmation.
Includes index.
1. Electronic digital computers-Programming.
I. Title. II. Series.
QA76.6.A75813 1985 001.64’2 84-14436
ISBN 0-12-064460-6 (alk. paper)
PRINTED IN THE UNITED STATES OF AMERICA
83 86 87 88 9 8 7 6 3 4 3 2 1
FOUNDATIONS OF PROGRAMMING. Translated from the original French edition
entitled LES BASES DE LA PROGRAMMATION, published by Dunod, Paris,
©BORDAS 1983.
Contents
Preface xiii
List of Programs Discussed in the Book xxiii
Notations xxvii
Translator's Introduction xxxi
Chapter 1 Iterative Programming
1.1 An Incorrect Program 1
1.2 The Assignment Instruction 2
1.3 Assertions and Instructions 4
1.3.1 Assignment 4
1.3.2 Selection 6
1.3.3 Branching Instruction 6
1.3.4 The WHILE Instruction 7
1.3.5 The Loop 8
1.4 The Interpretation of a Program 9
1.5 Recurrent Construction of Iterative Programs 11
1.6 Partial Correctness 13
1.7 Strengthening the Recurrence Hypothesis 16
1.8 The Effect of the Choice of the Recurrence Hypothesis 17
1.9 “Heap Sort” 22
Exercises 24
Chapter 2 Recursive Programming
2.1 Recursivity Recalled 27
2.2 The Construction of Recursive Definitions 28
2.2.1 The Factorial Function 28
2.2.2 The Exponential Function 29
2.2.3 Reverse of a String 30
2.2.4 Expression of an Integer in Base b 31
v/7
viii Contents
2.2.5 Fibonacci Numbers 31
2.2.6 The Product of Two Integers 32
2.3 Computation of a Recursively Defined Function 32
2.3.1 Monadic Definition 32
2.3.2 Dyadic Definition 33
2.4 The Nature of a Recursive Definition 34
2.5 Properties of a Recursively Defined Function 35
2.5.1 A Simple Example 35
2.5.2 Computational Precision 36
2.5.3 Complexity 38
2.6 The Choice of a Recursive Form 39
2.6.1 The Problem of the Termination 39
2.6.2 Complexity 40
2.7 Transformation of Recursive Definitions 41
2.8 The Proper Use of Recursion 43
2.8.1 Function 91 44
2.8.2 Call by Need 46
2.9 Functional Programming 46
Exercises 49
Chapter 3 Recurrent Programming
3.1 Direct Algorithms 51
3.2 Construction of Algorithms 53
3.3 The Precedence Relation 55
3.4 Transformation into a Program 56
3.5 “Lazy” Evaluation 58
3.6 Recurrent Algorithm 60
3.6.1 An Example 60
3.6.2 The General Form 63
3.6.3 Deep Recurrences 64
3.7 Execution of a Recurrent Algorithm 65
3.8 Transformation into an Iterative Program 67
3.8.1 The General Case 67
3.8.2 An Example 68
3.8.3 The Reduction of the Number of Variables 69
3.9 The Use of Recurrence in the Writing of a Program 70
3.10 Giving a Meaning to a Program 76
Exercises 78
Chapter 4 From Recursion to Recurrence
4.1 The Recurrent Form Associated with a Recursive Scheme 81
4.1.1 The Scheme to Be Considered 81
4.1.2 The Associated Recurrent Form 82
4.1.3 The Iterative Program 83
4.1.4 Example 84
4.2 The Stack 85
4.3 Programs without Stacks 90
4.4 A Program with Only One Loop 92
4.5 Interpretation of the Recursive Scheme 93
Contents ¡x
4.6 Other Simplifications 93
4.6.1 Associativity 93
4.6.2 Permutability 95
4.7 A Degenerate Form of the Recursive Scheme 96
4.7.1 The Degenerate Form 96
4.7.2 When a Is Constant 97
4.7.3 When b Is the Identity Operation 98
4.8 Special Cases 99
4.8.1 A Dyadic Scheme 100
4.8.2 Non-Associativity 101
Exercises 104
Chapter 5 From Recursion to Iteration
5.1 An Example of Direct Transformation 105
5.1.1 Invariance in a Loop 105
5.1.2 Construction of the Iterative Program 106
5.2 Extension 107
5.2.1 Generalisation 107
5.2.2 The Test for Exit 107
5.2.3 Progression 108
5.2.4 Initialisation 108
5.3 Examples 108
5.3.1 The Reverse of a String 108
5.3.2 Expression in Base b 110
5.4 Program Synthesis 113
5.5 A Complex Recursion 116
5.6 Happy Numbers 118
5.7 The Hamming Sequence 125
Exercises 127
Chapter 6 Regular Actions
6.1 Intuitive Presentation of the Idea of an Action 129
6.2 Systems of Regular Actions 131
6.3 Interpretation of a System of Regular Actions 133
6.3.1 Interpretation as Label 133
6.3.2 Decomposition of a Program into Actions 135
6.3.3 Actions as Procedures without Parameters 136
6.4 The Graph of a System of Actions 137
6.5 Substitution 138
6.5.1 The Copy Rule 138
6.5.2 The Inverse Transformation 139
6.6 Transformation from Terminal Recursion to Iteration 140
6.6.1 A Particular Case 140
6.6.2 The General Case 142
6.7 The Structure of a System of Regular Actions 144
6.7.1 The General Case 144
6.7.2 Example: Finding a Substring of a String 145
6.8 Identification 150
Exercises 156
X Contents
Chapter 7 Program Transformations
7.1 Definitions and Notations 159
7.2 Simple Absorption and Simple Expansion 161
7.3 Double Iteration and Loop Absorption 163
7.4 Proper Inversion 167
7.5 Repetition 170
7.6 Local Semantic Transformations 170
7.6.1 Assignments 170
7.6.2 Selection Instructions 173
7.7 The Development of More Complex Transformations 175
7.7.1 WHILE Loops 175
7.7.2 A Transformation due to Suzan Gerhardt 177
7.7.3 Remark on the AND Operator 181
7.8 Application to a Problem of Termination 182
7.9 Change of Strategy 184
Exercises 193
Chapter 8 The Transformation of Sub-Programs from Recursive to Iterative
8.1 Generalised Actions 195
8.1.1 Intuitive Presentation 195
8.1.2 Definition 196
8.1.3 Interpretation 197
8.2 Régularisation 200
8.2.1 The General Case 200
8.2.2 The Use of Predicates 200
8.2.3 The Property of Invariance 200
8.2.4 The Activation Counter 201
8.2.5 The «-ary Counter 202
8.3 Example 203
8.4 The Schemes of Irlik 205
8.5 Formal Parameters and Global Variables 210
8.5.1 Local Variables 210
8.5.2 Formal Parameters 210
8.6 A Known Recursive Scheme 211
Exercises 217
Chapter 9 Analytical Programming
9.1 Analytical Programming 221
9.2 An Old Friend 223
9.2.1 Creation of the Recursive Sub-Program 223
9.2.2 Régularisation 225
9.2.3 First Realisation of the Stack 226
9.2.4 Second Implementation of the Stack 226
9.2.5 Variations 229
9.3 A Problem of Permutations 230
9.3.1 The Recursive Procedure 230
9.3.2 First Iterative Form 232
9.3.3 Second Iterative Form 235
Contents XI
9.4 The Towers of Hanoi 242
9.4.1 Recursive Procedure 242
9.4.2 The First Form 243
9.5 A General Result 250
9.5.1 The Stack 251
9.5.2 Recomputing the Arguments 251
9.6 The Towers of Hanoi—Second Form 252
9.7 Remarks on the Two Solutions of the Towers of Hanoi 255
Exercises 258
Bibliography 261
Index 263
Preface
Informatics (or computer science or information processing) is too young
a science to have become the subject of many historical studies or philosoph
ical analyses. To me, however, its history seems quite exceptional. It is
normal for a science to be bom out of the observation of nature. When a
sufficient number of duly observed facts have been recorded, the outline of a
model can be sketched, and this in its turn allows the prediction of new
patterns of behaviour which are then subject to experimental verification.
Technology comes later, the model being confirmed, to a certain degree of
precision, by experiment, possible applications are conceived and come to
birth. The discovery of electricity is typical of such an evolution. The electric
motor and incandescent lamp did not appear until well after the develop
ment of the first theoretical models of electrostatics and of electromag
netism.
Much more rarely, technology has come before science. The steam engine
was built long before the science of thermodynamics enabled its output to be
calculated. In informatics we have an extreme example of this class.
The computer was engendered by the necessity for computation experi
enced during the Second World War. It was not the brainchild of some
brilliant dabbler, but the product of a technology founded on a well-estab
lished science, electronics, and supported by a no less well-founded mathe
matical model, Boolean algebra. There is nothing unusual about this. But it
was followed by wild speculation on the part of industrialists who believed
that such monsters might have applications in everyday life and who engi
neered these machines for the market. This theme is to be found developed
in a book by Rene Moreau [MOR].
From then on we have witnessed an incredible development of the means
of computation, requiring the support of numerous technicians—
operators, programmers, . . . . This in turn led to the need to establish
xiii
XIV Preface
numerous new educational programmes, which began to be satisfied in
about 1960. But the universities which took responsibility for this realised
very quickly that they were not dealing simply with an application of the
science of electronics aided by a very old branch of mathematics, numerical
analysis. We were face to face with something fundamental, with a very old
activity of the human mind, but one whose significance we were not able to
grasp because there was no technical means of allowing it to take full flight.
In the same way as astronomy began with the telescopes of Galileo, but
was unable fully to develop until better means of observation became tech
nically possible, so informatics, the science of information processing, will
not be able to show itself clearly until the proper means are found to exercise
it [AR]. It would not be right to allow the reader to believe that what is said
here is an absolute and proven truth, recognised by universal consensus.
There are very many who believe in the existence of a science of informatics,
as is shown, for example, by academic instances in every country: in all the
great universities there are departments of “computer science”; the French
Academy defines ‘Tinformatique” as a science, and the French Academy of
Sciences has two headings “informatique” in its proceedings. But there are
just as many again who would restrict its scope, and deny it all claim to a
character of its own. In this sense, the position of the Academy of Sciences is
ambiguous: there is not one unique classification for informatics, as would
be the case for a well-established discipline, but rather two, one for theoreti
cal information science, a branch of mathematics concerned with the prob
lems posed by information processing, and the other at the level of “science
for the engineer.” Many professionals see in informatics nothing more than a
technique, sufficiently complicated to require a specific training, but of
narrow breadth. Bruno Lussato has become a champion of this idea, assert
ing that informatics can be learnt in three weeks [LUS].
I believe this to be a consequence of the very peculiar development of the
discipline. As had been said, the technology came first, founded as always on
a science, solid-state physics, but remote from its proper concern, the treat
ment of information. Since then we have spent much energy trying to master
techniques for which, the need not having been foreseen, we were never
adequately prepared. There has hardly been time to think. The history of
programming, within the history of informatics, is in this respect very re
vealing.
In the beginning there were the first computers, for which we had to write
programs in the only language which they could interpret, their own, the
machine language. This was extremely tedious, with a very high risk of error,
and so machine languages were very soon replaced by assembly languages,
maintaining in their forms the structures of the machine languages, and
offering no more distinct operations than the machines could cope with by
Preface xv
hardware. It very soon became clear that the fragmentation of thought im
posed by the very restricted set of these primitive operations was a handicap,
and the first developed language, Fortran, appeared about 1955. This was a
decisive step. The choice of structures for this language and the manner of
writing of its compiler were to leave a deep mark on the history of program
ming.
In fact, the language was conceived fundamentally as an abbreviation of
assembly languages, and maintained two of their principal characteristics:
—the assignment instruction, or modification of the contents of a unit
storage in the computer,
—the idea of the instruction sequence, broken by the GO TO instruction,
conditional or unconditional.
Very many languages developed rapidly from this common origin. The
principal languages still in use today, Algol 60, Cobol, Basic, . . . , ap
peared over a period of at most five years. Lisp is of the same period, but it
deserves special mention; it was not constructed on the same universal
primitives, having no concept of assignment, no loop, no instruction se
quence, but it was based on the recursive definition of functions.
This language explosion, this modem Babel, has caused much dissipation
of energy in the writing of compilers, and in heated argument over a false
problem—that of the comparative merits of the different languages. Un
happily, this game has not yet stopped. Take any assembly, anywhere, of
sleepy computer scientists, and turn the discussion on to a programming
language. They will all wake up and throw themselves into the debate. If you
think about this, it is worrying, indeed deeply disturbing. All these languages
in fact have been built upon the same universal primitives, as has already
been pointed out; and the principal problems flow from this fact. Two of the
chief difficulties in programming practice arise from the assignment instruc
tion and the branch instruction. Why such rivalry between such close
cousins?
As long as we work ourselves into such excitement over these languages,
we are apt to forget that they are only a means of expression and that the
essential thing is to have something to say, not how to say it.
Ce que l’on conçoit bien s’énonce clairement et les mots pour le dire
arrivent aisément [BOI].
[“That which is well conceived can be expressed clearly, and the words for
saying it will come easily”—Nicolas Boileau, 1636-1711.]
The means for the construction of programs were rudimentary, indeed
non-existent. The literature of the period abounds in works of the type
“Programming in Basic” or “Programming in Fortran IV.” Teaching was no
