Programming Languages: Principles and Paradigms 9781848829138, 9781848829145, 1848829132

Table of contents :
Foreword......Page 7
Introduction......Page 8
Acknowledgements......Page 10
Contents......Page 11
The Concepts of Abstract Machine and of Interpreter......Page 18
The Interpreter......Page 19
An Example of an Abstract Machine: The Hardware Machine......Page 22
The language of the physical machine......Page 23
Interpreter......Page 24
Implementation of an Abstract Machine......Page 26
Implementation in Hardware......Page 27
Emulation Using Firmware......Page 28
Notation......Page 30
Purely compiled implementation......Page 31
Comparing the Two Techniques......Page 33
Implementation: The Real Case and The Intermediate Machine......Page 34
Hierarchies of Abstract Machines......Page 38
Exercises......Page 41
References......Page 42
Levels of Description......Page 43
Grammar and Syntax......Page 44
Context-Free Grammars......Page 46
BNF......Page 47
Derivations and languages......Page 48
Derivation Trees......Page 49
Ambiguity......Page 52
Contextual Syntactic Constraints......Page 55
Lexical analysis......Page 57
Syntactic analysis......Page 59
Generation of intermediate forms......Page 60
Semantics......Page 61
State......Page 63
Transitions......Page 64
Command semantics......Page 65
Computations......Page 66
Implementation......Page 68
Exercises......Page 69
References......Page 70
The Halting Problem......Page 72
Expressiveness of Programming Languages......Page 74
Formalisms for Computability......Page 75
There are More Functions than Algorithms......Page 76
Chapter Summary......Page 78
Exercises......Page 79
References......Page 80
Names and Denotable Objects......Page 81
Denotable Objects......Page 83
Environments and Blocks......Page 84
Blocks......Page 85
Types of Environment......Page 86
Operations on Environments......Page 89
Scope Rules......Page 91
Static Scope......Page 92
Dynamic Scope......Page 94
Some Scope Problems......Page 96
Chapter Summary......Page 99
Bibliographical Notes......Page 100
Exercises......Page 101
References......Page 104
Techniques for Memory Management......Page 105
Dynamic Memory Management Using Stacks......Page 107
Activation Records for In-line Blocks......Page 110
Activation Records for Procedures......Page 111
Stack Management......Page 113
Fixed-Length Blocks......Page 115
Variable-Length Blocks......Page 117
Single free list......Page 118
Static Scope: The Static Chain......Page 119
Static Scope: The Display......Page 123
Dynamic Scope: Association Lists and CRT......Page 125
Central Referencing environment Table (CRT)......Page 128
Chapter Summary......Page 129
Exercises......Page 130
References......Page 132
Expressions......Page 133
Infix Notation......Page 134
Prefix Notation......Page 135
Postfix Notation......Page 136
Infix Notation: Precedence and Associativity......Page 137
Prefix Notation......Page 138
Evaluation of Expressions......Page 139
Subexpression Evaluation Order......Page 141
The Concept of Command......Page 143
The Variable......Page 144
Assignment......Page 145
Composite Command......Page 150
Goto......Page 151
Other sequence control commands......Page 153
If......Page 154
Case......Page 155
Unbounded iteration......Page 158
Bounded iteration......Page 159
Expressiveness of bounded iteration......Page 161
The for in C......Page 162
For-each......Page 163
Structured Programming......Page 164
Recursion......Page 166
Tail Recursion......Page 169
Recursion or Iteration?......Page 173
Chapter Summary......Page 174
Exercises......Page 175
References......Page 177
Control Abstraction......Page 178
Parameters......Page 179
Functional Abstraction......Page 180
Call by value......Page 182
Call by reference......Page 183
Call by constant......Page 184
Call by result......Page 185
Call by value-result......Page 186
Call by name......Page 187
Higher-Order Functions......Page 191
Functions as Parameters......Page 192
Implementation of deep binding......Page 193
Binding policy and static scope......Page 194
What defines the environment......Page 196
Functions as Results......Page 197
Exceptions......Page 199
Pragmatics......Page 202
Implementing Exceptions......Page 203
Chapter Summary......Page 204
Bibliographical Notes......Page 206
Exercises......Page 207
References......Page 209
Data Types......Page 210
Types as Support for Conceptual Organisation......Page 211
Types for Correctness......Page 212
Types and Implementation......Page 213
Type Systems......Page 214
Static and Dynamic Checking......Page 215
Scalar Types......Page 216
Characters......Page 217
Fixed Point......Page 218
Complex......Page 219
Enumerations......Page 220
Intervals......Page 221
Records......Page 222
Variant Records and Unions......Page 224
Unions in C......Page 225
Variants and Security......Page 226
Arrays......Page 229
Checking......Page 230
Storage and Calculation of Indices......Page 231
Form of an Array: Where an Array is Allocated......Page 232
Dope Vectors......Page 233
Sets......Page 234
Pointers......Page 235
Pointer Arithmetic......Page 237
Deallocation......Page 238
Recursive Types......Page 240
Functions......Page 242
Equivalence......Page 243
Equivalence by Name......Page 244
Structural Equivalence......Page 245
Compatibility and Conversion......Page 247
Coercions......Page 248
Polymorphism......Page 250
Overloading......Page 251
Universal Parametric Polymorphism......Page 252
Implicit Polymorphism......Page 253
Subtype Universal Polymorphism......Page 254
Remarks on the Implementation......Page 255
Type Checking and Inference......Page 257
Safety: An Evaluation......Page 259
Avoiding Dangling References......Page 260
Tombstone......Page 261
Locks and Keys......Page 262
Garbage Collection......Page 263
Reference Counting......Page 264
Mark and Sweep......Page 266
Interlude: Pointer Reversal......Page 267
Copy......Page 268
Chapter Summary......Page 271
Exercises......Page 272
References......Page 275
Abstract Data Types......Page 277
Information Hiding......Page 280
Modules......Page 283
Chapter Summary......Page 284
Exercises......Page 287
References......Page 288
The Limits of Abstract Data Types......Page 289
Fundamental Concepts......Page 293
Objects......Page 294
Classes......Page 295
Objects in the heap and on the stack......Page 298
Subtypes......Page 299
Redefinition of a method......Page 300
Abstract classes......Page 301
The subtype relation......Page 302
Constructors......Page 303
Inheritance and visibility......Page 304
Single and multiple inheritance......Page 305
Dynamic Method Lookup......Page 309
Objects......Page 313
Classes and inheritance......Page 314
Single Inheritance......Page 315
Downcasting......Page 316
The Problem of Fragile Base Class......Page 317
Dynamic Method Dispatch in the JVM......Page 318
Vtable Structure......Page 321
Replicated multiple inheritance......Page 323
Shared multiple inheritance......Page 324
Polymorphism and Generics......Page 326
Subtype Polymorphism......Page 327
Generics in Java......Page 329
Implementation of Generics in Java......Page 333
Generics, Arrays and Subtype Hierarchy......Page 335
Supertypes and Views......Page 337
Bibliographical Notes......Page 340
Exercises......Page 341
References......Page 343
Computations without State......Page 345
Expressions and Functions......Page 347
Computation as Reduction......Page 349
The Fundamental Ingredients......Page 350
Evaluation......Page 351
Capture-Free Substitution......Page 352
Evaluation Strategies......Page 353
Evaluation by name......Page 354
Comparison of the Strategies......Page 355
Local Environment......Page 357
Types......Page 358
Pattern Matching......Page 359
Infinite Objects......Page 361
Imperative Aspects......Page 362
Implementation: The SECD Machine......Page 365
The Functional Paradigm: An Assessment......Page 367
Program Correctness......Page 368
Program schemata......Page 369
Fundamentals: The lambda-calculus......Page 370
Substitution......Page 371
Normal forms......Page 372
Fixpoint operators......Page 373
Chapter Summary......Page 376
Exercises......Page 377
References......Page 378
Deduction as Computation......Page 380
Terminological Note......Page 381
An Example......Page 382
Alphabet......Page 385
Terms......Page 386
Logic Programs......Page 387
The Logic Variable......Page 388
Substitution......Page 390
Most General Unifier......Page 392
A Unification Algorithm......Page 394
Martelli and Montanari's unification algorithm......Page 395
The Herbrand Universe......Page 398
Declarative and Procedural Interpretation......Page 399
Procedure Calls......Page 400
Evaluation of a non-atomic goal......Page 401
Heads with arbitrary terms......Page 402
Control: Non-determinism......Page 403
Backtracking in Prolog......Page 404
Some Examples......Page 406
Prolog......Page 409
Arithmetic......Page 410
Cut......Page 411
Negation......Page 412
Logic Programming and Databases......Page 414
Logic Programming with Constraints......Page 415
Advantages and Disadvantages of the Logic Paradigm......Page 417
Chapter Summary......Page 419
Exercises......Page 420
References......Page 422
Beginnings......Page 423
Factors in the Development of Languages......Page 425
FORTRAN......Page 427
Algol......Page 428
LISP......Page 429
Simula......Page 430
C......Page 431
Pascal......Page 432
Declarative languages......Page 433
PROLOG......Page 434
The 1980s......Page 435
C++......Page 436
CLP......Page 437
Java......Page 438
Chapter Summary......Page 440
References......Page 441
Index......Page 443

Citation preview

Undergraduate Topics in Computer Science

Undergraduate Topics in Computer Science (UTiCS) delivers high-quality instructional content for undergraduates studying in all areas of computing and information science. From core foundational and theoretical material to final-year topics and applications, UTiCS books take fresh, concise, and modern approach and are ideal for self-study or for a one- or two-semester course. The texts are all authored by established experts in their fields, reviewed by an international advisory board, and contain numerous examples and problems. Many include fully worked solutions.

For further volumes: http://www.springer.com/series/7592

Maurizio Gabbrielli and Simone Martini

Programming Languages: Principles and Paradigms

Prof. Dr. Maurizio Gabbrielli Università di Bologna Bologna Italy

Prof. Dr. Simone Martini Università di Bologna Bologna Italy

Series editor Ian Mackie Advisory board Samson Abramsky, University of Oxford, UK Chris Hankin, Imperial College London, UK Dexter Kozen, Cornell University, USA Andrew Pitts, University of Cambridge, UK Hanne Riis Nielson, Technical University of Denmark, Denmark Steven Skiena, Stony Brook University, USA Iain Stewart, University of Durham, UK David Zhang, The Hong Kong Polytechnic University, Hong Kong

ISSN 1863-7310 ISBN 978-1-84882-913-8 e-ISBN 978-1-84882-914-5 DOI 10.1007/978-1-84882-914-5 Springer London Dordrecht Heidelberg New York British Library Cataloguing in Publication Data A catalogue record for this book is available from the British Library Library of Congress Control Number: 2010922995 Translated from the original Italian edition: “Linguaggi di programmazione: principi e paradigmi”, published in 2006 by McGraw-Hill Companies, Publishing Group Italia. © Springer-Verlag London Limited 2010 Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms of licenses issued by the Copyright Licensing Agency. Enquiries concerning reproduction outside those terms should be sent to the publishers. The use of registered names, trademarks, etc., in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant laws and regulations and therefore free for general use. The publisher makes no representation, express or implied, with regard to the accuracy of the information contained in this book and cannot accept any legal responsibility or liability for any errors or omissions that may be made. Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com)

To Francesca and Antonella, who will never want to read this book but who contributed to it being written.

To Costanza, Maria and Teresa, who will read it perhaps, but who have done everything to stop it being written.

Foreword

With great pleasure, I accepted the invitation extended to me to write these few lines of Foreword. I accepted for at least two reasons. The first is that the request came to me from two colleagues for whom I have always had the greatest regard, starting from the time when I first knew and appreciated them as students and as young researchers. The second reason is that the text by Gabbrielli and Martini is very near to the book that I would have liked to have written but, for various reasons, never have. In particular, the approach adopted in this book is the one which I myself have followed when organising the various courses on programming languages I have taught for almost thirty years at different levels under various titles. The approach, summarised in 2 words, is that of introducing the general concepts (either using linguistic mechanisms or the implementation structures corresponding to them) in a manner that is independent of any specific language; once this is done, “real languages” are introduced. This is the only approach that allows one to reveal similarities between apparently quite different languages (and also between paradigms). At the same time, it makes the task of learning different languages easier. In my experience as a lecturer, ex-students recall the principles learned in the course even after many years; they still appreciate the approach which allowed them to adapt to technological developments without too much difficulty. The book by Gabbrielli and Martini has, as central reference point, an undergraduate course in Computer Science. For this reason, it does not have complex prerequisites and tackles the subject by finding a perfect balance between rigour and simplicity. Particularly appreciated and successful is the force with which they illuminate the connections with other important “areas of theory” (such as formal languages, computability, semantics) which the book rightly includes (a further justification for their inclusion being that these topics are no longer taught in many degree courses). Giorgio Levi, Pisa.

vii

Introduction

Facilius per partes in cognitionem totius adducimur (Seneca, Epist. 89,1)

Learning a programming language, for most students in computing, is akin to a rite of passage. It is an important transition, soon recognised as insufficient. Among the tools of the trade, there are many languages, so an important skill for the good computer professional is to know how to move from one language to another (and how to learn new ones) with naturalness and speed. This competence is not obtained by learning many different languages from scratch. Programming languages, like natural languages, have their similarities, analogies and they inherit characteristics from each other. If it is impossible to learn tens of languages well, it is possible completely to understand the mechanisms that inspire and guide the design and implementation of hundreds of different languages. This knowledge of the “parts” facilitates the understanding of the “whole” of a new language and therefore underpins a fundamental methodological competence in the life of the computing professional, at least as far as it allows them to anticipate innovations and to outlive technologies that grow obsolete. It is for these reasons that a course on the general aspects of programming languages is, throughout the world, a key step at advanced level for a computing professional (at university or in a profession). The fundamental competences which a computing professional must possess about programming languages are of at least four types: • Some aspects that are properly considered linguistic. • Knowledge of how language constructs can be implemented and the relative cost of these implementations. • Knowledge of those architectural aspects influencing implementation. • Compilation techniques. It is rare that a single course deals with all four of these aspects. In particular, description of architectural aspects and compilation techniques are both topics that are sufficiently complex and elaborate to merit independent courses. The remaining 2 aspects are primarily the content of a general course on programming languages and comprise the principle subject of this book. ix

x

Introduction

The literature is rich in texts dealing with these subjects. Generations of students have used them in their learning. All these texts, though, have in mind an advanced reader who already understands many different programming languages, who already has a more than superficial competence with fundamental mechanisms and who is not afraid when confronted by a fragment of code written in an unknown language (because they are able understand it by analogy using the differences between it and what they already know). These are texts, then, that we can say are on “comparative languages”. These are long, deep and stimulating, but they are too long and deep (read: difficult) for the student who begins their career with a single programming language (or at most 2) and who still has to learn the basic concepts in detail. This text aims to fill this gap. Experts will see that the content in large measure reflects classical themes. But these very themes are treated in an elementary fashion, assuming only the indispensable minimum of prerequisites. The book also avoids being a catalogue of the differences between different existing programming languages. The ideal (or reference) reader is one who knows one language (well) (for example, Pascal, C, C++ or Java). It is better if they have had some exposure to another language or paradigm. References to languages that are now obsolete have also been avoided and code examples are rarely written in a specific programming language. The text freely uses a sort of pseudo-language (whose concrete syntax was inspired by C and Java) and seeks, in this way, to describe the most relevant aspects of different languages. Every so often, the boxes at the top of pages contain development of material or a note on a basic concept or something specific about common languages (C, C++, Java; ML and L ISP for functional languages; P ROLOG for logic-programming languages). The material in boxes can almost always be omitted on a first reading. Every chapter contains a short sequence of exercises which should be understood as a way of demonstrating an understanding of the material. There are no truly difficult exercises or any that require more than 10 minutes for their solution. Chapter 3 (Foundations) deals with themes that are not usually encountered in a book on programming languages. It is, however, natural, while discussing static semantics and comparing languages, to ask what are the limits to syntactic analysis of programs and whether what can be done in one language can also be done in another. Rather than send the reader to another text, given the cultural and pragmatic relevance of these questions, we decided to answer these questions directly. In an informal but rigorous manner, in the space of a few pages, we present the undecidability of the halting problem. We also show that all general purpose programming languages express the same class of functions. This helps students who do not always have complete courses on foundations understand the principal results on the limitations on computations. As well as principles, the text also introduces the three principal programming paradigms: object oriented (a theme that is already obligatory in computing), functional and logic programming. The need to write an introductory text is the reason for the exclusion of important themes, such as concurrency and scripting languages, whose mastery represent important skills.

Introduction

xi

Use of the text The text is first of all a university textbook, even if there is an almost total absence of mathematical and formal prerequisites (this lack makes the book suitable for personal study by the professional who wishes to deepen their knowledge of the mechanisms that lie behind the languages they use). The choice of themes and the presentation style were largely influenced by the experience of teaching the content as part of the degree course in Computer Science in the Faculty of Mathematical, Physical and Natural Sciences at the University of Bologna. In our experience, a course on programming languages for 6 credits in the second year of a 3-year degree course can cover most of the fundamental aspects covered in the first ten chapters (say 4/5 of them) and, perhaps, including a brief outline of one of the remaining paradigms. With increase in student maturity, the quantity of material that can be presented will clearly increase. In a master’s degree course, the material could also be completed by a treatment of compilation. Acknowledgements Our thanks to Giorgio Levi goes beyond the fact that he had the grace to write the Foreword. Both of us owe to him our first understanding of the mechanisms that underpin programming languages. His teaching appears in this book in a way that is anything but marginal. Ugo Dal Lago drew the figures using METAPOST, Cinzia Di Giusto, Wilmer Ricciotti, Francesco Spegni and Paolo Tacchella read and commented attentively on the drafts of some chapters. The following people pointed out misprints and errors: Irene Borra, Ferdinanda Camporesi, Marco Comini, Michele Filannino, Matteo Friscini, Stefano Gardenghi, Guido Guizzunti, Giacomo Magisano, Flavio Marchi, Fabrizio Massei, Jacopo Mauro, Maurizio Molle, Mirko Orlandelli, Marco Pedicini, Andrea Rappini, Andrea Regoli, Fabiano Ridolfi, Giovanni Rosignoli, Giampiero Travaglini, Fabrizio Giuseppe Ventola. We gladly acknowledge the support of the Dipartimento di Scienze dell’Informazione of the Università di Bologna towards the English translation. Maurizio Gabbrielli Bologna Simone Martini Bologna

Contents

1

2

Abstract Machines . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 The Concepts of Abstract Machine and of Interpreter . . . . . 1.1.1 The Interpreter . . . . . . . . . . . . . . . . . . . . . 1.1.2 An Example of an Abstract Machine: The Hardware Machine . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Implementation of a Language . . . . . . . . . . . . . . . . 1.2.1 Implementation of an Abstract Machine . . . . . . . 1.2.2 Implementation: The Ideal Case . . . . . . . . . . . . 1.2.3 Implementation: The Real Case and The Intermediate Machine . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Hierarchies of Abstract Machines . . . . . . . . . . . . . . . 1.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . 1.5 Bibliographic Notes . . . . . . . . . . . . . . . . . . . . . . 1.6 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

5 9 9 13

. . . . . .

. . . . . .

. . . . . .

17 21 24 24 24 25

How to Describe a Programming Language 2.1 Levels of Description . . . . . . . . . . 2.2 Grammar and Syntax . . . . . . . . . . 2.2.1 Context-Free Grammars . . . . . 2.3 Contextual Syntactic Constraints . . . . 2.4 Compilers . . . . . . . . . . . . . . . . 2.5 Semantics . . . . . . . . . . . . . . . . 2.6 Pragmatics . . . . . . . . . . . . . . . . 2.7 Implementation . . . . . . . . . . . . . 2.8 Chapter Summary . . . . . . . . . . . . 2.9 Bibliographical Notes . . . . . . . . . . 2.10 Exercises . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

27 27 28 30 39 41 45 52 52 53 53 53 54

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . .

1 1 2

xiii

xiv

Contents

3

Foundations . . . . . . . . . . . . . . . . . . . . 3.1 The Halting Problem . . . . . . . . . . . . . 3.2 Expressiveness of Programming Languages . 3.3 Formalisms for Computability . . . . . . . . 3.4 There are More Functions than Algorithms . 3.5 Chapter Summary . . . . . . . . . . . . . . 3.6 Bibliographical Notes . . . . . . . . . . . . 3.7 Exercises . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

57 57 59 60 61 63 64 64 65

4

Names and The Environment . . . . . . 4.1 Names and Denotable Objects . . . . 4.1.1 Denotable Objects . . . . . . 4.2 Environments and Blocks . . . . . . 4.2.1 Blocks . . . . . . . . . . . . 4.2.2 Types of Environment . . . . 4.2.3 Operations on Environments 4.3 Scope Rules . . . . . . . . . . . . . 4.3.1 Static Scope . . . . . . . . . 4.3.2 Dynamic Scope . . . . . . . 4.3.3 Some Scope Problems . . . . 4.4 Chapter Summary . . . . . . . . . . 4.5 Bibliographical Notes . . . . . . . . 4.6 Exercises . . . . . . . . . . . . . . . References . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

67 67 69 70 71 72 75 77 78 80 82 85 86 87 90

5

Memory Management . . . . . . . . . . . . . . . . . . 5.1 Techniques for Memory Management . . . . . . . . 5.2 Static Memory Management . . . . . . . . . . . . . 5.3 Dynamic Memory Management Using Stacks . . . 5.3.1 Activation Records for In-line Blocks . . . . 5.3.2 Activation Records for Procedures . . . . . 5.3.3 Stack Management . . . . . . . . . . . . . . 5.4 Dynamic Management Using a Heap . . . . . . . . 5.4.1 Fixed-Length Blocks . . . . . . . . . . . . 5.4.2 Variable-Length Blocks . . . . . . . . . . . 5.5 Implementation of Scope Rules . . . . . . . . . . . 5.5.1 Static Scope: The Static Chain . . . . . . . 5.5.2 Static Scope: The Display . . . . . . . . . . 5.5.3 Dynamic Scope: Association Lists and CRT 5.6 Chapter Summary . . . . . . . . . . . . . . . . . . 5.7 Bibliographic Notes . . . . . . . . . . . . . . . . . 5.8 Exercises . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

91 91 93 93 96 97 99 101 101 103 105 105 109 111 115 116 116 118

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

Contents

xv

6

Control Structure . . . . . . . . . . . . . . . . . . . . 6.1 Expressions . . . . . . . . . . . . . . . . . . . . 6.1.1 Expression Syntax . . . . . . . . . . . . . 6.1.2 Semantics of Expressions . . . . . . . . . 6.1.3 Evaluation of Expressions . . . . . . . . . 6.2 The Concept of Command . . . . . . . . . . . . . 6.2.1 The Variable . . . . . . . . . . . . . . . . 6.2.2 Assignment . . . . . . . . . . . . . . . . 6.3 Sequence Control Commands . . . . . . . . . . . 6.3.1 Commands for Explicit Sequence Control 6.3.2 Conditional Commands . . . . . . . . . . 6.3.3 Iterative Commands . . . . . . . . . . . . 6.4 Structured Programming . . . . . . . . . . . . . . 6.5 Recursion . . . . . . . . . . . . . . . . . . . . . 6.5.1 Tail Recursion . . . . . . . . . . . . . . . 6.5.2 Recursion or Iteration? . . . . . . . . . . 6.6 Chapter Summary . . . . . . . . . . . . . . . . . 6.7 Bibliographical Notes . . . . . . . . . . . . . . . 6.8 Exercises . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

119 119 120 123 125 129 130 131 136 136 140 144 150 152 155 159 160 161 161 163

7

Control Abstraction . . . . . . . . . 7.1 Subprograms . . . . . . . . . . . 7.1.1 Functional Abstraction . . 7.1.2 Parameter Passing . . . . 7.2 Higher-Order Functions . . . . . 7.2.1 Functions as Parameters . 7.2.2 Functions as Results . . . 7.3 Exceptions . . . . . . . . . . . . 7.3.1 Implementing Exceptions 7.4 Chapter Summary . . . . . . . . 7.5 Bibliographical Notes . . . . . . 7.6 Exercises . . . . . . . . . . . . . References . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

165 166 167 169 178 179 184 186 190 191 193 194 196

8

Structuring Data . . . . . . . . . . . . . . . . . . . . . . 8.1 Data Types . . . . . . . . . . . . . . . . . . . . . . . 8.1.1 Types as Support for Conceptual Organisation 8.1.2 Types for Correctness . . . . . . . . . . . . . 8.1.3 Types and Implementation . . . . . . . . . . . 8.2 Type Systems . . . . . . . . . . . . . . . . . . . . . 8.2.1 Static and Dynamic Checking . . . . . . . . . 8.3 Scalar Types . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Booleans . . . . . . . . . . . . . . . . . . . . 8.3.2 Characters . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

197 197 198 199 200 201 202 203 204 204

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

xvi

Contents

8.4

8.5

8.6 8.7

8.8 8.9 8.10

8.11

8.12 8.13 8.14 9

8.3.3 Integers . . . . . . . . . . . . . . . 8.3.4 Reals . . . . . . . . . . . . . . . . . 8.3.5 Fixed Point . . . . . . . . . . . . . . 8.3.6 Complex . . . . . . . . . . . . . . . 8.3.7 Void . . . . . . . . . . . . . . . . . 8.3.8 Enumerations . . . . . . . . . . . . 8.3.9 Intervals . . . . . . . . . . . . . . . 8.3.10 Ordered Types . . . . . . . . . . . . Composite Types . . . . . . . . . . . . . . . 8.4.1 Records . . . . . . . . . . . . . . . 8.4.2 Variant Records and Unions . . . . . 8.4.3 Arrays . . . . . . . . . . . . . . . . 8.4.4 Sets . . . . . . . . . . . . . . . . . . 8.4.5 Pointers . . . . . . . . . . . . . . . 8.4.6 Recursive Types . . . . . . . . . . . 8.4.7 Functions . . . . . . . . . . . . . . . Equivalence . . . . . . . . . . . . . . . . . 8.5.1 Equivalence by Name . . . . . . . . 8.5.2 Structural Equivalence . . . . . . . . Compatibility and Conversion . . . . . . . . Polymorphism . . . . . . . . . . . . . . . . 8.7.1 Overloading . . . . . . . . . . . . . 8.7.2 Universal Parametric Polymorphism 8.7.3 Subtype Universal Polymorphism . . 8.7.4 Remarks on the Implementation . . . Type Checking and Inference . . . . . . . . Safety: An Evaluation . . . . . . . . . . . . Avoiding Dangling References . . . . . . . 8.10.1 Tombstone . . . . . . . . . . . . . . 8.10.2 Locks and Keys . . . . . . . . . . . Garbage Collection . . . . . . . . . . . . . 8.11.1 Reference Counting . . . . . . . . . 8.11.2 Mark and Sweep . . . . . . . . . . . 8.11.3 Interlude: Pointer Reversal . . . . . 8.11.4 Mark and Compact . . . . . . . . . 8.11.5 Copy . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . Bibliographic Notes . . . . . . . . . . . . . Exercises . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . .

Data Abstraction . . . . . . . . . . . . . 9.1 Abstract Data Types . . . . . . . . . 9.2 Information Hiding . . . . . . . . . 9.2.1 Representation Independence

. . . .

. . . .

. . . .

. . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

205 205 205 206 207 207 208 209 209 209 211 216 221 222 227 229 230 231 232 234 237 238 239 241 242 244 246 247 248 249 250 251 253 254 255 255 258 259 259 262

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

265 265 268 271

Contents

9.3 9.4 9.5 9.6

xvii

Modules . . . . . . . Chapter Summary . . Bibliographical Notes Exercises . . . . . . . References . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

271 272 275 275 276

10 The Object-Oriented Paradigm . . . . . . . . . . . 10.1 The Limits of Abstract Data Types . . . . . . . 10.1.1 A First Review . . . . . . . . . . . . . . 10.2 Fundamental Concepts . . . . . . . . . . . . . . 10.2.1 Objects . . . . . . . . . . . . . . . . . . 10.2.2 Classes . . . . . . . . . . . . . . . . . . 10.2.3 Encapsulation . . . . . . . . . . . . . . 10.2.4 Subtypes . . . . . . . . . . . . . . . . . 10.2.5 Inheritance . . . . . . . . . . . . . . . . 10.2.6 Dynamic Method Lookup . . . . . . . . 10.3 Implementation Aspects . . . . . . . . . . . . . 10.3.1 Single Inheritance . . . . . . . . . . . . 10.3.2 The Problem of Fragile Base Class . . . 10.3.3 Dynamic Method Dispatch in the JVM . 10.3.4 Multiple Inheritance . . . . . . . . . . . 10.4 Polymorphism and Generics . . . . . . . . . . . 10.4.1 Subtype Polymorphism . . . . . . . . . 10.4.2 Generics in Java . . . . . . . . . . . . . 10.4.3 Implementation of Generics in Java . . . 10.4.4 Generics, Arrays and Subtype Hierarchy 10.4.5 Covariant and Contravariant Overriding . 10.5 Chapter Summary . . . . . . . . . . . . . . . . 10.6 Bibliographical Notes . . . . . . . . . . . . . . 10.7 Exercises . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

277 277 281 281 282 283 287 287 292 297 301 303 305 306 309 314 315 317 321 323 325 328 328 329 331

11 The Functional Paradigm . . . . . . . . . . 11.1 Computations without State . . . . . . . 11.1.1 Expressions and Functions . . . 11.1.2 Computation as Reduction . . . . 11.1.3 The Fundamental Ingredients . . 11.2 Evaluation . . . . . . . . . . . . . . . . 11.2.1 Values . . . . . . . . . . . . . . 11.2.2 Capture-Free Substitution . . . . 11.2.3 Evaluation Strategies . . . . . . 11.2.4 Comparison of the Strategies . . 11.3 Programming in a Functional Language . 11.3.1 Local Environment . . . . . . . 11.3.2 Interactiveness . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

333 333 335 337 338 339 340 340 341 343 345 345 346

. . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

xviii

Contents

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

346 347 349 350 353 355 358 364 365 365 366

12 The Logic Programming Paradigm . . . . . . . . . . . . 12.1 Deduction as Computation . . . . . . . . . . . . . . . 12.1.1 An Example . . . . . . . . . . . . . . . . . . 12.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12.2.1 The Language of First-Order Logic . . . . . . 12.2.2 Logic Programs . . . . . . . . . . . . . . . . 12.3 Theory of Unification . . . . . . . . . . . . . . . . . 12.3.1 The Logic Variable . . . . . . . . . . . . . . 12.3.2 Substitution . . . . . . . . . . . . . . . . . . 12.3.3 Most General Unifier . . . . . . . . . . . . . 12.3.4 A Unification Algorithm . . . . . . . . . . . . 12.4 The Computational Model . . . . . . . . . . . . . . . 12.4.1 The Herbrand Universe . . . . . . . . . . . . 12.4.2 Declarative and Procedural Interpretation . . . 12.4.3 Procedure Calls . . . . . . . . . . . . . . . . 12.4.4 Control: Non-determinism . . . . . . . . . . . 12.4.5 Some Examples . . . . . . . . . . . . . . . . 12.5 Extensions . . . . . . . . . . . . . . . . . . . . . . . 12.5.1 Prolog . . . . . . . . . . . . . . . . . . . . . 12.5.2 Logic Programming and Databases . . . . . . 12.5.3 Logic Programming with Constraints . . . . . 12.6 Advantages and Disadvantages of the Logic Paradigm 12.7 Chapter Summary . . . . . . . . . . . . . . . . . . . 12.8 Bibliographical Notes . . . . . . . . . . . . . . . . . 12.9 Exercises . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

369 369 371 374 374 376 377 377 379 381 383 387 387 388 389 392 395 398 398 403 404 406 408 409 409 411

13 A Short Historical Perspective . . . . . . . . . 13.1 Beginnings . . . . . . . . . . . . . . . . . 13.2 Factors in the Development of Languages . 13.3 1950s and 60s . . . . . . . . . . . . . . . 13.4 The 1970s . . . . . . . . . . . . . . . . . 13.5 The 1980s . . . . . . . . . . . . . . . . . 13.6 1990s . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

413 413 415 417 421 425 428

11.4 11.5 11.6 11.7 11.8 11.9

11.3.3 Types . . . . . . . . . . . . . . . . 11.3.4 Pattern Matching . . . . . . . . . . 11.3.5 Infinite Objects . . . . . . . . . . . 11.3.6 Imperative Aspects . . . . . . . . Implementation: The SECD Machine . . . The Functional Paradigm: An Assessment Fundamentals: The λ-calculus . . . . . . . Chapter Summary . . . . . . . . . . . . . Bibliographical Note . . . . . . . . . . . . Exercises . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . .

Contents

xix

13.7 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 430 13.8 Bibliographical Notes . . . . . . . . . . . . . . . . . . . . . . . . 431 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433

Chapter 1

Abstract Machines

Abstraction mechanisms play a crucial role in computing because they allow us to manage the complexity inherent in most computational systems by isolating the important aspects in a specific context. In the field of programming languages, these mechanisms are fundamental, both from a theoretical viewpoint (many important concepts can be appropriately formalised using abstractions) and in the practical sense, because programming languages today use common abstraction-creating constructs. One of the most general concepts employing abstraction is the abstract machine. In this chapter, we will see how this concept is closely related to the programming languages. We will also see how, without requiring us to go into the specific details of any particular implementation, it allows us to describe what an implementation of a programming language is. To do this, we will describe in general terms what is meant by the interpreter and the compiler for a language. Finally, will see how abstract machines can be structured in hierarchies that describe and implement complex software systems.

1.1 The Concepts of Abstract Machine and of Interpreter In the context of this book, the term “machine” refers clearly to a computing machine. As we know, an electronic, digital computer is a physical machine that executes algorithms which are suitably formalised so that the machine can “understand” them. Intuitively, an abstract machine is nothing more than an abstraction of the concept of a physical computer. For actual execution, algorithms must be appropriately formalised using the constructs provided by a programming language. In other words, the algorithms we want to execute must be represented using the instructions of a programming language, L . This language will be formally defined in terms of a specific syntax and a precise semantics—see Chap. 2. For the time being, the nature of L is of no concern to us. Here, it is sufficient to know that the syntax of L allows us to use a given finite set of constructs, called instructions, to construct programs. A program in L M. Gabbrielli, S. Martini, Programming Languages: Principles and Paradigms, Undergraduate Topics in Computer Science, DOI 10.1007/978-1-84882-914-5_1, © Springer-Verlag London Limited 2010

1

2

1 Abstract Machines

Fig. 1.1 The structure of an abstract machine

(or program written in L ) therefore is nothing more than a finite set of instructions of L . With these preliminary remarks, we now present a definition that is central to this chapter. Definition 1.1 (Abstract Machine) Assume that we are given a programming language, L . An abstract machine for L , denoted by ML , is any set of data structures and algorithms which can perform the storage and execution of programs written in L . When we choose not to specify the language, L , we will simply talk of the abstract machine, M , omitting the subscript. We will soon see some example abstract machines and how they can actually be implemented. For the time being, let us stop and consider the structure of an abstract machine. As depicted in Fig. 1.1, a generic abstract machine ML is composed of a store and an interpreter. The store serves to store data and programs while the interpreter is the component that executes the instructions contained in programs. We will see this more clearly in the next section.

1.1.1 The Interpreter Clearly the interpreter must perform the operations that are specific to the language it is interpreting, L . However, even given the diversity of languages, it is possible

1.1 The Concepts of Abstract Machine and of Interpreter

3

to discern types of operation and an “execution method” common to all interpreters. The type of operation executed by the interpreter and associated data structures, fall into the following categories: 1. Operations for processing primitive data; 2. Operations and data structures for controlling the sequence of execution of operations; 3. Operations and data structures for controlling data transfers; 4. Operations and data structures for memory management. We consider these four points in detail. 1. The need for operations such as those in point one is clear. A machine, even an abstract one, runs by executing algorithms, so it must have operations for manipulating primitive data items. These items can be directly represented by a machine. For example, for physical abstract machines, as well as for the abstract machines used by many programming languages, numbers (integer or real) are almost always primitive data. The machine directly implements the various operations required to perform arithmetic (addition, multiplication, etc.). These arithmetic operations are therefore primitive operations as far as the abstract machine is concerned1 . 2. Operations and structures for “sequence control” allow to control the execution flow of instructions in a program. The normal sequential execution of a program might have to be modified when some conditions are satisfied. The interpreter therefore makes use of data structures (for example to hold the address of the next instruction to execute) which are manipulated by specific operations that are different from those used for data manipulation (for example, operations to update the address of the next instruction to execute). 3. Operations that control data transfers are included in order to control how operands and data is to be transferred from memory to the interpreter and vice versa. These operations deal with the different store addressing modes and the order in which operands are to be retrieved from store. In some cases, auxiliary data structures might be necessary to handle data transfers. For example, some types of machine use stacks (implemented either in hardware or software) for this purpose. 4. Finally, there is memory management. This concerns the operations used to allocate data and programs in memory. In the case of abstract machines that are similar to hardware machines, storage management is relatively simple. In the limit case of a physical register-based machine that is not multiprogrammed, a program and its associated data could be allocated in a zone of memory at the start of execution and remain there until the end, without much real need for memory management. Abstract machines for common programming languages, instead, as will be seen, use more sophisticated memory management techniques. In fact, some constructs in these languages either directly or indirectly cause memory to be allocated or deallocated. Correct implementation of these operations requires suitable data 1 It should, however, be noted that there exist programming languages, for example, some declarative languages, in which numeric values and their associated operations are not primitive.

4

1 Abstract Machines

Fig. 1.2 The execution cycle of a generic interpreter

structures (for example, stacks) and dynamic operations (which are, therefore, executed at runtime). The interpreter’s execution cycle, which is substantially the same for all interpreters, is shown in Fig. 1.2. It is organised in terms of the following steps. First, it fetches the next instruction to execute from memory. The instruction is then decoded to determine the operation to be performed as well as its operands. As many operands as required by the instruction are fetched from memory using the method described above. After this, the instruction, which must be one of the machine’s primitives, is executed. Once execution of the operation has completed, any results are stored. Then, unless the instruction just executed is a halt instruction, execution passes to the next instruction in sequence and the cycle repeats. Now that we have seen the interpreter, we can define the language it interprets as follows: Definition 1.2 (Machine language) Given an abstract machine, ML , the language L “understood” by ML ’s interpreter is called the machine language of ML . Programs written in the machine language of ML will be stored in the abstract machine’s storage structures so that they cannot be confused with other primitive data on which the interpreter operates (it should be noted that from the interpreter’s viewpoint, programs are also a kind of data). Given that the internal representation of the programs executed by the machine ML is usually different from its external representation, then we should strictly talk about two different languages. In any

1.1 The Concepts of Abstract Machine and of Interpreter

5

“Low-level” and “High-level” languages A terminological note is useful. We will return to it in an historical perspective in Chap. 13. In the field of programming languages, the terms “low level” and “high level” are often used to refer, respectively, to distance from the human user and from the machine. Let us therefore call low-level, those languages whose abstract machines are very close to, or coincide with, the physical machine. Starting at the end of the 1940s, these languages were used to program the first computers, but, they turned out to be extremely awkward to use. Because the instructions in these languages had to take into account the physical characteristics of the machine, matters that were completely irrelevant to the algorithm had to be considered while writing programs, or in coding algorithms. It must be remembered that often when we speak generically about “machine language”, we mean the language (a low-level one) of a physical machine. A particular low-level language for a physical machine is its assembly language, which is a symbolic version of the physical machine (that is, which uses symbols such as ADD, MUL, etc., instead of their associated hardware binary codes). Programs in assembly language are translated into machine code using a program called an assembler. So-called high-level programming languages are, on the other hand, those which support the use of constructs that use appropriate abstraction mechanisms to ensure that they are independent of the physical characteristics of the computer. High-level languages are therefore suited to expressing algorithms in ways that are relatively easy for the human user to understand. Clearly, even the constructs of a high-level language must correspond to instructions of the physical machine because it must be possible to execute programs.

case, in order not to complicate notation, for the time being we will not consider such differences and therefore we will speak of just one machine language, L , for machine ML .

1.1.2 An Example of an Abstract Machine: The Hardware Machine From what has been said so far, it should be clear that the concept of abstract machine can be used to describe a variety of different systems, ranging from physical machines right up to the World Wide Web. As a first example of an abstract machine, let us consider the concrete case of a conventional physical machine such as that in Fig. 1.3. It is physically implemented using logic circuits and electronic components. Let us call such a machine M HL H and let L H be its machine language.

6

1 Abstract Machines

Fig. 1.3 The structure of a conventional calculator

For this specific case, we can, using what we have already said about the components of an abstract machine, identify the following parts. Memory The storage component of a physical computer is composed of various levels of memory. Secondary memory implemented using optical or magnetic components; primary memory, organised as a linear sequence of cells, or words, of fixed size (usually a multiple of 8 bits, for example 32 or 64 bits); cache and the registers which are internal to the Central Processing Unit (CPU). Physical memory, whether primary, cache or register file, permits the storage of data and programs. As stated, this is done using the binary alphabet. Data is divided into a few primitive “types”: usually, we have integer numbers, so-called “real” numbers (in reality, a subset of the rationals), characters, and fixedlength sequences of bits. Depending upon the type of data, different physical representations, which use one or more memory words for each element of the type are used. For example, the integers can be represented by 1s or 2s complement numbers contained in a single word, while reals have to be represented as floating point numbers using one or two words depending on whether they are single or double precision. Alphanumeric characters are also implemented as sequences of binary numbers encoded in an appropriate representational code (for example, the ASCII or UNI CODE formats). We will not here go into the details of these representations since they will be examined in more detail in Chap. 8. We must emphasise the fact that although all data is represented by sequences of bits, at the hardware level we can distinguish different categories, or more properly types, of primitive data that can be manipulated directly by the operations provided by the hardware. For this reason, these types are called predefined types. The language of the physical machine The language, L H which the physical machine executes is composed of relatively simple instructions. A typical instruc-

1.1 The Concepts of Abstract Machine and of Interpreter

7

tion with two operands, for example, requires one word of memory and has the format: OpCode Operand1 Operand2

where OpCode is a unique code which identifies one of the primitive operations defined by the machine’s hardware, while Operand1 and Operand2 are values which allow the operands to be located by referring to the storage structures of the machine and their addressing modes. For example, ADD R5, R0

might indicate the sum of the contents of registers R0 and R5, with the result being stored in R5, while ADD (R5), (R0)

might mean that the sum of the contents of the memory cells whose addresses are contained in R0 and R5 is computed and the result stored in the cell whose address is in R5. It should be noted that, in these examples, for reasons of clarity, we are using symbolic codes such as ADD, R0, (R0). In the language under consideration, on the other hand, we have binary numeric values (addresses are expressed in “absolute” mode). From the viewpoint of internal representation, instructions are nothing more than data stored in a particular format. Like the instructions and data structures used in executing programs, the set of possible instructions (with their associated operations and addressing modes) depends on the particular physical machine. It is possible to discern classes of machine with similar characteristics. For example, we can distinguish between conventional CISC (Complex Instruction Set Computer) processors which have many machine instructions (some of which are quite complex) and RISC (Reduced Instruction Set Computers) architectures in which there tend to be fewer instructions which are, in particular, simple enough to be executed in a few (possibly one) clock cycle and in pipelined fashion. Interpreter With the general structure of an abstract machine as a model, it is possible to identify the following components of a physical (hardware) machine: 1. The operations for processing primitive data are the usual arithmetic and logical operations. They are implemented by the ALU (Arithmetic and Logic Unit). Arithmetic operations on integers, and floating-point numbers, booleans are provided, as are shifts, tests, etc. 2. For the control of instruction sequence execution, there is the Program Counter (PC) register, which contains the address of the next instruction to execute. It is the main data structure of this component. Sequence-control operations specifically use this register and typically include the increment operation (which handles the normal flow of control) and operations that modify the value stored in the PC register (jumps).

8

1 Abstract Machines

3. To handle data transfer, the CPU registers interfacing with main memory are used. They are: the data address register (the MAR or Memory Address Register) and the data register (MDR or Memory Data Register). There are, in addition, operations that modify the contents of these registers and that implement various addressing modes (direct, indirect, etc.). Finally, there are operations that access and modify the CPU’s internal registers. 4. Memory processing depends fundamentally on the specific architecture. In the simplest case of a register machine that is not multi-programmed, memory management is rudimentary. The program is loaded and immediately starts executing; it remains in memory until it terminates. To increase computation speed, all modern architectures use more sophisticated memory management techniques. In the first place, there are levels of memory intermediate between registers and main memory (i.e., cache memory), whose management needs special data structures and algorithms. Second, some form of multi-programming is almost always implemented (the execution of a program can be suspended to give the CPU to other programs, so as to optimise the management of resources). As a general rule, these techniques (which are used by operating systems) usually require specialised hardware support to manage the presence of more than one program in memory at any time (for example, dynamic address relocation). All the techniques so far described need specific memory-management data structures and operations to be provided by the hardware. In addition, there are other types of machine that correspond to less conventional architectures. In the case of a machine which uses a (hardware) stack instead of registers, there is the stack data structure together with the push and pop operations. The interpreter for the hardware machine is implemented as a set of physical devices which comprise the Control Unit and which support execution of the socalled fetch-decode-execute cycle. using the sequence control operations. This cycle is analogous to that in the generic interpreter such as the one depicted in Fig. 1.2. It consists of the following phases. In the fetch phase, the next instruction to be executed is retrieved from memory. This is the instruction whose address is held in the PC register (the PC register is automatically incremented after the instruction has been fetched). The instruction, which, it should be recalled, is formed of an operation code and perhaps some operands, is then stored in a special register, called the instruction register. In the decode phase, the instruction stored in the instruction register is decoded using special logic circuits. This allows the correct interpretation of both the instruction’s operation code and the addressing modes of its operands. The operands are then retrieved by data transfer operations using the address modes specified in the instruction . Finally, in the execute phase, the primitive hardware operation is actually executed, for example using the circuits of the ALU if the operation is an arithmetic or logical one. If there is a result, it is stored in the way specified by the addressing mode and the operation code currently held in the instruction register. Storage is performed by means of data-transfer operations. At this point, the instruction’s execution is complete and is followed by the next phase, in which the next instruction is

1.2 Implementation of a Language

9

fetched and the cycle continues (provided the instruction just executed is not a stop instruction). It should be noted that, even if only conceptually, the hardware machine distinguishes data from instructions. At the physical level, there is no distinction between them, given that they are both represented internally in terms of bits. The distinction mainly derives from the state of the CPU. In the fetch state, every word fetched from memory is considered an instruction, while in the execute phase, it is considered to be data. It should be observed that, finally, an accurate description of the operation of the physical machine would require the introduction of other states in addition to fetch, decode and execute. Our description only aims to show how the general concept of an interpreter is instantiated by a physical machine.

1.2 Implementation of a Language We have seen that an abstract machine, ML , is by definition a device which allows the execution of programs written in L . An abstract machine therefore corresponds uniquely to a language, its machine language. Conversely, given a programming language, L , there are many (an infinite number) of abstract machines that have L as their machine language. These machines differ from each other in the way in which the interpreter is implemented and in the data structures that they use; they all agree, though, on the language they interpret—L . To implement a programming language L means implementing an abstract machine which has L as its machine language. Before seeing which implementation techniques are used for current programming languages, we will first see what the various theoretical possibilities for an abstract machine are.

1.2.1 Implementation of an Abstract Machine Any implementation of an abstract machine, ML must sooner or later use some kind of physical device (mechanical, electronic, biological, etc.) to execute the instructions of L . The use of such a device, nevertheless, can be explicit or implicit. In fact, in addition to the “physical” implementation (in hardware) of ML ’s constructs, we can even think instead of an implementation (in software or firmware) at levels intermediate between ML and the underlying physical device. We can therefore reduce the various options for implementing an abstract machine to the following three cases and to combinations of them: • implementation in hardware; • simulation using software; • simulation (emulation) using firmware.

10

1 Abstract Machines

Microprogramming Microprogramming techniques were introduced in the 1960s with the aim of providing a whole range of different computers, ranging from the slowest and most economical to those with the greatest speed and price, with the same instruction set and, therefore, the same assembly language (the IBM 360 was the most famous computer on which microprogramming was used). The machine language of microprogrammed machines is at an extremely low level and consists of microinstructions which specify simple operations for the transfer of data between registers, to and from main memory and perhaps also passage through the logic circuits that implement arithmetic operations. Each instruction in the language which is to be implemented (that is, in the machine language that the user of the machine sees) is simulated using a specific set of microinstructions. These microinstructions, which encode the operation, together with a particular set of microinstructions implementing the interpretation cycle, constitute a microprogram which is stored in special read-only memory (which requires special equipment to write). This microprogram implements the interpreter for the (assembly) language common to different computers, each of which has different hardware. The most sophisticated (and costly) physical machines are built using more powerful hardware hence they can implement an instruction by using fewer simulation steps than the less costly models, so they run at a greater speed. Some terminology needs to be introduced: the term used for simulation using micro-programming, is emulation; the level at which microprogramming occurs is called firmware. Let us, finally, observe that a microprogrammable machine constitutes a single, simple example of a hierarchy composed of two abstract machines. At the higher level, the assembly machine is constructed on top of what we have called the microprogrammed machine. The assembly language interpreter is implemented in the language of the lower level (as microinstructions), which is, in its turn, interpreted directly by the microprogrammed physical machine. We will discuss this situation in more depth in Sect. 1.3.

Implementation in Hardware The direct implementation of ML in hardware is always possible in principle and is conceptually fairly simple. It is, in fact, a matter of using physical devices such as memory, arithmetic and logic circuits, buses, etc., to implement a physical machine whose machine language coincides with L . To do this, it is sufficient to implement in the hardware the data structures and algorithms constituting the abstract machine.2 2 Chapter

3 will tackle the question of why this can always be done for programming languages.

1.2 Implementation of a Language

11

The implementation of a machine ML in hardware has the advantage that the execution of programs in L will be fast because they will be directly executed by the hardware. This advantage, nevertheless, is compensated for by various disadvantages which predominate when L is a generic high-level language. Indeed, the constructs of a high-level language, L , are relatively complicated and very far from the elementary functions provided at the level of the electronic circuit. An implementation of ML requires, therefore, a more complicated design for the physical machine that we want to implement. Moreover, in practice, such a machine, once implemented, would be almost impossible to modify. In would not be possible to implement on it any future modifications to L without incurring prohibitive costs. For these reasons,in practice, when implementing ML , in hardware, only low-level languages are used because their constructs are very close to the operations that can be naturally defined using just physical devices. It is possible, though, to implement “dedicated” languages developed for special applications directly in hardware where enormous execution speeds are necessary. This is the case, for example, for some special languages used in real-time systems. The fact remains that there are many cases in which the structure of a highlevel language’s abstract machine has influenced the implementation of a hardware architecture, not in the sense of a direct implementation of the abstract machine in hardware, but in the choice of primitive operations and data structures which permit simpler and more efficient implementation of the high-level language’s interpreter. This is the case, for example with the architecture of the B5500, a computer from the 1960s which was influenced by the structure of the Algol language. Simulation Using Software The second possibility for implementing an abstract machine consists of implementing the data structures and algorithms required by ML using programs written in another language, L ′ , which, we can assume, has already been implemented. Us′ , we can, indeed, implement the machine M ing language L ′ ’s machine, ML ′ L using appropriate programs written in L ′ which interpret the constructs of L by simulating the functionality of ML . In this case, we will have the greatest flexibility because we can easily change the programs implementing the constructs of ML . We will nevertheless see a performance that is lower than in the previous case because the implementation of ML ′ , which, in its turn, must be implemented in uses another abstract machine ML ′ hardware, software or firmware, adding an extra level of interpretation. Emulation Using Firmware Finally, the third possibility is intermediate between hardware and software implementation. It consists of simulation (in this case, it is also called emulation) of the data structures and algorithms for ML in microcode (which we briefly introduced in the box on page 10).

12

1 Abstract Machines

Partial Functions A function f : A → B is a correspondence between elements of A and elements of B such that, for every element a of A, there exists one and only one element of B. We will call it f (a). A partial function, f : A → B, is also a correspondence between the two sets A and B, but can be undefined for some elements of A. More formally: it is a relation between A and B such that, for every a ∈ A, if there exists a corresponding element b ∈ B, it is unique and is written f (a). The notion of partial function, for us, is important because, in a natural fashion, programs define partial functions. For example, the following program (written in a language with obvious syntax and semantics and whose core will however be defined in Fig. 2.11): read(x); if (x == 1) then print(x); else while (true) do skip computes the partial function: ! 1 if x = 1 f (n) = undefined

otherwise

Conceptually, this solution is similar to simulation in software. In both cases, ML is simulated using appropriate programs that are executed by a physical machine. Nevertheless, in the case of firmware emulation, these programs are microprograms instead of programs in a high-level language. As we saw in the box, microprograms use a special, very low-level language (with extremely simple primitive operations) which are stored in a special read-only memory instead of in main memory, so they can be executed by the physical machine at high speed. For this reason, this implementation of an abstract machine allows us to obtain an execution speed that is higher than that obtainable from software simulation, even if it is not as fast as the equivalent hardware solution. On the other hand, the flexibility of this solution is lower than that of software simulation, since, while it is easy to modify a program written in a high-level language, modification of microcode is relatively complicated and requires special hardware to re-write the memory in which the microcode is stored. The situation is anyway better than in the hardware implementation case, given that microprograms can be modified. Clearly, for this solution to be possible, the physical machine on which it is used must be microprogrammable. Summarising, the implementation of ML in hardware affords the greatest speed but no flexibility. Implementation in software affords the highest flexibility and least speed, while the one using firmware is intermediate between the two.

1.2 Implementation of a Language

13

1.2.2 Implementation: The Ideal Case Let us consider a generic language, L , which we want to implement, or rather, for which an abstract machine, ML is required. Assuming that we can exclude, for the reasons just given, direct implementation in hardware of ML , we can assume that, for our implementation of ML , we have available an abstract machine, M oL o , which we will call the host machine, which is already implemented (we do not care how) and which therefore allows us to use the constructs of its machine language L o directly. Intuitively, the implementation of L on the host machine M oL o takes place using a “translation” from L to L o. Nevertheless, we can distinguish two conceptually very different modes of implementation, depending on whether there is an “implicit” translation (implemented by the simulation of ML ’s constructs by programs written in L o) or an explicit translation from programs in L to corresponding programs in L o. We will now consider these two ways in their ideal forms. We will call these ideal forms: 1. purely interpreted implementation, and 2. purely compiled implementation.

Notation Below, as previously mentioned, we use the subscript L to indicate that a particular construct (machine, interpreter, program, etc.) refers to language L . We will use the superscript L to indicate that a program is written in language L . We will use Prog L to denote the set of all possible programs that can be written in language L , while D denotes the set of input and output data (and, for simplicity of treatment, we make no distinction between the two). A program written in L can be seen as a partial function (see the box): PL : D → D such that P L (Input) = Output if the execution of P L on input data Input terminates and produces Output as its result. The function is not defined if the execution of P L on its input data, Input, does not terminate.3 3 It should be noted that there is no loss of generality in considering only one input datum, given that it can stand for a set of data.

14

1 Abstract Machines

Fig. 1.4 Purely interpreted implementation

Purely interpreted implementation In a purely interpreted implementation (shown in Fig. 1.4), the interpreter for ML is implemented using a set of instructions in L o. That is, a program is implemented in L o which interprets all of L ’s L o. instructions; this is an interpreter. We will call it IL Once such interpreter is implemented, executing a program P L (written in lanLo guage L ) on specified input data D ∈ D , we need only execute the program IL L on machine M oL o , with P and D as input data. More precisely, we can give the following definition. Definition 1.3 (Interpreter) An interpreter for language L , written in language L o, is a program which implements a partial function: Lo : (Prog L × D) → D IL

Lo such that IL (P L , Input) = P L (Input) (1.1)

The fact that a program can be considered as input datum for another program should not be surprising, given that, as already stated, a program is only a set of instructions which, in the final analysis, are represented by a certain set of symbols (and therefore by bit sequences). In the purely interpreted implementation of L , therefore, programs in L are not explicitly translated. There is only a “decoding” procedure. In order to execute L o uses a set of instructions in L o which an instruction of L , the interpreter IL corresponds to an instruction in language L . Such decoding is not a real translation because the code corresponding to an instruction of L is executed, not output, by the interpreter. It should be noted that we have deliberately not specified the nature of the machine M oL o . The language L o can therefore be a high-level language, a low-level language or even one firmware. Purely compiled implementation With purely compiled implementation, as shown in Fig. 1.5, the implementation of L takes place by explicitly translating programs written in L to programs written in L o. The translation is performed by a special program called compiler; it is denoted by CL ,L o . In this case, the language L is usually called the source language, while language L o is called the object language. To execute a program P L (written in language L ) on input

1.2 Implementation of a Language

15

Fig. 1.5 Pure compiled implementation

data D, we must first execute CL ,L o and give it P L as input. This will produce a compiled program PcL o as its output (written in L o). At this point, we can execute PcL o on the machine M oL o supplying it with input data D to obtain the desired result. Definition 1.4 (Compiler) A compiler from L to L o is a program which implements a function: CL ,L o : Prog L → Prog L o such that, given a program P L , if CL ,L o (P L ) = PcL o ,

(1.2)

P L (Input) = PcL o (Input)

(1.3)

then, for every Input∈ D 4 :

Note that, unlike pure interpretation, the translation phase described in (1.2) (called compilation) is separate from the execution phase, which is, on the other hand, handled by (1.3). Compilation indeed produces a program as output. This program can be executed at any time we want. It should be noted that if M oL o is the only machine available to us, and therefore if L o is the only language that we can use, the compiler will also be a program written in L o. This is not necessary, however, for the compiler could in fact be executed on another abstract machine altogether and this, latter, machine could execute a different language, even though it produces executable code for M oL o . 4 It

should be noted that, for simplicity, we assume that the data upon which programs operate are the same for source and object languages. If were not the case, the data would also have to be translated in an appropriate manner.

16

1 Abstract Machines

Comparing the Two Techniques Having presented the purely interpreted and purely compiled implementation techniques, we will now discuss the advantages and disadvantages of these two approaches. As far as the purely interpreted implementation is concerned, the main disadvantage is its low efficiency. In fact, given that there is no translation phase, in order to L o must perform a decoding of L ’s execute the program P L , the interpreter IL constructs while it executes. Hence, as part of the time required for the execution of P L , it is also necessary to add in the time required to perform decoding. For example, if the language L contains the iterative construct for and if this construct is not present in language L o, to execute a command such as: P1: for (I = 1, I R2 then goto L2 translation of C ... R1 = R1 + 1 goto L1 L2: ...

It is important to repeat that, as shown in (1.1), the interpreter does not generate code. The code shown immediately above is not explicitly produced by the interpreter but only describes the operations that the interpreter must execute at runtime once it has decoded the for command. It can also be seen that for every occurrence of the same command in a program written in L , the interpreter must perform a separate decoding steep; this does not improve performance. In our example, the command C inside the loop must be decoded n times, clearly with consequent inefficiency. As often happens, the disadvantages in terms of efficiency are compensated for by advantages in terms of flexibility. Indeed, interpreting the constructs of the program that we want to execute at runtime allows direct interaction with whatever is running the program. This is particularly important, for example, because it makes defining program debugging tools relatively easy. In general, moreover, the development of an interpreter is simpler than the development of a compiler; for this reason, interpretative solutions are preferred when it is necessary to implement a new language within a short time. It should be noted, finally, that an interpretative implementation allows a considerable reduction in memory usage, given that the

1.2 Implementation of a Language

17

program is stored only in its source version (that is, in the language L ) and no new code is produced, even if this consideration is not particularly important today. The advantages and disadvantages of the compilational and interpretative approaches to languages are dual to each other. The translation of the source program, P L , to an object program, PcL o , occurs separately from the latter’s execution. If we neglect the time taken for compilation, therefore, the execution of PcL o will turn out to be more efficient than an interpretive implementation because the former does not have the overhead of the instruction decoding phase. In our first example, the program fragment P1 will be translated into fragment P2 by the compiler. Later, when necessary, P2 will executed without having to decode the for instruction again. Furthermore, unlike in the case of an interpreter, decoding an instruction of language L is performed once by the compiler, independent of the number of times this instruction occurs at runtime. In our example, the command C is decoded and translated once only at compile time and the code produced by this is executed n times at runtime. In Sect. 2.4, we will describe the structure of a compiler, together with the optimisations that can be applied to the code it produces. One of the major disadvantages of the compilation approach is that it loses all information about the structure of the source program. This loss makes runtime interaction with the program more difficult. For example, when an error occurs at runtime, it can be difficult to determine which source-program command caused it, given that the command will have been compiled into a sequence of object-language instructions. In such a case, it can be difficult, therefore, to implement debugging tools; more generally, there is less flexibility than afforded by the interpretative approach.

1.2.3 Implementation: The Real Case and The Intermediate Machine Burly purely compiled and interpreted implementations can be considered as the two extreme cases of what happens in practice when a programming language is implemented. In fact, in real language implementations, both elements are almost always present. As far as the interpreted implementation is concerned, we immediately observe that every “real” interpreter operates on an internal representation of a program which is always different from the external one. The translation from the external notation of L to its internal representation is performed using real translation (compilation, in our terminology) from L to an intermediate language. The intermediate language is the one that is interpreted. Analogously, in every compiling implementation, some particularly complex constructs are simulated. For example, some instructions for input/output could be translated into the physical machine’s language but would require a few hundred instructions, so it is preferable to translate them into calls to some appropriate program (or directly to operating system operations), which simulates at runtime (and therefore interprets) the high-level instructions.

18

1 Abstract Machines

Can interpreter and compiler always be implemented? At this point, the reader could ask if the implementation of an interpreter or a compiler will always be possible. Or rather, given the language, L , that we want to implement, how can we be sure that it is possible to implement a particular program L o in language L o which performs the interpretation of all the constructs of L ? IL How, furthermore, can we be sure that it is possible to translate programs of L into programs in L o using a suitable program, CL ,L o ? The precise answer to this question requires notions from computability theory which will be introduced in Chap. 3. For the time being, we can only answer that the existence of the interpreter and compiler is guaranteed, provided that the language, L o, that we are using for the implementation is sufficiently expressive with respect to the language, L , that we want to implement. As we will see, every language in common use, and therefore also our L o, have the same (maximum) expressive power and this coincides with a particular abstract model of computation that we will call Turing Machine. This means that every possible algorithm that can be formulated can be implemented by a program written in L o. Given that the interpreter for L is no more than a particular algorithm that can execute the instructions of L o. L , there is clearly no theoretical difficulty in implementing the interpreter IL As far as the compiler is concerned, assuming that it, too, is to be written in L o, the argument is similar. Given that L is no more expressive than L o, it must be possible to translate programs in L into ones in L o in a way that preserves their meaning. Furthermore, given that, by assumption, L o permits the implementation of any algorithm, it will also permit the implementation of the particular compiling program CL ,L o that implements the translation.

Fig. 1.6 Implementation: the real case with intermediate machine

The real situation for the implementation of a high-level language is therefore that shown in Fig. 1.6. Let us assume, as above, that we have a language L that has to be implemented and assume also that a host machine M oL o exists which has already been constructed. Between the machine ML that we want to implement and

1.2 Implementation of a Language

19

the host machine, there exists a further level characterised by its own language, L i and by its associated abstract machine, M iL i , which we will call, the intermediate language and intermediate machine, respectively. As shown in Fig. 1.6, we have both a compiler CL ,L i which translates L to L i L o which runs on the machine M o and an interpreter IL L o (which simulates the i machine M iL i ). In order to execute a generic program, P L , the program must first be translated by the compiler into an intermediate language program, Pi L i . L o . It should be noted that, in Next, this program is executed by the interpreter IL i the figure, we have written “interpreter or runtime support (RTS)” because it is not L o . In the case in which the always necessary to implement the entire interpreter IL i intermediate language and the host machine language are not too distant, it might be enough to use the host machine’s interpreter, extended by suitable programs, which are referred to as its runtime support, to simulate the intermediate machine. Depending on the distance between the intermediate level and the source or host level, we will have different types of implementation. Summarising this, we can identify the following cases: 1. ML = M iL i : purely interpreted implementation. 2. ML ̸= M iL i ̸= M oL o . (a) If the interpreter of the intermediate machine is substantially different from the interpreter for M oL o , we will say that we have an implementation of an interpretative type. (b) If the interpreter of the intermediate machine is substantially the same as the interpreter for M oL o (of which it extends some of its functionality), we will say that we have a implementation of a compiled type. 3. M iL i = M oL o , we have a purely compiled implementation.

The first and last cases correspond to the limit cases already encountered in the previous section. These are the cases in which the intermediate machines coincide, respectively, with the machine for the language to be implemented and with the host machine. On the other hand, in the case in which the intermediate machine is present, we have an interpreted type of implementation when the interpreter for the intermediate machine is substantially different from the interpreter for M oL o . In this case, L o must be implemented using language L o. The diftherefore, the interpreter IL i ference between this solution and the purely interpreted one lies in the fact that not all constructs of L need be simulated. For some constructs there are directly corresponding ones in the host machine’s language, when they are translated from L to the intermediate language L i, so no simulation is required. Moreover the distance between M iL i and M oL o is such that the constructs for which this happens are few in number and therefore the interpreter for the intermediate machine must have many of its components simulated. In the compiled implementation, on the other hand, the intermediate language is closer to the host machine and the interpreter substantially shares it. In this case, then, the intermediate machine, M iL i , will be implemented using the functionality of M oL o , suitably extended to handle those source language constructs of L

20

1 Abstract Machines

which, when also translated into the intermediate language L i, do not have an immediate equivalent on the host machine. This is the case, for example, in the case of some I/O operations that are, even when compiled, usually simulated by suitable programs written in L o. The set of such programs, which extend the functionality of the host machine and which simulate at runtime some of the functionality of the language L i, and therefore also of the language L , constitute the so-called run-time support for L . As can be gathered from this discussion, the distinction between the intermediate cases is not clear. There exists a whole spectrum of implementation types ranging from that in which everything is simulated to the case in which everything is, instead, translated into the host machine language. What to simulate and what to translate depends a great deal on the language in question and on the available host machine. It is clear that, in principle, one would tend to interpret those language constructs which are furthest from the host machine language and to compile the rest. Furthermore, as usual, compiled solutions are preferred in cases where increased execution efficiency of programs is desired, while the interpreted approach will be increasingly preferred when greater flexibility is required. It should also be noted that the intermediate machine, even if it is always present in principle, is not often actually present. The exceptions are cases of languages which have formally stated definitions of their intermediate machines, together with their associated languages (which is principally done for portability reasons). The compiled implementation of a language on a new hardware platform is a rather big task requiring considerable effort. The interpretive implementation is less demanding but does requires some effort and often poses efficiency problems. Often, it is desired to implement a language on many different platforms, for example when sending programs across a network so that they can be executed on remote machines (as happens with so-called aplets). In this case, it is extremely convenient first to compile the programs to an intermediate language and then implement (interpret) the intermediate language on the various platforms. Clearly, the implementation of the intermediate code is much easier than implementing the source code, given that compilation has already been carried out. This solution to the portability of implementations was adopted for the first time on a large scale by the Pascal language, which was defined together with an intermediate machine (with its own language, P-code) which was designed specifically for this purpose. A similar solution was used by the Java language, whose intermediate machine (called the JVM—Java Virtual Machine) has as its machine language the so-called Java Byte Code. It is now implemented on every type of computer. As the last note, let us emphasise the fact, which should be clear from what we have said so far, that one should not talk about an “interpreted language” or a “compiled language”, because each language can be implemented using either of these techniques. One should, instead, talk of interpretative or compiled implementations of a language.

1.3 Hierarchies of Abstract Machines

21

Fig. 1.7 The three levels of a microprogrammed computer

1.3 Hierarchies of Abstract Machines On the basis of what we have seen, a microprogrammed computer, on which a high-level programming language is implemented, can be represented as shown in Fig. 1.7. Each level implements an abstract machine with its own language and its own functionality. This schema can be extended to an arbitrary number of levels and a hierarchy is thus produced, even if it is not always explicit. This hierarchy is largely used in software design. In other words, hierarchies of abstract machines are often used in which every machine exploits the functionality of the level immediately below and adds new functionality of its own for the level immediately above. There are many examples of hierarchies of this type. For example, there is the simple activity of programming. When we write a program P in a language, L , in essence, we are doing no more than defining a new language, LP (and therefore a new abstract machine) composed of the (new) functionalities that P provides to the user through its interface. Such a program can therefore be used by another program, which will define new functionalities and therefore a new language and so on. It can be noted that, broadly speaking, we can also speak of abstract machines when dealing with a set of commands, which, strictly speaking, do not constitute a real programming language. This is the case with a program, with the functionality of an operating system, or with the functionality of a middleware level in a computer network. In the general case, therefore, we can imagine a hierarchy of machines ML 0 , ML 1 , . . . , ML n . The generic machine, ML i is implemented by exploiting the functionality (that is the language) of the machine immediately below (ML i−1 ). At the same time, ML i provides its own language Li to the machine above ML i+1 , which, by exploiting that language, uses the new functionality that ML i provides with respect to the lower levels. Often, such a hierarchy also has the task of masking lower levels. ML i cannot directly access the resources provided by the machines below it but can only make use of whatever language Li−1 provides. The structuring of a software system in terms of layers of abstract machines is useful for controlling the system’s complexity and, in particular, allows for a degree of independence between the various layers, in the sense that any internal modification to the functionality of a layer does not have (or should not have) any influence on the other layers. For example, if we use a high-level language, L , which uses an operating system’s file-handling mechanisms, any modification to these mechanisms (while the interface remains the same) does not have any impact on programs written in L .

22

1 Abstract Machines

Fig. 1.8 A hierarchy of abstract machines

A canonical example of a hierarchy of this kind in a context that is seemingly distant from programming languages is the hierarchy5 of communications protocols in a network of computers, such as, for example, the ISO/OSI standard. In a context closer to the subject of this book, we can consider the example shown in Fig. 1.8. At the lowest level, we have a hardware computer, implemented using physical electronic devices (at least, at present; in the future, the possibility of biological devices will be something that must be actively considered). Above this level, we could have the level of an abstract, microprogrammed machine. Immediately above (or directly above the hardware if the firmware level is not present), there is the abstract machine provided by the operating system which is implemented by programs written in machine language. Such a machine can be, in turn, seen as a hierarchy of many layers (kernel, memory manager, peripheral manager, file system, commandlanguage interpreter) which implement functionalities that are progressively more remote from the physical machine: starting with the nucleus, which interacts with the hardware and manages process state changes, to the command interpreter (or shell) which allows users to interact with the operating system. In its complexity, therefore, the operating system on one hand extends the functionality of the physical machine, providing functionalities not present on the physical machine (for example, primitives that operate on files) to higher levels. On the other hand, it masks some hardware primitives (for example, primitives for handling I/O) in which the higher levels in the hierarchy have no interest in seeing directly. The abstract machine provided by the operating system forms the host machine on which a highlevel programming language is implemented using the methods that we discussed in previous sections. It normally uses an intermediate machine, which, in the diagram (Fig. 1.8), is the Java Virtual machine and its bytecode language. The level provided by the abstract machine for the high-level language that we have implemented (Java 5 In the literature on networks, one often speaks of a stack rather than, more correctly, of a hierarchy.

1.3 Hierarchies of Abstract Machines

23

Program Transformation and Partial Evaluation In addition to “translation” of programs from one language to another, as is done by a compiler, there are numerous transformation techniques involving only one language that operate upon programs. These techniques are principally defined with the aim of improving performance. Partial evaluation is one of these techniques and consists of evaluating a program against an input so as to produce a program that is specialised with respect to this input and which is more efficient than the original program. For example, assume we have a program P (X, Y ) which, after processing the data X, performs operations on the data in Y depending upon the result of working on X. If the data, X, input to the program are always the same, we can transform this program to P ′ (Y ), where the computations using X have already been performed (prior to runtime) and thereby obtain a faster program. More formally, a partial evaluator for the language L is a program which implements the function: PevalL : (ProgL × D) → ProgL which has the following characteristics. Given a generic program, P , written in L , taking two arguments, the result of partially evaluating P with respect to one of its first input D1 is: PevalL (P , D1 ) = P ′

where the program P ′ (the result of the partial evaluation) accepts a single argument and is such that, for any input data, Y , we have: IL (P , (D1 , Y )) = IL (P ′ , Y ) where IL is the language interpreter.

in this case) is not normally the last level of the hierarchy. At this point, in fact, we could have one or more applications which together provide new services. For example, we can have a “web machine” level in which the functions required to process Web communications (communications protocols, HTML code display, applet running, etc.) are implemented. Above this, we might find the “Web Service” level providing the functions required to make web services interact, both in terms of interaction protocols as well as of the behaviour of the processes involved. At this level, truly new languages can be implemented that define the behaviour of so-called “business processes” based on Web services (an example is the Business Process Execution Language). Finally, at the top level, we find a specific application, in our case electronic commerce, which, while providing highly specific and restricted functionality, can also be seen in terms of a final abstract machine.

24

1 Abstract Machines

1.4 Chapter Summary The chapter has introduced the concepts of abstract machine and the principle methods for implementing a programming language. In particular, we have seen: • The abstract machine: an abstract formalisation for a generic executor of algorithms, formalised in terms of a specific programming language. • The interpreter: an essential component of the abstract machine which characterises its behaviour, relating in operational terms the language of the abstract machine to the embedding physical world. • The machine language: the language of a generic abstract machine. • Different language typologies: characterised by their distance from the physical machine. • The implementation of a language: in its different forms, from purely interpreted to purely compiled; the concept of compiler is particularly important here. • The concept of intermediate language: essential in the real implementation of any language; there are some famous examples (P-code machine for Pascal and the Java Virtual Machine). • Hierarchies of abstract machines: abstract machines can be hierarchically composed and many software systems can be seen in such terms.

1.5 Bibliographic Notes The concept of abstract machine is present in many different contexts, from programming languages to operating systems, even if at times it is used in a much more informal manner than in this chapter. In some cases, it is also called a virtual machine, as for example in [5], which, however, presents an approach similar to that adopted here. The descriptions of hardware machines that we have used can be found in any textbook on computer architecture, for example [6]. The intermediate machine was introduced in the first implementations of Pascal, for example [4]. For more recent uses of intermediate machine for Java implementations, the reader should consult some of the many texts on the JVM, for example, [3]. Finally, as far as compilation is concerned, a classic text is [1], while [2] is a more recent book with a more up-to-date treatment.

1.6 Exercises 1. Give three examples, in different contexts, of abstract machines. 2. Describe the functioning of the interpreter for a generic abstract machine.

References

25

3. Describe the differences between the interpretative and compiled implementations of a programming language, emphasising the advantages and disadvantages. 4. Assume you have available an already-implemented abstract machine, C, how could you use it to implement an abstract machine for another language, L? 5. What are the advantages in using an intermediate machine for the implementation of a language? 6. The first Pascal environments included: • A Pascal compiler, written in Pascal, which produced P-code (code for the intermediate machine); • The same compiler, translated into P-code; • An interpreter for P-code written in Pascal.

To implement the Pascal language in an interpretative way on a new host machine means (manually) translating the P-code interpreter into the language on the host machine. Given such an interpretative implementation, how can one obtain a compiled implementation for the same host machine, minimising the effort required? (Hint: think about a modification to the compiler for Pascal also written in Pascal.) L (X, Y ), written in language L , for a different lan7. Consider an interpreter, IL 1 guage, L 1, where X is the program to be interpreted and Y is its input data. Consider a program P written in L 1. What is obtained by evaluating L PevalL (IL 1, P ) L with respect to P ? (This transformation i.e., from the partial evaluation of IL 1 is known as Futamura’s first projection.)

References 1. A. V. Aho, R. Sethi, and J. D. Ullman. Compilers: Principles, Techniques, and Tools. AddisonWesley, Reading, 1988. 2. A. W. Appel. Modern Compiler Implementation in Java. Cambridge University Press, Cambridge, 1998. This text exists also for C and ML. 3. T. Lindholm and F. Yellin. The Java Virtual Machine Specification, 2nd edition. Sun and Addison-Wesley, Cleveland, 1999. 4. S. Pemberton and M. Daniels. Pascal Implementation: The p4 Compiler and Interpreter. Ellis Horwood, Chichester, 1982. 5. T. Pratt and M. Zelkowitz. Programming Languages: Design and Implementation, 4th edition. Prentice-Hall, New York, 2001. 6. A. Tannenbaum. Structured Computer Organization. Prentice-Hall, New York, 1999.

Chapter 2

How to Describe a Programming Language

A programming language is an artificial formalism in which algorithms can be expressed. For all its artificiality, though, this formalism remains a language. Its study can make good use of the many concepts and tools developed in the last century in linguistics (which studies both natural and artificial languages). Without going into great detail, this chapter poses the problem of what it means to “give” (define or understand) a programming language and which tools can be used in this undertaking.

2.1 Levels of Description In a study which has now become a classic in linguistics, Morris [6] studied the various levels at which a description of a language can occur. He identified three major areas: grammar, semantics and pragmatics. Grammar is that part of the description of the language which answers the question: which phrases are correct? Once the alphabet of a language has been defined as a first step (in the case of natural language, for example, the Latin alphabet of 22 or 26 letters, the Cyrillic alphabet, etc.), the lexical component, which uses this alphabet, identifies the sequence of symbols constituting the words (or tokens) of the language defined. When alphabet and words have been defined, the syntax describes which sequences of words constitute legal phrases. Syntax is therefore a relation between signs. Between all possible sequences of words (over a given alphabet), the syntax chooses a subset of sequences to form phrases of the language proper.1 1 In linguistics, obviously, things are more complicated. In addition to the lexical and the syntactic levels, there is also a morphological level which is distinct from the two previous ones. At the morphological level, the different forms assumed by words (or phrases) as a function of their grammatical function are defined. For example in the lexicon (that is, the dictionary, the thesaurus of the language in question), we find the word “bear” with the associated lexical value given by the image of the animal that everybody knows. At the morphological level, on the other hand, the word is the convertible into the root “bear” and the morpheme “-s” which signals the plural. The natural language’s phonetic aspects are also present but they are of no interest to us here.

M. Gabbrielli, S. Martini, Programming Languages: Principles and Paradigms, Undergraduate Topics in Computer Science, DOI 10.1007/978-1-84882-914-5_2, © Springer-Verlag London Limited 2010

27

28

2 How to Describe a Programming Language

Semantics is that part of the description of the language which seeks to answer the question “what does a correct phrase mean?” Semantics, therefore, attributes a significance to every correct phrase. In the case of natural languages, the process of attribution of meaning can be very complex; in the case of artificial languages the situation is rather simpler. It is not difficult to assume, in this case, that semantics is a relation between signs (correct sentences) and meanings (autonomous entities existing independently of the signs that are used to describe them). For example, the meaning of a certain program could be the mathematical function computed by that program. The semantic description of that language will be constructed using techniques allowing us, when given a program, to fix the function the program computes. It is at the third level that the principal actor makes its appearance on the scene, the person who uses a certain language. Pragmatics is that part of a language description which asks itself “how do we use a meaningful sentence?” Sentences with the same meaning can be used in different ways by different users. Different linguistic contexts can require the use of different sentences; some are more elegant, some are antiquated, or more dialect-based than others. Understanding these linguistic mechanisms is no less important than knowing the syntax and semantics. In the case of programming languages, we can add a fourth level to the three classical ones: the implementation level. Given that the languages that interest us are procedural languages (that is, languages whose correct phrases specify actions), it remains for us to describe “how to execute a correct sentence, in such a way that we respect the semantics”. A knowledge of the semantics is, in general, enough for the language user, but the software designer (and more importantly the language designer) is also interested in the process with which operative phrases implement the state under consideration. It is precisely this which is described by the language implementation. We can give a fairly rudimentary example which we hope will serve our purposes. Let us consider the natural language used to express recipes in cooking. The syntax determines the correct sentences with which a recipe is expressed. The semantics is about explaining “what is” a recipe, independent of its (specific) execution. Pragmatics studies how a cook (“that cook”) interprets the various sentences of the recipe. In the end, the implementation describes the way (where, and with what ingredients) the kitchen recipe transforms into the dish that the semantics prescribes. In the next sections, we analyse the role performed by the four levels when they are applied to programming languages.

2.2 Grammar and Syntax We have already said that the grammar of a language first establishes the alphabet and lexicon. Then by means of a syntax, it defines those sequences of symbols corresponding to well-formed phrases and sentences (or to “sentences” in short). Clearly, at least from the viewpoint of natural language, the definition of the (finite) alphabet is immediate. Even the lexicon can be defined, at least to a first approximation, in

2.2 Grammar and Syntax

29

a simple fashion. We will be content, for the time being, with a finite vocabulary; we can simply list the words of interest to us. This is certainly what happens with natural languages, given that dictionaries are finite volumes!2 How do we describe the syntax? In a natural language, it is the same natural language which is used, in general, to describe its own syntax (classical examples are grammar textbooks for various languages). Also a syntax for a programming language is often described using natural language, particularly for the older languages. Natural language, though, often introduces ambiguity in its syntactic description and, in particular, it is of no use in the process of translating (compiling) a program in a high-level language into another (generally, at a lower level) language. Linguistics, on the other hand, through the work in the 1950s of the American linguist Noam Chomsky, has developed techniques to describe syntactic phenomena in a formal manner. This description uses formalisms designed specifically to limit the ambiguity that is always present in natural language. These techniques, known as generative grammar, are not of much use in describing the syntax of natural languages (which are too complex and highly sophisticated). Instead, they are a fundamental tool for describing the syntax of programming languages (and particularly their compilation, as we will briefly see in Sect. 2.4). Example 2.1 We will describe a simple language. It is the language of palindromic strings, composed of the symbols a and b.3 Let us therefore begin by fixing the alphabet, A = {a, b}. We must now select, from all strings over A (that is finite sequences of elements of A), the palindromic strings. The simplest way to do this is to observe that there is a simple recursive definition of a palindromic string. Indeed, we can say (this is the basis of the induction) that a and b are palindromic strings. If, then, s is any string that we know already to be palindromic, then so are asa and bsb (this is the induction step). It is not difficult to convince ourselves that this definition captures all and only the palindromic strings of odd length over A. It remains to account for even-length strings, such as abba. To include these as well, we add the fact that the empty string (that is the string which contains no symbol from the alphabet) is also a palindromic string to the base case of the inductive definition. Now our definition categorises all and only the palindromic strings over the alphabet A. If a string really is a palindromic string, for example aabaa, or abba, there exists a sequence of applications of the inductive rule just mentioned which will construct it. On the other hand, if a string is not a palindromic string (for example aabab), there is no way to construct it inductively using the rules just introduced. Context-Free Grammars, which we introduce in the next section, are a notation for the concise and precise expression of recursive definitions of strings such as 2 In programming languages, the lexicon can also be formed from an infinite set of words. We will see below how this is possible. 3A

string is palindromic if it is identical to its mirror image. That is, the string is the same when read from left to right or right to left. A famous example in Latin is, ignoring spaces, the riddle “in girum imus nocte et consumimur igni”.

30

2 How to Describe a Programming Language

the one we have just seen. The inductive definition of palindromic strings can be expressed in grammatical form as: P P P P P

→ →a →b → aP a → bP b

In these rules, P stands for “any palindromic string”, while the arrow → is read as “can be”. The first three lines will be immediately recognised as the basis of the inductive definition, while the last two form the induction step.

2.2.1 Context-Free Grammars The example just given is an example of a context-free grammar, a fundamental device for the description of programming languages. We begin by introducing a little notation and terminology. Having fixed a finite (or denumerable) set A, which we call the alphabet, we denote by A∗ the set of all finite strings over A (that is finite length sequences of elements of A; the ∗ operator is called Kleene’s star). Let us immediately observe that, according to the definition, the sequence of length zero also belongs to A∗ —this is the empty string, denoted by ϵ. A formal language over the alphabet A is nothing more than a subset of A∗ . A formal grammar serves to identify a certain subset of strings from all those possible over a given alphabet.4 Definition 2.1 (Context-Free Grammar) A context-free grammar is a quadruple (NT, T , R, S) where: 1. NT is a finite set of symbols (non-terminal symbols, or variables, or syntactic categories). 2. T is a finite set of symbols (terminal symbols). 3. R is a finite set of productions (or rules), each of which is composed of an expression of the form: V →w

where V (the head of the production) is a single non-terminal symbol and w (the body) is a string composed of zero or more terminal or non-terminal symbols (that is w is a string over T ∪ NT). 4 In formal languages, a sequence of terminal symbols which appears in a language is usually called a “word” of the language. We do not use this terminology; instead we speak of strings, to avoid ambiguity with words and phrases of a language (natural or artificial), in the sense in which they are normally understood.

2.2 Grammar and Syntax

31

4. S is an element of NT (the initial symbol). According to this definition, therefore, the grammar in the example shown in Example 2.1 is composed of the quadruple ({P }, {a, b}, R, P ), where R is the set of productions used in the example. Let us observe that, according to the definition, a production can have an empty body, that is, it can be composed of the null symbol, or, more properly, can be formed from the empty string, ϵ. We will see in a later section how a given grammar defines a language over the alphabet formed from its terminal symbols. Let us begin however with an example. Example 2.2 Let us see a simple grammar that describes arithmetic expressions (over the operators +, ∗, −, both unary and binary). The atomic elements of these expressions are simple identifiers formed from finite sequences of the symbols a and b. We define the grammar G = ({E, I }, {a, b, +, ∗, −, (, )}, R, E), where R is the following set of productions: 1. E → I 2. E → E + E 3. E → E ∗ E 4. E → E − E 5. E → −E 6. E → (E) 7. I 8. I 9. I 10. I

→a →b → Ia → Ib

Unlike the grammar in Example 2.1, this one has more than one non-terminal symbol corresponding, in an informal way, to an expression (E) or to an identifier (I ). Note, once more, how the productions are a synthetic way to express recursive definitions. In this case, we are dealing with two definitions (which have been graphically separated), of which one (the one for E) uses in its base case the non-terminal symbol inductively defined using the other recursive definition. BNF In the context of programming languages, context-free grammars were used for the first time in the definition of the language Algol60. In the report that introduced Algol60, the grammar that defines the language is described using a notation that is slightly different from the one we have just introduced. This notation, (considered, among other things, to be usable with a reduced character set, that does not include arrow, cursives, upper case, etc.) goes under the name of Backus Naur normal form (BNF), named after two authoritative members of the Algol committee (John Backus who had previously directed the Fortran project and had written the compiler for it—the first high-level language, and Peter Naur). In BNF:

32

2 How to Describe a Programming Language

Fig. 2.1 A derivation of the string ab ∗ (a + b)

E ⇒3 E ∗ E ⇒1 I ∗ E ⇒10 I b ∗ E ⇒7 ab ∗ E ⇒6 ab ∗ (E) ⇒2 ab ∗ (E + E) ⇒1 ab ∗ (I + E) ⇒7 ab ∗ (a + E) ⇒1 ab ∗ (a + I ) ⇒8 ab ∗ (a + b)

• The arrow “→” is replaced by “::=”. • The non-terminal symbols are written between angle brackets (for example ⟨Exp⟩ and ⟨Ide⟩ could be the two non-terminal symbols of the grammar of Example 2.2). • Productions with the same head are grouped into a single block using vertical bar (“|”) to separate the productions. In Example 2.2, the productions for E could therefore be expressed as follows: ⟨E⟩ ::= ⟨I ⟩ | ⟨E⟩ + ⟨E⟩ | ⟨E⟩ ∗ ⟨E⟩ | ⟨E⟩ − ⟨E⟩ | −⟨E⟩ | (⟨E⟩). Moreover, some notations mix symbols (for example, use of the vertical bar, the arrow and non-terminal symbols written in italic upper case). Derivations and languages A grammar inductively defines a set of strings. We can make explicit the operative aspect of this inductive definition using the concept of derivation. Example 2.3 We can ensure that the string ab ∗ (a + b) is correct according to the grammar of Example 2.2, reading the productions as “rewriting rules”, and by repeatedly applying them. We use a bigger arrow (“⇒”) to denote the operation of string rewriting. We can then proceed as follows. We start with the initial symbol, E, and rewrite it using a production (which we are allowed to select). Let us, for example, use production (3), and we obtain the rewriting E ⇒ E ∗ E. Now we concentrate on the right-hand side of this production. We have two E’s that can be rewritten (expanded) independently of each other. Let us take the one on the left and apply production (1) to obtain E ∗ E ⇒ I ∗ E. We can now choose whether we expand I or E (or the other way round). Figure 2.1 shows the rewriting that we have just started, developed until the string ab ∗ (a + b) has been derived. The production used is represented by each ⇒s’ subscript. We can capitalise on this example in the following definition. Definition 2.2 (Derivation) Having fixed a grammar, G = (NT, T , R, S), and assigned two strings, v and w over NT ∪ T , we say that w is immediately derived

2.2 Grammar and Syntax Fig. 2.2 A derivation tree for the string ab ∗ (a + b)

33

E ⇒3 E ∗ E ⇒6 E ∗ (E) ⇒2 E ∗ (E + E) ⇒1 E ∗ (E + I ) ⇒8 E ∗ (E + b) ⇒1 E ∗ (I + b) ⇒7 E ∗ (a + b) ⇒1 I ∗ (a + b) ⇒10 I b ∗ (a + b) ⇒7 ab ∗ (a + b)

from v (or: v is rewritten in a single step into w), if w is obtained from v by substituting the body of a production of R whose head is V for a non-terminal symbol, V , in v. In this case, we will write v ⇒ w. We say that w is derived from v (or: v is rewritten to w) and we write v ⇒∗ w, if there exists a finite (possibly empty) sequence of immediate derivations v ⇒ w0 ⇒ w1 ⇒ · · · ⇒ w. Using the notation just introduced, and using the grammar for expressions that we have used so far we can write, for example E ∗ E ⇒∗ ab ∗ (a + I ). Particularly interesting are those derivations where on the left of the ⇒∗ symbol there is the grammar’s initial symbol and on the right is a string solely composed of terminal symbols. In a certain sense, these are maximal derivations which cannot be extended (by rewriting a non-terminal) either on the left or right. Following the intuition that has led us to the introduction of grammars, these derivations are the ones that give us the correct strings as far as the grammar is concerned. Definition 2.3 (Generated Language) The language generated by a grammar G = (NT, T , R, S) is the set L (G) = {w ∈ T ∗ | S ⇒∗ w}. Note that this definition, in accordance with everything we said at the start of Sect. 2.2.1, defines precisely a language over T ∗ . Derivation Trees The derivation of a string is a sequential process. In it, there are steps that must be performed in a certain order. For example, in Fig. 2.1, it is clear that the first ⇒10 must follow the first ⇒3 because production (10) rewrites the nonterminal symbol I which does not exist in the initial string (which is composed of only the initial symbol E) which is introduced by production (3). But there are some steps whose order could be exchanged. In the derivation in Fig. 2.1, for example, each time that it is necessary to rewrite a non-terminal symbol, the leftmost is always chosen. We could imagine, on the other hand, concentrating first on the rightmost non-terminal symbol, thereby obtaining the derivation shown in Fig. 2.2. The two derivations that we have given for the string ab ∗ (a + b) are, in a highly intuitive way, equivalent. Both reconstruct the structure of the string in the same way (in terms of non-terminal and terminal strings), while they differ only in the

34

2 How to Describe a Programming Language

Fig. 2.3 A derivation tree for the string ab ∗ (a + b)

order with which the productions are applied. This fact is made explicit in Fig. 2.3 which represents the derivation of the string ab ∗ (a + b) in the form of a tree. Definition 2.4 Given a grammar, G = (NT, T , R, S), a derivation tree (or parse tree) is an ordered tree in which: Each node is labelled with a symbol in NT ∪ T ∪ {ϵ}. The root is labelled with S. Each interior node is labelled with a symbol in NT. If a certain node has the label A ∈ NT and its children are m1 , . . . , mk labelled respectively with X1 , . . . , Xk , where Xi ∈ NT ∪ T for all i ∈ [1, k], then A → X1 . . . Xk is a production of R. 5. If a node has label ϵ, then that node is the unique child. If A is its parent, A → ϵ is a production in R.

1. 2. 3. 4.

It is easy to see that, a derivation tree can be obtained from any derivation. It is enough to start at the root (labelled with the initial symbol) and successively adding a level of children corresponding to the production used during the derivation. By applying this procedure to the derivation of Fig. 2.1, the derivation tree of Fig. 2.3 is obtained. Let us now apply this construction procedure to the derivation tree in Fig. 2.2. Again, the tree in Fig. 2.3 is obtained. The two derivations result in the same tree, and this fact corresponds to the intuition that the two derivations were substantially equivalent. Derivation trees are one of the most important techniques in the analysis of programming language syntax. The structure of the derivation tree indeed expresses, by means of its subtrees, the logical structure that the grammar assigns to the string.

2.2 Grammar and Syntax

35

Trees The concept of tree is of considerable importance in Computer Science and is also used a great deal in common language (think of a genealogical tree, for example). A tree is an information structure that can be defined in different ways and that exists in different “spaces”. For our purposes, we are interested only in ordered, rooted trees (or simply trees) which we can define as follows. A (rooted, ordered) tree is a finite set of elements called nodes, such that if it is not empty, a particular node is called the root and the remaining nodes, if they exist, are partitioned between the elements of an (ordered) n-tuple ⟨S1 , S2 , . . . , Sn ⟩, n ≥ 0, where each Si , i ∈ [1, N] is a tree. Intuitively, therefore, a tree allows us to group nodes into levels where, at level 0, we have the root, at level 1 we have the roots of the trees S1 , S2 , . . . , Sn and so on. Another (equivalent) definition of tree is often used. It is probably more significant for the reader who is familiar with genealogical trees, botanical classifications, taxonomies, etc. According to this definition, a tree is a particular case of a graph: a (rooted, ordered) tree is therefore a pair T = (N, A), where N is a finite set of nodes and A is a set of ordered pairs of nodes, called arcs, such that: • The number of arcs is equal to one less than the number of nodes. • T is connected, that is, for each pair of nodes, n, m ∈ N , there exists a sequence of distinct nodes n0 , n1 , . . . , nk such that n0 = n and nk = m and the pair (ni , ni+1 ) is an arc, for i = 0, . . . , k − 1. • A (unique) node, r, is said to be the root and the nodes are ordered by level according to the following inductive definition. The root is at level 0; if a node n is at level i, and there exists the arc (n, m) ∈ A then node m is at level i + 1. • Given a node, n, the nodes m such that there exists an arc (n, m) ∈ A are said to be the children of n (and n is said to be their parent); for every node n ∈ N , a total order is established on the set of all the children of n. Using a curious mix of botanical, mathematical and “familiar” terms, nodes with the same parent are said to be siblings while nodes without children are said to be leaves. The root is the only node without a parent. For example, the tree in Fig. 2.4 corresponds to the following derivation: E ⇒2 E + E ⇒3 E ∗ E + E ⇒1 I ∗ E + E ⇒7 a ∗ E + E ⇒1 a ∗ I + E ⇒8 a ∗ b + E ⇒1 a ∗ b + I ⇒7 a ∗ b + a

36

2 How to Describe a Programming Language

Fig. 2.4 A derivation tree for the string a ∗ b + a

Fig. 2.5 Another derivation tree for the string a ∗ b + a

In the tree in Fig. 2.4, we can see that the subexpression a ∗ b appears as a left child of a sum. This expresses the fact that the string a ∗ b + a must be interpreted as “first multiply a by b and add the result to a”, given that in order to compute the sum, the operand present in the left subtree is needed. Ambiguity Let us consider the following derivation (again using the grammar of Example 2.2): E ⇒3 E ∗ E ⇒1 I ∗ E ⇒7 a ∗ E ⇒2 a ∗ E + E ⇒1 a ∗ I + E ⇒8 a ∗ b + E ⇒1 a ∗ b + I ⇒7 a ∗ b + a

If we construct the corresponding derivation tree, we obtain the tree in Fig. 2.5. Comparing the trees in Figs. 2.4 and 2.5, it can be seen that we have two different trees producing the same string. Reading the leaves of the two trees from left to right, in both cases, we obtain the string a ∗ b + a. Let us observe, however, that the two trees are radically different. The second assigns a structure to the same string that is quite different (and therefore reveals a different precedence implicit in the arithmetic operators). If we want to use derivation trees to describe the logical

2.2 Grammar and Syntax

37

structure of a string, we are in a bad position. The grammar of Example 2.2 is incapable of assigning a unique structure to the string in question. According to how the derivation is constructed, the precedence of the two arithmetic operators differs. Let us now see a formal definition of these concepts. First, let us be clear about what it means to read or visit the leaves of a tree “from left to right”. Visiting a tree consists of following a path through the tree’s nodes so that each node is visited exactly once. There are different ways to visit nodes (depth-, breadth-first and symmetric), which, when applied to the same tree, produce different sequences of nodes. If only the leaves are considered, however, each and every one of these methods produces the same result for which we can use the following definitions: Definition 2.5 Let T = (N, A), be a non-empty, ordered tree with root r. The result of the left-to-right traversal of T is the sequence of nodes (leaves) obtained by the following recursive definition: • If r has no children, the result of the traversal is r. • If r has k children, m1 , . . . , mk , let T1 , . . . , Tk be the subtrees of T such that Ti has mi as its root (Ti therefore contains mi and all of that part of T which is underneath this node). The result of the traversal is the sequence of nodes obtained by visiting T1 to Tk in turn, from left to right. A this point, we can say what it means for a string to admit a derivation tree. Definition 2.6 We say that a string of characters admits a derivation tree T if it is the result of a left-to-right traversal of T . Finally, we can give the definition that interests us. Definition 2.7 (Ambiguity) A grammar, G, is ambiguous if there exists at least one string of L (G) which admits more than one derivation tree. We remark that ambiguity comes not from the existence of many derivations for the same string (a common and innocuous property) but from the fact that (at least) one string has more than one derivation tree. An ambiguous grammar is useless as description of a programming language because it cannot be used to translate (compile) a program in a unique fashion. Fortunately, given an ambiguous grammar it is often possible to transform it into another, unambiguous, grammar that generates the same language.5 Techniques for grammar disambiguation are outside the scope of this book. By way of example, Fig. 2.6 shows an unambiguous grammar whose generated language coincides with the one in Example 2.2. 5 There exist pathological cases of languages which are generated only by ambiguous grammars. These languages have no relevance to programming languages.

38 Fig. 2.6 An unambiguous grammar for the language of expressions

2 How to Describe a Programming Language

G′ = ({E, T , A, I }, {a, b, +, ∗, −, (, )}, R ′ , E) E →T |T +E |T −E T →A|A∗T A → I | −A | (E) I → a | b | Ia | Ib

We have a grammar which interprets the structure of an expression according to the usual concept of arithmetic operator precedence. Unary minus (“-”) has the highest precedence, followed by ∗, followed in their turn by + and binary − (which have the same precedence). The grammar interprets, then, a sequence of operators at the same level of precedence by association to the right. For example, the string a + b + a will be assigned the same structure as the string a + (b + a). The absence of ambiguity is paid for by increased complexity. There are more non-terminals and the intuitive interpretation of the grammar is therefore more difficult. The need to provide unambiguous grammars explains the contortions that appear in the definitions of some programming languages. For example, Fig. 2.7 shows an extract of the official grammar for Java’s conditional command (its if) (the nonterminal symbols are printed in italic, while the terminal symbols in this extract are if, else and brackets). This grammar is interesting for two reasons. First, note that what are formally considered single symbols (terminal or non-terminal) in context-free grammars are here represented by words composed of a number of characters. For example, if represents a single terminal symbol and, analogously, IfThenElseStatement represents a non-terminal symbol. This happens because, in the definition of a programming language, it is preferential to use meaningful words (if, then, else) which can, up to certain limits, suggest an intuitive meaning, rather than symbols which would be harder to understand by the language user. In other words, as we will better see in the next chapters, that the use of (meaningful) symbolic names definitely makes programming easier. Analogously, for non-terminal symbols, they make the grammar easier to understand. It is definitely better to use names such as Statement rather than single symbols. The second interesting aspect of the grammar is its complex nature. This complexity is necessary to resolve the ambiguity of strings (programs) such as the one exemplified by the following skeleton program: if (expression1) if (expression2) command1; else command2;

Java, like a great many other programming languages allows conditional commands both with an else branch and without it. When an if command without else is combined with an if with an else branch (as in the case of the program appearing above), it is necessary to determine which of the two ifs is the owner of the single else. The grammar in Fig. 2.7 is an unambiguous one which makes

2.3 Contextual Syntactic Constraints

39

Statement ::= . . . | IfThenStatement | IfThenElseStatement | StatementWithoutTrailingSubstatement StatementWithoutTrailingSubstatement ::= . . . | Block | EmptyStatement | ReturnStatement StatementNoShortIf ::= . . . | StatementWithoutTrailingSubstatement | IfThenElseStatementNoShortIf IfThenStatement ::= if ( Expression ) Statement IfThenElseStatement ::= if ( Expression ) StatementNoShortIf else Statement IfThenElseStatementNoShortIf ::= if ( Expression ) StatementNoShortIf else StatementNoShortIf Fig. 2.7 Grammar for Java conditional commands

“an else clause belong to the innermost if to which it might possibly belong” (from the Java definition [3]). In simple words, the else is paired with the second if (the one which tests expression2). Intuitively, this happens because, once an if command with an else is introduced by use of the non-terminal symbol IfThenElseStatement, the command in the then branch will be unable to hold an if command without an else, as can be seen by inspection of the rules which define the non-terminal symbol StatementNoShortIf.

2.3 Contextual Syntactic Constraints The syntactic correctness of a phrase of a programming language sometimes depends on the context in which that phrase occurs. Let us consider, for example, the assignment I = R+3;. Assuming that the productions in the grammar that are used permit the correct derivation of this string, it might be, though, incorrect at the exact point in the program at which it occurs. For example, if the language requires the declaration of variables, it is necessary for programs to contain the declarations of I and R before the assignment. If, then, the language is typed, it would not accept the assignment if the type of the expression R+3 is not compatible6 with that of the variable I. Strings that are correct with respect to the grammar, therefore, can be legal only in a given context. There are many examples of these contextual syntactic constraints: • An identifier must be declared before use (Pascal, Java). • The number of actual parameters to a function must be the same as the formal parameters (C, Pascal, Java, etc.). 6 All these concepts will be introduced below. For now, an intuitive understanding of these concepts will suffice.

40

2 How to Describe a Programming Language

• In the case of assignment, the type of an expression must be compatible with that of the variable to which it is assigned (C, Pascal, Java, etc.). • Assignments to the control variable of a for loop are not permitted (Pascal). • Before using a variable, there must have been an assignment to it (Java). • A method can be redefined (overridden) only by a method with the same signature (Java) or with a compatible signature (Java5). • ... These are, to be sure, syntactic constraints. However, their contextual nature makes it impossible to describe them using a context-free grammar (the name of this class of grammars was chosen purpose). A book on formal languages is required to go into detail on these issues; here, it suffices to note that there exist other types of grammar, called contextual grammars.7 These grammars permit the description of cases such as this. These grammars are difficult to write, to process and, above all, there are no automatic techniques for efficient generation of translators, such as exist, on the other hand, for context-free grammars. This suggests, therefore, that use of grammars should be limited to the non-contextual description of syntax and then to express the additional contextual constraints using natural language or using formal techniques such as transition systems (which we will see in Sect. 2.5 when we consider semantics). The term static semantic constraint is used in programming language jargon to denote the contextual constraints that appear in the syntactic aspects of a language. In the jargon, “syntax” in general means “describable using a context-free grammar”, “static semantics” means “describable with verifiable contextual constraints on a static basis using the program text”, while “dynamic semantics” (or simply “semantics”) refers to everything that happens when a program is executed. The distinction between context-free and context-dependent syntax (that is, static semantics) is established precisely by the expressive power of context-free grammars. The distinction between syntax and semantics is not always clear. Some cases are clear. Let us assume, for example, that we have a language whose definition establishes that should a division by 0 happen during execution, the abstract machine for the language must report it with an explicit error. This is clearly a dynamic semantic constraint. But let us assume, now, that the definition of another language is specified as follows: A program is syntactically incorrect when a division by 0 can happen.

The program in Fig. 2.8 would be syntactically incorrect in this hypothetical language because there exists a sequence of executions (those in which the read command assigns the value 0 to A) which causes division by zero. Does the constraint that we have stated above (which certainly cannot be expressed in a free grammar) belong to static or dynamic semantics? It is clear that it refers to a dynamic event 7 In extreme synthesis, in a contextual grammar, a production can take the form (which is more general than in a context-free grammar) uAv → uwv, where u, v and w are strings over T ∪ NT. Fundamental to this production, the non-terminal symbol A can be rewritten to w only if it appears in a certain context (the one described by u and v).

2.4 Compilers Fig. 2.8 A program that can cause a division by 0

41 int A, B; read(A); B = 10/A;

Fig. 2.9 An abstract syntax tree

(division by zero) but the constraint, to be meaningful (that is, that it really does exclude some programs) would have to be detected statically (as we have done for the simple program given above). A person can decide that it is syntactically incorrect without executing it but only from looking at the code and reasoning about it). More important than its classification, is understanding whether we have a verifiable constraint or not. Otherwise stated, is it really possible to implement an abstract machine for such a language, or does the very nature of the constraint imply that there can exist no abstract machine which is able to check it in a static fashion for an arbitrary program? These are questions that we cannot immediately answer, even though they are very important, because they concern what we can, and cannot, do with an abstract machine. We will concern ourselves with these questions in the next chapter (Chap. 3).

2.4 Compilers The moment has arrived at which to see in outline how the syntactic description of a language can be used automatically to translate a program. We know from Chap. 1 that such an automatic translator is called a compiler, whose general logical structure is shown in Fig. 2.10. It is characterised by a cascaded series of phases. The various phases, starting with a string representing the program in the source language, generate various internal intermediate representations until a string in the object language is generated. Note that, as seen in the previous chapter, in this context, “object language” does not necessarily equate to “machine code” or to “lowlevel language”. It is merely a language towards which the translation is directed. In what follows, we briefly describe the different phases of compilation. We do not pretend to explain how to construct a compiler (see [1]), but just to fix some ideas useful for our study of programming languages. Lexical analysis The aim of lexical analysis is to read the symbols (characters) forming the program sequentially from the input and to group these symbols into

42

2 How to Describe a Programming Language

Fig. 2.10 Organisation of a compiler

meaningful logical units, which we call tokens, (which are analogous, for our programming language, to the words in the dictionary of a natural language). For example, the lexical analyser of C or Java, when presented with the string x = 1 + foo++; will produce 7 tokens: the identifier x, the assignment operator =, the number 1, the addition operator +, the identifier foo, the auto increment operator ++ and finally the command termination token ;. Particularly important tokens are the reserved words of the language (such as for, if, else, etc.), operators, open and close brackets (such as { and } in C or Java, but also those such as begin and end in Pascal). Lexical analysis (or scanning) is a very simple operation which scans the input text of the source program from left to right, taking a single pass to recognise tokens. No check is yet made on the sequence of tokens such as, for example, checking that brackets are correctly balanced. As discussed in detail in the box, the technical tool used for lexical analysis is a particular class of generative grammars (regular grammars). The use of a grammar to describe the elements of the lexicon is due both to the necessity of efficiently recognising these elements, and to

2.4 Compilers

43

Abstract and Concrete Syntax The grammar of a programming language defines the language as a set of strings. This set of strings corresponds in a natural way to the set of their derivation trees. These trees are much more interesting than the strings. First, they abstract from the specific lexical characteristic of the tokens. It can also happen that lexically different structures can result in the same tree. The tree depicted in Fig. 2.9 could correspond to the Pascal string: if A=0 then X:=0 else X:=1

or to the Java string: if (A==0) X=0; else X=1;

As we have already repeatedly observed, derivation trees are interesting because they express the canonical structure that can be assigned to the string. Not all derivation trees correspond to legal programs. We know that static semantic analysis has the task of selecting those trees satisfying the contextual constraints of the language. The set of trees resulting from this process constitutes the abstract syntax of language. This is a much more convenient way of thinking of a language if we are interested in its manipulation (and not merely in writing correct programs in it).

the fact that, unlike the case of natural language lexicons, lexicons for programming languages can be formed from an infinite set of words and therefore a simple list, so the one used in a normal dictionary is inadequate (think, for example, of the possibility of defining identifiers as sequences of characters of arbitrary length starting with a particular letter). Syntactic analysis Once the list of tokens has been constructed, the syntactic analyser (or parser) seeks to construct a derivation tree for this list. This is, clearly, a derivation tree in the grammar of the language. Each leaf of this tree must correspond to a token from the list obtained by the scanner. Moreover, these leaves, read from left to right, must form a correct phrase (or a sequence of terminal symbols) in the language. We already know that such trees represent the logical structure of the program which will be employed by the successive phases of compilation. It can happen that the parser is unable to construct a derivation tree. This happens when the input string is not correct with reference to the language’s grammar. In such a case, the parser reports the errors it has encountered and compilation is aborted. In reality, lexical and syntactic analysis are interleaved in a more direct fashion than appears from these notes (in particular, the two phases are not sequential but the scanner produces a token for each invocation of the parser); more details can be obtained from one of the many texts on compilers.

44

2 How to Describe a Programming Language

Regular Grammars The difference between lexical and syntactic analysis can be made precise using a formal classification of grammars. If a grammar has all productions of the form A → bB (or in the form A → Bb), where A and B are non-terminal symbols (B can also be absent or coincide with A) and b is a single terminal symbol, the grammar is said to be regular. In Example 2.2, the (sub-) grammar based on the non-terminal symbol I is a regular grammar (while the subgrammar for E is not). The expressive power of regular grammars is highly limited. In particular, using a regular grammar, it is not possible to “count” an arbitrary number of characters. As a consequence, it is not possible to express the balancing of syntactic structures such as brackets using a regular grammar. Technically, lexical analysis is the first phase of translation which checks that the input string can be decomposed into tokens, each of which is described by a regular grammar (in Example 2.2, lexical analysis would have recognised the sequences of a and b as instances of the non-terminal symbol I ). Once the sequence of tokens has been obtained, syntactic analysis takes place using a properly context-free grammar which uses the tokens produced by the preceding lexical analysis as its terminal symbols.

Semantic analysis The derivation tree (which represents the syntactic correctness of the input string) is subjected to checks of the language’s various context-based constraints. As we have seen, it is at this stage that declarations, types, number of function parameters, etc., are processed. As these checks are performed, the derivation tree is augmented with the information derived from them and new structures are generated. By way of an example, every token that corresponds to a variable identifier will be associated with its type, the place of declaration and other useful information (for example its scope, see Chap. 4). To avoid the useless duplication of this information, it is, in general, collected into structures external to the derivation tree. Among these structures, the one in which information about identifiers is collected is called the symbol table. The symbol table plays an essential role in successive phases. At the cost of boring the reader, so that we do not confuse it with what we call semantics in Sect. 2.5, let us note that the term semantic analysis is an historical relic and that it is concerned with context-based syntactic constraints. Generation of intermediate forms An appropriate traversal of the augmented derivation tree allows an initial phase of code generation. It is not yet possible to generate code in the object language, given that there are many optimisations left to do and they are independent of the specific object language. Moreover, a compiler is often implemented to generate code for a whole series of object languages (for example, machine code for different architectures), not just one. It is useful, therefore, to concentrate all choices relating to a specific language in a single phase and

2.5 Semantics

45

to generate code to an intermediate form, which is designed to be independent of both the source and the object languages. Code optimisation The code obtained from the preceding phases by repeatedly traversing the derivation tree is fairly inefficient. There are many optimisations that can be made before generating object code. Typical operations that can be performed are: • Removal of useless code (dead code removal). That is, removal of pieces of code that can never be executed because there is no execution sequence that can reach them. • In-line expansion of function calls. Some function (procedure) calls can be substituted by the body of the associated function, making execution faster. It also makes other optimisations possible. • Subexpression factorisation. Some programs compute the same value more than once. If, and when, this fact is discovered by the compiler, the value of the common subexpression can be calculated once only and then stored. • Loop optimisations. Iterations are the places where the biggest optimisations can be performed. Among these, the most common consists of removing from inside a loop the computation of subexpressions whose value remains constant during different iterations. Code generation Starting with optimised intermediate form, the final object code is generated. There follows, in general, a last phase of optimisation which depends upon the specific characteristics of the object language. In a compiler that generates machine code, an important part of this last phase is register assignment (decisions as to which variables should be stored in which processor registers). This is a choice of enormous importance for the efficiency of the final program.

2.5 Semantics As is intuitively to be expected, the description of the semantics of a programming language is somewhat more complex than its syntactic description. This complexity is due both to technical problems, as well to the need to mediate between two opposing issues: the need for exactness as well as for flexibility. As far as exactness is concerned, a precise and unambiguous description is required of what must be expected from every syntactically correct construct so that every user knows a priori (that is before program execution), and in a manner independent of the architecture, what will happen at runtime. This search for exactness, however, must not preclude different implementations of the same language, all of which are correct with respect to the semantics. The semantic specification must therefore also be flexible, that is, it must not anticipate choices that are to be made when the language is implemented (and which therefore do not play a part in the definition of the language itself). It would not be difficult to achieve exactness at the expense of flexibility. It is enough to give the semantics of a language using a specific compiler on a specific

46

2 How to Describe a Programming Language

architecture. The official meaning of a program is given by its execution on this architecture after translation using that compiler. Apart form the difficulty of speaking in general about the semantics of the language’s constructs, this solution has no flexibility. Although we have constructed what we claim to be a semantics, there exists only one implementation (the official one) and all the other implementations are completely equivalent. But to what level of detail is the canonical implementation normative? Is the computation time of a particular program part of its definition? Is the reporting of errors? How can typically architecture-dependent input/output commands be ported to a different architecture? When the implementation technology of the physical machine changes, how is the semantics, which we have incautiously defined in terms of a specific machine, affected? One of the difficulties of semantic definition is really that of finding the happy medium between exactness and flexibility, in such a way as to remove ambiguity, still leaving room for implementation. This situation suggests using formal methods to describe the semantics. Methods of this kind have existed for a long time for the artificial languages of mathematical logic and they have been adapted by computer scientists for their own ends. Yet, some semantic phenomena make formal description complex and not easily usable by anyone who does not have the appropriate skills. It is for this reason that the majority of official programming language definitions use natural language for their semantic description. This does not detract from the fact that formal methods for semantics are very often used in the preparatory phases of the design of a programming language, or to describe some of its particular characteristics, where it is paramount to avoid ambiguity at the cost of simplicity. Formal methods for semantics divide into two main families: denotational and operational semantics.8 Denotational semantics is the application to programming languages of techniques developed for the semantics of logico-mathematical languages. The meaning of a program is given by a function which expresses the input/output behaviour of the program itself. The domain and codomain of this function are suitable mathematical structures, such as the environment and the memory (store), that are internal to the language. Refined mathematical techniques (continuity, fixed points, etc.) allow the appropriate treatment of phenomena such as iteration and recursion (see [8]). In the operational approach, on the other hand, there are no external entities (for example, functions) associated with language constructs. Using appropriate methods, an operational semantics specifies the behaviour of the abstract machine. That is, it formally defines the interpreter, making reference to an abstract formalism at a much lower level. The various operational techniques differ (sometimes profoundly) in their choice of formalism; some semantics use formal automata, others use systems of logico-mathematical rules, yet others prefer transition systems to specify the state transformations induced by a program. 8 For completeness, we should also talk about algebraic and axiomatic semantics, but simplicity and conciseness require us to ignore them.

2.5 Semantics

47

Num ::= 1 | 2 | 3 | . . . Var ::= X1 | X2 | X3 | . . . AExp ::= Num | Var | (AExp + AExp) | (AExp − AExp) BExp ::= tt | ff | (AExp == AExp) | ¬BExp | (BExp ∧ BExp) Com ::= skip | Var := AExp | Com; Com | if BExp then Com else Com | while BExp do Com Fig. 2.11 Syntax of a simple imperative language

This is not a book in which an exhaustive treatment of these semantic techniques can be given. We content ourselves with a simple example of techniques based on transition systems to give a semantics for a rudimentary imperative language. This technique, called SOS (Structured Operational Semantics, [7]), is highly versatile and has been effectively used in giving the semantics to some languages including Standard ML (an influential functional language). Figure 2.11 shows the grammar of a simple language. For reasons of readability (and so that we can obtain a concise semantics), we have a grammar with infinite productions for the Num and Var non-terminal symbols. The explicit presence of brackets around each binary operator application eliminates possible problems of ambiguity. We need to introduce some notation. We will use n to denote an arbitrary Num (numeric constant); using X, we will denote an arbitrary Var (variable). We write a for an arbitrary AExp (arithmetic expression). We use b to denote an arbitrary BExp (boolean expression, where tt and ff denote the values true and false, respectively). We write c for arbitrary Comm (commands). We use, when needed, subscripts to distinguish between objects of the same syntactic category (for example, we will write a1 , a2 , etc., for AExps). State The semantics of a command in our language uses a simple memory model which stores values of Var. In this model, a state is a finite sequence of pairs of the form (X, n) which we can read as “in the current state, the variable X has the value n” (in our little language, the value will always be an integer but we can easily imagine more complex situations). Given a command c (that is a derivation tree that is correct according to the grammar in Fig. 2.11), its reference state is given by a sequence of pairs which includes all Vars which are named in c. We denote an arbitrary state by σ or τ , with or without subscripts. We need to define some operations on states: modification of an existing state and the retrieval of a variable’s value in the current state. To this end, given a state, σ , a Var X and a value v, we write σ [X ← v] to denote a new state that is the same as σ but differs from it by associating X with the value v (and thereby losing any previous association to X). Given a state, σ , and a variable, X, we write σ (X) for the value that σ associates with X; this value is undefined if X does not appear in the domain of σ (σ is therefore a partial function).

48

2 How to Describe a Programming Language

Example 2.4 Let us fix σ = [(X, 3), (Y, 5)], we have σ [X ← 7] = [(X, 7), (Y, 5)]. We also have σ (Y ) = 5 and σ [X ← 7](X) = 7; σ (W ) is undefined. Transitions Structured operational semantics can be seen as an elegant way of defining the functioning of an abstract machine without going into any details about its implementation.9 This functioning is expressed in terms of the elementary computational steps of the abstract machine. The formal way in which structured operational semantics defines the meaning of a program, c, is in terms of a transition which expresses a step in the transformation (of the state and/or of the program itself) induced by the execution of the command. The simplest form of transition is: ⟨c, σ ⟩ → τ,

where c is a command, σ the starting state and τ the terminal state. The interpretation that we give to this notation is that if we start the execution of c in the state σ , the execution terminates (in a single step) with state τ . For example, the transition which defines the skip command is ⟨skip, σ ⟩ → σ. It can be seen that we have a command that does nothing. Starting in any state, σ , skip terminates leaving the state unchanged. In more complex cases, a terminal situation will be reached not in a single large step, but rather in many little steps which progressively transform the state (starting with σ ); the command, c, is progressively executed a part at a time until the whole has been “consumed”. These little steps are expressed by transitions of the form: ⟨c, σ ⟩ → ⟨c′ , σ ′ ⟩. For example, one of the transitions which define the conditional command will be: ⟨if tt then c1 else c2 , σ ⟩ → ⟨c1 , σ ⟩, This means that if the boolean condition is true, the command in the then branch must be executed. Some transitions, finally, are conditional: if some command, c1 , has a transition, then the command c has another transition. Conditional transitions take the form of a rule, expressed as a fraction: ⟨c2 , σ2 ⟩ → ⟨c2′ , σ2′ ⟩ ⟨c1 , σ1 ⟩ → ⟨c1′ , σ1′ ⟩ . ⟨c, σ ⟩ → ⟨c′ , σ ′ ⟩ We read this rule in the following way. If the command, c1 , starting in state σ1 , can perform a computational step that transforms itself into command c1′ in state 9 Using terminology which we will use again in the final chapters of this book, we can say that it is a declarative description of the language’s abstract machine.

2.5 Semantics

49

⟨X, σ ⟩ → ⟨σ (X), σ ⟩ ⟨(n + m), σ ⟩ → ⟨p, σ ⟩ where p = n + m

⟨(n − m), σ ⟩ → ⟨p, σ ⟩ where p = n − m e n ≥ m

⟨a2 , σ ⟩ → ⟨a ′′ , σ ⟩ ⟨a1 , σ ⟩ → ⟨a ′ , σ ⟩ ⟨(a1 + a2 ), σ ⟩ → ⟨(a ′ + a2 ), σ ⟩ ⟨(a1 + a2 ), σ ⟩ → ⟨(a1 + a ′′ ), σ ⟩ ⟨a2 , σ ⟩ → ⟨a ′′ , σ ⟩ ⟨a1 , σ ⟩ → ⟨a ′ , σ ⟩ ⟨(a1 − a2 ), σ ⟩ → ⟨(a ′ − a2 ), σ ⟩ ⟨(a1 − a2 ), σ ⟩ → ⟨(a1 − a ′′ ), σ ⟩ Fig. 2.12 Semantics of arithmetic expressions

σ1′ , and if the command c2 , starting in σ2 , can perform a computational step and transform itself into the command c2′ in state σ2′ , then the command, c, starting in the state σ can perform a computational step and transform itself into the command c′ in state σ ′ . It is clear that a specific rule will express a number of meaningful relationships between c, c1 and c2 (and their respective states). In general, c1 and c2 will be subcommands of c.10 Expression semantics Figure 2.12 shows the rules for the semantics of arithmetic expressions. The first three rules are terminal rules (that is, the computation to the right of the arrow is in a form to which no more transitions can be applied). In order of presentation, they define the semantics of a variable, of addition in the case in which both of the summands are constants, of subtraction in the case in which both its arguments are constants and its result is a natural number. Note that no semantics is given for expressions such as 5 − 7. The second group of four rules is formed of conditional rules. The first pair defines the semantics of sums and expresses the fact that to calculate the value of a sum, it is necessary first to evaluate its two arguments separately. Note how the semantics specifies no order of evaluation for the arguments of an addition. Subtraction is handled in a similar fashion. Figure 2.13 shows the semantics of logical expressions and adopts the same ideas as for arithmetic expressions. Note that in this figure, bv denotes a boolean value (tt or ff). Command semantics It can be seen how the state, σ , always remains unaltered during the evaluation of an expression and how it is only used to obtain the value of a variable. This changes for the semantics of commands as shown in Fig. 2.14. Note how the rules in the Figure are essentially of two types: those which, for every command, express the actual computational step for that command (this holds for rules (c1), (c2), (c4), (c6), (c7) and (c9)), as well as those which serve just to make 10 It will not have escaped the attentive reader that what we have called conditional rules are, in reality, inductive rules forming part of the definition of transition relations.

50

2 How to Describe a Programming Language

⟨(n == m), σ ⟩ → ⟨tt, σ ⟩ if n = m

⟨(n == m), σ ⟩ → ⟨ff, σ ⟩ if n ̸= m

⟨(bv1 ∧ bv2 ), σ ⟩ → ⟨bv, σ ⟩ where bv is the and of bv1 and bv2 ⟨¬tt, σ ⟩ → ⟨ff, σ ⟩

⟨¬ff, σ ⟩ → ⟨tt, σ ⟩

⟨a1 , σ ⟩ → ⟨a ′ , σ ⟩ ⟨a2 , σ ⟩ → ⟨a ′′ , σ ⟩ ⟨(a1 == a2 ), σ ⟩ → ⟨(a ′ == a2 ), σ ⟩ ⟨(a1 == a2 ), σ ⟩ → ⟨(a1 == a ′′ ), σ ⟩ ⟨b1 , σ ⟩ → ⟨b′ , σ ⟩ ⟨(b1 ∧ b2 ), σ ⟩ → ⟨(b′ ∧ b2 ), σ ⟩

⟨b2 , σ ⟩ → ⟨b′′ , σ ⟩ ⟨(b1 ∧ b2 ), σ ⟩ → ⟨(b1 ∧ b′′ ), σ ⟩

⟨b, σ ⟩ → ⟨b′ , σ ⟩ ⟨¬b, σ ⟩ → ⟨¬b′ , σ ⟩ Fig. 2.13 Semantics of boolean expressions

⟨skip, σ ⟩ → σ ⟨X := n, σ ⟩ → σ [X ← n]

(c2)

⟨c1 , σ ⟩ → σ ′ (c4) ⟨c1 ; c2 , σ ⟩ → ⟨c2 , σ ′ ⟩

(c1)

⟨a, σ ⟩ → ⟨a ′ , σ ⟩ (c3) ⟨X := a, σ ⟩ → ⟨X := a ′ , σ ⟩ ⟨c1 , σ ⟩ → ⟨c1′ , σ ′ ⟩

⟨c1 ; c2 , σ ⟩ → ⟨c1′ ; c2 , σ ′ ⟩

(c5)

⟨if tt then c1 else c2 , σ ⟩ → ⟨c1 , σ ⟩ (c6) ⟨if ff then c1 else c2 , σ ⟩ → ⟨c2 , σ ⟩ (c7) ⟨b, σ ⟩ → ⟨b′ , σ ⟩ (c8) ⟨if b then c1 else c2 , σ ⟩ → ⟨if b′ then c1 else c2 , σ ⟩ ⟨while b do c, σ ⟩ → ⟨if b then c; while b do c else skip, σ ⟩ (c9) Fig. 2.14 Semantics of commands

the computation of a subcommand (or of a subexpression) progress. The semantic description of our language is now complete. Computations A computation is a sequence of transitions which cannot be extended by another transition. Moreover, each transformation in a computation must be described by some rule.

2.5 Semantics

51

Example 2.5 Let us consider the following program, c: X := 1; while ¬(X == 0) do X := (X − 1) Let us fix a state which includes all the variables mentioned in the program, for example, σ = [(X, 6)]. We can calculate the computation of c in σ as follows. To abbreviate the notation, we write c′ to denote the iterative command while ¬(X == 0) do X := (X − 1). It is not difficult to see that the computation generated by c is the following: ⟨c, σ ⟩ → ⟨c′ , σ [X ← 1]⟩ → ⟨if ¬(X == 0) then X := (X − 1); c′ else skip, σ [X ← 1]⟩ → ⟨if ¬(1 == 0) then X := (X − 1); c′ else skip, σ [X ← 1]⟩ → ⟨if ¬ff then X := (X − 1); c′ else skip, σ [X ← 1]⟩ → ⟨if tt then X := (X − 1); c′ else skip, σ [X ← 1]⟩ → ⟨X := (X − 1); c′ , σ [X ← 1]⟩ → ⟨X := (1 − 1); c′ , σ [X ← 1]⟩ → ⟨X := 0; c′ , σ [X ← 1]⟩ → ⟨c′ , σ [X ← 0]⟩ → ⟨if ¬(X == 0) then X := (X − 1); c′ else skip, σ [X ← 0]⟩ → ⟨if ¬(0 == 0) then X := (X − 1); c′ else skip, σ [X ← 0]⟩ → ⟨if ¬tt then X := (X − 1); c′ else skip, σ [X ← 0]⟩ → ⟨if ff then X := (X − 1); c′ else skip, σ [X ← 0]⟩ → ⟨skip, σ [X ← 0]⟩ → σ [X ← 0] The computation in the example just discussed is a terminated computation, in the sense that, after a certain number of transitions, a situation is reached in which no other transition is possible. It can be seen that, moreover, the definition of computation that we have given above does not require that a computation be finite but only that it cannot be extended. There is, therefore, the possibility that there are infinite computations, as the following example demonstrates: Example 2.6 Consider the following program, d: X := 1; while (X == 1) do skip Assume we are in the state τ = [(X, 0)]. Let d ′ be the command while (X == 1) do skip. We have: ⟨d, τ ⟩ → ⟨d ′ , τ [X ← 1]⟩ → ⟨if (X == 1) then skip ; d ′ else skip, τ [X ← 1]⟩ → ⟨if (1 == 1) then skip ; d ′ else skip, τ [X ← 1]⟩

52

2 How to Describe a Programming Language

→ ⟨if tt then skip ; d ′ else skip, τ [X ← 1]⟩ → ⟨ skip ; d ′ , τ [X ← 1]⟩ → ⟨d ′ , τ [X ← 1]⟩ → ... There exist, therefore, two fundamentally different types of computations: finite ones (also called terminating) and divergent ones (that is, infinite ones which correspond, intuitively, to looping programs).

2.6 Pragmatics If a precise description of the syntax and semantics of a programming language is (and must be) given, the same is not true of the pragmatics of the language. Let us recall that, for our purposes, the pragmatics of a language answers the question “what is the purpose of this construct?” or “what use is a certain command?” It is clear, therefore, that the pragmatics of a programming language is not established once and for all during its definition (that is, the definition of its syntax and semantics). On the contrary, it evolves with the use of the language. All suggestions about programming style are part of pragmatics. For example, there is the principle that jumps (gotos) should be avoided at all possible times. The choice of the most appropriate mode for passing parameters to a function is also a pragmatic question, as is the choice between bounded and unbounded iteration. In a sense, the pragmatics of a programming language coincides with software engineering (the discipline which studies methods for the design and production of software) and is not much studied there. For many other aspects, on the other hand, clarifying the purpose and use of constructs is an essential part of the study of a programming language. It is for this that we will often refer below to pragmatics, possibly without making it explicit that we are so doing.

2.7 Implementation The final level of programming language description will not be considered in this book in details. As we amply saw in the previous chapter, implementing a language means writing a compiler for it, as well as implementing an abstract machine for the compiler’s object language; or to write an interpreter and implement the abstract machine in the language in which the interpreter is written. Alternatively, as happens in practice, a mix of both techniques is employed. Once more, this is not a book in which we can be exhaustive about these matters. But it would not be correct to present the constructions of programming languages without some reference to their implementation cost. Even without specifying the set of constructions in an interpreter, for each construct, we should always ask: “How is it to be implemented?”, “At what cost?” The answer to these questions will also help us better to understand

2.8 Chapter Summary

53

the linguistic aspect (because a certain construct is formed in a certain way), as well as the pragmatic one (how can a certain construct best be used).

2.8 Chapter Summary The chapter introduced the fundamental techniques for the description and implementation of a programming language. • The distinction between syntax, semantics, pragmatics and implementation. Each of these disciplines describes a crucial aspect of the language. • Context-free grammars. A formal method essential for the definition of a language’s syntax. • Derivation trees and ambiguity. Derivation trees represent the logical structure of a string. The existence of a unique tree for every string permits a canonical interpretation to be assigned to it. • Static semantics. Not all syntactic aspects of a language are describable using grammars: Static semantic checks are concerned with eliminating from legal programs those strings which, though correct as far as the grammar is concerned, do not respect additional contextual constraints. • The organisation of a compiler. • Structured operational semantics. A formal method for describing the semantics of programming languages based on transition systems.

2.9 Bibliographical Notes The literature on the topics of this chapter is enormous, even considering only introductory material. We limit ourselves to citing [4], the latest edition of a classic text on formal languages used by generations of students. For compiler-construction methods, we refer the reader to [1] and [2]. An introduction to operational semantics is [5], which also deals with denotational semantics; at a more advanced level, see [8], which also deals with denotational semantics.

2.10 Exercises 1. Consider the grammar G′′ , obtained from that in Fig. 2.6 by substituting the productions for the non-terminal symbol T with the following: T → A | E ∗ T. Show that G′′ is ambiguous. 2. Give the obvious ambiguous grammar for the conditional command if, then, else.

54

2 How to Describe a Programming Language

3. Using the grammar fragment in Fig. 2.7 as a reference point, construct a derivation tree for the string if (expression1) if (expression2) command1 else command2

Assume that the following derivations exist: Expression ⇒∗ expression1, Expression ⇒∗ expression2, StatementWithoutTrailingSubstatement ⇒∗ command, StatementWithoutTrailingSubstatement ⇒∗ command. 4. Define a grammar that will generate all the pairs of balanced curly brackets (braces). 5. Define a grammar that generates the language {a n bm | n, m ≥ 1} using only productions of the form N → tM or N → t, where N and M are any non-terminal symbol and t is any terminal symbol. Try to give an intuitive explanation of why there exists no grammar with these characteristics which generates the language {a n bn | n ≥ 1}. 6. Modify the rule of Fig. 2.12 so as to describe a right-to-left evaluation of arithmetic expressions. 7. Calculate the computation of the command X := 1; while ¬(X == 3) do X := (X + 1) starting with a chosen state. 8. In Example 2.5, the last transition has as its right member only a state (and not a pair composed of a command and a state). Is this always the case in a finite computation? (Hint: consider the command X := 0; X := (X − 1), starting with any state whatsoever which includes X.) 9. State what the computation corresponding to the following command is: X := 1;

X := (X − 1);

X := (X − 1);

X := 5

10. Considering Exercises 8 and 9, state a criterion which allows the division of finite computations into those which are correct and those which terminate because of an error.

References 1. A. V. Aho, R. Sethi, and J. D. Ullman. Compilers: Principles, Techniques, and Tools. AddisonWesley, Reading, 1988. 2. A. W. Appel. Modern Compiler Implementation in Java. Cambridge University Press, Cambridge, 1998. 3. J. Gosling, B. Joy, G. Steele, and G. Bracha. The Java Language Specification, 3/E. Addison Wesley, Reading, 2005. Available online at http://java.sun.com/docs/books/jls/index.html.

References

55

4. J. E. Hopcroft, R. Motwani, and J. Ullman. Introduction to Automata Theory, Languages, and Computation. Addison-Wesley, Reading, 2001. 5. C. Laneve. La Descrizione Operazionale dei Linguaggi di Programmazione. Franco Angeli, Milano, 1998 (in Italian). 6. C. W. Morris. Foundations of the theory of signs. In Writings on the Theory of Signs, pages 17–74. Mouton, The Hague, 1938. 7. G. D. Plotkin. A structural approach to operational semantics. Technical Report DAIMI FN-19, University of Aarhus, 1981. 8. G. Winskel. The Formal Semantics of Programming Languages. MIT Press, Cambridge, 1993.

Chapter 3

Foundations

In this chapter, we will not be concerned with programming languages but with the limits of the programs that we can write, asking whether there exist problems that no program can solve. A motivation for this research is the question that we asked at the end of Sect. 2.3: that is, is it possible to construct a static semantic analyser which can verify constraints imposed by the programming language’s definition? We will soon discover, however, that the answer to the question is rather more general and is, in reality, a kind of absolute limit to what can (and cannot) be done with a computer. Although the material in this chapter can appear abstract, our treatment is wholly elementary.

3.1 The Halting Problem In Sect. 2.3, we asked if there exists a static semantic analyser able to determine whether a program can generate a division by zero error during execution. Instead of tackling this problem, we will examine a larger problem, one that is also more interesting. We will ask whether there exists a static analyser able to discover whether a program, when provided with certain input data, will loop. There is no need to emphasise the usefulness of a check of this kind. If we know, prior to execution, that a given program will loop when presented with some input data, we will have a way of showing automatically that it definitely contains an error. A static analyser is nothing more than a program used as a subprogram of a compiler. Let us, therefore, fix a programming language, L , in which we will write programs. Given a program, P , and an input x, we write P (x) to denote the result of the computing P on x. We should note that, in general, the program P might not terminate on x because of a loop or of an infinite recursion. Writing P (x), therefore, we do not necessarily indicate a computation that terminates. Without loss of generality, we can now reformulate the question as: Does there exist a program, H , that, having been given as input a program P (in the language L ) and its input data x, will terminate and print “yes” if P (x) terminates, and terminate and print “no” if P (x) loops? M. Gabbrielli, S. Martini, Programming Languages: Principles and Paradigms, Undergraduate Topics in Computer Science, DOI 10.1007/978-1-84882-914-5_3, © Springer-Verlag London Limited 2010

57

58

3 Foundations

We emphasise that H has two inputs. It must always terminate (we do not want a compiler that loops!) and it must function on every program, P , written in L and every input x. We can then assume, again without loss of generality, that H is written in the language L , since L , to be interesting, must be in a language in which it is possible to write all possible programs.1 We now show our hand. We want to show that there exists no program H with the behaviour we have just discussed. We will argue by contradiction, assuming we can have such an H , and from this we will derive a contradiction. The reasoning might seem a little contorted at first sight but requires no advanced knowledge. The argument, however, is subtle and elegant; the reader should read it more than once and be sure of understanding the critical role of self application. 1. Let us assume, by contradiction, that we have a program H with the properties stated above. 2. Using H , we can write a program K, with only one input (which will be another program), with the following specification: The program K, given P as input, terminates printing “yes” if H (P , P ) prints “no”; it goes into a loop if H (P , P ) prints “yes”.

Writing the program K, given that H is available, is simple. We read the input P , call H as a subprogram, passing P as first and second parameter. We wait until H terminates (this will certainly happen, given H ’s specification). If H (P , P ) terminates and prints “no” (we can assume that we can intercept this printing and stop it from appearing on the output), K prints “yes”. If, on the other hand, H (P , P ) prints “yes”, then K goes into an infinite loop programmed for the purpose. If we recall the specification of H , we can summarise the semantics of K as: " “yes” if P (P ) does not terminate, K(P ) = (3.1) does not terminate if P (P ) does terminate. At first sight the application of P to itself seems strange. There is no miracle. P will receive an input consisting of a string representing the text of P .2 3. Let us now execute K on its own text. That is, we focus on K(K). What is its behaviour? If we substitute K for P in (3.1), we obtain: " “yes” if K(K) does not terminate, K(P ) = (3.2) does not terminate if K(K) does terminate. 4. Now let us observe that (3.2) is absurd! It says that K(K) terminates (printing “yes”) when K(K) fails to terminate and that it does not terminate when K(K) terminates. 1 Clarifying 2 If

the sense of “all possible programs” is actually one of the aims of this chapter.

we had assumed that the input to P was a number, the string comprising the text of P can read as a number: a number i, whose bits denote the individual characters in the text of P .

3.2 Expressiveness of Programming Languages

59

5. Where does this contradiction come from? Not from K itself, which, as we have seen, is a simple program which uses H . The contradiction arises from having to assume the existence of a program with the properties of H . Therefore, H cannot exist. We have therefore proved that there exists no decision procedure (in the language L ) capable of determining whether any another program in L terminates on an arbitrary input. We use here decision procedure in the technical sense of a program that: (i) works for arbitrary arguments; (ii) always terminates and (iii) determines (by responding “yes” or “no”) those arguments which are solutions to the problem and those which are not. This result, one of fundamental importance in computing, is called the undecidability of the halting problem. Many other interesting problems are undecidable in the same way. We will discuss some in the next section after first having discussed the characteristics of L from which the result derives. We can thus tackle the problem of the expressive power of programming languages.

3.2 Expressiveness of Programming Languages At first sight, the result we obtained in the last section can appear fairly limited. If we take a language different from L , perhaps the program H can exist without generating a contradiction. Upon reflection, though, we have not assumed much about L . We have used L in an implicit way to define the program K, given H (that is, at Step 2 of the proof). To be able truly to write K, the following conditions must be satisfied: 1. There must be some form of conditional available in L , so that the cases in the definition of K can be distinguished; 2. It must be possible to define functions which do not terminate in L (we must therefore have at our disposal some form of iteration or recursion). At this level of detail, L is nothing special. What programming language does not provide these constructs? If a language provides these constructs, it can be used in place of L in the proof, showing that a program like H exists in no programming language worth its salt. The undecidability of the halting problem is not, therefore, a contingent fact, related to any particular programming language, nor is it the expression of our inability as programmers. On the contrary, it is a limitation that is in some way absolute, indissolubly linked to the intuitive concepts of program (algorithm) and with that of programming language. It is a principle of nature, similar to the conservation of energy or to the principles of thermodynamics. In nature, there exist more problems and functions than there are programs that we can write. There are problems to which there correspond no program that is anything but insignificant; the halting problem is definitely one of them. Rather, as argued in Sect. 3.3, the problems for which there exists a program for their solution constitute only a tiny part of the set of all possible problems.

60

3 Foundations

As with the halting problem, when we say that some problem is undecidable, we mean that there exists no program such that: (i) it accepts arbitrary arguments; (ii) it always terminates and (iii) it determines which arguments are solutions to the problem and which are not. We will stray too far if we begin a proof of the undecidability of any other important problems; the interested reader can consult any good text on the theory of computability for them. We can however list some undecidable problems without attempting to explain all the terms used or to undertake any proofs. The following problems are undecidable: • • • • •

Determine whether a program computes a constant function; Determine whether two programs compute the same function; Determine whether a program terminates for every input; Determine whether a program diverges for every input; Determine whether a program, given an input, will produce an error during its execution; • Determine whether a program will cause a type error (see the box on page 204).

Undecidability results tell us that they do not exist general software tools which will automatically establish significant properties of programs.

3.3 Formalisms for Computability To make the discussion of L more precise, we need to fix a programming language and show that the reasoning of the previous section applies to it. Historically, the first language in which the impossibility of writing program H was shown was the language of the Turing Machine. The Turing Machine language is a notation which is, at first sight, highly rudimentary. It was introduced in the 1930s by the mathematician Alan M. Turing. It is summarised in the Turing Machines box. It is at first sight surprising that such a rudimentary formalism (there is no predefined arithmetic; everything turns on the positioning of a finite number of symbols on a tape) could be good enough to express computations as sophisticated as those needed to write K on the basis of H . More surprising is the fact that there exists a Turing Machine which can act as an interpreter for others; that is a machine which, once an input has been written on its own tape, as well as the (appropriately coded) description of a generic machine and an input for it, executes the computation which that machine would perform on that input. This interpreter is, to all intents and purposes, a (very simple) computer like those that we know today (program and data in memory, fundamental cycle which interprets program instructions). A function is computable in a language L if there exists a program in L which computes it. More precisely, the (partial—see the box on page 12) function f : A → B is computable if there exists a program P with the following properties: for each element a ∈ A, whenever P is executed on an input a, which we write P (a), it terminates providing as an output f (a) if f (a) is defined; the computation P (a) does not terminate if f is undefined at a.

3.4 There are More Functions than Algorithms

61

Turing Machines A Turing machine is composed of an infinite tape, divided into cells, each of which stores a single symbol from a finite alphabet. A mobile head reads from and writes to the tape. At any time, the head is positioned over a single cell. The machine is controlled by a finite-state controller. At each step in the computation, the machine reads a symbol from the tape and, according to the state of the machine and symbol that it has read, the controller decides which symbol to substitute for it on the tape and if the head is to move to the left or to the right; the controller therefore enters another state (remember, there is a finite number of states). The controller of a Turing machine can be seen as its associated program. We might expect there to be fewer functions computed by a Turing Machine than those which can be computed by a sophisticated, modern programming language. In investigating this question, there have been many suggestions since the 1930s formalisms for expressing algorithms (programs), amongst which there are the General Recursive Functions of Church-Gödel and Kleene (which make no reference to programming languages), the Lambda Calculus (which we will examine in Chap. 11), and then all current programming languages. Indeed, all these formalisms and languages can be simulated by each other. That is, it is possible in each of these formalisms to write an interpreter for any of the others. From this, it follows that they are all equivalent in terms of the functions that they compute. They all compute exactly the same functions as the Turing Machine. In principle, therefore, every algorithm is expressible in any programming language. This is frequently expressed by saying that all programming languages are Turing complete (or Turing equivalent). The undecidability results can also be expressed by saying that there exist functions which cannot be computed (with a Turing Machine, or, by the above, in any programming language). If all languages are equivalent with respect to the functions they compute, it is clear that they are not equivalent as far as their flexibility of use, pragmatics, abstraction principles and so on, are concerned. And often this complex of properties is referred to as the expressiveness of a language. While all these computability formalisms provide a definite result about equivalence in terms of the functions that can be expressed, these same formalisms are useless when discussing the expressiveness of languages. In fact, even now, there is no agreement on how formally to tackle these aspects.

3.4 There are More Functions than Algorithms In Sect. 3.1, we gave a specific example of a uncomputable function. We can give another proof that there exist functions which cannot be computed using a simple cardinality argument (though, unlike in Sect. 3.1, we will not produce a specific example). That is, we show that, in nature, there are more functions than algorithms.

62

3 Foundations

First of all, let us consider any formal system which allows us to express algorithms and which, for simplicity we can assume to be a programming language, L , (this could, however, be generalised to a wider definition). It is easy enough to see that the set of all possible (finite) programs that can be written in L is denumerable, that is, they can be put into one-one correspondence with the natural numbers (which we denote by N). We can, in fact, first consider the set P1 containing all programs of length one (which contain a single character), then the set P2 containing all programs of length two, and so on. Every set, Pi , is finite and can be ordered, for example lexicographically (first all programs which begin with a, then all those which begin with b, and so on by succeeding characters). It is clear that by doing this, by taking into account the ordering produced by the subscript in the sets P1 , P2 , . . . , and then doing the same with the internal indices in each set, we can count (or enumerate) all possible programs and therefore put them into one-one correspondence with the natural numbers. In more formal terms, when this has been done, we can say that the cardinality of the set of all programs writable in L is equal to the cardinality of the naturals. Let us now consider the set F containing all the functions N → {0, 1}. An important theorem of Cantor states that this set is not denumerable but has a cardinality which is strictly greater than that of N. Given that every program expresses a unique function, the set N is too small to contain all the functions in F as programs in L . Let us see a direct proof of the fact that F is not denumerable. Let us assume that F is denumerable, that is it is possible to write F = {fj }j ∈N . Let us observe, first of all, that we can put F into one-one correspondence with the set B of all the infinite sequences of binary numbers. To each fj ∈ F , there corresponds the sequence bj,1 , bj,2 , bj,3 , . . . , where bj,i = fj (i), for i, j ∈ N. Therefore if F is denumerable, so too is the set B. Since B is denumerable, we can enumerate its elements one after the other, listing, for each element (for every sequence), the binary digits which comprise it. We can arrange such an enumeration in an infinite square matrix: b1,1 , b2,1 , b3,1 , .. .

b1,2 , b2,2 , b3,2 ,

b1,3 , b2,3 , b3,3 ,

... ... ...

where row j contains the sequence for the j th function. Writing b for the complement of the binary number b, let us now consider the sequence of binary numbers b1,1 , b2,2 , b3,3 , . . . . This sequence (since it is an infinite sequence of binary numbers) is certainly an element of B, however it does not appear in our matrix (and therefore does not appear in our enumeration) for the reason that each line is different at at least one point. Along the diagonal, the sequence found in the matrix has elements bj,j , while, by construction, the new sequence has the element bj,j in position j . We have therefore a contradiction: we had assumed that F = {fj }j ∈N was an enumeration of all functions (that is, of all sequences), while we have constructed

3.5 Chapter Summary

63

Church’s Thesis The proofs of equivalence of the various programming languages (and between the various computability formalisms) are genuine theorems. Given the languages L and L ′ , write first in L the interpreter for L ′ and then write in L ′ the interpreter for L . At this point L and L ′ are known to be equivalent. A proof of this type has been effectively given for all existing languages, so they are therefore provably equivalent. This argument would, in reality, leave open the door to the possibility that sooner or later someone will be in a position to find an intuitively computable function which is not associated with a program in any existing programming language. All equivalence results proved over more than the last 70 years, however, amount to convincing evidence that this is impossible. In the mid-1930s, Alonzo Church proposed a principle (which since then has become known as Church’s, or the Church-Turing, Thesis) that states exactly this impossibility. We can formulate Church’s Thesis as: every intuitively computable function is computed by a Turing Machine. In contrast to the equivalence results, Church’s Thesis is not a theorem because it refers to a concept (that of intuitive computability) which is not amenable to formal reasoning. It is, rather, a philosophical principle which the computer science community assumes with considerable strength to be true so that it will not even be discredited by new computational paradigms, for example quantum computing.

a function (a sequence) which did not belong to the enumeration. Therefore the cardinality of F is strictly greater than that of N. It can be shown that F has the cardinality of the real numbers. This fact indicates that the set of programs (which is denumerable) is much smaller than that of all possible functions, and therefore of all possible problems.

3.5 Chapter Summary The phenomenon of computation on which Computer Science is founded has its roots in the theory of computability which studies the formalisms in which one can express algorithms and their limits. The chapter has only presented the main result of this theory. This is a fact of the greatest importance, one that every computer scientist should know. The principal concepts which were introduced are: • Undecidability: there exist many important properties of programs which cannot be determined in a mechanical fashion by an algorithm; amongst these is the halting problem. • Computability: a function is computable when there exists a program which computes it. The undecidability of the halting problem assures us that there exist functions which are not computable.

64

3 Foundations

• Partiality: the functions expressed by a program can be undefined on some arguments, corresponding to those data for which the program will fail to terminate. • Turing Completeness: every general-purpose programming language computes the same set of functions as those computed by a Turing Machine.

3.6 Bibliographical Notes The original undecidability result is in the paper by A.M. Turing [3] which ought to be necessary reading for every computer scientist with an interest in theory. More can be found on the arguments of this chapter in any good textbook on computability theory, among which, let us recommend [1], which we cited in Chap. 2, and the classic [2] which after more than 40 years continues to be one of the most authoritative references.

3.7 Exercises 1. Proof that the restricted halting problem is undecidable. That is, determine whether a program terminates when it is applied to itself. (Suggestion: if the problem were decidable, the program which decides it would have to have the same property as program K, which can be derived by contradiction in the usual fashion.) 2. Show that the problem of verifying whether a program computes a constant function is undecidable. Hint: given a generic program P , consider the program QP , with a single input, specified as follows: " 1 if P (P ) terminates, QP (y) = does not terminate otherwise. (i) Write the program QP ; (ii) assume now that P is a program such that P (P ) terminates. What is the behaviour of QP , as y varies? (iii) what is, on other hand, the behaviour of QP , as y varies, if P (P ) does not terminate? (iv) from (ii) and (iii), it can be obtained that QP computes the constant function one if and only if P (P ) terminates; (v) if it were now decidable whether a program computes a constant function, the restricted halting problem would also be decidable, given that the transformation that, given P , constructs QP is completely general.

References

65

References 1. J. E. Hopcroft, R. Motwani, and J. Ullman. Introduction to Automata Theory, Languages, and Computation. Addison-Wesley, Reading, 2001. 2. H. Rogers. Theory of Recursive Functions and Effective Computability. McGraw Hill, New York, 1967. 3. A. Turing. On computable numbers, with an application to the Entscheidungsproblem. Proc. Lond. Math. Soc., 42:230–365, 1936. A Correction, ibidem, 43 (1937), 544–546.

Chapter 4

Names and The Environment

The evolution of programming languages can be seen in large measure as a process which has led, by means of appropriate abstraction mechanisms, to the definition of formalisms that are increasingly distant from the physical machine. In this context, names play a fundamental role. A name, indeed, is nothing more than a (possibly meaningful) sequence of characters used to represent some other thing. They allow the abstraction either of aspects of data, for example using a name to denote a location in memory, or aspects of control, for example representing a set of commands with a name. The correct handling of names requires precise semantic rules as well as adequate implementation mechanisms. In this chapter, we will analyse these rules. We will, in particular, look at the concept of environment and the constructs used to organise it. We will also look at visibility (or scope) rules. We leave until the next chapter treatment of the implementation of these concepts. Let us immediately observe how, in languages with procedures, in order to define precisely the concept of environment one needs other concepts, related to parameter passing. We will see these concepts in Chap. 7. In the case of object-oriented languages, finally, there are other specific visibility rules which we will consider in Chap. 10.

4.1 Names and Denotable Objects When we declare a new variable in a program: int fie;

or we define a new function: int foo( ){ fie = 1; }

M. Gabbrielli, S. Martini, Programming Languages: Principles and Paradigms, Undergraduate Topics in Computer Science, DOI 10.1007/978-1-84882-914-5_4, © Springer-Verlag London Limited 2010

67

68

4 Names and The Environment

we introduce new names, such as fie and foo to represent an object (a variable and a function in our example). The character sequence fie can be used every time that we want to refer to the new variable, just as the character sequence foo allows us to call the function that assigns to fie the value 1. A name is therefore nothing more than a sequence of characters used to represent, or denote, another object.1 In most languages, names are formed of identifiers, that is by alphanumeric tokens, moreover other symbols can also be names. For example, + and - are names which denote, in general, primitive operations. Even though it might seems obvious, it is important to emphasise that a name and the object it denotes are not the same thing. A name, indeed, is just a character string, while its denotation can be a complex objects such as a variable, a function, a type, and so on. And in fact, a single object can have more than one name (in this case, one speaks of aliasing), while a single name can denote different objects at different times. When, therefore, we use, as we may, the phrase “the variable fie” or the phrase “the function foo”, it should be remembered that the phrases are abbreviations for “the variable with the name fie” and “the function with the name foo”. More generally, in programming practice, when a name is used, it is almost always meant to refer to the object that it denotes. The use of names implements a first, elementary, data abstraction mechanism. For example, when, in an imperative language, we define a name using a variable, we are introducing a symbolic identifier for a memory location; therefore we are abstracting from the low-level details of memory addresses. If, then, we use the assignment command: fie = 2;

the value 2 will be stored in the location reserved for the variable named fie. At the programming level, the use of the name avoids the need to bother with whatever this location is. The correspondence between name and memory location must be guaranteed by the implementation. We will use the term environment to refer to that part of the implementation responsible for the associations between names and the objects that they denote. We will see better in Sect. 6.2.1 what exactly constitutes a variable and how it can be associated with values. Names are fundamental even for implementing a form of control abstraction. A procedure2 is nothing more than a name associated with a set of commands, together with certain visibility rules which make available to the programmer its sole interface (which is composed of the procedure’s name and possibly some parameters). We will see the specifics of control abstraction in Chap. 7. 1 Here and in the rest of this chapter, “object” is intended in a wide sense, with no reference to technical terms used in the area of object-oriented languages. 2 Here and elsewhere, we will use the generic term “procedure” for procedures as well as functions, methods and subprograms. See also Sect. 7.1.

4.1 Names and Denotable Objects

69

4.1.1 Denotable Objects The objects to which a name can be given are called denotable objects. Even if there are considerable differences between programming languages, the following is a non-exhaustive list of possible denotable objects: • Objects whose names are defined by the user: variables, formal parameters, procedures (in the broad sense), user-defined types, labels, modules, user-defined constants, exceptions. • Objects whose names are defined by the programming language: primitive types, primitive operations, predefined constants. The association (or binding) between a name and an object it denotes can therefore be created at various times. Some names are associated with objects during the design of a language, while other associations are introduced only when a program is executed. Considering the entire process ranging from a programming language’s definition to the execution of a specific program, we can identify the following phases for the creation of bindings of names to objects: Design of language In this phase, bindings between primitive constants, types and operations of the language are defined (for example, + indicates addition, and int denotes the type of integers, etc.). Program writing Given that the programmer chooses names when they write a program, we can consider this phase as one with the partial definition of some bindings, later to be completed. The binding of an identifier to a variable, for example, is defined in the program but is effectively created only when the space for the variable is allocated in memory. Compile time The compiler, translating the constructs of the high-level language into machine code, allocates memory space for some of the data structures that can be statically processed. For example, this is the case for the global variables of a program. The connection between a variable’s identifier and the corresponding memory location is formed at this time. Runtime This term denotes the entire period of time between starting and termination of a program. All the associations that have not previously been created must be formed at runtime. This is the case, for example, for bindings of variable identifiers to memory locations for the local variables in a recursive procedure, or for pointer variables whose memory is allocated dynamically. In the previous description we have ignored other important phases, such as linking and loading in which other bindings (for example for external names referring to objects in other modules). In practice, however, two principle phases are distinguished using the terms “static” and “dynamic”. The term “static” is used to refer to everything that happens prior to execution, while “dynamic” refers to everything that happens during execution. Thus, for example, static memory management is performed by the compiler, while dynamic management is performed by appropriate operations executed by the abstract machine at runtime.

70 Fig. 4.1 A name denoting different objects

4 Names and The Environment {int fie; fie = 2; {char fie; fie = a; } }

4.2 Environments and Blocks Not all associations between names and denotable objects are fixed once and for all at the start of program execution. Many can vary during execution. To be able to understand how these associations behave, we need to introduce the concept of environment. Definition 4.1 (Environment) The set of associations between names and denotable objects which exist at runtime at a specific point in the program and at a specific time during execution, is called the (referencing) environment. Usually, when we speak of environments, we refer only to associations that are not established by the language definition. The environment is therefore that component of the abstract machine which, for every name introduced by the programmer and at every point in the program, allows the determination of what the correct association is. Note that the environment does not exist at the level of the physical machine. The presence of the environment constitutes one of the principle characteristics of high-level languages which must be simulated in a suitable fashion by each implementation of the language. A declaration is a construct that allows the introduction of an association in the environment. High-level languages often have explicit declarations, such as: int x; int f (){ return 0; } type T = int;

(the first is a declaration of a variable, the second of a function named f, the third is declaration of a new type, T, which coincides with type int). Some languages allow implicit declarations which introduce an association in the environment for a name when it is first used. The denoted object’s type is deduced from the context in which the name is used for the first time (or sometimes from the syntactic form of the name). As we will see in detail below, there are various degrees of freedom in associations between names and denotable objects. First of all, a single name can denote different objects in different parts of the program. Consider, for example, the code of Fig. 4.1. The outermost name fie denotes an integer variable, while the inner one is of type character.

4.2 Environments and Blocks

71

It is also possible that a single object is denoted by more than one name in different environments. For example, if we pass a variable by reference to a procedure, the variable is accessible using its name in the calling program and by means of the name of the formal parameter in the body of the procedure (see Sect. 7.1.2). Alternatively, we can use pointers to create data structures in which the same object is then accessible using different names. While different names for the same object are used in different environments, no particular problems arise. The situation is more complicated when a single object is visible using different names in the same environment. This is called aliasing and the different names for the same object called aliases. If the name of a variable passed by reference to a procedure is also visible inside the same procedure, we have a situation of aliasing. Other aliasing situations can easily occur using pointers. If X and Y are variables of pointer type, the assignment X = Y allows us to access the same location using both X and Y. Let us consider, for example, the following fragment of C program where, as we will do in the future, we assume that write(Z) is a procedure which allows us to print the value of the integer variable Z: int *X, *Y; // X,Y pointers to integers X = (int *) malloc (sizeof (int)); // allocate heap memory *X = 5; // * dereference Y=X; // Y points to the same object as X *Y=10; write(*X);

The names X and Y denote two different variables, which, however, after the execution of the assignment command X = Y, allow to access the same memory location (therefore, the next print command will output the value 10). It is, finally, possible that a single name, in a single textual region of the program, can denote different objects according to the execution flow of the program. The situation is more common than it might seem at first sight. It is the case, for example, for a recursive procedure declaring a local name. Other cases of this type, which are more subtle, will be discussed below in this chapter when will discuss dynamic scope (Sect. 4.3.2).

4.2.1 Blocks Almost all important programming languages today permit the use of blocks, a structuring method for programs introduced by A LGOL 60. Block structuring is fundamental to the organisation of the environment. Definition 4.2 (Block) A block is a textual region of the program, identified by a start sign and an end sign, which can contain declarations local to that region (that is, which appear within the region).

72

4 Names and The Environment

The start- and end-block constructs vary according to the programming language: begin ... end for languages in the A LGOL family, braces {...} for C and Java, round brackets (...) for L ISP and its dialects, let ... in ... end in ML, etc. Moreover, the exact definition of block in the specific programming language can differ slightly from the one given above. In some cases, for example, one talks about block only when there are local declarations. Often, though, blocks have another important function, that of grouping a series of commands into a syntactic entity which can be considered as a single (composite) command. These distinctions, however, are not relevant as far as we are concerned. We will, therefore, use the definition given above and we distinguish two cases: Block associated with a procedure This is a block associated with declarations local to a procedure. It corresponds textually to the body of the procedure itself, extended with the declarations of formal parameters. In-line block This is a block which does not correspond to a declaration of procedure and which can appear (in general) in any position where a command can appear.

4.2.2 Types of Environment The environment changes during the execution of a program. However, the changes occur generally at two precise times: on the entry and exit of a block. The block can therefore be considered as the construct of least granularity to which a constant environment can be associated.3 A block’s environment, meaning by this terminology the environment existing when the block is executed, is initially composed of associations between names declared locally to the block itself. In most languages allowing blocks, blocks can be nested; that is, the definition of one block can be wholly included in that of another. An example of nested anonymous blocks is shown in Fig. 4.1. The overlapping of blocks so the last open block is not the first block to be closed is never permitted. In other words a sequence of commands of the following kind is not permitted in any language: open block A; open block B; close block A; close block B;

Different languages vary, then, in the type of nesting they permit. In C, for example, blocks associated with procedures cannot be nested inside each other (that is, there cannot be procedure declarations inside other procedures), while in Pascal and Ada this restriction is not present.4 3 Declarations in the block are evaluated when the block is entered and are visible throughout the block. There exist many exceptions to this rule, some of which will be discussed below. 4 The reasons for this restriction in C will be made clear in the next chapter when we will have discussed techniques for implementing scope rules.

4.2 Environments and Blocks

73

Block nesting is an important mechanism for structuring the environment. There are mechanisms that allow the declarations local to a block to be visible in blocks nested inside it. Remaining informal for the time being, we say that a declaration local to a block is visible in another block when the association created by such a declaration is present in the second block. Those mechanisms of the language which regulate how and when the declaration is visible are called visibility rules. The canonical visibility rule for languages with blocks is well known: A declaration local to a block is visible in that block and in all blocks listed within it, unless there is a new declaration of the same name in that same block. In this case, in the block which contains the redefinition the new declaration hides the previous one.

In the case in which there is a redefinition, the visibility rule establishes that only the last name declared will be visible in the internal block, while in the exterior one there is a visibility hole. The association for the name declared in the external block will be, in fact, deactivated for the whole of the interior block (containing the new declaration) and will be reactivated on exit from the inner block. Note that there is no visibility from the outside inwards. Every association introduced in the environment local to a block is not active (or rather the name that it defines is not visible) in an exterior block which contains the interior one. Analogously, if we have two blocks at the same nesting level, or if neither of the two contains the other, a name introduced locally in one block is not visible in the other. The definition just given, although apparently precise, is insufficiently so to establish with precision what the environment will be at an arbitrary point in a program. We will assume this rule for the rest of this section, while the next will be concerned with stating the visibility rules correctly. In general we can identify three components of an environment, as stated in the following definition. Definition 4.3 (Type of environment) The environment associated with a block is formed of the following components: Local environment This is composed of the set of associations for names declared locally to the block. In the case in which the block is for a procedure, the local environment contains also the associations for the formal parameters, given that they can be seen, as far as the environment is concerned, as locally declared variables. Non-local environment This is the environment formed from the associations for names which are visible from inside a block but which have not been declared locally. Global environment Finally, there is the environment formed from associations created when the program’s execution began. It contains the associations for names which can be used in all blocks forming the program. The environment local to a block can be determined by considering only the declarations present in the block. We must look outside the block to define the non-local environment. The global environment is part of the non-local environment. Names

74 Fig. 4.2 Nested blocks with different environments

4 Names and The Environment A:{int a =1; B:{int b = 2; int c = 2; C:{int c =3; int d; d = a+b+c; write(d) } D:{int e; e = a+b+c; write(e) } } }

introduced in the local environment can be themselves present in the non-local environment. In such cases, the innermost (local) declaration hides the outermost one. The visibility rules specify how names declared in external blocks are visible in internal ones. In some cases, it is possible to import names from other, separately defined modules. The associations for these names are part of the global environment. We will now consider the example in Fig. 4.2, where, for ease of reference, we assume that the blocks can be labelled (as before, we assume also that write(x) allows us to print an integer value). The labels behave as comments as far as the execution is concerned. Let us assume that block A is the outermost. It corresponds to the main program. The declaration of the variable a introduces an association in the global environment. Inside block B two variables are declared locally (b and c). The environment for B is therefore formed of the local environment, containing the association for the two names (b and c) and from the global environment containing the association for a. Inside block C, 2 local variables (c and d) are declared. The environment of C is therefore formed from the local environment, which contains the association for the two names (c and d) and from the non-local environment containing the same global environment as above, and also the association for the name b which is inherited from the environment of block B. Note that the local declaration of c in block C hides the declaration of c present in block B. The print command present in block C will therefore print the value 6. In block D, finally, we have a local environment containing the association for the local name e, the usual global environment and the non-local environment, which, in addition to the association for a contains the association for the names b and c introduced in block B. Given that variable c has not been internally re-declared, in this case, therefore, the variable declared in block B remains visible and the value printed will be 5. Note that the association for the name d does not appear in the

4.2 Environments and Blocks

75

environment non-local to D, given that this name is introduced in an exterior block which does not contain D. The visibility rules, indeed, allows only the inheritance of names declared in exterior blocks from interior ones and not vice versa.

4.2.3 Operations on Environments As we have seen, changes in the environment are produced at entry to and exit from a block. In more detail, during the execution of the program, when a new block is entered, the following modifications are made to the environment: 1. Associations between locally declared names and the corresponding denotable objects are created. 2. Associations with names declared external to and redefined inside the block are deactivated. Also when the block is exited, the environment is modified as follows: 1. The associations for names declared locally to the block and the objects they denote are destroyed . 2. The associations are reactivated between names that existed external to the block and which were redefined inside it. More generally, we can identify the following operations on names and on the environment: Creation of associations between names and denoted object (naming) This is the elaboration of a declaration (or the connection of a formal to an actual parameter) when a new block containing local or parameter declarations is entered. Reference to a denoted object via its name This is the use of the name (in an expression, in a command, or in any other context). The name is used to access the denoted object. Deactivation of association between name and denoted object This happens when entering a block in which a new association for that name is created locally. The old association is not destroyed but remains (inactive) in the environment. It will be usable again when the block containing the new association is left. Reactivation of an association between name and denoted object When leaving block in which a new association for that name is created locally, reactivation occurs. The previous association, which was deactivated on entry to the block, can now be used. Destruction of an association between name and denoted object (unnaming) This is performed on local associations when the block in which these associations were created is exited. The association is removed from environment and can no longer be used. Let us explicitly note, however, that any environment contains both active and inactive associations (they correspond to declarations that have been hidden by the

76

4 Names and The Environment

effects of the visibility rules). As far as denotable objects are concerned, the following operations are permitted: Creation of a denotable object This operation is performed while allocating the storage necessary to contain the object. Sometimes, creation includes also the initialisation of the object. Access to a denotable object Using the name, and hence the environment, we can access the denotable object and thus access its value (for example, to read the content of a variable). Let us observe that the set of rules which locate the environment has, as its aim, making the association between a name and the object which it refers one-to-one (at a given point in the program and during a given execution). Modification of a denotable object It is always possible to access the denotable object via a name and then modify its value (for example, by assigning a value to a variable). Destruction of a denotable object An object can be destroyed by reallocating the memory reserved for it. In many languages, the operations of creating an association between the name and a denotable object and that of creating a denotable object take place at the same time. This is the case, for example, in a declaration of the form: int x;

This declaration introduces into the environment a new association between the name x and an integer variable. At the same time, it allocates the memory for the variable. Yet, this is not always the case and, in general, it is not stated that the lifetime of a denotable object, that is the time between the creation of the object and its destruction, coincides with the lifetime of the association between name and object. Indeed, a denotable object can have a lifetime that is greater than the association between a name and the object itself, as the case in which a variable is passed to a procedure by reference. The association between the formal parameter and associated variable has a lifetime less than that of the variable itself. More generally, a situation of this type occurs when a temporary name (for example, one local to a block) is introduced for an object which already has a name. Note that the situation we are considering is not that shown in Fig. 4.2. In this case, indeed, the internal declaration of the variable, c, does not introduce a new name for an existing object, but introduces a new object (a new variable). Even if, at first sight, this seems odd, it can also be the case that the lifetime of an association between name and a denoted object is greater than that of the object itself. More precisely, it can be the case that a name allows access to an object which no longer exists. Such an anomalous situation can occur, for example, if we call by reference an existing object and then deallocate the memory for it before the procedure terminates. The formal parameter to the procedure, in this case, will denote an object which no longer exists. A situation of this type, in which it is possible to access an object whose memory has been reallocated, is called a dangling reference and is a symptom of an error. We will return to the problem dangling references in Chap. 8, where we will present some methods to handle them.

4.3 Scope Rules

77

4.3 Scope Rules We have seen how, on block entry and exit, the environment can change as a result of the operations for the creation, destruction, activation and the deactivation of associations. These changes are reasonably clear for local environments, but are less clear where the non-local environment is concerned. The visibility rules stated in the previous section indeed lend themselves to at least two different interpretations. Consider for example the following program fragment: A:{int x = 0; void fie(){ x = 1; } B:{int x; fie(); } write(x); }

Which value will be printed? To answer this question, the fundamental problem is knowing which declaration of x refers to the non-local occurrence of this name appearing in the assignment in procedure fie’s body. On the one hand, we can reasonably think that the value 1 is printed, given that procedure fie is defined in block A and, therefore, the x which appears in the body of the procedure could be that defined on the first line of A. On the other hand, however, we can also reason as follows. When we call procedure fie, we are in block B, so the x that we are using in the assignment present in the body of the procedure is the one declared locally to block B. This local variable is now no longer visible when we exit block B, so write(x) refers to the variable x declared and initialised to 0 in block A and never again modified. Therefore the procedure prints the value 0. Before the reader tries to find possible tricks in the above reasoning, we must assert that they are both legitimate. The result of the program fragment depends on the scope rule being used, as will become clear at the end of the section. The visibility rule that we have stated above establishes that a “declaration local to a block is visible in that block and all the blocks nested within it” but does not specify whether this concept of nesting must be considered in a static (that is based on the text of the program) or dynamic (that is based on the flow of execution) fashion. When the visibility rules, also called scope rules, depend only on the syntactic structure of the program, we will talk of a language with static or lexical scope. When it is influenced also by the control flow at runtime, we are dealing with a language with dynamic scope. In the following sections we will analyse these two concepts in detail.

78

4 Names and The Environment

4.3.1 Static Scope In a language with static (or lexical) scope, the environment in force at any point of the program and at any point during execution depends uniquely on the syntactic structure of the program itself. Such an environment can then be determined completely by the compiler, hence the term “static”. Obviously there can be different static scope rules. One of the simplest, for example, is that of the first version of the Basic language which allowed a single global environment in which it was possible to use only a small number of names (some hundreds) and where declarations were not used. Much more interesting is the static scope rule that is used in those blockstructured languages that allow nesting. This was introduced in A LGOL 60 and is retained, with few modifications, by many modern languages, including Ada, Pascal and Java. The rule can be defined as follows: Definition 4.4 (Static Scope) The static scope rule, or the rule of nearest nested scope, is defined by the following three rules: (i) The declarations local to a block define the local environment of that block. The local declarations of a block include only those present in the block (usually at the start of the block itself) and not those possibly present in blocks nested inside the block in question. (ii) If a name is used inside a block, the valid association for this name is the one present in the environment local to the block, if it exists. If no association for the name exists in the environment local to the block, the associations existing in the environment local to the block immediately containing the starting block are considered. If the association is found in this block, it is the valid one, otherwise the search continues with the blocks containing the one with which we started, from the nearest to the furthest. If, during this search, the outermost block is reached and it contains no association for the name, then this association must be looked up in the language’s predefined environment. If no association exists here, there is an error. (iii) A block can be assigned a name, in which case the name is part of the local environment of the block which immediately includes the block to which the name has been assigned. This is the case also for blocks associated with procedures. It can be immediately seen that this definition corresponds to the informal visibility rules that we have already discussed, suitably completed by a static interpretation of the concept of nesting. Among the various details of the rule, the fact should not escape us that the declaration of a procedure introduces an association for name of a procedures in the environment local to the block containing the declaration (therefore, because of nesting, the association is also visible in the block which constitutes the body of the procedure, a fact which permits the definition of recursive procedures). The procedure’s formal parameters, moreover, are present only in the environment local to

4.3 Scope Rules Fig. 4.3 An example of static scope

79 {int x = 0; void fie(int n){ x = n+1; } fie(3); write(x); {int x = 0; fie(3); write(x); } write(x); }

the procedure and are not visible in the environment which contains the procedure’s declaration. In a language with static scope, we will call the scope of a declaration that portion of the program in which the declaration is visible according to Definition 4.4. We conclude our analysis of static scope by discussing the example in Fig. 4.3. The first and third occurrences of write print the value 4, while the second prints the value 0. Note that the formal parameter, n, is not visible outside of the body of the procedure. Static scope allows the determination of all the environments present in a program simply by reading its text. This has two important consequences of a positive nature. First, the programmer has a better understanding of the program, as far as they can connect every occurrence of a name to its correct declaration by observing the textual structure of the program and without having to simulate its execution. Moreover, this connection can also be made by the compiler which can therefore determine each and every use of a name. This makes it possible, at compile time, to perform a great number of correctness tests using the information contained in types; it can also perform considerable number of code optimisations. For example, if the compiler knows (using declarations) that the variable x which occurs in a block is an integer variable, it will signal an error in the case in which a character is assigned to this variable. Similarly, if the compiler knows that the constant fie is associated with the value 10, it can substitute the value 10 for every reference to fie, so avoiding having to arrange for this operation to be performed at runtime, therefore, it updates the code. If, instead, the correct declaration for x and for fie can be determined only at execution time, it is clear that these checks and this optimisation are not possible as compilation time. Note that, even with the static scope rules, the compiler cannot know in general which memory location will be assigned to the variable with name x nor what its value might be, given that this information depends on the execution of the program. When using the static scope rule, moreover, the compiler is in possession of some important information about the storage of variables (in particular it knows the offsets relative to a fixed position, as we will see in detail in the next chapter), that it uses to compile efficient accesses to variables. As we will see, this information is not available using dynamic scope, which, therefore, leads to less efficient exe-

80 Fig. 4.4 An example of dynamic scope

4 Names and The Environment {const x = 0; void fie(){ write(x); } void foo(){ const x =1; fie(); } foo(); }

cution. For these reasons, most current languages (for example A LGOL, Pascal, C, C++, Ada, scheme and Java) use some form of static scope.

4.3.2 Dynamic Scope Dynamic scope was introduced in some languages, such as, for example, APL, L ISP (some versions), SNOBOL and P ERL, mainly to simplify runtime environment management. In fact it is true that static scope imposes a fairly complicated runtime regime because the various non-local environments are involved in a way that does not reflect the normal flow of activation and deactivation of blocks. We seek to understand the problem by considering the fragment of code in Fig. 4.4 and following its execution. First, the outermost block is entered and the association between the name x and the constant 0 is created, as well as that between the names fie, foo and associated procedures (as we said above, this association can be performed by the compiler). Next the call to the procedure foo is executed and control enters the block associated with the procedure. In this block, the link between the name x and the constant 1 is created; then the call to procedure fie is executed which causes entry to a new block (the one for the latter procedure). It is at this point that the command write(x) is executed and given that x is not a name local to the block introduced by the procedure fie, the association for the name x must be looked up in outer blocks. However, according to the rules of static scope, as presented in the last section, the first external block in which to look for the association for x is not the last block to be activated (it is the one for procedure foo in our example); such an external block depends on the structure of the program. In this case, then, the correct association for the name x used by fie is the one located in the first block and consequently the value 0 is printed. The block belonging to procedure foo, even if it contains a declaration for x and is still active, is not considered. Generalising from the previous example, we can say that, under static scope, the sequence of blocks that must be considered to resolve references to non-local names is different from the sequence of blocks that is opened and exited during the program’s normal flow of control. The opening and closing can be handled in a natural manner using the LIFO (Last In First Out) discipline, that is using a stack. The sequence of blocks that need examining to implement static scope depends on

4.3 Scope Rules Fig. 4.5 Another example of dynamic scope

81 {const x = 0; void fie(){ write(x); } void foo(){ const x = 1; {const x = 2; } foo(); } foo(); }

the syntactic structure of the program and being able to handle it correctly at runtime depends upon the use of additional data structures, as we will see in detail in the next chapter. To simplify the management of the runtime environment some languages use then the dynamic scope rule. This rule determines the associations between names and denoted objects using the backward execution of the program. In such languages, resolving non-local names requires only a stack dedicated to handling blocks at runtime. In our example, this means that, when the command write(x) is executed, the association for the name and x is sought in the second block (relative to procedure foo), rather than in the first block, because this is the last block, different from the current one, in which we entered and from which we have not yet exited. Given that in the second block, we find the declaration const x = 1, in the case of dynamic scope the preceding program prints the value 1. With more precision the dynamic scope rule, also called the rule of the most recent association, can be defined as follows. Definition 4.5 (Dynamic Scope) According to the rule of dynamic scope, the valid association for a name X, at any point P of a program, is the most recent (in the temporal sense) association created for X which is still active when control flow arrives at P. It is appropriate to observe that this rule does not contradict the informal visibility rule that we stated in Sect. 4.2.2. A moment’s reflection shows, indeed, that the dynamic scope rule expresses nothing other than the same visibility rule but the concept of block nesting is understood in a dynamic sense. Let us again note how the difference between static and dynamic scope enters only into the determination of the environment which is currently not local and not global. For the local and global environment, the two rules coincide. Let us conclude by discussing the example in Fig. 4.5. In a language with dynamic scope, the code prints the value 1 because when the command write(x) is executed, the last association created for x which is still active associates x with 1. The association which associates x to 2, even if it is the most recent one to be created, is no longer active when procedure fie is executed and is therefore not considered.

82

4 Names and The Environment

Note that dynamic scope allows the modification of the behaviour of procedure or subprogram without using explicit parameters but only by redefining some of the non-local variables used. To explain this point, assume that we have a procedure visualise(text) which can visualise text in various colours, according to the value of the non-local variable colour. If we assume that in the majority of cases, the procedure visualises text in black, it is natural to assume that we do not wish to introduce another parameter to the procedure in order to determine the colour. If the language uses dynamic scope, in the case in which the procedure has to visualise a text in red, it will be enough to introduce the declaration for the variable colour before the call of the procedure. We can therefore write: ... {var colour = red; visualise(head); }

Then the call to procedure visualise now will use the colour red, because of the effect of dynamic scope. This flexibility of dynamic scope, is, on the one hand, advantageous, yet, on the other, it often makes programs more difficult to read, given that the same procedure call, in conditions differing by only one non-local variable can produce different results. If the variable (colour in our example) is modified in an area of program that is distant from the procedure call, understanding what has happened will probably turn out to be difficult. For this reason, as well as for low runtime efficiency, dynamic scope remains little used in modern general-purpose languages, which instead use the static scope rule.

4.3.3 Some Scope Problems In this section, we will discuss some questions about static scope. The major differences between the rules for static scope in various languages are based on where declarations can be introduced and what will be the exact visibility of the local variables. The scope rules just introduced, lend themselves to more than one interpretation and, in some cases, they can also be the cause of anomalous behaviour. Let us discuss here some different and important situations that can happen. Let us, first, take the case of Pascal in which the static scope rule that we have already seen is extended with the following additional rules: 1. Declarations can appear only at the start of a block. 2. The scope of a name extends from the start to the end of the block in which the declaration of the name itself appears (excluding possible holes in scope) independent of the position of that declaration.

4.3 Scope Rules

83

3. All names not predefined by the language must be declared before use. It is an error therefore to write: begin const fie = value; const value = 0; ... end

This is because value is used before its definition. It could be assumed that such a fragment might be correct if it were inserted into a block already containing a definition of value. Also in this case, though, an error is produced. In fact, let us write: begin const value = 1; procedure foo; const fie = value; const value = 0; ... begin ... end ... end

Now, the rules that we have seen tell us that the declaration of the procedure foo introduces an internal block in which the local declaration of value (which initialises to the constant to 0) covers the external declaration (which initialises the constant to 1). Therefore the name value appearing in the declaration const fie = value;

must refer to the declaration const value = 0;

in the internal block. However this declaration occurs after the use of the name, therefore contravening Rule 3. In such a case, therefore, the more correct behaviour for a Pascal compiler is to raise a static semantic error as soon as it has analysed the declaration of fie. Some compilers, though, assign to fie the value 1; this is clearly incorrect for the reason that it violates the visibility rule. To avoid this type of problem, some languages with static scope, such as C and Ada, limit the scope of declarations to that portion of the block between the point at which the declarations occur and the end of the book itself (excluding, as usual, holes in scope). In these languages, therefore, we do not encounter the above problem where the name value appearing in the declaration

84

4 Names and The Environment

Fig. 4.6 A list const fie = value;

would refer to the declaration in the external block, given that the name internally declared is no longer visible. However, also in these languages names must be declared before being used. So also in this case the following declarations const fie = value; const value = 0;

produce an error if value is not declared in an external block. Rule 3, which prescribes declaration before use, is particularly burdensome in some cases. Indeed, it forbids the definition of recursive types or mutually recursive procedures. Let us assume, for example, that we want to define a data type like a list which, as we know, is a variable-length data structure formed of a (possibly empty) ordered sequence of elements of some type and in which it is possible to add or remove elements. In a list, only the first element can be directly accessed (to access an arbitrary element, it is necessary to traverse the list sequentially). A list, as shown in Fig. 4.6, can be implemented using a sequence of elements, each of which is formed of two fields: the first will contain the information we want to store (for example, an integer); the second will contain a pointer to the next element of the list, if it exists, otherwise it stores the value nil if the list has ended. We can access the list using the pointer of the first element of the list (which is usually called the head). In Pascal, we can define the list type as follows: type list = ˆelement; type element = record information: integer; successor: list end

Here ˆT denotes the type of pointers to objects of type T. A value of type list is a pointer to an arbitrary element of the list. The value of type element corresponds to an element of the list, which is composed of an integer and by a field the type list which allows it to connect to the next element. This declaration is incorrect according to Rule 3. In fact, whatever the order of the declarations of list and element may be, it can be seen that we use a name which has not yet been defined. This problem is resolved in Pascal by relaxing Rule 3. For data of a pointer type, and only for them, is it permitted to refer to a name that has not yet been declared. The declaration given above for list are therefore correct in Pascal. In the case of C and Ada, on the other hand, the analogues of the previous declarations are not permitted. To specify mutually recursive types, it is necessary to

4.4 Chapter Summary

85

use incomplete declarations which introduce a name which will later be specified in full. For example, in Ada we can write: type element; type list is access element; type element is record information: integer; successor: list; end record;

This solves the problem of using a name before its declaration. The problem presents itself in the analogous case of the definition of mutually recursive procedures. Here, Pascal uses incomplete definitions. If procedure fie is to be defined in terms of procedure foo and vice versa, in Pascal, we must write: procedure fie(A:integer); forward; procedure foo(B: integer); begin ... fie(3); ... end procedure fie; begin ... foo(4); ... end

In the case of function names, it is strange to observe that C, on the other hand, allows the use of an identifier before its declaration. The declaration of mutually recursive functions does not require any special treatment. Rule 3 is relaxed in as many ways as there are programming languages. Java, for example, allows a declaration to appear at any point in a block. If the declaration is of a variable, the scope of the name being declared extends from the point of declaration to the end of the block (excluding possible holes in scope). If, on the other hand, the declaration refers to a member of a class (either a field or a method), it is visible in all classes in which it appears, independent of the order in which the declarations occur.

4.4 Chapter Summary In this chapter we have seen the primary aspects of name handling in high-level languages. The presence of the environment, that is of a set of associations between names and the objects they represent, constitute one of the principal characteristics that differentiate high-level from low-level languages. Given the lack of environment in low-level languages, name management, as well as that of the environment,

86

4 Names and The Environment

is an important aspect in the implementation of a high-level language. We will see implementation aspects of name management in the next chapter. Here we are interested in those aspects which must be known to every user (programmer) of a high-level language so that they fully understand the significance of names and, therefore, of the behaviour of programs. In particular, we have analysed the aspects that are listed below: • The concept of denotable objects. These are the objects to which names can be given. Denotable objects vary according to the language under consideration, even if some categories of object (for example, variables) are fairly general. • Environment. The set of associations existing at runtime between names and denotable objects. • Blocks. In-line or associated with procedures, these are the fundamental construct for structuring the environment and for the definition of visibility rules. • Environment Types. These are the three components which at any time characterise the overall environment: local environment, global environment and nonlocal environment. • Operations on Environments. Associations present in the environment in addition to being created and destroyed, can also be deactivated, a re-activated and, clearly, can be used. • Scope Rules. Those rules which, in every language, determine the visibility of names. • Static Scope. The kind of scope rule typically used by the most important programming languages. • Dynamic Scope. The scope rule that is easiest to implement. Used today in few languages. In an informal fashion, we can say that the rules which define the environment are composed of rules for visibility between blocks and of scope rules, which characterise how the non-local environment is determined. In the presence of procedures, the rules we have given are not yet sufficient to define the concept of environment. We will return to this issue in Chap. 7 (in particular at the end of Sect. 7.2.1).

4.5 Bibliographical Notes General texts on programming languages, such as for example [2, 3] and [4], treat the problems seen in this chapter, even if they are almost always viewed in the context of the implementation. For reasons of clarity of exposition, we have chosen to consider in this chapter only the semantic rules for name handling and the environment, while we will consider their implementation in the next chapter. For the rules used by individual languages, it is necessary to refer to the specific manuals, some of which are mentioned in bibliographical notes for Chap. 13, even if at times, as we have discussed in Sect. 4.3.3, not all the details are adequately clarified. The discussion in Sect. 4.3.3 draws on material from [1].

4.6 Exercises

87

4.6 Exercises Exercises 6–13, while really being centred on issues relating to scope, presuppose knowledge of parameter passing which we will discuss in Chap. 7. 1. Consider the following program fragment written in a pseudo-language which uses static scope and where the primitive read(Y) allows the reading of the variable Y from standard input. ... int X = 0; int Y; void fie(){ X++; } void foo(){ X++; fie(); } read(Y); if Y > 0{int X = 5; foo();} else foo(); write(X);

State what the printed values are. 2. Consider the following program fragment written in a pseudo-language that uses dynamic scope. ... int X; X = 1; int Y; void fie() { foo(); X = 0; } void foo(){ int X; X = 5; } read(Y); if Y > 0{int X; X = 4; fie();} else fie(); write(X);

State which is (or are) the printed values. 3. Consider the following code fragment in which there are gaps indicated by (*) and (**). Provide code to insert in these positions in such a way that:

88

4 Names and The Environment

a. If the language being used employs static scope, the two calls to the procedure foo assign the same value to x. b. If the language being used employs dynamic scope, the two calls to the procedure foo assign different values to x. The function foo must be appropriately declared at (*). {int i; (*) for (i=0; i 1. It is clear that the number of active calls to Fib depends, other than on the point of execution, on the value of the argument, n. Using a simple recurrence relation, it can be verified that the number, C(n), of calls to Fib necessary to calculate the value of the term Fib(n) (and, therefore, the simultaneously active calls) is exactly equal to this value. From a simple inspection of the code, indeed, it can be seen that C(n) = 1 for n = 0 and n = 1, while C(n) = C(n − 1) + C(n − 2) for n > 1. It is known that the Fibonacci numbers grow exponentially, so the number of calls to fib is of the order of O(2n ). Given that every procedure call requires its own memory space to store parameters, intermediate results, return addresses, and so on, in the presence of recursive procedures, static allocation of memory is no longer sufficient and we have to allow dynamic memory allocation and deallocation operations, which are performed during the execution of the program. Such dynamic memory processing can be implemented in a natural fashion using a stack for procedure (or in-line block) activations since they follow a LIFO (Last In First Out) policy—the last procedure called (or the last block entered) will be the first to be exited. There are, however, other cases which require dynamic memory management for which a stack is not enough. These are cases in which the language allows explicit memory allocation and deallocation operations, as happens, for example, in C with the malloc and free commands. In these cases, given that the allocation operation (malloc) and the one for deallocation (free) can be alternated in any order whatsoever, it is not possible to use a stack to manage the memory and, as we will better see as the chapter unfolds, a particular memory structure called a heap is used. 2 The sequence takes the name of the Pisan mathematician of the same name, known also as Leonardo da Pisa (ca., 1175–1250), who seems to have encountered the sequence by studying the increase in a population of rabbits. For information on inductive definition, see the box on page 153.

5.2 Static Memory Management

93

5.2 Static Memory Management Static memory management is performed by the complier before execution starts. Statically allocated memory objects reside in a fixed zone of memory (which is determined by the compiler) and they remain there for the entire duration of the program’s execution. Typical elements for which it is possible statically to allocate memory are global variables. These indeed can be stored in a memory area that is fixed before execution begins because they are visible throughout the program. The object code instructions produced by the compiler can be considered another kind of static object, given that normally they do not change during the execution of the program, so in this case also memory will be allocated by the compiler. Constants are other elements that can be handled statically (in the case in which their values do not depend on other values which are unknown at compile time). Finally, various compiler-generated tables, necessary for the runtime support of the language (for example, for handling names, for type checking, for garbage collection) are stored in reserved areas allocated by the compiler. In the case in which the language does not support recursion, as we have anticipated, it is possible statically to handle the memory for other components of the language. Substantially, this is done by statically associating an area of memory in which is stored the information local to the procedure with each procedure (or subroutine)3 itself. This information is composed of local variables, possible parameters of the procedure (containing both arguments and results), the return address (or the address to which control must pass when the procedure terminates), possible temporary values used in complex calculations and various pieces of “bookkeeping” information (saved register values, information for debugging and so on). The situation of a language with only static memory allocation is shown in Fig. 5.1. It will be noted that successive calls to the same procedure share the same memory areas. This is correct because, in the absence of recursion, there cannot be two different calls to the same procedure that are active at the same time.

5.3 Dynamic Memory Management Using Stacks Most modern programming languages allow block structuring of programs.4 Blocks, whether in-line or associated with procedures, are entered and left using the LIFO scheme. When a block A is entered, and then a block B is entered, before leaving A, it is necessary to leave B. It is therefore natural to manage the memory 3 It would be more correct to speak of subroutines because this was the term used in languages that used static memory allocation, such as, for example, the first versions of F ORTRAN from the 1960s and 70s. 4 We

will see below that important languages, such as C, though, do not offer the full potential of this mechanism, in that they do not permit the declaration of local procedures and functions in nested blocks.

94

5 Memory Management

Fig. 5.1 Static memory management

space required to store the information local to each block using a stack. We will see an example. Example 5.2 Let us consider the following program: A:{int a = 1; int b = 0; B:{int c = 3; int b = 3; } b=a+1; }

At runtime, when block A is entered, a push operation allocates a space large enough to hold the variables a and b, as shown in Fig. 5.2. When block B is entered, we have to allocate a new space on the stack for the variables c and b (recall that the inner variable b is different from the outer one) and therefore the situation, after this second allocation, is that shown in Fig. 5.3. When block B exits, on the other hand, it is necessary to perform a pop operation to deallocate the space that had been reserved for the block from the stack. The situation after such a deallocation and after the assignment is shown in Fig. 5.4. Analogously, when block A exits, it will be necessary to perform another pop to deallocate the space for A as well. The case of procedures is analogous and we consider it in Sect. 5.3.2. The memory space, allocated on the stack, dedicated to an in-line block or to an activation of a procedure is called the activation record, or frame. Note that an acti-

5.3 Dynamic Memory Management Using Stacks

95

Fig. 5.2 Allocation of an activation record for block A in Example 5.2

Fig. 5.3 Allocation of activation records for blocks A and B in Example 5.2

Fig. 5.4 Organisation after the execution of the assignment in Example 5.2

vation record is associated with a specific activation of a procedure (one is created when the procedure is called) and not with the declaration of a procedure. The values that must be stored in an activation record (local variables, temporary variables, etc.) are indeed different for the different calls on the same procedure. The stack on which activation records are stored is called the runtime (or system) stack.

96

5 Memory Management

Fig. 5.5 Organisation of an activation record for an in-line block

It should finally be noted, that to improve the use of runtime memory, dynamic memory management is sometimes also used to implement languages that do not support recursion. If the average number of simultaneously active calls to the same procedure is less than the number of procedures declared in the program, using a stack will save space, for there will be no need to allocate a memory area for each declared procedure, as must be done in the case of entirely static management.

5.3.1 Activation Records for In-line Blocks The structure of a generic activation record for an in-line block is shown in Fig. 5.5. The various sectors of the activation record contain the following information: Intermediate results When calculations must be performed, it can be necessary to store intermediate results, even if the programmer does not assign an explicit name to them. For example, the activation record for the block: {int a =3; b= (a+x)/ (x+y);}

could take the form shown in Fig. 5.6, where the intermediate results (a+x) and (x+y) are explicitly stored before the division is performed. The need to store intermediate results on the stack depends on the compiler being used and on the architecture to which one is compiling. On many architectures they can be stored in registers. Local variables Local variables which are declared inside blocks, must be stored in a memory space whose size will depend on the number and type of the variables. This information in general is recorded by the compiler which therefore will be able to determine the size of this part of the activation record. In some cases, however, there can be declarations which depend on values recorded only at runtime (this is, for example, the case for dynamic arrays, which are present in some languages, whose dimensions depend on variables which are only instantiated at execution time). In these cases, the activation record also contains a variable-length

5.3 Dynamic Memory Management Using Stacks

97

Fig. 5.6 An activation record with space for intermediate results

part which is defined at runtime. We will examine this in detail in Chap. 8 when discussing arrays. Dynamic chain pointer This field stores a pointer to the previous activation record on the stack (or to the last activation record created). This information is necessary because, in general, activation records have different sizes. Some authors call this pointer the dynamic link or control link. The set of links implemented by these pointers is called the dynamic chain.

5.3.2 Activation Records for Procedures The case of procedures and functions5 is analogous to that of in-line blocks but with some additional complications due to the fact that, when a procedure is activated, it is necessary to store a greater amount of information to manage correctly the control flow. The structure of a generic activation record for a procedure is shown in Fig. 5.7. Recall that a function, unlike a procedure, returns a value to the caller when it terminates its execution. Activation records for the two cases are therefore identical with the exception that, for functions, the activation record must also keep tabs on the memory location in which the function stores its return value. Let us now look in detail at the various fields of an activation record: Intermediate results, local variables, dynamic chain pointer The same as for in-line blocks. Static chain pointer This stores the information needed to implement the static scope rules described in Sect. 5.5.1. Return address Contains the address of the first instruction to execute after the call to the current procedure/function has terminated execution. Returned result Present only in functions. Contains the address of the memory location where the subprogram stores the value to be returned by the function when it terminates. This memory location is inside the caller’s activation record. Parameters The values of actual parameters used to call the procedure or function are stored here. The organisation of the different fields of the activation record varies from implementation to implementation. The dynamic chain pointer and, in general, every 5 Here

and below, we will almost always use the terms “function” and “procedure” as synonyms. Although there are is no agreement between authors, the term “procedure” should denote a subprogram which does not directly return a value, while a function is a subprogram that returns one.

98

5 Memory Management

Fig. 5.7 Structure of the activation record for a procedure

pointer to an activation record, points to a fixed (usually central) area of the activation record. The addresses of the different fields are obtained, therefore, by adding a negative or positive offset to the value of the pointer. Variable names are not normally stored in activation records and the compiler substitutes references to local variables for addresses relative to a fixed position in (i.e., an offset into) the activation record for the block in which the variables are declared. This is possible because the position of a declaration inside a block is fixed statically and the compiler can therefore associate every local variable with an exact position inside the activation record. In the case of references to non-local variables, also, as we will see when we discuss scope rules, it is possible to use mechanisms that avoid storing names and therefore avoid having to perform a runtime name-based search through the activationrecord stack in order to resolve a reference. Finally, modern compilers often optimise the code they produce and save some information in registers instead of in the activation record. For simplicity, in this book, we will not consider these optimisations. In any case for greater clarity, in the examples, we will assume that variable names are stored in activation records. To conclude, let us note that all the observations that we have made about variable names, their accessibility and storage in activation records, can be extended to other kinds of denotable object.

5.3 Dynamic Memory Management Using Stacks

99

5.3.3 Stack Management Figure 5.8 shows the structure of a system stack which we assume growing downwards (the direction of stack growth varies according to the implementation). As shown in the figure, an external pointer to the stack points to the last activation record on the stack (pointing to a predetermined area of the activation record which is used as a base for calculating the offsets used to access local names). This pointer, which we call the activation record pointer, is also called the frame or current environment pointer (because environments are implemented using activation records). In the figure, we have also indicated where the first free location is. This second pointer, used in some implementations, can, in principle, also be omitted if the activation-record pointer always points to a position that is at a pre-defined distance from the start of the free area on the stack. Activation records are stored on and removed from the stack at runtime. When a block is entered or a procedure is called, the associated activation record is pushed onto the stack; it is later removed from the stack when the block is exited or when the procedure terminates. The runtime management of the system stack is implemented by code fragments which the compiler (or interpreter) inserts immediately before and after the call to a procedure or before the start and after the end of a block. Let us examine in detail what happens in the case of procedures, given that the case of in-line blocks is only a simplification. First of all, let us clarify the terminology that we are using. We use “caller” and “callee” to indicate, respectively, the program or procedure that performs a call (of a procedure) and the procedure that has been called.

Fig. 5.8 The stack of activation records

100

5 Memory Management

Stack management is performed both by the caller and by the callee. To do this, as well as handling other control information, a piece of code called the calling sequence is inserted into the caller to be executed, in part, immediately before the procedure call. The remainder of this code is executed immediately after the call. In addition, in the callee two pieces of code are added: a prologue, to be executed immediately after the call, and an epilogue, which is executed when the procedure ends execution. These three code fragments manage the different operations needed to handle activation records and correctly implement a procedure call. The exact division of what the caller and callee do depends, as usual, on the compiler and on the specific implementation under consideration. Moreover, to optimise the size of code produced, it is preferable that the larger part of the activity is given to the callee, since the code is added only once (to the code associated with the declaration of the call) instead of many times (to the code associated with different calls). Without therefore further specifying the division of activities, they consist of the following tasks: Modification of program counter This is clearly necessary to pass control to the called procedure. The old value (incremented) must be saved to maintain the return address. Allocation of stack space The space for the new activation record must be preallocated and therefore the pointer to the first free location on the stack must be updated as a consequence. Modification of activation record pointer The pointer must point to the new activation record for the called procedure; the activation record will have been pushed onto the stack. Parameter passing This activity is usually performed by the caller, given that different calls of the same procedure can have different parameters. Register save Values for control processing, typically stored in registers, must be saved. This is the case, for example, with the old activation record pointer which is saved as a pointer in the dynamic chain. Execution of initialisation code Some languages require explicit constructs to initialise some items stored in the new activation record. When control returns to the calling program, i.e. when the called procedure terminates, the epilogue (in the called routine) and the calling sequence (in the caller) must perform the following operations: Update of program counter This is necessary to return control to the caller. Value return The values of parameters which pass information from the caller to the called procedure, or the value calculated by the function, must be stored in appropriate locations usually present in the caller’s activation record and accessible to the activation record of the called procedure. Return of registers The value of previously saved registers must be restored. In particular, the old value of the activation record pointer must be restored. Execution of finalisation code Some languages require the execution of appropriate finalisation code before any local objects can be destroyed.

5.4 Dynamic Management Using a Heap

101

Deallocation of stack space The activation record of the procedure which has terminated must be removed from the stack. The pointer to (the first free position on) the stack must be modified as a result. It should be noted that in the above description, we have omitted the handling of the data structures necessary for the implementation of scope rules. This will be considered in detail in Sect. 5.5 of this chapter.

5.4 Dynamic Management Using a Heap In the case in which the language includes explicit commands for memory allocation, as for example do C and Pascal, management using just the stack is insufficient. Consider for example the following C fragment: int *p, *q; /* p,q NULL pointers to integers p = malloc (sizeof (int)); /* allocates the memory pointed to by q = malloc (sizeof (int)); /* allocates the memory pointed to by *p = 0; /* dereferences and assigns */ *q = 1; /* dereferences and assigns */ free(p); /* deallocates the memory pointed free(q); /* deallocates the memory pointed

*/ p */ q */ to by p */ to by q */

Given that the memory deallocation operations are performed in the same order as allocations (first p, then q), the memory cannot be allocated in LIFO order. To manage explicit memory allocations, which can happen at any time, a particular area of memory, called a heap, is used. Note that this term is used in computing also to mean a particular type of data structure which is representable using a binary tree or a vector, used to implement efficiently priorities (and used also in the “heap sort” sorting algorithm, where the term “heap” was originally introduced). The definition of heap that we use here has nothing to do with this data structure. In the programming language jargon, a heap is simply an area of memory in which blocks of memory can be allocated and deallocated relatively freely. Heap management methods fall into two main categories according to whether the memory blocks are considered to be of fixed or variable length.

5.4.1 Fixed-Length Blocks In this case, the heap is divided into a certain number of elements, or blocks, of fairly small fixed length, linked into a list structure called the free list, as shown in Fig. 5.9. At runtime, when an operation requires the allocation of a memory block from the heap (for example using the malloc command), the first element of the free list is removed from the list, the pointer to this element is returned to the operation that

102

5 Memory Management

Fig. 5.9 Free list in a heap with fixed-size blocks

Fig. 5.10 Free list for heap of fixed-size blocks after allocation of some memory. Grey blocks are allocated (in use)

requested the memory and the pointer to the free list is updated so that it points to the next element. When memory is, on the other hand, freed or deallocated (for example using free), the freed block is linked again to the head of the free list. The situation after some memory allocations is shown in Fig. 5.10. Conceptually, therefore, management of a heap with fixed-size blocks is simple, provided that it is known how to identify and reclaim the memory that must be returned to the free list easily. These operations of identification and recovery are not obvious, as we will see below.

5.4 Dynamic Management Using a Heap

103

5.4.2 Variable-Length Blocks In the case in which the language allows the runtime allocation of variable-length memory spaces, for example to store an array of variable dimension, fixed-length blocks are no longer adequate. In fact the memory to be allocated can have a size greater than the fixed block size, and the storage of an array requires a contiguous region of memory that cannot be allocated as a series of blocks. In such cases, a heap-based management scheme using variable-length blocks is used. This second type of management uses different techniques, mainly defined with the aim of increasing memory occupation and execution speed for heap management operations (recall that they are performed at runtime and therefore impact on the execution time of the program). As usual, these two characteristics are difficult to reconcile and good implementations tend towards a rational compromise. In particular, as far as memory occupancy is concerned, it is a goal to avoid the phenomenon of memory fragmentation. So-called internal fragmentation occurs when a block of size strictly larger than the requested by the program is allocated. The portion of unused memory internal to the block clearly will be wasted until the block is returned to the free list. But this is not the most serious problem. Indeed, so-called external fragmentation is worse. This occurs when the free list is composed of blocks of a relatively small size and for which, even if the sum of the total available free memory is enough, the free memory cannot be effectively used. Figure 5.11 shows an example of this problem. If we have blocks of size x and y (words or some other unit—it has no relevance here) on the free list and we request the allocation of a block of greater size, our request cannot be satisfied despite the fact that the total amount of free memory is greater than the amount of memory that has been requested. The memory allocation techniques tend therefore to

Fig. 5.11 External fragmentation

104

5 Memory Management

“compact” free memory, merging contiguous free blocks in such a way as to avoid external fragmentation. To achieve this objective, merging operations can be called which increase the load imposed by the management methods and therefore reduce efficiency. Single free list The first technique we examine deals with a single free list, initially composed of a single memory block containing the entire heap. It is indeed convenient to seek to maintain blocks of largest possible size. It makes no sense, therefore, initially to divide the heap into many small blocks as, on the other hand, we did in the case of fixed-size blocks. When the allocation of a block of n words of memory is requested, the first n words are allocated and the pointer to the start of the head is incremented by n. Successive requests are handled in a similar way, in which deallocated blocks are collected on a free list. When the end of the heap’s memory space is reached, is necessary to reuse deallocated memory and this can be done in the two following ways: (i) Direct use of the free list In this case, a free list of blocks of variable size is used. When the allocation of a memory block n words in length is requested, the free list is searched for a block of size k words, where k is greater than or equal to n. The requested memory is allocated inside this block. The unused part of the block (of size k − n) if longer than some predefined threshold, is used to form a new block that is inserted into the free list (internal fragmentation is permitted below this threshold). The search for a block of sufficient size can be performed using one of two methods. Using first fit, the search is for the first block of sufficient size, while using best fit, the search is for a block whose size is the least of those blocks of sufficient size. The first technique favours processing time, while the second favours memory occupation. For both, however, the cost of allocation is linear with respect to the number of blocks on the free list. If the blocks are held in order of increasing block size, the two schemes are the same, because the list is traversed until a large enough block is found. Moreover, in this case, the cost of insertion of a block into the free list increases (from constant to linear), because is necessary to find the right place to insert it. Finally, when a deallocated block is returned to the free list, in order to reduce external fragmentation, a check is make to determine whether the physically adjacent blocks are free, in which case they are compacted into a single block. This type of compaction is said to be partial because it compacts only adjacent blocks. (ii) Free memory compaction In this technique, when the end of the space initially allocated to the heap is reached, all blocks that are still active are moved to the end; they are the blocks that cannot be returned to the free list, leaving all the free memory in a single contiguous block. At this point, the heap pointer is updated so that it points to the start of the single block of free memory and allocation starts all over again. Clearly, for this technique to work, the blocks of allocated memory must be movable, something that is not always guaranteed (consider blocks whose addresses are stored in pointers on the stack). Some compaction techniques will be discussed in Sect. 8.12, when we discuss garbage collection.

5.5 Implementation of Scope Rules

105

Multiple free lists To reduce the block allocation cost, some heap management techniques use different free lists for blocks of different sizes. When a block of size n is requested, the list that contains blocks of size greater than or equal to n is chosen and a block from this list is chosen (with some internal fragmentation if the block has a size greater than n). The size of the blocks in this case, too, can be static or dynamic and, in the case of dynamic sizes, two management methods are commonly used: the buddy system and the Fibonacci heap. In the first, the size of the blocks in the various free lists are powers of 2. If a block of size n is requested and k is the least integer such that 2k ≥ n, then a block of size 2k is sought (in the appropriate free list). If such a free block is found it is allocated, otherwise, a search is performed in the next free list for a block of size 2k+1 and it is split into two parts. One of the two blocks (which therefore has size 2k ) is allocated, while the other is inserted into the free list for blocks of size 2k . When a block resulting from a split is returned to the free list, a search is performed for its “buddy”, that is the other half that was produced by the split operation, and it is free, the two blocks are merged to re-form the initial block of size 2k+1 . The Fibonacci heap method is similar but uses Fibonacci numbers instead of powers of 2 as block sizes. Given that the Fibonacci sequence grows more slowly than the series 2n , this second method leads to less internal fragmentation.

5.5 Implementation of Scope Rules The possibility of denoting objects, even complex ones, by names with appropriate visibility rules constitutes one of the most important aspects that differentiate high-level languages from low-level ones. The implementation of environments and scope rules discussed in Chap. 4 requires, therefore, suitable data structures. In this section, we analyse these structures and their management. Given that the activation record contains the memory space for local names, when a reference to a non-local name is encountered, the activation records that are still active must be examined (that is, the ones present on the stack) in order to find the one that corresponds to the block where the name in question was declared; this will be the block that contains the association for our name. The order in which to examine the activation records varies according to the kind of scope under consideration.

5.5.1 Static Scope: The Static Chain If the static scope rule is employed, as we anticipated in Chap. 4, the order in which activation records are consulted when resolving non-local references is not the one defined by their position on the stack. In other words, the activation record directly connected by the dynamic chain pointer is not necessarily the first activation record in which to look in order to resolve a non-local reference; the first activation record within which to look is defined by the textual structure of the program. Let us see an example.

106

5 Memory Management

Fig. 5.12 Activation stack with static chain (see Example 5.3)

Example 5.3 Consider the following code (as usual, for ease of reference, we have labelled the blocks): A:{int y=0; B:{int x = 0; void (int n){ x = n+1; y = n+2; } C:{int x = 1; fie(2); write(x); } } write(y); }

After executing the call fie(2), the situation on the activation-record stack is that shown in Fig. 5.12. The first activation record on the stack (the uppermost one in the figure) is for the outermost block; the second is the one for block B; the third is for C and finally the fourth is the activation record for the call to the procedure. The non-local variable, x, used in procedure fie, as we know from the static scope rule is not the one declared in block C but the one declared in block B. To be able

5.5 Implementation of Scope Rules

107

Fig. 5.13 A block structure

to locate this information correctly at runtime, the activation record for the call to the procedure is connected by a pointer, called the static chain pointer, to the record for the block containing the declaration of the variable. This record is linked, in its turn, by a static chain pointer to the record for block A, because this block, being the first immediately external to B, is the first block to be examined when resolving references non-local to B. When inside the call to procedure fie, the variables x and y are used, to access the memory area in which they are stored the static chain pointers are followed from fie’s activation record until first the record for B is encountered (for x) and then that for A (when searching for y). Generalising this example, we can say that, for the runtime management of static scope, the activation of the generic block B is linked by the static chain pointer to the record for the block immediately enclosing B (that is the nearest block that contains B). It should be noted that in the case in which B is the block for a procedure call, the block immediately enclosing B is the one containing the declaration of the procedure itself. Moreover if B is active, that is if its activation record is on the stack, then also the blocks enclosing B must be active and therefore can be located on the stack. Hence, in addition to the dynamic chain, which is formed from the various records present on the system stack (linked in the order of the stack itself), there must exist a static chain, formed from the various static chain pointers used to represent the static nesting structure of the blocks within the program. As an example, consider Fig. 5.13 which shows a generic structure of blocks which results from nested procedures. Consider now the sequence of calls: A, B, C, D, E, C, where it is intended that each call remains active when the next call is made. The situation on the activation-record stack, with is various static chain pointers, after such a sequence of calls is that shown in Fig. 5.14. The runtime management of the static chain is one of the functions performed by the calling sequence, prologue and epilogue code, as we saw above. Such a management of the static chain can be performed by the caller and the callee in various ways. According to the most common approach, when a new block is entered, the caller calculates the static chain pointer and then passes it to the called routine. This

108

5 Memory Management

Fig. 5.14 Static chain for the previous structure and the sequence of calls A, B, C, D, E, C

computation is fairly simple and can be easily understood by separating the two cases: The called routine is external to the caller In this case, by the visibility rules defined by static scope, for the called routine to be visible, it must be located in an outer block which includes the caller’s block. Therefore, the activation record for such an outer block must already be stored on the stack. Assume that among the caller and the called routines, there are k levels of nesting in the program’s block structure; if the caller is located on nesting level n and the called routine is on level m, we can assume therefore that k = n − m. This value of k can be determined by the compiler, because it depends only on the static structure of the program and therefore can be associated with the call in question. The caller can then calculate the static chain pointer for the called procedure simply by dereferencing its own static chain pointer k times (that is, it runs k steps along its own static chain). Called inside calling routine In this case, the visibility rules ensure that the called routine is declared in same the block in which the call occurs and therefore the first block external to the called one is precisely that of the caller. The static chain pointer of the called routine must point to the caller’s activation record. The caller can simply pass to the called routine the pointer to its own activation record as a pointer to the static chain. Once the called routine has received the static chain pointer, it need only store it in the appropriate place in its activation record, an operation that can be performed by the prologue code. When a block exit occurs, the static chain requires no particular management actions. We have hinted at the fact that the compiler, in order to perform runtime staticchain management, keeps track of the nesting level of procedure calls. This is done using the symbol table, a sort of dictionary where, more generally, the compiler stores all the names used in the program and all the information necessary to manage the objects denoted by the names (for example to determine the type) and to implement the visibility rules. In particular, a number is maintained that depends on the nesting level and indicates the scope that contains the declaration of a name; this allows to associate to

5.5 Implementation of Scope Rules

109

each name a number indicating the scope when the declaration for such a name is made. Using this number, it is possible to calculate, at compile time, the distance between the scope of the call and that of the declaration which is necessary at runtime to handle the static chain. It should be noted that this distance is calculated statically and it also allows the runtime resolution of non-local references without having to perform any name searches in the activation record on the stack. Indeed, if we use a reference to the non-local name, x, to find the activation record containing the memory space for x it suffices to start at the activation record corresponding to the block that contains the reference and follow the static chain for a number of links equal to the value of the distance. Inside the activation record that is thus found, the memory location for x is also fixed by the compiler and, therefore, at runtime, there is no need for a search but only the static offset of x with respect to the activation record pointer is needed. However, it is clear that, in a static model, the compiler cannot completely resolve a reference to a non-local name and it is always necessary to follow the static-chain links at runtime. This is why, in general, it is not possible to know statically what the number of activation records present on the stack is. As a concrete example of what has just been said, consider the code in Example 5.3. The compiler “knows” that to use variable y in procedure fie, it is necessary to pass two external blocks (B and A) to arrive at the one containing the declaration of the variable. It is enough, therefore, to store this value at compilation time so that it can subsequently be known, at runtime, that to resolve the name y, it is necessary to follow two pointers in the static chain. It is not necessary to store the name y explicitly because its position inside the activation record for the block A is fixed by the compiler. Analogously, the type information that we, for clarity, have included in Fig. 5.12, is stored in the symbol table, and after appropriate compiletime checks, can, in a large part, be omitted at runtime.

5.5.2 Static Scope: The Display The implementation of static scope using the static chain has one inconvenient property: if we have to use a non-local name declared in an enclosing block, k levels of block away from the point at which we currently find ourselves, at runtime we have to perform k memory accesses to follow the static chain to determine the activation block that contains the memory location for the name of interest. This problem is not all that severe, given that in real programs it is rare that more than 3 levels of block and procedure nesting are required. The technique called the display, however, allows the reduction of the number of accesses to a constant (2). This technique uses a vector, called the display, containing as many elements as there are levels of block nesting in the program, where the kth element of the vector contains the pointer to the activation record at nesting level k that is currently active. When a reference is made to a non-local object, declared in an block

110

5 Memory Management

Fig. 5.15 Display for the structure in Fig. 5.13 and the call sequence A, B, C, D, E, C

external to level k, the activation record containing this object can be retrieved simply by accessing the kth position in the vector and following the pointer stored there. Display processing is very simple, even if it is slightly more costly than static chain handling; when an environment is entered or left, in addition to updating the pointer stored in the vector, it is also necessary to save the old value. More precisely, when a procedure is called (or an in-line block is entered) at level k, position k in the

5.5 Implementation of Scope Rules

111

display will have to be updated with the value of the pointer to the activation record for the call, because this has become the new active block at level k. Before this update, however, it is necessary to save the preceding contents of the kth position of the display, normally storing it in the activation record of the call. The need to save the old display value can be better understood by examining the following 2 possible cases: The called routine is external to the caller Let use assume that the call is at nesting level n and the called routine is at level m, with m < n. The called routine and the caller therefore share the static structure up to level m − 1 and also the display up to position m − 1. Display element m is updated with the pointer to the activation record of the called routine and until the called routine terminates, the active display is the one formed of the first m elements. The old value contained in position m must be saved because it points to the activation record of the block which will be re-activated when the called routine terminates; thereafter, the display will go back to being the one used before the call. The called routine is located inside the caller The nesting depth reached this far is incremented. If the caller is located at level n, caller and called routine share the whole current display up to position n and it is necessary to add a new value at position n + 1, so that it holds the pointer to the activation record for the caller. When we have the first activation of a block at level n + 1, the old value stored in the display is of no interest to us. However, in general, we cannot know if this is the case. Indeed, we could have reached the current call by a series of previous calls that also use level n + 1. In this case, as well, it will be necessary therefore to store the old value in the display at position n + 1.

Both display update and the saving of the old value can be performed by the called procedure. Figure 5.15 shows the handling of the display for the call sequence A, B, C, D, E, C, using the block structure described in Fig. 5.13. The pointers on the left of the stack denote storage of the old display value in the activation record of the called routine, while the dotted pointer denotes a display pointer that is not currently active.

5.5.3 Dynamic Scope: Association Lists and CRT Conceptually, the implementation of the dynamic scope rule is much simpler than the one for static scope. Indeed, given that non-local environments are considered in the order in which they are activated at runtime, to resolve a non-local reference to a name x, it suffices, at least in principle, to run backwards down the stack, starting with the current activation record until the activation record is found in which the name x is declared. The various associations between names and the objects they denote which constitute the various local environment can be stored directly in the activation record. Let us consider, for example, the block structure shown in Fig. 5.16, where the

112

5 Memory Management

Fig. 5.16 A block structure with local declarations

Fig. 5.17 Environment for block D in Fig. 5.16 after the call sequence A, B, C, D, with dynamic scope implemented using stored associations in the activation record. In grey: inactive associations

names denote local variable declarations (assuming the usual visibility rules). If we execute the call sequence A, B, C, D (where, as usual, all the calls remain active) when control reaches block D, we obtain the stack shown in Fig. 5.17 (the field on the right of each name contains the information associated with the object denoted by its name). The environment (local or otherwise) of D is formed from all the name-denoted object associations in which the information field is in white in the figure. The association fields that are no longer active are shown in grey. An association is not active either because the corresponding name is no longer visible (this is the case for v) or because it has been redefined in an inner block (this is the case for w and for the occurrences of x in A and B). Other than direct storage in the activation record, name-object associations can be stored separately in an association list, called an A-list, which is managed like a stack. This solution is usually chosen for L ISP implementations.

5.5 Implementation of Scope Rules

113

Fig. 5.18 Environment for block D in Fig. 5.16, after the call sequence A, B, C, D, with dynamic scope implemented using an A-list

When the execution of a program enters a new environment, the new local associations are inserted into the A-list. When an environment is left, the local associations are removed from the A-list. The information about the denoted objects will contain the location in memory where the object is actually stored, its type, a flag which indicates whether the association for this object is active (there can also be other information needed to make runtime semantic checks). Figure 5.18 shows how dynamic scope is implemented for the example in Fig. 5.16 using an A-list (the fields in grey are implemented using the flags described above and are omitted from the figure). Both using A-list and using direct storage in the activation record, the implementation of dynamic scope has two disadvantages. First, names must be stored in structures present at runtime, unlike in the scheme that we saw for static scope. In the case of the A-list, this is clear (it depends on its definition). In the case, on the other hand, in which activation records are used to implement local environments, the need to store names depends on the fact that the same name, if declared in different blocks, can be stored in different positions in different activation records. Given that we are using the dynamic scope rule, we cannot statically determine which is the block (and therefore the activation record) that can be used to resolve a non-local reference; we cannot know the position in the activation record to access in order to search for the association belonging the name that we are looking for. The only possibility is therefore explicitly to store the name and perform a search (based on the name itself) at runtime. The second disadvantage is due to the inefficiency of this runtime search. It can often be the case that is necessary to scan almost all of the list (which is either

114

5 Memory Management

an A-list or a stack of activation records) in the case reference is made to a name declared in one of the first active blocks (as for “global” names). Central Referencing environment Table (CRT) To restrict the effects of these two disadvantages, at the cost of a greater inefficiency in the block entry and exit operations, we can implement dynamic scope in a different way. This alternative approach is based on the Central Referencing environment Table (CRT). Using the CRT-based technique, environments are defined by arranging for all the blocks in the program to refer to an single central table (the CRT). All the names used in the program are stored in this table. For each name, there is a flag indicating whether the association for the name is active or not, together with a value composed of a pointer to information about the object associated with the name (memory location, type, etc.). If we assume that all the identifiers used in the program are not known at compile time, each name can be given a fixed position in the table. At runtime, access to the table can, therefore, take place in constant time by adding the memory address of the start of the table to an offset from the position of the name of interest. When, on the other hand, all names are not known at compile time, the search for a name’s position in the table can be make use of runtime hashing for efficiency. The block entry and exit operations now are, however, more complicated. When entering block B from block A, the central table must be modified to describe B’s new local environment, and, moreover, deactivated associations must be saved so that they can be restored when block B exits and control returns to block A. Usually a stack is the best data structure for storing such associations. It should be observed that the associations for a block are not necessarily stored in contiguous locations within the CRT. To perform the operations required of the CRT on block entry and exit, it is necessary, therefore,to consider the individual elements of the table. This can be done in a convenient fashion by associating with each entry in the table (i.e., with every name present) a dedicated stack that contains the valid associations at the top and, in successive locations, the associations for this name that have been deactivated. This solution is shown in Fig. 5.19 (the second column contains the flags). Alternatively, we can use a single hidden stack separate from the central table to store the deactivated associations for all names. In this case, for every name, the second column of the table contains a flag which indicates whether the association for this name is active or not, while the third column contains the reference to the object denoted by the name in question. When an association is deactivated, it is stored in the hidden stack to be removed when it becomes active again. Considering the structure in Fig. 5.16 and the call sequence A, B, C, D, the development of the CRT is shown in the upper part of Fig. 5.20; the lower portion of the Figure depicts the evolution of the hidden stack. Using the CRT, with or without the hidden stack. access to an association in the environment requires one access to the table (either direct or by means of a hash function) and one access to another memory area by means of the pointer stored in the table. Therefore, no runtime search is required.

5.6 Chapter Summary

115

Fig. 5.19 Environment for block D in Fig. 5.16 after the call sequence A, B, C, D, with dynamic scope implemented using a CRT Fig. 5.20 Environment for block D of Fig. 5.16 after the call sequence A, B, C, D, with dynamic scope implemented using a CRT and hidden stack

5.6 Chapter Summary In this chapter, we have examined the main techniques for both static and dynamic memory management, illustrating the reasons for dynamic memory management using a stack and those that require the use of a heap. It remains to consider the important exception to this: in the presence of a particular type of recursion (called tail recursion) memory can be managed in a static fashion (this case will be given detailed consideration in the next chapter). We have illustrated in detail the following on stack-based management: • The format of activation records for procedures and in-line blocks. • How the stack is managed by particular code fragments which are inserted into the code for the caller, as well as in the routine being called, and which act to implement the various operations for activation record allocation, initialisation, control field modification, value passing, return of results, and so on. In the case of heap-based management, we saw: • Some of the more common techniques for its handling, both for fixed- and variable-sized blocks. • The fragmentation problem and some methods which can be used to limit it.

116

5 Memory Management

Finally, we discussed the specific data structures and algorithms used to implement the environment and, in particular, to implement scope rules. We examined the following in detail: • • • •

The static chain. The display. The association list. The central referencing table.

This has allowed us better to understand our hint in Chap. 4 that it is more difficult to implement the static scope rules than those for dynamic scope. In the first case, indeed, whether static chain pointers or the display is used, the compiler makes use of appropriate information on the structure of declarations. This information is gathered by the compiler using symbol tables and associated algorithms, such as, for example, LeBlanc-Cook’s, whose details fall outside the scope of the current text. In the case of dynamic scope, on the other hand, management can be, in principle, performed entirely at runtime, even if auxiliary structures are often used to optimise performance (for example the Central Referencing Table).

5.7 Bibliographic Notes Static memory management is usually treated in textbooks on compilers, of which the classic is [1]. Determination of the (static) scopes to associate with the names in a symbol table can be done in a number of ways, among which one of the best known is due to LeBlanc and Cook [2]. Techniques for heap management are discussed in many texts, for example [4]. Stack-based management for procedures and for scope was introduced in A L GOL , whose implementation is described in [3]. For memory management in various programming languages, the reader should refer to texts specific to each language, some which are cited at the end of Chap. 13.

5.8 Exercises 1. Using some pseudo-language, write a fragment of code such that the maximum number of activation records present on the stack at runtime is not statically determinable. 2. In some pseudo-language, write a recursive function such that the maximum number of activation records present at runtime on the stack is statically determinable. Can this example be generalised? 3. Consider the following code fragment: A:{int X= 1; ....

5.8 Exercises

117

B:{ X = 3; .... } .... }

Assume that B is nested one level deeper that A. To resolve the reference to X present in B, why is it not enough to consider the activation record which immediate precedes that of B on the stack? Provide a counter-example filling the spaces in the fragment with dots with appropriate code. 4. Consider the following program fragment written in a pseudo-language using static scope: void P1 { void P2 { body-ofi-P2 } void P3 { void P4 { body-of-P4 } body-of-P3 } body-of-P1 }

Draw the activation record stack region that occurs between the static and dynamic chain pointers when the following sequence of calls, P1, P2, P3,P4,P2 has been made (is it understood that at this time they are all active: none has returned). 5. Given the following code fragment in a pseudo-language with goto (see Sect. 6.3.1), static scope and labelled nested blocks (indicated by A: { ... }): A: { int x = 5; goto C; B: {int x = 4; goto E; } C: {int x = 3; D: {int x = 2; } goto B; E: {int x = 1; // (**) } } }

The static chain is handled using a display. Draw a diagram showing the display and the stack when execution reaches the point indicated with the comment (**). As far as the activation record is concerned, indicate what the only piece of information required for display handling is.

118

5 Memory Management

6. Is it easier to implement the static scope rule or the one for dynamic scope? Give your reasons. 7. Consider the following piece of code written in a pseudo-language using static scope and call by reference (see Sect. 7.1.2): {int x = 0; int A(reference int y) { int x =2; y=y+1; return B(y)+x; } int B(reference int y){ int C(reference int y){ int x = 3; return A(y)+x+y; } if (y==1) return C(x)+y; else return x+y; } write (A(x)); }

Assume that static scope is implemented using a display. Draw a diagram showing the state of the display and the activation-record stack when control enters the function A for the second time. For every activation record, just give value for the field that saves the previous value of the display.

References 1. A. V. Aho, R. Sethi, and J. D. Ullman. Compilers: Principles, Techniques, and Tools. AddisonWesley, Reading, 1988. 2. R. P. Cook and T. J. LeBlanc. A symbol table abstraction to implement languages with explicit scope control. IEEE Trans. Softw. Eng., 9(1):8–12, 1983. 3. B. Randell and L. J. Russell. Algol 60 Implementation. Academic Press, London, 1964. 4. C. Shaffer. A Practical Introduction to Data Structures and Algorithm Analysis. AddisonWesley, Reading, 1996.

Chapter 6

Control Structure

In this chapter, we will tackle the problem of managing sequence control, an important part in defining the execution of program instructions in a generic abstract machine’s interpreter. In low-level languages, sequence control is implemented in a very simple way, just by updating the value of the PC (Program Counter) register. In high-level languages, however, there are special language-specific constructs which permit the structuring of control and the implementation of mechanisms that are much more abstract than those available on the physical machine. One thinks, for example, of the simple evaluation of an arithmetic expression: even if we find them obvious and natural, operations of this kind requires the use of control mechanisms that specify the order in which operands are evaluated, and operator precedence, and so on. In this chapter, we will consider the constructs used in programming languages for the explicit or implicit specification of sequence control. We will first consider expressions, spending some time on the syntactic aspects of the usual notation for representing expressions, as well as the semantic aspects of their evaluation. We will then move on to commands and, after discussing the concepts of variable and assignment, we will see the main commands for sequence control present in modern languages, showing the difference between structured and unstructured control and briefly illustrating the principles of structured programming. We will finally examine some aspects that are significant to recursion and clarify an important terminological distinction between imperative and declarative languages. We will leave the examination of those constructs that allow the implementation of mechanisms for control abstraction until the next chapter.

6.1 Expressions Expressions, together with commands and declarations, are one of the basic components of every programming language. We can say that expressions are the essential component of every language because, although there exist declarative languages in M. Gabbrielli, S. Martini, Programming Languages: Principles and Paradigms, Undergraduate Topics in Computer Science, DOI 10.1007/978-1-84882-914-5_6, © Springer-Verlag London Limited 2010

119

120

6 Control Structure

which commands are absent, expressions, numeric or symbolic, are present in every language. First, let us try to clarify what sorts of object we are talking about. Definition 6.1 (Expressions) An expressions is a syntactic entity whose evaluation either produces a value or fails to terminate, in which case the expression is undefined. The essential characteristic of an expression, that which differentiates it from a command, is therefore that its evaluation produces a value. Examples of numerical expressions are familiar to all: 4+3*2, for example, is an expression whose evaluation is obvious. Moreover, it can be seen that, even in such a simple case, in order to obtain the correct result, we have made an implicit assumption (derived from the mathematical convention) about operator precedence. This assumption, which tells us that * has precedence over + (and that, therefore, the result of the evaluation is 10 and not 14), specifies a control aspect for evaluation of expressions. We will see below other more subtle aspects that can contribute to modify the result of the evaluation of an expression. Expressions can be non-numeric, for example in L ISP, we can write (cons a b) to denote an expression which, if it is evaluated, returns the so-called pair formed by a and b.

6.1.1 Expression Syntax In general, an expression is composed of a single entity (constant, variable, etc.) or even of an operator (such as +, cons, etc.), applied to a number of arguments (or operands) which are also expressions. We saw in Chap. 2 how expression syntax can be precisely described by a context-free grammar and that an expression can be represented by a derivation tree in which, in addition to syntax, there is also semantic information relating to the evaluation of the expression. Tree structures are also often used to represent an expression internally inside the computer. However, if we want to use expressions in a conventional way in the text of a program, linear notations allow us to write an expression as a sequence of symbols. Fundamentally, the various notations differ from each other by how they represent the application of an operator to its operands. We can distinguish three main types of notation. Infix Notation In this notation, a binary operation symbol is placed between the expressions representing its two operands. For example, we write x+y to denote than the addition of x and y, or (x+y)*z to denote the multiplication by z of the result of the addition of x and y. It can be seen that, in order to avoid ambiguity in the application of operator to operands, brackets and precedence rules are required. For operators other than binary ones, we must basically fall back on their representation in terms of binary symbols, even if, in this case, this representation is not

6.1 Expressions

121

Lisp and S-expressions The programming language L ISP (an acronym of LISt Processor), which was developed at the beginning of the 1960s by John McCarthy and by a group of researchers at MIT (Massachusetts Institute of Technology), is a language designed for symbolic processing, which has been particularly important in Artificial Intelligence. In particular, in the 1970s, the language Scheme was developed from a dialect of Lisp; Scheme is still in use in academic circles. A Lisp program is composed of sequences of expressions to be evaluated by the language’s interpreter. Some expressions are used to define functions which are then called in other expressions. Control is exercised using recursion (there is no iterative construct). As the very name of the language implies, a L ISP program mainly handles expressions constructed from lists. The basic data structures in L ISP, in fact, is the dotted pair, or rather a pair of data items written with a dot separating the two components: for example, (A.B). A pair like this is implemented as a cons cell, or rather by the application of the cons operator to two arguments, as in (cons A B). As well as atomic types (integers, floating point numbers, character strings), the two arguments of cons can be other dotted pairs so this data structure allows the implementation of symbolic expressions, so-called S-expressions. S-expressions are binary trees which allow the representation of lists as a particular case. For example, it is possible to construct the list A B C as (cons A (cons B (cons C nil))), where nil is a particular value denoting the empty list. Among the many interesting characteristics of L ISP, programs and data are represented using the same syntax and the same internal representation. This allows the evaluation of data structures as if they were programs and to modify programs as if they were data.

the most natural. A programming language which insists on infix notation even for user-defined functions is Smalltalk, an object oriented language. Infix notation is the one most commonly used in mathematics, and, as a consequence is the one used by most programming languages, at least for binary operators and for user syntax. Often, in fact, this notation is only an abbreviation or, as we say, a syntactic sugar used to make code more readable. For example, in Ada, a + b is an abbreviation for +(a,b), while in C++ the same expression is an abbreviation for a.operator+(b). Prefix Notation Prefix notation is another type of notation. It is also called prefix Polish notation.1 The symbol which represents the operation precedes the symbols representing the operands (written from left to right, in the same way as text). Thus, to write the sum of x and y, we can write +(x,y), or, without using parentheses, 1 This terminology derives from the fact that the Polish mathematician W. Łukasiewicz was the person to make prefix notation without parentheses fashionable.

122

6 Control Structure

+ x y, while if we want to write the application of the function f to the operands a and b, we write f(a b) or fab. It is important to note that when using this kind of notation, parentheses and operator precedence rules are of no relevance, provided that the arity (that is the number of operands) of every operator is already known. In fact there is no ambiguity about which operator to apply to any operands, because it is always the one immediately preceding the operands. For example if we write: *(+(a b)+(c d))

or even * + a b + c d

we mean the expression represented by (a+b)*(c+d) in normal infix notation. The majority of regular languages use prefix notation for unary operators (often using parentheses to group arguments) and for user-defined functions. Some programming languages even use prefix notation for binary operators. L ISP represents functions using a particular notation known as Cambridge Polish, which places operators inside parentheses. In this notation, for example the last expression becomes: (*(+ a b)(+ c d)).

Postfix Notation Postfix notation is also called Reverse Polish. It is similar to the last notation but differs by placing the operator symbol after the operands. For example, the last expression above when written in postfix notation is: a b + c d + *.

Prefix notation is used in the intermediate code generated by some compilers. It is also used in programming languages (for example Postscript). In general, an advantage of Polish notation (prefix or otherwise) over infix is that the former can be used in a uniform fashion to represent operators with any number of operands. In infix notation, on the other had, representing operators with more than two operands means that we have to introduce auxiliary operators. A second advantage, already stated, is that there is the possibility of completely omitting parentheses even if, for reasons of readability, both mathematical prefix notation f(a b) and Cambridge Polish (f a b) use parentheses. A final advantage of Polish notation, as we will see in the next subsection is that it makes the evaluation of an expression extremely simple. For this reason, this notation became rather successful during the 1970s and 80s when it was used for the first pocket-sized calculators.

6.1 Expressions

123

6.1.2 Semantics of Expressions According to the way in which an expression is represented, the way in which its semantics is determined changes and so, consequently, does its method of evaluation. In particular, in infix representation the absence of parentheses can cause ambiguity problems if the precedence rules for different operators and the associativity of every binary operator are not defined clearly. When considering the most common programming languages, it is also necessary to consider the fact that expressions are often represented internally in the form of a tree. In this section we will discuss these problems, starting with the evaluation of expressions in each of the three notations that we saw above. Infix Notation: Precedence and Associativity When using infix notation, we pay for the facility and naturalness of use with major complication in the evaluation mechanism for expressions. First of all, if parentheses are not used systematically, it is necessary to clarify the precedence of each operator. If we write 4 + 3 * 5, for example, clearly we intend the value of 19 as the result of the expression and not 35: mathematical convention, in fact, tells us that we have to perform the multiplication first, and the addition next; that is, the expression is to be read as 4 + (5 * 3) and not as (4 + 3) * 5. In the case of less familiar operators, present in programming languages, matters are considerably more complex. If, for example, in Pascal one writes: x=4 and y=5

where the and is the logical operator, contrary to what many will probably expect, we will obtain an error (a static type error) because, according to Pascal’s precedence rules, this expression can be interpreted as x=(4 and y)=5

and not as (x=4) and (y=5).

In order to avoid excessive use of parentheses (which, when in doubt it is good to use), programming languages employ precedence rules to specify a hierarchy between the operators used in a language based upon the relative evaluation order. Various languages differ considerably in their definition of such rules and the conventions of mathematical notation are not always respected to the letter. A second problem in expression evaluation concerns operator associativity. If we write 15-5-3, we could intend it to be read as either (15-5)-3 or as 15-(5-3), with clearly different results. In this case, too, mathematical convention says that the usual interpretation is the first. In more formal terms, the operator “−” associates

124

6 Control Structure

from left to right.2 In fact, the majority of arithmetic operators in programming languages associate from left to right but there are exceptions. The exponentiation operator, for example, often associates from right to left, as in mathematical nota2 tion. If we write 53 , or, using a notation more familiar to programmers, 5 ** 3 2 ** 2, we mean 5(3 ) , or 5 ** (3 ** 2), and not (53 )2 , or ((5 ** 3) ** 2). Thus, when an operator is used, it is useful to include parentheses when in doubt about precedence and associativity. In fact, there is no lack of special languages that in this respect have rather counter-intuitive behaviour. In APL, for example, the expression 15-5-3 is interpreted as 15 -(5 - 3) rather than what we would ordinarily expect. The reason for this apparent strangeness is that in APL there are many new operators (defined to operate on matrices) that do not have an immediate equivalents in other formalisms. Hence, it was decided to abandon operator precedence and to evaluate all expressions from right to left. Even if there is no difficulty in conceiving of a direct algorithm to evaluate an expression in infix notation, the implicit use of precedence and associativity rules, together with the explicit presence of parentheses, complicates matters significantly. In fact, it is not possible to evaluate an expression in a single left-to-right scan (or one from right to left), given that in some cases we must first evaluate the rest of the expression and then return to a sub-expression of interest. For example, in the case of 5+3*2, when the scan from left to right arrives at +, we have to suspend the evaluation of this operator but divert to the evaluation of 3*2 and then go back to the evaluation of +. Prefix Notation Expressions written in prefix Polish notation lend themselves to a simple evaluation strategy which proceeds by simply walking the expression from left to right using a stack to hold its components. It can be assumed that the sequence of symbols that forms the expression is syntactically correct and initially not empty. The evaluation algorithm is described by the following steps, where we use an ordinary stack (with the push and pop operations) and a counter C to store the number of operands requested by the last operator that was read: 1. Read in a symbol from the expression and push it on the stack; 2. If the symbol just read is an operator, initialise the counter C with the number of arguments of the operator and go to step 1. 3. If the symbol just read it is an operand, decrement C. 4. If C ̸= 0, go to 1. 5. If C = 0, execute the following operations: (a) Apply the last operator stored on the stack to the operands just pushed onto the stack, storing the results in R, eliminate operator and operands from the stack and store the value of R on the stack. (b) If there is no operator symbol in the stack go to 6. 2 A binary operator, op, is said to be associative if x op (y op z) = (x op y) op z holds; that is, whether it associates from the right to the left or left to right makes no difference.

6.1 Expressions

125

(c) Initialise the counter C to n − m, where n is the number of the argument of the topmost operator on the stack, and m is number of operands present on the stack above this operator. (d) Go to 4. 6. If the sequence remaining to be read is not empty, go to 1. The result of the evaluation is located on the stack when the algorithm finishes. It should be noted that the evaluation of an expression using this algorithm assumes that we know in advance the number of operands required by each operator. This requires that we syntactically distinguish unary from binary operators. Furthermore, it is generally necessary to check that the stack contains enough operands for the application of the operator (Step 5.(c) in the algorithm above). This check is not required when using postfix notation, as we see below. Postfix Notation The evaluation of expression in Polish notation is even simpler. In fact, we do not need to check that all the operands for the last operator have been pushed onto the stack, since the operands are read (from left to right) before the operators. The evaluation algorithm is then the following (as usual, we assume that the symbol sequence is syntactically correct and is not empty): 1. Read the next symbol in the expression and push it on the stack. 2. If the symbol just read is an operator apply it to the operands immediately below it on the stack, store the result in R, pop operator and operands from the stack and push the value in R onto the stack. 3. If the sequence remaining to be read is not empty, go to 1. 4. If the symbol just read is an operand, go to 1. This algorithm also requires us to know in advance the number of operands required by each operator.

6.1.3 Evaluation of Expressions As we saw the start of the Chap. 2 and as we extensively discussed in that chapter, expressions, like the other programming language constructs, can be conveniently represented by trees. In particular, can be represented by a tree (called the expression’s syntax tree) in which: • Every non-leaf node is labelled with an operator. • Every subtree that has as root a child of a node N constitutes an operand for the operator associated with N . • Every leaf node is labelled with a constant, variable or other elementary operand.

Trees like this can be directly obtained from the derivation trees of an (unambiguous) grammar for expressions by eliminating non-terminal symbols and by appropriate rearrangement of the nodes. It can be seen also that, given the tree representation, the linear infix, prefix and postfix representations can be obtained by traversing

126

6 Control Structure

Fig. 6.1 An expression

the tree in a symmetric, prefix or postfix order, respectively. The representation of expressions as trees clarifies (without needing parentheses) precedence and associativity of operators. The subtrees found lower in the tree constitute the operands and therefore operators at lower levels must be evaluated before those higher in the tree. For example the tree shown in Fig. 6.1 represents the expression: (a+f(b))*(c+f(b))

This expression can be obtained (parentheses apart) from the symmetric-order traversal of the tree (f is here an arbitrary unary operation). For languages with a compilative implementation, as we have seen, the parser implements syntactic analysis by constructing a derivation tree. In the specific case of expressions then, infix representation in the source code is translated into a treebased representation. This representation is then used by successive phases of the compilation procedure to generate the object code implementing runtime expressions evaluation. This object code clearly depends on the type of machine for which the compiler is constructed. In the case in which we have a traditional physical machine, for example, code of a traditional kind (i.e. in the form opcode operand1 operand2) is generated which uses registers as well as a temporary memory locations to store intermediate results of evaluation. In some particular cases, on the other hand, object code can be represented using a prefix or postfix form which is subsequently evaluated by a stack architecture. This is the case for example in the executable code for many implementations of SNOBOL4 programs. In the case of languages with an interpretative implementation, it is also convenient to translate expressions, normally represented in the source code in infix notation, into a tree representation which can then be directly evaluated using a tree traversal. This is the case, for example, in interpreted implementations of L ISP, where the entire program is represented as a tree. It is beyond the scope of the present text to go into details on mechanisms for generating code or for evaluating expression in an interpreter. However, it is important to clarify some difficult points which often cause ambiguity. For convenience, we will fix on the evaluation of expressions represented in infix form. We will see that what we have to say applies equally to the direct evaluation of expressions represented as a tree, as well as to code generation-mechanisms.

6.1 Expressions

127

Subexpression Evaluation Order Infix notation precedence and associativity rules (or the structure, when expressions are represented as trees) do not hint at the order to evaluate an operator’s operands (i.e., nodes at the same level). For example, in the expression in Fig. 6.1, nothing tells us that it is necessary first to evaluate either a+f(b) or c+f(b). There is also nothing explicit about whether the evaluation of operands or operator should come first; nor, in general, whether expressions which are mathematically equivalent can be inter-substituted without modifying the result (for example, (a-b+c) and(a+c-b) could be considered equivalent). While in mathematical terms these differences are unimportant (the result does not change), from our viewpoint these questions are extremely relevant and for the following five reasons. Side effects In imperative programming languages, expression evaluation can modify the value of any variables through so-called side effects. A side effect is an action that influences the result (partial or final) of a computation without otherwise explicitly returning a value in the context in which it is found. The possibility of side effects renders the order of evaluation of operands relevant to the final result. In our example in Fig. 6.1, if the evaluation of the function f were to modify the value of its operand through side effects, first executing a+f(b) rather than c+f(b), could change the value produced by the evaluation (see Exercise 1). As far as side effects are concerned, languages follow various approaches. On the one hand, pure declarative languages do not permit side effects at all, while languages which do allow them in some cases forbid the use in expressions of functions that can cause side effects. In other, more common cases where the presence of side effects is permitted, the order with which expressions are evaluated is, though, clearly stated in the definition of the language. Java, for example, imposes left-toright evaluation of expressions (while C fixes no order at all). Finite arithmetic Given the set of numbers represented in a computer is finite (see also Sect. 8.3), reordering expressions can cause overflow problems. For example, if a has, as its value, the maximum integer representable and b and c are positive numbers such that b > c, right-to-left evaluation of (a-b+c) does not produce overflow, while we have an overflow resulting from the evaluation from left to right of (a+c-b). Moreover, when we do not have overflow, the limited precision of computer arithmetic implies that changing the order of the operands can lead to different results (this is particularly relevant in cases of floating point computation). Undefined operands When the application of operator to operands is considered, two evaluation strategies can be followed. The first, called eager evaluation, consists of first evaluating all the operands and then applying the operator to the values thus obtained. The strategy probably seems the most reasonable when reasoning in terms of normal arithmetic operators. The expressions that we use in programming languages, however, pose problems over and above those posed by arithmetic expressions, because some can be defined even when some of the operands are missing. Let us consider the example of a conditional expression of the form:

128

6 Control Structure

a == 0 ? b : b/a

We can write this in C to denote the value of b/a when a is non-zero and b, otherwise. This expression results from the application of a single operator (expressed in infix notation using two binary operators ? and :) to three operands (the boolean expression, a==0, and the two arithmetic expressions b and b/a). Clearly here we cannot use eager evaluation for such conditional expressions because the expression b/a would have to be evaluated even when a is equal to zero and this would produce an error. In such a case, it is therefore better to use a lazy evaluation strategy which mainly consists of not evaluating operands before the application of the operator, but in passing the un-evaluated operands to the operator, which, when it is evaluated, will decide which operands are required, and will only evaluate the ones it requires. The lazy evaluation strategy, used in some declarative languages, is much more expensive to implement than eager evaluation and for this reason, most languages use eager evaluation (with the significant exception of conditional expressions as we will see below). There are languages which use a mix of both the techniques (A LGOL, for example). We will discuss the various strategies for evaluating expressions in greater detail when we consider functional languages in Chap. 11. Short-circuit evaluation The problem detailed in the previous point presents itself with particular clarity when evaluating Boolean expressions. For example, consider the following expression (in C syntax): a == 0 || b/a > 2

If the value of a is zero and both operands of || are evaluated at the same time, it is clear that an error will result (in C, “||” denotes the logical operation of disjunction). To avoid this problem, and to improve the efficiency of the code, C, like other languages uses a form of lazy evaluation, also called short-circuiting evaluation, of boolean expressions. If the first operand of a disjunction has the value true then the second is not evaluated, given that the overall result will certainly have the value true. In such a case, the second expression is short-circuited in the sense that we arrive at the final value before knowing the value of all of the operands. Analogously, if the first operand of a conjunction has the value false, the second is not evaluated, given that the overall result can have nothing other than the value false. It is opportune to recall that not all languages use this strategy for boolean expressions. Counting on the presence of a short-circuited evaluation, without being certain that the language uses it, is dangerous. For example, we can write in Pascal p := list; while (p nil ) and (pˆ.value 3) do p := pˆ.next;

The intention of this code is to traverse a list until we have arrived at the end or until we have encountered the value 3. This is badly written code that can produce

6.2 The Concept of Command

129

a runtime error. Pascal, in fact, does not use short-circuit evaluation. In the case in which we have p = nil, the second operand of the conjunction (pˆ.value 3) yields an error when it dereferences a null pointer. Similar code, on the other hand, mutatis mutandis, can be written in C without causing problems. In order to avoid ambiguity, some languages (for example C and Ada), explicitly provide different boolean operators for short-circuit evaluation. Finally, it should be noted that this kind of evaluation can be simulated using a conditional command (see Exercise 2). Optimisation Frequently, the order evaluation of subexpressions influences the efficiency of the evaluation of an expression for reasons relating to the organisation of the physical machine. For example, consider the following code: a = vector[i]; b = a*a + c*d;

In the second expression, it is probably better first to evaluate c*d, given that the value of a has to be read from memory (with the first instruction) and might not be yet available; in such a case, the processor would have to wait before calculating a * a. In some cases, the compiler can change the order of operands expressions to obtain code that is more efficient but semantically equivalent. The last point explains many of the semantic problems that appear while evaluating expressions. Given the importance of the efficiency of the object code produced by the compiler, it is given considerable liberty in the precise definition of its expression evaluation method, without it being specified at the level of semantic description of the language (as we have already said, Java is a rare exception). The result of this kind of approach is that, sometimes, different implementations of the same language produce different results for the same expression, or have errors at runtime whose source is hard to determine. Wishing to capitalise in a pragmatic prescription, given what has been said so far, if we do not know the programming language well and the specific implementation we are using, if we want to write correct code, it is wise to use all possible means at our disposal to eliminate as many sources of ambiguity as possible in expression evaluation (such as brackets parentheses, specific boolean operations, auxiliary variables in expressions, etc.).

6.2 The Concept of Command If, as we were saying above, expressions are present in all programming languages, the same is not true for commands. They are constructs that are typically present (but not entirely restricted to them) in so-called imperative languages. Definition 6.2 (Command) A command is a syntactic entity whose evaluation does not necessarily return a value but can have a side effect.

130

6 Control Structure

A command, or more generally, any other construct, has a side-effect if it influences the result of the computation but its evaluation returns no value to the context in which it is located. This point is fairly delicate and merits clarification with an example. If the print command in a hypothetical programming language can print character strings supplied as an argument, when the command print “pippo” is evaluated, we will not obtain a value but only a side-effect which is composed of the characters “pippo” appearing on the output device. The attentive reader will be aware that the definition of command, just as the previous definition of expression, it is not very precise, given that we have referred to an informal concept of evaluation (the one performed by the abstract machine of the language to which the command or the expression belongs). It is clear that we can always modify the interpreter so that we obtain some value as a result of the evaluation of the command. This is what happens in some languages (for example in C assignment also returns the value to the right of =, see Sect. 6.2.2). A precise definition and, equally, an exact distinction, between expressions and commands on the basis of their semantics is possible only in the setting of a formal definition of the semantics of language. In such a context, the difference between the two concepts derives from the fact that, once a starting state has been fixed, the result of the evaluation of an expression is a value (together with possible sideeffects). On the other hand, the result of evaluating a command is a new state which differs from the start state precisely in the modifications caused by the side-effects of the command itself (and which are due principally to assignments). Command is therefore a construct whose purpose is the modification of the state. The concept of state can be defined in various ways; in Sect. 2.5, we saw a simple version, one which took into account the value of all the variables present in the program. If the aim of a command is to modify the state, it is clear that the assignment command is the elementary construct in the computational mechanism for languages with commands. Before dealing with them, however, it is necessary to clarify the concept of variable.

6.2.1 The Variable In mathematics, a variable is an unknown which can take on all the numerical values in a predetermined set. Even if we keep this in mind, in programming languages, it is necessary to specify this concept in more detail because, as we will see also in Sects. 11.1 and 12.3, the imperative paradigm uses a model for variables which is substantially different from that employed the in logic and functional programming paradigms. The classical imperative paradigm uses modifiable variables. According to this model, the variable is seen as a sort of container, or location (clearly referring to physical memory), to which a name can be given and which contains values (usually of a homogeneous type, for example integers real, characters etc.). These values can

6.2 The Concept of Command

131

Fig. 6.2 A modifiable variable

be changed over time, by execution of assignment commands (whence comes the adjective “modifiable”). This terminology might seem tautological to the average computer person, who is almost always someone who knows an imperative language and is therefore used to modifiable variables. The attentive reader, though, will have noted that, in reality, variables are not always modifiable. In mathematics a variable represents a value that is unknown but when such a value is defined the link thus created cannot be modified later. Modifiable variables are depicted in Fig. 6.2. The small box which represents the variable with the name x can be re-filled with a value (in the figure, the value is 3). It can be seen that the variable (the box) is different from the name x which denotes it, even if it is common to say “the variable x” instead of “the variable with the name x”. Some imperative languages (particularly object-oriented ones) use a model that is different from this one. According to this alternative model, a variable is not a container for a value but is a reference to (that is a mechanism which allows access to) a value which is typically stored in the heap. This is a new concept analogous to that of the pointer (but does not permit the usual pointer-manipulation operations). We will see this in the next section after we have introduced assignment commands. This variable model is called, in [8], the “reference model”, while in [6], where it is discussed in the context of the language CLU, is called the “object model”. Henceforth, we will refer to this as the reference model of variables. (Pure) functional languages, as we will see in more detail in Sect. 11.1, use a concept of variable similar to the mathematical one: a variable is nothing more than an identifier that stands for a value. Rather, it is often said that functional languages “do not have variables”, meaning that (in their pure forms) they do not have any modifiable variables. Logic languages also use identifiers associated with values as variables and, as with functional languages, once a link between a variable identifier and a value is created, it can never be eliminated. There is however a mode in which the value associated with a variable can be modified without altering the link, as will be seen in Sect. 12.3.

6.2.2 Assignment Assignment is the basic command that allows the modification of the values associated with modifiable variables. It also modifies the state in imperative languages. It is an apparently very simple command. However, as will be seen, in different programming languages, there are various subtleties to be taken into account. Let us first see the case that will probably be most familiar to the reader. This is the case of an imperative language which uses modifiable variables and in which

132

6 Control Structure

assignment is considered only as a command (and not also as an expression). One example is Pascal, in which we can write X := 2

to indicate that the variable X is assigned the value 2. The effect of such a command is that, after its execution, the container associated with the variable (whose name is) X will contain the value 2 in place of the value that was there before. It should be noted that this is a side effect, given that the evaluation of the command does not on its own, return any kind of value. Furthermore, every access to X in the rest of the program will return the value 2 and not the one previously stored. Consider now the following command: X := X+1

The effect of this assignment, as we know, is that of assigning to the variable X its previous value incremented by 1. Let us observe the different uses of the name, X, of the variable in the two operands of the assignment operator. The X appearing to the left of the := symbol is used to indicate the container (the location) inside which the variable’s value can be found. The occurrence of the X on the right of the := denotes the value inside the container. This important distinction is formalised in programming languages using two different sets of values: l-values are those values that usually indicate locations and therefore are the values of expressions that can be on the left of an assignment command. On the other hand, r-values are the values that can be stored in locations, and therefore are the values of expressions that can appear on the right of an assignment command. In general, therefore, the assignment command has the syntax of a binary operator in infix form: exp1 OpAss exp2

where OpAss indicates the symbol used in the particular language to denote assignment (:= in Pascal, = in C, FORTRAN, SNOBOL and Java, ← in APL, etc.). The meaning of such a command (in the case of modifiable variables) is as follows: compute the l-value of exp1, determining, thereby, a container loc; compute the r-value of exp2 and modify the contents of loc by substituting the value just calculated for the one previously there.3 Which expressions denote (in the context on the left of an assignment) an l-value depends on the programming language: the usual cases are variables, array elements, record fields (note that, as a consequence, calculation of an l-value can be arbitrarily complex because it could involve function calls, for example when determining an array index). In some languages, for example C, assignment is considered to be an operator whose evaluation, in addition to producing a side effect, also returns the r-value thus computed. Thus, if we write in C: 3 Some languages, e.g., Java, allow the left-hand side to be evaluated before the right-hand side; others (e.g., C), leave this decision to the implementer.

6.2 The Concept of Command

133

x = 2;

the evaluation of such a command, in addition to assigning the value 2 to x, returns the value 2. Therefore, in C, we can also write: y = x = 2;

which should be interpreted as: (y = (x = 2));

This command assigns the value 2 to x as well as to y. In C, as in other languages, there are other assignment operators that can be used, either for increasing code legibility or avoiding unforeseen side effects. Let us take up the example of incrementing a variable. Once again we have: x = x+1;

This command, unless optimised by the compiler, requires, in principle, two accesses to the variable x: one to determine the l-value, and one to obtain the r-value. If, from the efficiency viewpoint, this is not serious (and can be easily optimised by the compiler), there is a question which is much more important and which is again related to side-effects. Let us then consider the code: b = 0; a[f(3)] = a[f(3)]+1;

where a is a vector and f is a function defined as follows: int f (int n){ if b == 0{ b=1; return 1; } else return 2; }

This function is defined in such a way that the non-local reference to b in the body of f refers to the same variable b that is cleared in the previous fragment. Given that f modifies the non-local variable b, it is clear that the assignment a[f(3)] = a[f(3)]+1

does not have the effect of incrementing the value of the element a[f(3)] of the array, as perhaps we wanted it to do. Instead, it has the effect of assigning the value of a[1]+1 to a[2] whenever the evaluation of the left-hand component of the assignment precedes the evaluation of the right-hand one. It should be noted, on the other hand, that the compiler cannot optimise the computation of r-values, because the programmer might have wanted this apparently anomalous behaviour.

134

6 Control Structure

To avoid this problem we can clearly use an auxiliary variable and write: int j = f(3); a[j] = a[j]+1;

Doing this obscures the code and introduces a variable which expresses very little. To avoid all of this, languages like C provide assignment operators which allow us to write: a[f(3)] += 1;

This add to the r-value of the expression present on the left the quantity present on the right of the += operator, and then assigns the result to the location obtained as the l-value of the expression on the left. There are many specific assignment commands that are similar to this one. The following is an incomplete list of the assignment commands in C, together with their descriptions: • X = Y: assign the r-value of Y to the location obtained as the l-value of X and return the r-value of X; • X += Y (or X -= Y): increment (decrement) X by the quantity given by the r-value of Y and return of the new r-value; • ++X (or -X): increment (decrement) X by and return the new r-value of X; • X++ (or X-): return the r-value of X and then increment (decrement) X.

We will now see how the reference model for variables differs from the traditional modifiable-variable one. In a language which uses the reference model (for example, CLU and, as we will see, in specific cases, Java) after an assignment of the form: x=e

x becomes a reference to an object that is obtained from the evaluation of the expression e. Note that this does not copy the value of e into the location associated with x. This difference becomes clear if we consider an assignment between two variables using the reference model. x=y

After such an assignment, x and y are two references to the same object. In the case in which this object is modifiable (for example, record or array), a modification performed using the variable x becomes visible through variable y and vice versa. In this model, therefore, variables behave in a way similar to variables of a pointer type in languages which have that type of data. As we will more clearly see in Sect. 8.4.5, a value of a pointer type is no more than the location of some data item (or, equivalently, its address in some area of memory). In many languages which have pointer types, the values of such types can be explicitly manipulated (which causes several problems as we will also see in Chap. 8). In the case of the reference model, however, these values can be manipulated only implicitly using assignments

6.2 The Concept of Command

135

Environment and Memory In Chap. 2, we defined the semantics of a command by referring to a simple notion of state, which we defined as a function associating with every variable present in the program, the value it takes. This concept of state, although adequate for didactic purposes in mini-languages, is not sufficient when we want to describe the semantics of real programming languages which use modifiable variables and assignments. In fact, we have already seen in Chap. 4 (and will see in more detail in the next two chapters) that parameter-passing mechanisms as well as pointers can easily create situations in which two different names, for example X and Y, refer to the same variable, or rather the same location in memory. Such case of aliasing cannot be described using a simple function State: Names → Values because with a simple function it is not possible to express the fact that a modification of the value associated with (the variable denoted by) X also reflects on the value associated with Y. To correctly express the meaning of modifiable variables, we therefore use two separate functions. The first, called the environment, mostly corresponds to the concept of environment introduced in Chap. 4: in other words, it is a function Environment: Names → DenotableValues which maps names to the values they denote. The set (or, as one says in semantics jargon, the domain) of names often coincides with that of identifiers. The domain DenotableValues, instead, includes all values to which a name can be given; what these values are depends on the programming language but if the language provides modifiable variables then this domain certainly includes memory locations. The values associated with locations are, on the other hand, expressed by a function Memory: Locations → StorableValues which (informally) associates every location with the value stored in it. In this case also, what exactly is a storable value depends on the specific language. Therefore, when we say that “in the current state the variable X has the value 5”, formally we mean to say that we have an environment ρ and a memory σ such that σ (ρ(X)) = 5. Note that when a variable is understood to be an l-value, we are interested only in the location denoted by the name and, therefore, only in the environment is specified, while when we understand it as an r-value the store is also used. For example given environment ρ, and a store σ , the effect of the command X=Y is to produce a new state in which the value of ρ(σ (Y)) is associated with ρ(X). Let us recall, for completeness, that a third value domain important in the language semantics is formed from ExpressibleValues: these are those values which can be the result of the evaluation of a complex expression.

between variables. Java (which does not have pointers) adopts the reference model for variables for all class types, but uses the traditional modifiable-variable model for primitive types (integers, reals floating point, booleans and characters). Below, unless otherwise specified, when we talk about variables, we mean the modifiable variable.

136

6 Control Structure

6.3 Sequence Control Commands Assignment is the basic command in imperative languages (and in “impure” declarative languages); it expresses the elementary computation step. The remaining commands serve to define sequence control, or rather serve to specify the order in which state modifications produced by assignments, are to be performed. These other commands can be divided into three categories: Commands for explicit sequence control These are the sequential command and goto. Let us consider, in addition, the composite command, which allows us to consider a group of commands as a single one, as being in this category. Conditional (or selection) commands These are the commands which allow the specification of alternative paths that the competition can take. They depend on the satisfaction of specific conditions. Iterative commands These allow the repetition of a given command for a predefined number of times, or until the satisfaction of specific conditions. Let us consider these command typologies in detail.

6.3.1 Commands for Explicit Sequence Control Sequential Command The sequential command, indicated in many languages by a “;”, allows us directly to specify the sequential execution of two commands. If we write: C1 ; C2

the execution of C2 starts immediately after C1 terminates. In languages in which the evaluation of a command also returns a value, the value returned by the evaluation of the sequential command is that of the second argument. Obviously we can write a sequence of commands such as: C1 ; C2 ; ... ; Cn

with the implicit assumption that the operator “;” associates to the left. Composite Command In modern imperative languages, as we have already seen in Chap. 4, it is possible to group a sequence of commands into a composite command using appropriate delimiters such as those used by Algol: begin ... end

or those in C: { ... }

6.3 Sequence Control Commands

137

Imperative and Declarative Languages Denotable, storable and expressible values, even if they have a non-empty intersection, are conceptually distinct sets. In effect, many important differences between various languages depend on how these domains are defined. For example, functions are denotable but not expressible in Pascal, while they are expressible in Lisp and ML. A particularly important difference between various languages concerns the presence of storable value and the Memory semantic function which we saw in the previous box. In fact, in a rather synthetic fashion, we can classify as imperative those languages which have environments as well as memory functions; those languages which have only environments are declarative. Imperative languages, while they are high-level languages, are inspired by the physical structure of the computer. In them the concept of memory (or state) is interpreted as the set of associations between memory locations and values stored in those locations. A program, according to this paradigm, is a set of imperative commands and computation consists of a sequence of steps which modify the state, using as its elementary command the assignment. The terminology “imperative” here has to do with natural language: as in an imperative phrase, we say “take that apple” to express a command, so with an imperative command we can say “ assign to x the value 1”. Most programming languages normally used belong to the imperative paradigm (Fortran, Algol, Pascal, C, etc.). Declarative languages were introduced with the aim of offering a higher level programming paradigms, close to the notations of mathematics and logic, abstracting from the characteristics of the physical machine on which the programs are executed. In declarative languages (or at least in “pure” versions of them) there are no commands to modify the state, given that there are neither modifiable variables nor a semantic memory function. Programs are formed from a set of declarations (from which the name is derived) of functions or relations which define new values. According to the elementary mechanism used to specify the characteristics of the result, declarative languages are divided into two classes: functional and logic programming languages (the latter, also called logic languages for short). In the first case, computation consists of the evaluation of functions defined by the programmer using rules of a mathematical kind (mostly composition and application). In the second form of declarative language, on the other hand, computation is based on first-order logical deduction. Let us recall that, in actuality, there exist “impure” functional and logic languages that also have imperative characteristics (in particular, they include assignment). We will encounter both functional and logic languages in two next chapters.

Such a composite command, also called a block, can be used in any context in which a simple command is expected and therefore, in particular, can be used inside another composite command to create a tree-like structure of arbitrary complexity.

138

6 Control Structure

A Quibble about “;” Being rigorous, the “;” used to separate commands is not always a sequential command. In C, C++ and Java, for example, it is a command terminator more than an operator expressing concatenation. In fact, this can be easily seen when we deal with the last command in a block. In these languages, the “;” is always required, even if the command is not followed by another as in {x=1; x=x+1; }

In languages like Pascal, on the other hand, “;” is really an operator that sequentialises commands. The same example as above can be written as: begin x:=1; x:=x+1 end

To insert a “;” without there being a command to follow it is, however, a venial programming sin which the compiler absolves by inserting an empty command between the “;” and the end. An empty command is denoted by nothing syntactically and corresponds to no action.

Goto A unique place is occupied in the panorama of sequential control commands by the goto. It was included in the first programming languages and continues to be included in languages. It has 2 different forms (conditional or direct). This command is directly inspired by jump instructions in assembler languages and therefore by the sequence control of the hardware machine. The execution of the command goto A

transfers control to the point in the program at which the label A occurs (different languages differ in what exactly constitutes a label but these differences are not relevant to us). Despite its apparent simplicity and naturalness, the goto command has been at the centre of a considerable debate since the start of the 1970s (see, for example, the famous article by Dijkstra referred to in the bibliography), and, after about 30 years of debate, we can say that it is the detractors who have beaten the supporters of this command. To clarify the sense of this debate, let us, first of all, observe that the goto is not essential to the expressiveness of a programming language. A theorem due to Böhm and Jacopini in fact shows that any program can be translated into an equivalent one which does not use the goto (the formulation of the theorem,

6.3 Sequence Control Commands

139

obviously, is much more precise than our account). This result, moreover, does not come down on one side or the other. If, on the one hand, we can assert that, in principle, the goto is useless, on the other, it is possible to object (as has been done) that even this result shows that it is permissible to use the goto in programs. If just we wish to eliminate this command, in fact, it can be done using the Böhm and Jacopini transformation (which, in particular, completely destroys the structure of the reformulated program). The nexus of the question really is not of a theoretical nature but of a pragmatic one. Using goto, it is easily possible to write code which soon becomes incomprehensible and which still remains incomprehensible when all gotos are eliminated. We can think, for example, of a program of some considerable size where we have inserted jumps between points which are some of thousands of lines of code apart. Or, we can think of a subprogram in which exits are made at different points based on some condition and the exits are performed by gotos. These and other arbitrary uses of this construct make the code hard to understand, and therefore hard to modify, correct and maintain; this has the obvious negative consequences in terms of cost. To all of this, we can add the fact that the goto with its primitive method of transferring control, does not accord well with other mechanisms present in highlevel languages. What happens, for example, if we jump inside of a block? When and how is the activation record for this block initialised so that everything works correctly? If goto were used in an extremely controlled fashion, locally to small regions of code, the majority of these disadvantages would disappear. However, the cases in which it can be useful to use this command, such as exit from loops, return from a subprograms, handling of exceptions, can, in modern programming languages, be handled by specific, more appropriate, constructs. We can therefore assert that in modern high-level languages, the goto is a construct whose use is disappearing. Java is the first commercial language to have completely removed it from its set of admissible commands. Other sequence control commands If goto is dangerous in its general form, there are local and limited uses which are useful in given circumstances. Many languages make available limited forms of jump to confront these pragmatic necessities without having to make use of the brute force of a goto. Among these commands (which take on different forms in different languages), we find constructs such as break (for terminating the execution of a loop, of a case, or, in some languages, of the current block), continue (for terminating the current iteration in an iterative command and force the starting of the immediately following command) or return (to terminate the evaluation of the function, returning control to the caller, sometimes also passing a value). Finally, a more elaborate sequence control can be implemented using exceptions. We will deal with these in a more detailed fashion in Sect. 7.3 below.

140

6 Control Structure

6.3.2 Conditional Commands Conditional commands, or selection commands, express one alternative between two or more possible continuations of the computation based on appropriate logical conditions. We can divide conditional commands into two groups. If The if command, originally introduced in the A LGOL60 language, is present in almost all imperative languages and also in some declarative languages, in various syntactic forms which, really, can be reduced to the form: if Bexp then C1 else C2

where Bexp is a boolean expression, while C1 and C2 are commands. Informally, the semantics of such a command expresses an alternative in the execution of the computation, based on the evaluation of the expression Bexp. When this evaluation returns true, the command C1 is executed, otherwise the command C2 is executed. The command is often present in the form without the else branch: if Bexp then C1

In this case, too, if the condition is false, the command C1 is not executed and control passes to the command immediately after the conditional. As we saw in Chap. 2, the presence of a branching if as in the command if Bexp1 if Bexp2 then C1 else C2

causes problems of ambiguity, which can be resolved using a suitable grammar which formally describes the rules adopted by the language (for example, the else branch belongs to the innermost if; this is the rule in Java and it is used in almost every language). To avoid problems of ambiguity, some languages use a “ terminator” to indicate where the conditional command ends, as for example in: if Bexp then C1 else C2 endif

Furthermore, in some cases, instead of using a list of nested if then elses, use is made of an if equipped with more branches, analogous to the following: if Bexp1 then C1 elseif Bexp2 then C2 ... elseif Bexpn then Cn else Cn+1 endif

6.3 Sequence Control Commands

141

The implementation of the conditional command poses no problems, and makes use of instructions for test and jump that are found in the underlying physical machine.4 The evaluation of the boolean expression can use the shorter circuit technique that we saw above. Case The command is a specialisation of the if command, just discussed, with more branches. In its simplest form it is written as follows: case Exp of label1: C1; label2: C2; ... labeln: Cn; else Cn+1

where Exp is an expression whose value is of a type compatible with that of the labels label1, ... , labeln, while C1, ... , Cn+1 are commands. Each label is represented by one or more constants and the constant used in different labels are different from each other. The type permitted for labels, as well as their form, varies from language to language. In most cases, a discrete type is permitted (see Sect. 8.3), including enumerations and intervals. So, for example, we can use the constants 2 and 4 to denote a label, but in some languages we can also write 2,4 to indicate either the value 2 or the value 4, or 2 .. 4 to indicate all values between 2 and 4 (inclusive). The meaning of this command, as stated above, is analogous to that of a multibranch if. Once the expression Exp has been evaluated, the command which occurs in the unique branch whose label includes the value to which Exp evaluated is executed. The else branch is executed whenever there is no other branch whose label satisfies the condition stated above. It is clear that whatever can be done using a case can certainly be expressed using a nested series of ifs. Even so, many languages include some form of case in their commands, either to improve the readability of the code, or because it is possible to compile a case much more efficiently than a long series of nested ifs. A case is, in fact, implemented in assembly language using a vector of contiguous cells called a jump table, in which each element of the table contains the address of the first instruction of the corresponding command in the case’s branches. The use of such a table is shown in Fig. 6.3, where, for simplicity, it is assumed that the labels label1,.., labeln are the consecutive constants 0, 1, . . . , n − 1. As should be clear in the figure, the expression which appears as an argument to the case is evaluated first of all. The value thus obtained is then used as an offset (index) to compute the position in the jump table of the instruction which performs the jump to the chosen branch. The extension of this mechanism to the general case in which labels are sets or intervals as simple (see Exercise 3). 4 At the assembly language level, and therefore in the language of the physical machine, there are jump operations, conditional or not, analogous to the goto in high-level languages.

142

6 Control Structure

Fig. 6.3 Implementation of case

This implementation mechanism for case gives greater efficiency than a series of nested ifs. Using a jump table, once the value of the expression is calculated, two jump instructions are required to arrive at the code of the command to execute. Using nested ifs, on the other hand, for n alternative branches (in the worst case of an unbalanced if), it is necessary to evaluate O(n) conditions and perform O(n) jumps before arriving at the command of interest. The disadvantage of using a jump table is that, since it is a linear structure whose contiguous elements correspond to successive label values, it can consume a lot of space when the label values are dispersed over a fairly wide interval or when the individual labels are a type denoting a wide interval. In this case alternative methods can be used for calculating the jump address, such as sequential tests hashing or even methods based on binary search. Different languages exhibit significant differences in their case commands. In C, for example, the switch has the following syntax (also to be found in C++ and in Java): switch (Exp) body

6.3 Sequence Control Commands

143

where body can be any command that all. In general, though, the body is formed from a block in which some commands can be labelled; that is they are of the form: case label : command

while the last command of the block is of the form: default : command

When the expression Exp is evaluated and control is to be transferred to the command whose label coincides with the resulting value, if there are no labels with such a value, control passes to the command with the label default. If there is no default command, control passes to the first command following the switch. It can be seen that, once a the branch of the switch has been selected, control then flows into the immediately following branches. To obtain a construct with semantics analogous to that of the case we discussed above, it is necessary to insert an explicit control transfer at the end of the block, using a break: switch (Exp){ case label1: C1 break; case label2: C2 break; ... case labeln: Cn break; default: Cn+1 break; }

It can be seen also that in a switch, the value returned by the evaluation of the expression might not appear in any label, in which case the entire command has no effect. Finally, lists or ranges of values are not permitted as labels. This however is no real limitation, given that lists of values can be implemented using the fact that control passes from one branch to its successor when break is omitted. If, for example, we write: switch (Exp){ case 1: case 2: C2 break; case 3: C3 break; default: C4 break; }

in the case in which the value of Exp is 1, given that the corresponding branch does not contain a break command, control passes from the case 1 branch immediately to the case 2 branch and therefore it is as if we had used a list of values 1,2 for the label of C2.

144

6 Control Structure

6.3.3 Iterative Commands The commands that we have seen up to this point, excluding goto, only allow us to express finite computations, whose maximum length is determined statically by the length of the program text.5 A language which had only such commands would be of highly limited expressiveness. It would certainly not be Turing complete (recall Sect. 3.3), in that it would not permit the expression of all possible algorithms (consider, for example, scanning a vector of n elements, where n is not known a priori). In order to acquire the expressive power necessary to express all possible algorithms in low-level languages, jump instructions allowing the repetition of groups of instructions by jumping back to the start of the code are needed. In high-level languages, given that, as has been seen, it is desirable to avoid commands like goto, two basic mechanisms are employed to achieve the same effect: structured iteration and recursion. The first, which we consider in this section, is more familiar from imperative languages (and they almost always allow recursion as well). Suitable linguistic constructs (which we can regard as special versions of the jump command) allow us compactly to implement loops in which commands are repeated or iterated. At the linguistic level, it is possible to distinguish between unbounded iteration and bounded iteration. In bounded iteration, repetition is implemented by constructs that allow a determinate number of iterations. Unbounded iteration, on the other hand, is implemented by constructs which continue until some condition becomes true. Recursion which we will consider in the next section, allows, instead, the expression of loops in an implicit fashion, including the possibility that a function (or procedure) can call itself, thereby repeating its own body an arbitrary number of times. The use of recursion is more common in declarative languages (in many functional and logic languages there does not, in fact, exist any iterative construct). Unbounded iteration Unbounded iteration is logically controlled iteration. It is implemented by linguistic constructs composed of two parts: a loop condition (or guard) and a body, which is composed of a (possibly compound) command. When executed, the body is repeatedly executed until the guard becomes false (or true, according to the construct). In its most common form, this type of iteration takes the form of the while command, originally introduced in A LGOL:while while (Bexp) do C

The meaning of this command is as follows: (1) the boolean expression Bexp is evaluated; (2) if this evaluation returns the value true, execute the command C and return to (1); otherwise the while command terminates. In some languages there are also commands that test the condition after execution of the command (which is therefore always executed at least once). This construct is for example present in Pascal in the following form: 5 It can easily be seen that the maximum length of the computation is a linear function of the length of the program.

6.3 Sequence Control Commands

145

repeat C until Bexp

This is no more than an abbreviation for: C; while not Bexp do C

(not Bexp here indicates the negation of the expression Bexp). In C an analogous construct is do: do C while (Bexp)

which corresponds to: C; while Bexp do C

(note that the guard is not negated as in the case of repeat.) The while construct is simple to implement, given that it corresponds directly to a loop that is implemented on the physical machine using a conditional jump instruction. This simplicity of implementation should not deceive us about the power of this construct. Its addition to a programming language which contains only assignment and conditional commands immediately makes the language Turing complete. Our mini-language from Chap. 2 is therefore Turing complete (or: it allows the implementation of all computable functions). The same is not the case with bounded iteration which we will now turn to. Bounded iteration Bounded iteration (sometimes also called numerically controlled iteration) is implemented by linguistic constructs that are more complex than those used for unbounded iteration; their semantics is also more elaborate. These forms are very different and not always “pure” as we will see shortly. The model that we adopt in this discussion is that of A LGOL, which was then adopted by many other languages of the same family (but not by C or Java). Bounded iteration is implemented using some variant of the for command. Without wishing to use any specific syntax, it can be described as: for I = start to end by step do body

where I is a variable, called the index, or counter, or control variable; start and end are two expressions (for simplicity we can assume that they are of integer type and, in general, they must be of a discreet type); step is a (compile-time) non-zero integer constant; body is the command we want to repeat. This construct, in the “pure” form we are describing, is subject to the important static semantic constraint that the control variable can not be modified (either explicitly nor implicitly) during the execution of the body. The semantics of the bounded iteration construct can be described informally as follows (assuming that step is positive):

146

6 Control Structure

1. The expression start is evaluated, as is end. The values are frozen and stored in dedicated variables (which cannot be updated by the programmer). We denote them, respectively, as start_save and end_save. 2. I is initialised with the value of start_save. 3. If the value of I is strictly greater than the value of end_save, execution of the for command is terminated. 4. Execute body and increment I by the value of step. 5. Go to 3. In the case in which step is negative, the test in step (3) determines whether I is strictly less than end_save. It is worth emphasising the importance of step (1) above and the constraint that the control variable cannot be modified in the body. Their combined effect is to determine the number of times and the body will be executed before the loop begins execution. This number is given by the quantity, ic (iteration count), which is defined as: # $ end − start + step ic = step

if ic is positive, otherwise it is 0. It can be seen, finally, that there is no way of producing an infinite cycle with this construct. There are considerable differences, both syntactic and semantic, between the versions of this construct in different languages. First, not all languages require nonmodifiability of the control variable and/or the freezing of the control expressions. Strictly speaking, such cases do not implement bounded iteration because they are unable to compute ic once and once only. It is common, though, to continue speaking of bounded iteration even when the language does not guarantee determinateness, but this is obtained on any loop, by the programmer (modifying neither directly nor indirectly the control variable and the start, end and step expressions). Also different other aspects constitute important differences between languages, of which we mention four:

Number of iterations According to the semantics which we have just given, when step is positive, if the value of start is initially (strictly) greater than the value of end, body is not executed at all. Even this is not the case in all languages, just the majority. Some languages execute the test in Step 3 after having executed body. Step The requirement that step is a (non-zero) constant is necessary for statically determining its sign, so that the compiler can generate the appropriate code for the test in step 3. Some languages (such as Pascal and Ada) use a special syntax to indicate that step is negative, for example using downto or reverse in place of to. Other languages, such as, for example, some versions of Fortran, do not have a different syntax for the native step and their implementation of the for directly uses the iteration counter rather than the test of I and end. The value ic is computed and if this value is positive, it is used to control the loop, decrementing it by 1 until it reaches the value 0. If, on the other hand, ic has a negative value or is

6.3 Sequence Control Commands

147

equal to 0, the loop is never repeated. It is the use of this implementation technique that suggests the name numerically controlled iteration. Final index value The other subtle aspect concerns the value of the control variable I after the end of the loop. In many languages, I is a variable that is also visible outside of the loop. The most natural approach seems to be that of considering the value of I to be the last value assigned to it during execution of the for construct itself (in the case in which the loop terminates normally and the step is positive, the last value assigned to the index I is the first value greater than end). This approach, though, can generate type ambiguities or errors. Let us assume, for example, that I is declared as being of an interval type 1 .. 10 (from 1 to 10). If we use a command: for I = 1 to 10 by 1 do body

The final value assigned to I would have to be the successor of 10, which is clearly not an admissible value. An analogous problem occurs for integer values when the calculation of I causes an overflow. To avoid this problem, some languages (for example Fortran IV or Pascal) consider the value of I to be indeterminate on termination of the loop (that is, the language definition does not specify what it should be). In other words, each implementation of these languages is allowed to behave how it wishes, with the imaginable consequence of the non-portability of programs. Other languages (for example: AlgolW, Algol 68, Ada, and, in certain circumstances, C++) cut the matter short, decreeing that the control variable is a variable that is local to the for; hence it is not visible outside the loop. In this case the header of the for implicitly declares the control variable with a type that is determined from that one of start and end. Jump into a loop The last point which merits attention concerns the possibility of jumping into the middle of a for loop using a goto command. Most languages forbid such jumps for clear semantic reasons, while there are fewer restrictions on the possibility of using a goto for jumping out of a loop. We have just considered a number of important aspects of the implementation of for loops. Particular tricks can be used by the compiler to optimise the code that is produced (for example, eliminating tests which involve constants) or by limiting overflow situations which could occur when the incrementing the index I (by inserting appropriate tests). Expressiveness of bounded iteration Using bounded iteration, we can express the repetition of a command for n times, where n it is an arbitrary value not known when the program is written, but is fixed at when the iteration starts. It is clear that this is something that cannot be expressed using only conditional commands and assignment, because it is possible to repeat a command only by repeating the command in the body of the program syntactically. Given that every program has a finite length, we have a limit on the maximum number of repetitions that we can include in a specific program.

148

6 Control Structure

Despite this increase in expressive power, bounded iteration on its own is insufficient to make a programming language Turing complete. Think, for example, of a simple function f which can be defined as follows: f (x) =

!

x if x is even, does not terminate if x is odd.

Certainly such a function is computable. Every programmer would know how to implement it using a while or a goto or a recursive call so as to obtain a nonterminating computation. However such a function is not representable in a language only having assignment, sequential command, if and bounded iteration, given that, as can easily be verified in such a language, all programs terminate for every input. In other words, in such a language, only total functions can be defined while function f is partial.6 In order to obtain a language that is Turing complete, it is necessary to include unbounded iteration. The complication of the informal semantics of for is only apparent, and the easy translation into machine language of while should not deceive us. In fact, from a formal viewpoint, while is semantically more complicated than for. As we saw in Chap. 2, the semantics of the while command is defined in terms of itself, something which, if at first sight it appears a little strange, finds its formal justification in fix point techniques which are beyond the scope of this text (and to which we will mention in the section on recursion, below). Even if we have not formally defined the semantics of for, the reader can convince themselves that this can be given in simpler terms (see Exercise 4). The major complication in the semantics of while with respect to for corresponds to the greater expressiveness of the first construct. It is in fact clear that every for command can easily be translated into a while. It can now be asked why a language provides a bounded iteration construct when unbounded iteration constructs allow the same things to be done. The reply is principally of a pragmatic nature. The for it is a much more compact form of iteration, putting the three components of the iteration (initialisation, control and increment of the control variable) on the same line makes understanding what the loop does a lots easier; it can also prevent some common errors, such as forgetting the initialisation or increment of the control variable. The use of a for instead of a while can therefore be an important way to improve understanding and, therefore testing and maintenance of a program. There is also the implementation motive in some languages and on some architectures. A for a loop can often be compiled in a more efficient way (and, in particular, be optimised better) than a while, particularly as far as register allocation is concerned. The for in C In C (and in its successors, among them Java), the for is far from being, the in a general case, a bounded iteration construct. The general version is: 6 In

reality there are other total functions that are not definable using only assignment, sequential composition, if and for. A famous example is the Ackerman function, for whose definition the reader is referred to texts on computability theory for example [3].

6.3 Sequence Control Commands

149

for (exp1 ; exp2 ; exp3 ) body

Its semantics is the following: 1. 2. 3. 4.

Evaluate exp1; Evaluate exp2; if it is zero, terminate execution of the for; Execute body; Evaluate exp3 and go to (2).

As can be seen, there is no way to freeze the value of the control expressions, nor is there any ban on the possibility of modifying the value of index (which, in the general case, need not even exist). It is clear how the semantics expresses the fact that in C, for is, when all is said and done, an abbreviation for a while. Making use of the fact that, in C, a command is also an expression, we obtain the most usual form in which the for appears in C programs: for (i = initial; i 100) return x-10; else return ninetyone(ninetyone(x+11)); }

Is this tail recursive? Justify your answer. 6. The following code fragment is written in a pseudo-language which admits bounded iteration (numerically controlled) expressed using the for construct. z=1; for i=1 to 5+z by 1 do{ write(i); z++; } write(z);

What is printed by write? 7. Say what the following code block prints. This code is written in a language with static scope and call by name. The definition of the language contains the following phrase: “The evaluation of the expression E1 ◦ E2 where ◦ is any operator, consists of (i) the evaluation of E1 ; (ii) then the evaluation of E2 ; (iii) finally, the application of the operator ◦ to the two values previously obtained.” {int x=5; int P(name int m){ int x=2; return m+x; } write(P(x++) + x); }

References

163

References 1. H. Abelson and G. J. Sussman. Structure and Interpretation of Computer Programs. MIT Press, Cambridge, 1996. 2. P. Aczel. An introduction to inductive definitions. In J. Barwise, editor, Handbook of Mathematical Logic, pages 739–782. North-Holland, Amsterdam, 1977. 3. M. Aiello, A. Albano, G. Attardi, and U. Montanari. Teoria della Computabilità, Logica, Teoria dei Linguaggi Formali. ETS, Pisa, 1976 (in Italian). 4. C. Böhm and G. Jacopini. Flow diagrams, Turing machines and languages with only two formation rules. Commun. ACM, 9(5):366–371, 1966. 5. E. Dijkstra. Go to statement considered harmful. Communications of the ACM, 11(3):147–148, 1968. 6. B. Liskov and J. Guttag. Abstraction and Specification in Program Development. MIT Electrical Engineering and Computer Science Series. MIT Press, Cambridge, 1986. 7. T. Pratt and M. Zelkowitz. Programming Languages: Design and Implementation. PrenticeHall, New York, 2001 (quarta edizione). 8. M. L. Scott. Programming Language Pragmatics. Morgan Kaufmann, San Mateo, 2000. 9. G. Winskel. The Formal Semantics of Programming Languages. MIT Press, Cambridge, 1993.

Chapter 7

Control Abstraction

The concept of abstraction is a recurrent theme in this text. Right from the first chapter, we have encountered abstract machines and their hierarchies. For them, we used the terms “abstract” rather than “physical”, denoting by abstract machine, a set of algorithms and data structures not directly present in any specific physical machine, but executable on it by means of interpretation. Moreover, the fact that the concept of abstract machine, to some extent, hides the underlying machine is fundamental. “To abstract” means simply to hide something. Often, abstracting from some concrete data relating to some object, one succeeds in bringing out with more clarity a concept common to that object. Each description of a phenomenon (natural, artificial, physical, etc.) is not based on the set of all data relating to the phenomenon itself, otherwise it would be like a geographical map of scale 1:1, extremely precise but useless. Every scientific discipline describes a certain phenomenon, concentrating only on some aspects, those which have been found to be the most relevant to the agreed aims. It is for this reason that scientific language uses appropriate mechanisms to express these “abstractions”. Programming languages, themselves the abstractions of the physical machine, are no exception. Rather, expressiveness depends in an essential way on the mechanisms of abstraction which the languages provide. These mechanisms are the principal instruments available to the designer and programmer for describing in an accurate, but also simple and suggestive, way the complexity of the problems to be solved. In a programming language, in general, two classes of abstraction mechanisms are distinguished. That which provides control abstraction and that which provides data abstraction. The former provides the programmer the ability to hide procedural data; the latter allow the definition and use of sophisticated data types without referring to how such types will be implemented. In this chapter we will be concerned with the mechanisms for control abstraction, while data abstraction will be the subject of Chap. 9, after we have seen mechanisms for data structuring in the next chapter. M. Gabbrielli, S. Martini, Programming Languages: Principles and Paradigms, Undergraduate Topics in Computer Science, DOI 10.1007/978-1-84882-914-5_7, © Springer-Verlag London Limited 2010

165

166

7 Control Abstraction

Fig. 7.1 Definition and use of a function

int foo (int n, int a) { int tmp=a; if (tmp==0) return n; else return n+1; } ... int x; x = foo(3,0); x = foo(x+1,1);

7.1 Subprograms Every program of any complexity is composed of many components, each of which serves to provide part of a global solution. The decomposition of a problem into subproblems allows better management of complexity. A more restrictive problem is easier to solve. The solution to the global problem is obtained by appropriate composition of the solutions to these subproblems. In order for all of this to be efficient, however, it is necessary that the programming language provides linguistic support which facilitates and makes possible such subdivisions and, therefore, re-composition. This linguistic support allows the expression of decomposition and re-composition directly in the language, transforming these concepts from simple methodological suggestions into real and genuine instruments for design and programming. The key concept provided by all modern languages is that of the subprogram, procedure, or function.1 A function is a piece of code identified by name, is given a local environment of its own and is able to exchange information with the rest of the code using parameters. This concept translates into two different linguistic mechanisms. The first, definition (or declaration) of function, and its use (or call). In Fig. 7.1, the first five lines constitute the definition of the function named foo, whose local environment is composed from three names n, a and tmp.2 The first line is the header, while the remaining lines constitute the body of the function. The last two lines of Fig. 7.1 are the uses (or calls) of foo. A function exchanges information with the rest of the program using three principal mechanisms: parameters, return value, nonlocal environment. Parameters We distinguish between formal parameters, which appear in the definition of a function, and actual parameters, which appear, instead, in the call. The formal parameters are always names which, as far as the environment is concerned, behave as declarations local to the function itself. They behave, in particular, as bound variables, in the sense that their consistent renaming has no effect on the 1 These three terms assume different meanings in different languages. For example, “subprogram” is usually the most general term. In languages of the Algol family and their descendants, a procedure is a subprogram which modifies the state, while a function is a subprogram that returns a value. In this chapter, at least, we will use the three terms as synonyms. 2 The

name foo is part of the nonlocal environment of the function.

7.1 Subprograms Fig. 7.2 Renaming of formal parameters

167 int foo (int m, int b){ int tmp=b; if (tmp==0) return m; else return m+1; }

semantics of the function. For example, the function foo in Fig. 7.1 and that in Fig. 7.2 are indistinguishable, even though the second has different names for its formal parameters. The number and type of actual and formal parameters must, in general, coincide, although many type compatibility rules can be brought into play (see Sect. 8.7). There is sometimes also the possibility of declaring functions with a variable number of parameters. Return value Some functions exchange information with the rest of the program by returning a value as a result of the function itself, as well as through the use of parameters. Our function, foo, for example, returns an integer. The language makes available, in this case, the mechanism which allows the “return of value” to be expressed (for example the return construct which has also the effect of terminating the execution of the current function). In some languages, the name “function” is reserved for subprograms which return a value, while those subprograms which interact with the caller just via parameters or the non-local environment are called “procedures”. In languages which derive their syntax from C, all subprograms are, linguistically, functions. If the result type of a function is void, the function returns no meaningful value (the command to return such a value and to terminate execution is return). Nonlocal environment This is a less sophisticated mechanism with which a function can exchange information with the rest of the program. If the body of the function modifies a nonlocal variable, it is clear that such a modification is felt in all parts of the program where this variable is visible.

7.1.1 Functional Abstraction From a pragmatic viewpoint, subprograms are mechanisms which allow the software designer to obtain functional abstraction. A software component is an entity which provides services to its environment. The clients of such a component are not interested how the services are provided, only how to use them. The possibility of associating a function with every component allows separation of what the client needs to know (expressed in the header of the function: its name, its parameters, its result type, if present) from what it does not need to know (which is in the body). We have real functional abstraction when the client does not depend on the body

168

7 Control Abstraction

“Static” variables In all we have said, we have always assumed that the local environment of a function has the same lifetime as the function itself. In such a case, there is no primitive mechanism which one instance of a function can use for communicating information to another instance of the same function. The only way for this to happen is through the use of a nonlocal variable. In some languages, though, it is possible to arrange for that a variable (which must be local to a function) to maintain its value between one invocation of the function and another. In C, for example, this is achieved using the static modifier (Fortran uses save, Algol own, etc.). A static variable allows programmers to write functions with memory. The following function, for example, returns the number of times it has been called: int how_many_times(){ static int count; /* C guarantees that static variables are initialised to zero by the first activation of the function */ return count++; }

The declaration of a static variable introduces an association with unlimited lifetime into the environment (in the lifetime of the program, clearly). It should be observed that a static variable provides greater data abstraction than a global variable. It is not, in fact, visible from outside the function. The visibility mechanisms guarantee, therefore, that it is only modifiable inside the function body.

of a function, only on its header. In this case, the substitution (for example for efficiency reasons) of the body by another one with the same semantics is transparent to the system software in its entirety. If a system is based on functional abstraction, the three acts of specification, implementation and use of a function can occur independent of one another without knowledge of the context in which the other actions are performed. Functional abstraction is a methodological principle, whose functions provide linguistic support. It is clear that this is not a definitive support. It is necessary that the programmer correctly uses these functions, for example by limiting the interactions between function and call to parameter passing, because use of the nonlocal environment to exchange information between functions and the rest of the program destroys functional abstraction. On the other hand, functional abstraction is increasingly guaranteed by greater limitation of interaction between components to external behaviour, as expressed by function headers.

7.1 Subprograms

169

7.1.2 Parameter Passing The way in which actual parameters are paired with formal parameters, and the semantics which results from this, is called the parameter passing discipline. According to what is now traditional terminology, a specific mode is composed of the kind of communication that it supports, together with the implementation that produces this form of communication. The mode is fixed when the function is defined and can be different for each parameter; it is fixed for all calls of the function. From a strictly semantic viewpoint, the classification of the type of communication permitted by a parameter is simple. From a subprogram’s viewpoint, three parameter classes can be discerned: • Input parameters. • Output parameters. • Input/output parameters.

A parameter is of input type if it allows communication which is only in the direction from the caller to the function (the “callee”). It is of output type if it permits communication only in direction from the callee to the caller. Finally, it is input/output when it permits bidirectional communication. Note that this is a linguistic classification, part of the definition of the language; it is not derived from the use to which parameters are put. An input/output parameter remains that way even if it is used only in a unidirectional fashion (e.g., from caller to callee). It is clear that each of these types of communications can be obtained in different ways. The specific implementation technique constitutes, exactly, the “call mode”, which we will now subject to analysis, describing for each mode: • • • • •

What type of communication it allows. What form of actual parameter is permitted. The semantics of the mode. The canonical implementation. Its cost.

Of the modes that we will discuss, the first two (by value and by reference) are the most important and are widely used. The others are little more than variations on the theme of call by value. An exception is call by name, which we will discuss last. Although call by name is now disused as a parameter-passing mechanism, nevertheless, it allows us to present a simple case of what it means to “pass an environment” into a procedure. Call by value Call by value is a mode that corresponds to an input parameter. The local environment of the procedure is extended with an association between the formal parameter and a new variable. The actual parameter can be an expression. When called, the actual parameter is evaluated and its r-value obtained and associated with the formal parameter. On termination of the procedure, the formal parameter is destroyed, as is the local environment of the procedure itself. During the execution of

170 Fig. 7.3 Passing by value

7 Control Abstraction int y = 1; void foo (int x) { x = x+1; } ... y = 1; foo(y+1); // here y = 1

the body, there is no link between the formal and the actual parameter. There is no way of make use of a value parameter to transfer information from the callee to the caller. Figure 7.3 shows a simple example of passing by value. Like in C, C++, Pascal and Java, when we do not explicitly indicate any parameter-passing method for a formal parameter, it is to be understood that parameter is to be passed by value. The variable y never changes its value (it always remains 1). During the execution of foo, x assumes the initial value 2 by the effect of passing the parameter. It is then incremented to 3, finally it is destroyed with the entire activation record for foo. If we assume a stack-based allocation scheme, the formal parameter corresponds to a location in the procedure’s activation record in which the value of the actual parameter is stored during the calling sequence of the procedure. Let us note how this is an expensive method when the value parameter is bound to a large data structure. In such a case, the entire structure is copied to the formal.3 On the other hand, the cost of accessing the formal parameter is minimal, since it is the same as the cost of accessing a local variable in the body. Passing by value is a very simple mechanism with clear semantics. It is the default mechanism in many languages (e.g., Pascal) and is the only way to pass parameters in C and Java. Call by reference Call by reference (also called by variable) implements a mechanism in which the parameter can be used for both input and output. The actual parameter must be an expression with l-value (recall the definition of l-value on page 132). At the point of call, the l-value of the actual parameter is evaluated and the procedure’s local environment is extended with an association between the formal parameter and the actual parameter’s l-value (therefore creating an aliasing situation). The most common case is that in which the actual parameter is a variable. In this case, the formal and the actual are two names for the same variable. At the end of the procedure, the connection between the formal parameter and the actual parameter’s l-value is destroyed, as is the environment local to the procedure. It is clear that call by reference allows bidirectional communication: each modification of the formal parameter is a modification of the actual parameter. 3 The

reader who knows C should not be misled. In a language with pointers, as we will discuss below, often the passing of a complex structure consists of passing (by value) a pointer to the data structure. In such a case, it is the pointer that is copied, not the data structure.

7.1 Subprograms

171

Fig. 7.4 Passage by reference

int y = 0; void foo (reference int x) { x = x+1; } y=0; foo(y); // here y = 1

Fig. 7.5 Another example of passage by reference

int[] V = new V[10]; int i=0; void foo (reference int x) { x = x+1; } ... V[1] = 1; foo(V[i+1]); // here V[1] = 2

Figure 7.4 shows a simple example of call by reference (which we have notated in the pseudocode with the reference modifier). During the execution of foo, x is a name for y. Incrementing x in the body is, to all effects, the incrementing of y. After the call, the value of y is therefore 1. It can be seen that, as shown in Fig. 7.5, the actual parameter need not necessarily be a variable but can be an expression whose l-value is determined at call time. In a way similar to the first case, during the execution of foo, x is a name for v[1] and the increment of x in the body, is an increment of v[1]. After the call, the value of v[1] is, therefore, 2. In the stack-based abstract machine model, each formal is associated with a location in the procedure’s activation record. During the calling sequence, the l-value of the actual is stored in the activation record. Access to the formal parameter occurs via an indirection which uses this location. This is a parameter passing mode of very low cost. At the point of call, only an address need be stored; every reference to the formal is achieved by an indirect access (implemented implicitly by the abstract machine) which can be implemented at very low cost on many architectures. Call by reference is a low-level operation. It is possible in Pascal (var modifier) and in many other languages. It has been excluded from more modern languages. In these languages, however, some form of bidirectional communication between caller and callee can be obtained by exploiting the interaction between parameter passing and other mechanisms (the most important being the model chosen for variables) or the availability of pointers in the language. Two boxes show simple examples in C (and C++) and Java. The moral of the examples is that in an imperative language, passing by value is always accompanied by other mechanisms so that procedures are really a versatile programming technique. Call by constant We have already seen how call by value is expensive for largesized data. When, however, the formal parameter is not modified in the body of

172

7 Control Abstraction

Call by reference in C C admits only call by value but also allows the free manipulation of pointers and addresses. Making use of this fact, it is not difficult to simulate call by reference. Let us consider the problem of writing a simple function which swaps the values of two integer variables which are passed to the function as parameters. With only call by value, there is no way to do this. We can, though, combine call by value with pointer manipulation, as in the following example: void swap (int *a, int *b) { int tmp = *a; *a=*b; *b=tmp; } int v1 = ...; int v2 = ...; swap(&v1, &v2);

The formal parameters to swap (both by value) are of type pointer to integer (int *). The values of the actual parameters are the addresses (that is, the l-value) of v1 and v2 (obtained using the operator &). In the body of swap, the use of the * operator performs dereferencing of the parameters. For example, we can paraphrase the meaning of *a = *b as: take the value contained in the location whose address is contained in b and store it in the location whose address is stored in a. Our swap therefore simulates call-by-reference. the function, we can imagine maintaining the semantics of passing by value, implementing it using call by reference. This is what constitutes the read-only parameter method. This is a method that establishes an input communication and in which arbitrary expressions are permitted as actual parameters. The formal parameters passed by this method are subject to the static constraint that they cannot be modified in the body, either directly (by assignment) or indirectly (via calls to functions that modify them). From a semantic viewpoint, call by constant coincides completely with call by value, while the choice of implementation is left to the abstract machine. For data of small sizes, call by constant can be implemented as call by value. For larger structures, an implementation using a reference, without copy, will be chosen. Call by constant is an optimum way to “annotate” a given parameter to a procedure. By reading the header, one immediately has information about the fact that this parameter is input only. Furthermore, one can count on static semantic analysis to verify that this annotation is really guaranteed. Call by result Call by result is the exact dual of call by value. This a mode which implements output-only communication. The procedure’s local environment is extended with an association between the formal parameter and a new variable. The actual parameter must be an expression that evaluates to an l-value. When the procedure terminates (normally), immediately before the destruction of the local environ-

7.1 Subprograms

173

Bidirectional communication in Java A function like swap (in the box “Call by reference in C”) cannot be written in Java. However, we can make use of the fact that Java uses a reference-based model for variables (of class type) to obtain some form of bidirectional communication. Let us consider for example the following simple definition of a class: class A { int v; }

We can certainly write a method which swaps the values of the field v in two objects of class A: void swap (A a, A b) { int tmp = a.v; a.v= b.v; b.v=tmp; }

In this case, what is passed (by value) to swap are two references to objects of class A. Using the reference model for variables of class type, swap effectively swaps the values of the two fields. It can be seen, however, that a true simulation of call by reference is not possible, as it was with C.

ment, the current value of the formal parameter is assigned to the location obtained using the l-value from the actual parameter. It should be clear that, as in call by value, the following questions about evaluation order must be answered. If there is more than one result parameter, in which order (for example, from left to right) should the corresponding “backward assignment” from the actual to formal be performed? Finally, when is the actual parameter’s l-value determined? It is reasonable to determine it both when the function is called and when it terminates.4 It can be seen that, during the execution of the body, there is no link between the formal and actual parameter. There is no way to make use of a result parameter to transfer information from the caller to the callee. An example of call by result is shown in Fig. 7.6. The implementation of call by result is analogous to call by value, with which it shares its advantages and disadvantages. From a pragmatic viewpoint, the by-result mode simplifies the design of functions which must return (that is provide as result) more than one value, each in a different variable. Call by value-result The combination of call by value and call by result produces a method called call by value-result. This is a method that implements bidirectional communication using the formal parameter as a variable local to the procedure. 4 Construct an example which gives different results if the l-value of the actual is determined at call time or when the procedure terminates.

174 Fig. 7.6 Call by result

7 Control Abstraction void foo (result int x) {x = 8;} ... int y = 1; foo(y); // here y is 8

Fig. 7.7 Call by value-result

void foo (valueresult int x){ x = x+1; } ... y = 8; foo(y); // here y is 9

Fig. 7.8 Call by value-result is not call by reference

void foo (reference/valueresult int x, reference/valueresult int y, reference int z){ y = 2; x = 4; if (x == y) z = 1; } ... int a = 3; int b = 0; foo(a,a,b);

The actual parameter must be an expression that can yield an l-value. At the call, the actual parameter is evaluated and the r-value thus obtained is assigned to the formal parameter. At the end of the procedure, immediately before the destruction of the local environment, the current value of the formal parameter is assigned to the location corresponding to the actual parameter. An example of call by value-result is shown in Fig. 7.7. The canonical implementation of call by value-result is analogous to that of call by value, even if some languages (Ada, for example) choose to implement it as call by reference in the case of large-sized data, so that the problems of cost of call by value can be avoided. The implementation of call by value-result using a reference is, however, not semantically correct. Consider, for a moment, the fragment in Fig. 7.8. At first sight, the conditional command present in the body of foo seems useless, for x and y have just received distinct values. The reality is that x and y have different values only in the absence of aliasing. If, on the other hand, x and y are two different names for the same variable, it is clear that the condition x == y is always true. If, therefore, x and y are passed by value-result (there is no aliasing), the call foo(a,a,b) terminates without the value of b being modified. If, on the other hand, x and y are passed by reference (where there is aliasing), foo(a,a,b) terminates by assigning the value 1 to b.

7.1 Subprograms Fig. 7.9 Which environment should be used to evaluate x+1 in the body of foo?

175 int x=0; int foo (name int y){ int x = 2; return x + y; } ... int a = foo(x+1);

Call by name Call by name, introduced in A LGOL 60, is a semantically cleaner way of passing parameters than by reference. It is no longer used by any major imperative language. However, it is a conceptually important method worth the effort of studying in detail because of its properties and its implementation. The problem that the designers of A LGOL 60 set themselves was to give a precise semantics. The semantics should specify in an elementary fashion what the effect of a call to a function with specified parameters would be. The solution that they chose was to define the semantics of function call using the so-called copy rule. Without loss of generality, we will state it in the case of a function of one argument: Let f be a function with a single formal parameter, x, and let a be an expression of a type that is compatible with that of x. A call to f with an actual parameter a is semantically equivalent to the execution of the body of f in which all occurrences of the formal parameter, x, have been replaced by a.

As can easily be seen, it is a very simple rule. It reduces the semantics of function call to the syntactic operation of expanding the body of the function after a textual substitution of the actual for the formal parameter. This notion of substitution, however, is not a simple concept because it must take into account the fact it might have to deal with several different variables with the same name. Consider, for example, the function in Fig. 7.9. If we blindly apply the copy rule, the call foo(x+1) results in the execution of return x+x+1. This command, executed in the local environment of foo, returns the value 5. But it is clear that this is an incorrect application of the copy rule because it makes the result of the function depend on what the name of the local variable is. If the body of foo had been: {int z=2; return z+y;}

the same call would result in the execution of return z+x+1, with the result 3. In the first substitution that we suggested, we say that the actual parameter, x, was captured by the local declaration. The substitution of which the copy rule talks must therefore be a substitution that does not capture variables. It is not possible to avoid having different variables with the same name, so we can obtain a noncapturing substitution by requiring that the formal parameter, even after substitution, is evaluated in the environment of the caller and not in that of the callee. We can therefore define call by name as that method whose semantics is given by the copy rule, where the concept of substitution is always understood without capture. Equivalently, we can say that what is substituted is not merely the actual parameter, but the actual parameter together with its own evaluation environment which is fixed at the moment of call.

176 Fig. 7.10 Side effects of call by name

7 Control Abstraction int i = 2; int fie (name int y) { return y+y; } ... int a = fie(i++); // here i has value 4; a has value 5

void fiefoo (valueresult/name int x, valueresult/name int y) { x = x+1; y = 1; } ... int i = 1; int[] A = new int[5]; A[1]=4; fiefoo(i,A[i]); Fig. 7.11 Call by name is not call by value-result

Note how the copy rule requires that the actual parameter must be evaluated every time that the formal parameter is encountered during execution. Consider the example of Fig. 7.10, where the construct i++ has the semantics of returning the current value of the variable i and then incrementing the value of the variable by 1. The copy rule requires that the i++ construct must be evaluated twice. Once for every occurrence of the formal parameter y in fie. The first time, its evaluation returns the value 2 and increments the value of i by one. The second time, it returns the value 3 and increments i again. The example we have just discussed shows how it is an error to consider call by name as a complicated way of describing call by value-result. The two modes are semantically different, as Fig. 7.11 shows. Let us assume, first, that we are to execute fiefoo with parameters passed by value-result. On termination, we will have A[1] with value 1 and i with value 2, while the rest of the array A has not been touched. If, on the other hand, we execute the same procedure with the two parameters passed by name, on termination, we will have A[1] with value 4, i with value 2 and, what is more important, the element A[2] will have been updated to the value 1. It can be seen that, in this case, valueresult and call by reference will have exhibited the same behaviour. It remains to describe how call by name can be implemented. We have already discussed the necessity for the caller to pass not only the textual expression forming its actual parameter but also the environment in which this expression must be evaluated. We call a pair, (expression, environment), in which the environment includes (at least) all the free variables in the expression a closure.5 We can therefore 5 The

term “closure” comes from mathematical logic. A formula is closed when it does not contain free variables. A closure is a canonical method for transforming a piece of code containing nonlocal (that is, “free”) variables in a completely specified code.

7.1 Subprograms

177

Fig. 7.12 Implementation of call by name

say that, in the case of call by name, the caller passes a closure, formed from the actual parameter (in the form of a textual expression) and the current environment. When the callee encounters a reference to the formal parameter, it is resolved using the evaluation of the first component of the closure in the environment given by the second component. Figure 7.12 describes this situation in the particular case of an abstract machine with a stack. In this case, a closure is a pair formed from two pointers: the first points to the code that evaluates the expression of the formal parameter, the second is a pointer to the static chain, which indicates the block which forms the local environment in which to evaluate the expression. When a procedure f with a formal name parameter, x, is called with actual parameter a, the call constructs a closure whose first component is a pointer to the code for a and whose second component is a pointer to the (caller’s) actual activation record. It then binds this closure (for example, using another pointer) to the formal parameter x which resides in the called procedure’s activation record. We can finally summarise what we know on call by name. It is a method which supports input and output parameters. The formal parameter does not correspond to a variable that is local to the procedure; the actual parameter can be an arbitrary expression. It is possible that the actual and formal parameters can be aliased. The actual parameter must evaluate to an l-value if the formal parameter appears on the left of an assignment, The semantics of call by name was established by the copy rule which allows the maintenance of a constant link between formal and actual parameters during execution. The canonical implementation uses a closure. The procedure’s local environment is extended with an association between the formal and a closure, the latter being composed of the actual parameter and the environment in which the call occurs. Every access to the formal parameter is performed via the ex novo evaluation of the actual parameter in the environment stored in the closure. This is a very expensive parameter-passing method, both because of the need to pass a complex structure and, in particular, because of the repeated evaluation of the actual parameter in an environment that is not the current one.

178

7 Control Abstraction

Jensen’s Device Call by name allows side effects to be exploited to obtaining elegant and compact code, even though it often results in code that is difficult to understand and maintain. This is the case with the so-called Jensen’s Device which makes use of pass by name to pass a complex expression and, at the same time, a variable which appears in the same expression, in such a way that modifications to variable change the value of the expression. Let us consider the following example: int summation (name int exp; name int i; int start; int stop) { int acc = 0; for (i=start, iint we denote the type of the functions which take no argument (void) and return a value of type integer (int). The second line of the code is therefore the declaration of a function F which returns a function of no arguments which also returns an integer (note that return g returns the “function”, not its application). The first line after the body of F is the declaration of the name gg with which the result of the evaluation of F is dynamically associated. It should not be difficult to convince ourselves that the function gg returns the successor of the value of x. Using the static scope regime, this x is fixed by the structure of the program and not by the position of the call to gg, which could appear in an environment in which another definition of the name x occurs. We can, therefore, say that, in general, when a function returns a function as result, this result is a closure. In consequence, the abstract machine must be appropriately modified to take into the account calls to closures. Analogous to what happens

7.2 Higher-Order Functions

185

Fig. 7.17 Functions as results

{int x = 1; void->int F () { int g () { return x+1; } return g; } void->int gg = F(); int z = gg(); }

Fig. 7.18 Functions as result and stack discipline

void->int F () { int x = 1; int g () { return x+1; } return g; } void->int gg = F(); int z = gg();

Fig. 7.19 Activation records for Fig. 7.18

when a function is called via a formal parameter, when a function whose value is obtained dynamically (like gg), the static chain pointer of its activation record is determined using the associated closure (and not the canonical rules discussed in Sect. 5.5.1, which would be of no help). The general situation, moreover, is much more complex. If it is possible to return a function from the inside of a nested block, it is possible to arrange that its evaluation environment will refer to a name that, according to stack discipline, is going to be destroyed. Let us consider, indeed, the code in Fig. 7.18, where we have moved the declaration of x to the inside of F. Figure 7.19 shows the activation record arrangement when gg() is called. When the result of F() is assigned to gg, the closure which forms its value points to an environment containing the name x. But this environment is local to F and will therefore be destroyed on its termination. How is it possible, then, to call gg later than this without producing a dangling reference to x? The reply can only be drastic: abandon stack discipline for activation records, so that they can then stay

186

7 Control Abstraction

alive indefinitely, because they could constitute the environments for functions that will be evaluated subsequently. In languages with the characteristics that we have just discussed, local environments have an unlimited lifetime. The most common solution in this case is to allocate all activation records in the heap and to leave it to a garbage collector to deallocate them when it is discovered that there are no references to the names they contain. Every functional language is constructed around the possibility of returning functions as results. They must therefore take this problem head on. On the contrary, returning functions as results in imperative languages is rare; this is purely to maintain a stack discipline for activation records. In imperative languages which do permit functions as results, there are, generally, many restrictions aimed at guaranteeing that it is never possible to create a reference to an environment that has become deactivated (for example: no nested functions (C, C++), return only non-nested functions (Modula-2, Modula-3), appropriately restrict the scope of those nested functions that are returned (Ada), etc.).

7.3 Exceptions An exception is an event that is checked during the execution of a program and which must not (or cannot) be handled in the normal flow of control. Such events could be checking that a dynamic semantic error has occurred (e.g., a division by zero, overflow, etc.) or checking that a situation has occurred for which the programmer explicitly decides to terminate the current computation and transfer control to another point in the program, often outside the currently executing block. First-generation languages did not provide structures for handling such situations. They typically treat them by means of jumps (gotos). On the other hand, many modern languages such as C++, Ada and Java have structural mechanisms for exception handling which appear as real abstraction constructs. These constructs allow the interruption of a computation and the shifting of control outside of the current construct, block or procedure. Often, this mechanism also allows data to be passed across the jump, resulting in a very flexible (and also often efficient) tool for handling those cases of exceptional termination of a computation which the normal control constructs (loops and conditionals) are unable to handle properly. Devised for handling the unusual or exceptional cases which can present themselves in a program, exceptions are also useful, as we will see, when giving compact and efficient definitions of some ordinary algorithms. The mechanisms for handling exceptional situations vary greatly from language to language. We will restrict ourselves here to describing some common approaches and we do not pretend to be exhaustive. In general, we can say that, in order to correctly handle exceptions, a language must: 1. Specify which exceptions can be handled and how they can be defined. 2. Specify how an exception can be raised, that is which mechanisms cause the exceptional termination of a computation.

7.3 Exceptions

187

class EmptyExcp extends Throwable {int x=0;}; int average(int[] V) throws EmptyExcp(){ if (length(V)==0) throw new EmptyExcp(); else {int s=0; for (int i=0, i T; more generally, a function with header T f(S1 s1 , ..., Sn sn ){...}.

is of type S1 × · · · ×Sn ->T. The values of a functional type are therefore denotable in every language but are rarely expressible (or storable). In addition to definition, the principal operation permitted on a value of functional type is application, that is the invocation of a function on some arguments (actual parameters). In some languages, moreover, the type of functions has the same status of any other type: it is possible to pass functions as arguments to other functions, and to define functions which return functions as results. Such higher order languages belong, in particular, to the functional paradigm (which includes, to name but a few: ML, Haskell, Scheme). In these languages, a function is not just a piece of code equipped with its local environment, but may be handled like other data. We will see in Chap. 11, the outline of a possible abstract machine for doing this.

230

8 Structuring Data

Recursive Types in ML ML is an important functional language. It is equipped with an extended type system. It is a type-safe language with many interesting properties. The language allows the definition of explicitly recursive types using constructors, which are introduced as part of the definition of the type. By way of an example, our definition of list of integers can be written as (ignoring the fact that ML has lists as a predefined type): datatype int_list = Null | CONS of int * int_list;

In this definition, Null and CONS are constructors, that is function symbols to which there corresponds no code, but which serve only to construct, syntactically, terms of the desired type (in this case int_list). The vertical line is read as “or”. A value of type int_list is the constant Null, or is a pair (denoted by the constructor CONS) composed of an int and an int_list. Therefore CONS(2,Null) is a simple value of type int_list. Figure 8.9 shows the ML expression which corresponds to the value in Fig. 8.7. The language permits the definition of ill-founded recursive types. For example the following definition introduces the type empty; it is so-called because it is impossible to construct values of this type: datatype empty =

Void of empty;

Indeed, there is no basic constructor which will allow us to construct a value of type empty without presupposing another such value. CONS(2,CONS(33,CONS(1,CONS(4,CONS(3,CONS(1,CONS(21,Null))))))) Fig. 8.9 A value of type int_list in ML

8.5 Equivalence Having analysed the principal types that we find in programming languages, the time has come to discuss the rules which govern the correctness of programs with respect to types. The first class of these rules deals with the definition of when two types, which are formally different, are to be considered interchangeable. The rules define an equivalence relation between types. If two types are equivalent, every expression or value of one type is also an expression or value of the other, and vice versa. In the next section, we will discuss compatibility rules which specify when a value of one type can be used in a context in which the value of another type would be expected (but not conversely). Let us recall that a type is defined in the following form (the details will vary from language to language): type newtype = expression;

8.5 Equivalence

231

Relations of preorder and equivalence A binary relation, ∗, on a set, D, is a subset of the cartesian product of D with itself: ∗ ⊆ D × D. We write c ∗ d for (c, d) ∈ ∗. A relation is reflexive when, for every d ∈ D, it is true that d ∗ d. It is symmetric if, for all c, d ∈ D, if c ∗ d holds, then also d ∗ c holds. It is transitive if, for every c, d, e ∈ D, if c ∗ d and d ∗ e, then c ∗ e. It is antisymmetric if, for every c, d ∈ D, if c ∗ d and d ∗ c, then c coincides with d. If a relation is reflexive and transitive, it is said to be a preorder. If a preorder is also symmetric, it is an equivalence. If, on the other hand, a preorder is also antisymmetric, it is a partial order. Different languages interpret a definition like this in two different ways which lead to two distinct rules for type equivalence: • The definition of a type of can be opaque, in which case we have equivalence by name. • The definition of the type can be transparent, in which case we have structural equivalence.

8.5.1 Equivalence by Name If a language uses opaque type definitions, each new definition introduces a new type which is different from every preceding one. In this case, then, we have equivalence by name, as defined below. Definition 8.2 (Equivalence by name) Two types are equivalent by name only if they have the same name (so a type is equivalent only to itself). By way of example, let us consider the following definitions of types: type type type type

T1 T2 T3 T4

= = = =

1..10; 1..10; int; int;

Four distinct types are introduced. There is no equivalence between them. However, equivalence by name is too restrictive. Some languages (Pascal for example) adopt the rule of weak (or lax) equivalence by name. The simple renaming of a type does not generate a new type but only an alias for the same one. In the example above, using a weak equivalence by name, the types T3 and T4 are equivalent, but types T1 and T2 remain distinct. Under equivalence by name, each type has a unique definition which occurs at a unique point in the program, a fact which simplifies maintenance. Despite its simplicity, from the programming point of view, equivalence by name is the choice that

232

8 Structuring Data

Equivalence by Name in Pascal An aspect of equivalence by name that is not always pleasant is that two expressions of “anonymous” type correspond to two different types (because they do not have names, they cannot have the same name!). In the two following Pascal declarations: var V : array [1..10] of integer; W : array [1..10] of integer;

V and W do not have the same type. The situation is particularly bad when we declare a formal parameter to a procedure using an expression of anonymous type: procedure f (Z : array [1..10] of integer);

In this example, neither V nor W can be passed as actual parameters to f because the formal parameter Z is of a (third) type which is distinct from the two previous ones. most respects the intentions of the designer. If the programmer has introduced two different names for the same type, they will have their reasons which the language respects by maintaining two different types. Note that equivalence by name is defined with reference to a specific, fixed program and it does not make sense to ask whether two types are equivalent by name “in general”.

8.5.2 Structural Equivalence A type definition is transparent when the name of the type is just an abbreviation for the expression defining the type. In a language with transparent declarations, two types are equivalent if they have the same structure, that is if, substituting names for the relevant definitions, identical types are obtained. If a language uses transparent type definitions, the equivalence between types that is obtained is said to be structural equivalence. We can give a more precise recursive definition of structural equivalence. Definition 8.3 (Structural Equivalence) Structural equivalence of types is the (least) equivalence relation satisfying the following properties: • The name of a type is equivalent to itself; • If a type T is introduced with the definition type T = expression, T is equivalent to expression; • If two types are constructed by applying the same type constructor to equivalent types, then the two types are equivalent. By way of example, consider the following definitions:

8.5 Equivalence

233

type T1 = int; type T2 = char; type T3 = struct{ T1 a; T2 b; } type T4 = struct{ int a; char b; }

T3 and T4 are structurally equivalent. Some aspects of the definition of equivalence that we have given are deliberately vague or imprecise. For example, it is not clear whether the three following types are equivalent: type S = struct{ int a; int b; } type T = struct{ int n; int m; } type U = struct{ int m; int n; }

They result from the application of the same constructors, but they have been given names (or field order) that are different. A further subtle question concerns structural equivalence and recursive types: type R1 = struct{ int a; R2 p; } type R2 = struct{ int a; R1 p; }

Intuitively, we can think that R1 and R2 equivalent, but the type checker will be unable to solve the mutual recursion involved in these definitions (showing the equivalence between R1 and R2 requires a mathematical argument of some sophistication). Structural equivalence allows us to speak about equivalent types in general, not just those in a specific program. In particular, two equivalent types can always be substituted for each other in any context without altering the meaning of the program in which the substitution occurs (this general property of substitution is often known as referential transparency).

234

8 Structuring Data

It will come as no surprise to the reader to learn that existing languages almost always use some form of combination or variant of the two equivalence rules that we have just defined. We have already seen that Pascal uses (weak) equivalence by name; Java uses equivalence by name, except for arrays, for which it uses structural equivalence; C uses structural equivalence for arrays and for types defined using typedef, but not when it involves records (structs) and unions, for which it always uses equivalence by name; C++ uses equivalence by name (except when it inherits from C); ML uses structural equivalence, except for types defined using datatype; Modula-2 inherits from Pascal its use of equivalence by name, but Modula-3 uses structural equivalence; and so on.

8.6 Compatibility and Conversion The relation of compatibility between types, which is weaker than equivalence, allows the use of one type in a context in which another has been requested. Definition 8.4 (Compatibility) We say that type T is compatible with type S, if a value of type T is permitted in any context in which a value of type S would be admissible. In many languages, it is the rule of compatibility (and not that of equivalence) which controls the correctness of assignment (the type of the right-hand component must be compatible with that of the left-hand one), parameter passing (the type of the actual parameter must be compatible with that of the formal parameter), etc. It is clear that two equivalent types are also compatible with each other but in general the relation of compatibility is not symmetric: the canonical example is the compatibility that exists in many languages (but not in all: ML and Java, for example, do not admit it) between int and float (but not vice versa). The compatibility relation is therefore a pre-order (that is a reflexive and transitive relation) that is not symmetric, but almost never an ordering (that is it is not symmetric, but not antisymmetric either). In fact, in a language which admits structural equivalence, two types that are structurally equivalent are compatible but not equal. The compatibility relation, more than that of equivalence, varies enormously between languages. Without pretending to be complete, let us list some of the possible concepts that we can encounter in order of generality (that is, of the “generosity” of the compatibility relation). A type T can be compatible with S when: 1. Types T and S are equivalent; it is the most restrictive version of compatibility. 2. The values of T form a subset of the values of S: this is a case of an interval type, contained in its own base type (and therefore compatible with it). 3. All the operations on the values of S are also permitted on values of T. The simplest example (which however the does not correspond to compatibility in any of the principal commercial languages) is that of two record types. We assume that we have declared

8.6 Compatibility and Conversion

235

type S = struct{ int a; } type T = struct{ int a; char b; }

The only possible operation on values of type S is the selection of a field with name a; this also makes sense for values of type T. There is no inclusion relation between values of T and those of S, but there is a canonical way to obtain a value of S from a value of T: take the first component and forget the second. This interpretation of compatibility leads to a particular notion of compatibility based on the concept of subtype in object-oriented languages (we will discuss this below in Sect. 10.2.4). 4. The values of T correspond in a canonical fashion to values of S. In addition to the case outlined in the previous point, this is the case that we have already mentioned of int being compatible with float. (This is not an instance of point (2), above, because, as far as the implementation is concerned, the values of the two types are distinct). 5. Values of T can be made to correspond with some values of S. Once the requirement of the canonicality of correspondence has been dropped, every type can be made to be compatible with another defining a (conventional) way to transform one value of T into one of S. Using this very broad notion of compatibility, float can be made compatible with int by arbitrarily defining the conversion procedure (for example, rounding, truncation, etc.). In order to manage this collection of different interpretations as a unified whole, we introduce the notion of type conversion. This notion will be stated in two distinct ways: • Implicit conversion (also called coercion or forced conversion). This is the case in which the abstract machine inserts a conversion when there is no such indication in the high-level language; • Explicit conversion (or cast). This is when the conversion is indicated in the text of the program. Coercions In the presence of compatibility between the types T and S, the language allows a value of type T to occur where a value of type S is expected. When this happens, the compiler and/or abstract machines inserts a type conversion between T and S. We will call this a type coercion. From a syntactic viewpoint, coercion has no significance other than annotating a compatibility. From the implementation viewpoint, however, a coercion can correspond to different things depending upon the notion of compatibility adopted: 1. Type T is compatible with S and have the same storage representation (at least for values of T). In such a case, coercion remains a syntactic matter and causes no code to be generated.

236

8 Structuring Data

Casts which do not modify representation In some situations, especially in systems programming, it is useful to be able to change the type of an object without changing its representation in memory. This kind of conversion is obviously forbidden in type-safe languages, but is, though, permitted in many languages (these are often said to be “unchecked” (ADA) or “non-converting type casts”). An example in C using the addressing (&) and de-reference (*) operators is: int a = 233; float b = *((float*) &a);

First of all, the address of the integer variable a is taken, then it is converted explicitly into a pointer to a float using the cast (float *); finally, it is dereferenced and assigned to the real value b. The entire example is merely annotation for the compiler which does not result in any action by the machine. The bits, which in twos complement represents 233, are now interpreted as an the IEEE 754 representation for floating point numbers (provided that integer and float are represented by the same number of bytes). It is clear that a conversion which does not modify the stored representation is always an extremely delicate operation, as well as being a potential source of hard-to-fix errors.

2. Type T is compatible with S but there exists a canonical way to transform values of T into values of S. In this case, the coercion is executed by the abstract machine, which applies precisely the canonical conversion. For example, in the case of int and float, the abstract machine inserts code to transform (at runtime) the representation in twos complement that is required for integers to that for floating point. 3. The compatibility of T with S is based on an arbitrary correspondence between values of T with those of S. In this case, too, the abstract machine inserts code that performs the transformation. This is the case, also, of all those situations where T and S have the same representation , but T is a superset of S. For example, T is int and S is an integer interval12 (note that we are in the symmetric case to the “canonic” case, considered in point 1, in which T ⊆ S). Coercion in this case does not transform the representation but dynamically checks (at least if the language is supposed to be type safe) that the value of T belong to S. Languages with strong type checking tend to have few coercions (that is few compatibilities) of the last kind. On the other hand, in a language like C, the type system is designed to be by-passed and so permits numerous coercions (from char12 Almost all languages with interval types allow this kind of compatibility for the obvious reason of programming flexibility.

8.7 Polymorphism

237

acters to integers, from long reals to short, from long integers to short reals, and so on). Explicit Conversions Explicit conversions (or casts, using the name by which they are known in C and in other languages) are annotations in the language which specify that a value of one type must be converted to that of another type. In this case, as well, such a conversion can be either just a syntactic marking or can correspond to code that is executed by the abstract machine, using the scheme for coercions that we have already discussed. In our pseudo-language, we will follow the conventions of the C language family and will denote a cast using brackets: S s = (S) t;

Here we are assigning a value t, having converted it into type S, to a variable of type S. Not every explicit conversion is permitted, only those for which the language knows how to implement the conversion. It is clear that we can insert a cast where a compatibility exists. In this case explicit conversion is syntactically useless but must be advised for documentation purposes. Languages with few compatibilities make available, in general, many explicit conversions, which the programmer can use to annotate the program where a change of type is necessary. Generally, modern languages tend to prefer casts over coercions. They are more useful as far as documentation is concerned; they do not depend upon the syntactic context in which they appear, and, most importantly, they behave better in the presence of overloading and polymorphism (which we will consider shortly).

8.7 Polymorphism A type system in which any language object (value, function, etc.) has a unique type is said to be monomorphic.13 Here we will be interested in the more general concept given in the next definition. Definition 8.5 A type system in which the same object can have more than one type is said to be polymorphic.14 By analogy, we will say that the object is polymorphic when the type system assigns more than one type to it. Even the more conventional languages contain limited forms of polymorphism. The name + in many languages is of type int×int→int, as well as of type float×float→float. The value null has the type T* for every type T. The function length (which returns the number of elements of an array) is of type T[]→int for every type T. The list could be continued. In conventional languages, 13 This

is a word derived from the Greek and means “has only a single (mono) form (morphos)”

14 “Which

has many (poly) forms.”

238

8 Structuring Data

however, it is not in general permitted for the user to define polymorphic objects. Let us take as an example, a language with a type system that is fairly inflexible (for example, Pascal or Java but to some extent C also) and let us assume that we want to write a function that sorts a vector of integers. The resulting function could have the signature: void int_sort(int A[])

If we now need to sort a vector of characters, we need to define another function void char_sort (char C[])

which is wholly identical to the previous example except in the type annotations. A polymorphic language would allow the definition of a single function void sort( A[])

where denotes a generic type which will be specified at a later stage. In this section, we will analyse the phenomenon of polymorphism. We will start by distinguishing three different forms: • Ad hoc polymorphism, also called overloading. • Universal polymorphism, which can be further divided into: – Parametric polymorphism, and – Subtyping or inclusion polymorphism.

8.7.1 Overloading Overloading, as its other name (ad hoc polymorphism) suggests, is really polymorphism in appearance only. A name is overloaded when it corresponds to more than one object and context information must be used to determine which object is denoted by a specific instance of that name. The most common examples of this are: • The use of the name + to indicate either integer or real addition (and sometimes it also denotes concatenation of character sequences). • The ability to define more than one function (or constructor) with the same name but whose instances differ in the number or type of their parameters. In the case of overloading, therefore, a single name corresponds to more than one object (in fact, to a finite number of objects). If it is the name of a function, it will be associated with different pieces of code. The ambiguity of the situation is solved statically using type information that is present in the context. From the conceptual viewpoint, we can imagine a kind of pre-analysis of the program which solves cases of overloading by substituting a unambiguous name which uniquely denotes a unique object for each symbol that is overloaded. Overloading is therefore

8.7 Polymorphism

239

Polymorphic types and universal quantification Rather than writing a polymorphic type between angle brackets, a more uniform notation (one which is more suggestive, as well as mathematically more accurate) is that which uses universal quantification. Instead of -> void, we write ∀T.T[]->void. This is a notation that is well-suited to the description of all the variations on polymorphism which have been proposed; in Sect. 8.7.3 (and again in Sect. 10.4.1) it will be used to analyse subtype polymorphism.

a sort of abbreviation at the syntactic level. It vanishes as soon as we introduce additional information. Overloading should not be confused with coercion. They are two different mechanisms which solve different problems. On the other hand, in the presence of coercions, it might be not at all clear how a case of overloading should be solved. Consider for example the following expressions: 1 + 1.0 1 + 1.0

2 + 2.0 2.0 + 2

This quartet of expressions can be interpreted in several ways. First, + is overloaded with four different meanings. Second, + is overloaded with two meanings (integer and real) and coercion is inserted in the final two cases. Next, + merely denotes real addition and in the other three cases, coercions are employed. It is up to the definition of the language to determine which of these interpretations is correct.

8.7.2 Universal Parametric Polymorphism We begin with a definition that is relatively imprecise but adequate for our needs. Definition 8.6 A value exhibits universal parametric polymorphism (or parametric polymorphism, more briefly) when it has is an infinite number of different types which can be obtained by instantiating a single schema of general type. A universal polymorphic function is therefore composed of a single piece of code which operates uniformly on all the instances of its general type (because information about the type is not exploited by the algorithm which the function implements). Among the examples that we discussed at the start of the section, there are some that fall into this category: the value null, which belongs to every type T* (that is to every type that can be obtained by substituting an actual type for T); the function void sort( A[]), which sorts an array of any type whatsoever.

240

8 Structuring Data

Before presenting more examples, we need to extend the notation. Following on from what was suggested in Sect. 8.4.7, we can write the polymorphic type of sort as []→void. In this notation, we use angle brackets to indicate that is not a usual type but a sort of parameter. By substituting any “concrete” type for the parameter, we obtain a specific type for sort. Each way to substitute a type for corresponds to one of the infinite number of ways to apply the function: int[] > void, char[]-> void, etc. With this notation, the type of null should be more correctly given as *. Let us give another example. A function which exchanges two variables of any type. As with sort, if it is written in a language without polymorphism, we would need a swap function for every possible variable type. Using universal polymorphism, and assuming that we have at our disposition call by reference, we can write: void swap (reference x, reference y){ tmp = x; x = y; y = tmp; }

A polymorphic object can be instantiated to a specific type. The instantiation can happen in many different ways, according to the specific mechanism(s) for polymorphism provided by the language. The simplest model is that in which instantiation occurs automatically and is performed by the compiler or the abstract machine: int* k = null; char v,w; int i,j; ... swap(v,w); swap(i,j);

1

3

5

Without requiring additional annotations, on line 1, using information from the context (the assignment is performed on the variable of type int*), the type checker instantiates the type of null as int*. On line 5, swap is instantiated to character and, on line 6, to integer. Parametric polymorphism is general and flexible. It is present in programming languages in two notationally different forms called explicit and implicit parametric polymorphism. Explicit polymorphism Explicit polymorphism is the kind we have discussed thus far. In the program, there are explicit annotations (our ) which indicate the types to be considered parameters. This is the kind of polymorphism present in C++ (using the concept of “template”) and in Java (from version J2SE 5.0 using the “generic” notion). Implicit Polymorphism Other languages (in particular functional languages like ML) adopt implicit parametric polymorphism, in which the programmer need not

8.7 Polymorphism

241

provide any type indications and instead the type checker (or rather, more properly, the module performing type inference—see Sect. 8.9) tries to determine for each object the most general type from which the other types can be obtained by instantiation. The simplest example of a polymorphic function is that of the identity which, using a notation as close as possible to that which we have used this far, can be written as: fun Ide(x){return x;}

We will use the word fun to indicate that we are defining a function. The rest is totally analogous to the definitions we have already seen, except that there are no type annotations, either for parameters or results. Type inference will assign to the function Ide, the type ->. If the actual parameter is of type X, the result will be of type X, for any type X. The application of a polymorphic function obviously takes place without type indication. Ide(3) will be correctly typed as a value of type int, while Ide(true) be typed as bool. Let us consider here a final example of implicit parametric polymorphism combined with higher order: fun Comp(f,g,x){return f(g(x));}

Comp applies the composition of its first two parameters (the functions) to the argument x. What is the type that can be inferred for Comp? Here is the most general possible: (->) × (->) × ->

The inferred type is perhaps more general than the reader would have thought.

8.7.3 Subtype Universal Polymorphism Subtype polymorphism is typically present in object-oriented languages. It is a more limited form of universal polymorphism than parametric polymorphism. Indeed, here as well, a single object can be assigned an infinite number of different types. They are obtained by instantiating a single most general type. In this case, too, since it is a case of true polymorphism (i.e., universally quantified polymorphism), there is (at least conceptually) a single algorithm which is uniform in the type—that is, it does not depend upon the particular structure of the type—that can be instantiated to each of the infinite number of possible types. However, in the case of subtype polymorphism, not all of the possible instantiations of the schema for the most general type are admissible. Instantiations are limited by a notion of structural compatibility between types, that is, using the concept of subtype.

242

8 Structuring Data

Templates in C++ Parametric polymorphism is obtained in C++ by means of templates. These are program schemata which include parameters (of class or of type). The function swap could take the following form: template void swap (T& x, T& y){ T tmp = x; x = y; y = tmp; }

The operator, &, attached to the type of a formal parameter indicates that the parameter is passed by reference, a primitive parameter-passing mode in C++ (in which it differs from C). The instantiation of a template is automatic. The call swap(x,y) is instantiated to the common type of x and y.

To be more precise, let us assume that a subtype relation is defined over the language’s types. We denote this relation by the symbol ’a. The identifiers prefixed by ‘’’ are type variables in ML, that is they can be instantiated. We can request the evaluation of Ide as follows: - Ide(4); val it = 4 : int - Ide(true); val it = true : bool

Now the functions: - fun Comp(f,g,x) = f(g(x)); val Comp = fn : (’a->’b)*(’c->’a)*’c -> ’b - fun swap(x,y) = let tmp = !x in (x:=!y; y=tmp;); val swap = fn : (’a ref)*(’a ref) -> unit

In the case of swap, type inference finds that the two arguments cannot be generic values but variables (or references) of any type whatsoever (’a ref). The exclamation mark, “!”, is the explicit dereferencing operator. The identifier, unit, is the singleton type that is used for expressions with side effects. - val v = ref 0; val v = ref 0 : int ref - val w = ref 2; val w = ref 0 : int ref - swap(v,w); val it = () : unit - !w; val it = 0 : int

In the example, v and w are initialised, respectively, to a reference to 0 and 2. Type inference correctly deduces that they must be variables of type int. After the swap, the dereferencing of w obviously yields 0.

244

8 Structuring Data

The first way of handling polymorphism is that of solving it statically at link time15 (this is the case with C++). When a polymorphic function is called in two different instances, its code is instantiated in two different ways, one for each of the different instances required. Taking again the concrete example of swap, there is a local variable, tmp, which must be allocated in the activation record when swap is called. But the space to allocate for tmp depends on its type which is not known when the template for swap is originally compiled. At link time, though, polymorphic functions can be identified and their code is modified (instantiated) so as to take into account the actual type(s) with which they are called. The resulting code can then be linked. It can be seen that there can be many copies of the same template (one per instantiation) in the executable code. On the other hand, the execution of a template-using program is as efficient as a program that does not use them, because that templates no longer exist at runtime. In the case of other polymorphic languages (and ML is one of them), a single version of the code for a polymorphic function is maintained. It is this single piece of code that is executed when one of its instances is required. What is done about the type-dependent information (in the case of swap, this is the amount of store to allocate for tmp)? It is necessary to change the whole data representation. Instead of directly allocating the data in the activation record, a pointer is maintained that points to the actual data. The data also includes its own descriptors (representing dimensions, structure, etc.). In the case of swap, when it is necessary to store a value in tmp, a pointer to the variable x is accessed and its size (as recorded in the descriptor) is accessed. At this point, the memory necessary for tmp is allocated in the heap and a pointer to it is stored in the activation record. The flexibility, uniformity and the conciseness of the code (there are no repeated instances of the same function) are paid for by decreased efficiency—an indirect reference is always required to access a piece of data. We will see more implementation details for subtype polymorphism in Sect. 10.4 when considering object-oriented languages.

8.8 Type Checking and Inference We have already seen how a language’s type checker is responsible for verifying that a program respects the rules (in particular, the compatibility rules) imposed by the type system. In the case of a language with static checking, the type checker is one of the compiler’s modules; when type checking is dynamic, the type checker is a module in the runtime system. To perform its task, the type checker must determine the type of the expressions occurring in the program (for example, it must determine whether the type of the expression on the right-hand side of an assignment is compatible with the variable on the left-hand side). To do this, it uses the 15 Some

authors hold that in cases of this kind, we should talk of generics rather than polymorphism. We think, on the contrary, that the phenomenon of polymorphism is a syntactic phenomenon of a language, that can be obtained through several different implementation approaches.

8.8 Type Checking and Inference

245

type information that the programmer has explicitly placed at critical points in the program (for example, declarations of local names, parameter declarations, explicit conversions, etc.), as well as information that is implicit in the program text (for example, the types of predefined constants, those of numerical constants and so on). To determine the type of complex expressions, the type checker performs a simple traversal of the program’s abstract syntax tree (see the start of Sect. 6.1.3). Starting at the leaves (which represent variables and constants whose types are known), it moves upwards through the tree towards the root, computing the type of the composite expressions on the basis of the information provided by the programmer and the information it obtains from the type system (for example, the type system could establish that + is an operator which, when applied to two expressions of type int, permits an expression also of type int to be derived, while =, when applied to two arguments of scalar type, gives an expression of type bool). In many cases, the information provided by the programmer can turn out to be redundant, for example: int f(int n){return n+1;}

Starting with the fact that n is of type int, it can be easily inferred that the value returned by the function must be of type int. The explicit specification given by the programmer of the result type is a redundant specification that the language requires as a last resort so that it can report possible logical errors. Instead of the simple type checking method we have merely outlined, some languages use a more sophisticated procedure which we might call type inference. The progenitor of this family of languages is ML (we have cited this language a number of times above), whose type system is sophisticated and refined. Some ideas presented in work on ML have inspired the design of many different languages, even those of a non-functional kind. In order to introduce the concept of inference in a simplified form, we will again use the definition of function f. It is clear that also the specification that the formal parameter, n, must be an int is redundant. This is because the constant 1 is an integer and + takes two integers and returns an integer, so n must be an integer. From a declaration of the form: fun f(n){return n+1;}

it is certainly possible automatically to derive that f has type int -> int. Type inference is exactly this process of the attribution of a type to an expression in which explicit type declarations of its components do not occur. To perform this derivation, the algorithm also works on a syntax tree, again starting at the leaves but, this time, it must take into account the fact that it might not be immediately possible to determine a specific type for any atomic expression (n, in this case). In a case like this, the inference algorithm assigns a type variable which it might indicate by ’a (using ML notation). Climbing the tree again and using information present in the context, some constraints for type-variables will be collected. In our case, from the type of 1 and from that of + (which comes from looking up the table of predefined symbols), the constraint ’a = int is derived.

246

8 Structuring Data

This form of inference is more general and powerful than the simple type checking algorithm used in languages like Pascal, C or Java. It is capable of determining the most general type of a function, that is it can account for all the polymorphism implicit in an expression. This is done as follows: 1. Assign a type to each node in the syntax tree. For predefined names and constants, use the type stored in the symbol table. For new (i.e., programmer-defined) identifiers, and for every composite expression (which are stored as the internal nodes of the tree), use a type variable (one new variable for every expression or name); 2. Rewalk the syntax tree, generating an (equality) constraint between types at every internal node. For example, if we apply the function symbol, f, to which we have previously assigned the type ’a to the argument v of type ’b, the constraint ’a = ’b -> ’c will be generated to indicate that f must really be a function and that its argument must be of the same type as v (’c is a new type variable). 3. Resolve the constraints thus gathered using the unification algorithm (a powerful, but conceptually simple, instrument for symbolic manipulation which we will discuss in the context of logic languages, in Sect. 12.3). There are cases in which solving constraint equations does not remove all variables. If we apply the inference algorithm to fun g(n){return n;}

we will obtain, as type, ’a -> ’a. We already know that this is not an error but a positive characteristic: an expression whose most general type contains a type variable is a polymorphic expression.

8.9 Safety: An Evaluation We started our analysis of types in programming languages with the idea of safety based on types. This same notion has guided us in our examination of the various characteristics of type systems. The time has arrived to take into account what we have understood, classifying programming languages according to their safeness. Let us, then, distinguish between: 1. Non safe languages; 2. Locally safe languages; 3. Safe languages. In the category of unsafe languages, we find all of those languages whose type system is a more or less just a methodological suggestion to the programmer, in the sense that the language allows the programmer to bypass type checking. Every language that allows access to the representation of a data type belongs to this category, as does every language that allows access to the value of a pointer (pointer arithmetic, that is). C, C++ and all the languages of their family are unsafe.

8.10 Avoiding Dangling References

247

Locally unsafe languages are those languages whose type system is well regulated and type checked but which contain some, limited, constructs which, when used, allow insecure programs to be written. The languages Algol, Pascal, Ada and many of their descendants belong to this category, provided that the abstract machine really checks types that need dynamic checking, such as checking the limits of interval types (which, it should be recalled, can be used as an index type for arrays). The unsafe part results from the presence of unions (uncontrolled variants) and from the explicit deallocation of memory. Of these two constructs, it is the second that has the greater impact in practice (it is much more common to encounter programs which deallocate memory than those which make significant use of variant records), but it is the former that is the more dangerous. As we will see in the next section, it is possible to equip the abstract machine with appropriate mechanisms to allow it to detect and prevent dangling pointers, even if, for reasons of efficiency, they are almost never used. We have already seen different examples of type-system violations which are possible when using variant records. We have postponed until last the nastiest possibility: that variant records can be used to access and manipulate the value of a pointer. In Pascal, we can write:16 var v : record case bool of true : (i:integer); false : (p:ˆinteger) end

Here, ˆinteger is the Pascal notation for the type of pointers to integers. It is now possible to assign a pointer to the variant p, manipulate it as an integer using the variant i and then use it again as a pointer. Finally, we have safe languages for which a theorem guarantees that the execution of a typed program can never generate a hidden error “induced by the violation of a type.” In this category are languages with dynamic type checking like Lisp and Scheme, as well as languages with static checking such as ML, as well as languages with static checking but with many checks also performed at runtime (as in Java).

8.10 Avoiding Dangling References In this section, we will tackle the question of which mechanisms can be included in an abstract machine that will dynamically prevent dereference of dangling pointers. This is a problem we first discussed in Sect. 8.4.5. We will first present a radical solution which works in the general case of pointers into the heap or into the stack. We will then consider a somewhat less demanding mechanism that, however, works only for pointers into a heap (and then under some probabilistic assumptions). 16 In Pascal, pointers are allocated only on the heap by an allocation request (the new function).They can be assigned but there is no primitive method to access the value of a pointer.

248

8 Structuring Data

8.10.1 Tombstone Using tombstones, an abstract machine can detect every attempt at dereferencing a dangling reference. Every time an object is allocated in the heap (to be then accessed by pointer), the abstract machine also allocates an extra word in memory. This word is called the tombstone. In a similar fashion, a tombstone is allocated every time that a stack-referencing pointer is allocated (that is, to a certain approximation, every time that the “indirection-to” operator (&) is used). The tombstone is initialised with the address of the allocated object and the pointer receives the address of the tombstone. When a pointer is dereferenced, the abstract machine inserts a second level of indirection, so that it first accesses the tombstone and then uses what it finds there to access the object that is pointed to. When one pointer is assigned to another, it is the contents of the pointer (and not the tombstone) that is modified. Figure 8.10 shows this operation graphically. On deallocation of an object, or when an indirection on the stack becomes invalid because it is part of an activation record that has been popped,17 the associated tombstone becomes invalidated, and a special value is stored in it to signal that the data to which the pointer refers is dead (this is where the name of this technique derives from). An appropriate choice of such a value must be made so that every attempt to access the contents of an invalid tombstone is captured by the addressprotection mechanism of the underlying physical machine. Tombstones are allocated in a particular area of memory in the abstract machine (this, appropriately enough, is called the cemetery). The cemetery can be managed more efficiently than the heap because all tombstones are of the same size. For all its simplicity, the tombstone mechanism imposes a heavy cost in terms both of time and space. As far as time is concerned, we must consider the time required for the creation of tombstones, that for their checking (which can be reduced, as we have seen, if an underlying hardware protection mechanism can be used) and, most importantly, the cost of two levels of indirection. Tombstones are also expensive in terms of storage. They require a word of memory for every object allocated on the heap; a word is also required every time a pointer into the stack is created. If there are lots of allocations of small objects, the percentage of memory required by tombstones can be significant. Moreover, invalid tombstones always remain allocated, with the consequence that they might exhaust the space available in the cemetery, even though there might a great deal of space available on the heap. To prevent this last problem, it is possible to reuse those tombstones that are no longer in use (that is, those to which no pointer points) using a small reference-counting garbage collector (Sect. 8.11.1); this further increases the time cost of the mechanism. 17 The operation can be quite opaque. Consider the case of a variable passed by reference to a function. Inside the function, a pointer is created to point to the variable. The pointer will be created using an associated tombstone. The tombstone must be invalidated when the lifetime of the variable forming the actual parameter ends, not when the function terminates.

8.10 Avoiding Dangling References

249

Fig. 8.10 Tombstones

8.10.2 Locks and Keys An alternative to the tombstone technique is called locks and keys. This solves the problem of dangling references into a heap using a mechanism which does not suffer from the accumulated problems of tombstones. Every time an object is created on the heap, the object is associated with a lock which is a word of memory in which an arbitrary value is stored. (Strictly speaking, it should be a value that can be sequentially incremented every time an object is allocated, but which avoids values such as 0 and 1, the code of frequently used characters, and so on.) In this approach, a pointer is composed of a pair: the address proper and a key (a word of memory that will be initialised with the value of the lock corresponding to the object being pointed to). When one pointer is assigned to another, the whole pair is assigned. Every time the pointer is dereferenced, the abstract machine checks that the key opens the lock. In other words, it verifies that the information contained in the key coincides with that in the lock. In the case in which the values are not the same, an error is signalled. When an object is deallocated, its lock is invalidated and some canonical value (for example, zero) is stored, so that all the keys which previously opened it now cause an error (see Fig. 8.11). Clearly, it can happen that the area of memory previously used as a key is reallocated (for another lock or for some other structure). It is statistically highly improbable that an error will be signalled as a result of randomly finding an ex-lock that has the same value that it had prior to being clearing. Locks and keys also have a non-negligible cost. In terms of space, they cost even more than tombstones because it is necessary to associate an additional word with each pointer. On the other hand, locks as well as keys are deallocated at the same time as the object or the pointer of which they are a part. From an efficiency viewpoint, it is necessary to take into account both the cost of creation, and, more

250

8 Structuring Data

Fig. 8.11 Locks and keys

importantly, the high cost of pointer assignment and of determining whether the key opens a lock, something that happens every time a pointer is dereferenced.

8.11 Garbage Collection In languages without explicit memory deallocation, it is necessary to equip the abstract machine with a mechanism which could automatically reclaim the memory allocated on the heap that is no longer used. This is done by a garbage collector, introduced for the first time in L ISP around 1960, and since then included in many languages initially mostly functional, and later imperative. Java has a powerful and efficient garbage collector. From the logical point of view, the operation of a garbage collector consists of two phases: 1. Distinguish those objects that are still alive from those no longer in use (garbage detection); 2. Collect those objects known no longer to be in use, so that the program can reuse them. In practice these two phases are not always temporally separate, and the technique for reclaiming objects essentially depends on the one in which the objects no longer in use are discovered. We will see, then, that the “no longer in use” concept in a garbage collector is often a conservative approximation. For reasons of effi-

8.11 Garbage Collection

251

ciency,18 not all the objects that can be used again are, in reality, determined by the garbage collector to be so. The educational aim of this text does not permit us to describe a garbage collector for a real language, or to provide an exhaustive overview of the different techniques available (there are bibliographic references to exhaustive treatments). We will limit ourselves to presenting in some detail the main points in the light of the most common techniques. Real garbage collectors are variations on these techniques. In particular the collectors that are of greatest interest today are based upon some form of incremental reclamation of memory and are beyond the scope of this book. We can classify classical garbage collectors according to how they determine whether an object is no longer in use. We will have, therefore, collectors based on reference counting, as well as marking and copying. In the next few sections, we will present these collectors. We will discuss these techniques in terms of pointers and objects but the argument can equally be applied to languages without pointers which use the reference variable model. Finally, we will see that all the techniques that we consider need to be able to recognize those fields inside an object that correspond to pointers. If objects are created as instances of statically-defined types (so it is statically known where pointers are inside instances), the compiler can generate a descriptor containing offsets to the pointers in each type. Each object in the heap is associated with the type of which it is an instance (for example, via a pointer to its type descriptor). When an object is to be deallocated, the garbage collector accesses the type descriptor to access the pointers inside the object. Similar techniques are used to recognise which words in an activation record are pointers. If types are only known dynamically, descriptors have to be completely dynamic and allocated together with the object.

8.11.1 Reference Counting A simple way to tell whether an object is not in use is to determine whether there are any pointers to it. This is the reference counting technique. It defines what is probably the easiest way of implementing a garbage collector. When an object is created on the heap, an integer is allocated at the same time. This integer is the reference counter or reference count for the object. The reference count is inaccessible to the programmer. For each object, the abstract machine must ensure that the counter contains the number of pointers to this object that are still active. In order to do this, when an object is created (that is, a pointer for it is assigned for the first time), its counter is initialised to 1. When we have a pointer assignment: p = q;

18 As

well as decidability.

252

8 Structuring Data

Fig. 8.12 Reference counting

the counter belonging the object pointed to by q is incremented by one, while the counter of object pointed to by p is decremented by one. When a local environment is exited, the counters of all the objects pointed to by pointers local to the environment are decremented. Figure 8.12 shows operation of this technique in diagrammatic form. When a counter returns to the value 0, its associated object can be deallocated and returned to the free list. This object, moreover, might contain internal pointers, so before returning the memory occupied by an object to the free list, the abstract machine follows the pointers inside the object and decrements by one the counters of the objects they point to, recursively collecting all the objects whose counter has reached 0. From the viewpoint of the abstract division into two phases of a garbage collector, the update and checking of counters implement the garbage-detection phase. The collection phase occurs when the counter reaches zero. A clear advantage of this technique is that it is incremental because checking and collection are interleaved with the normal operation of the program. With a few adjustments, real-time systems (that is systems where there are absolute deadlines to response time) can employ this technique. The biggest defect, at least in principle, of this technique is in its inability to deallocate circular structures. Figure 8.13 shows a case in which a circular structure has no more access paths. However it cannot be collected because, clearly, its counters are not zero. It can be seen that the problem does not reside so much in the algorithm, as in the definition of what a useless object is. It is clear that all objects in a circular structure are not usable any more, but this is not at all captured by the definition of not being pointed at. Reference counting, despite its simplicity, is also fairly inefficient. Its cost is proportional to the combined work performed by the program (and not to the size of the heap or to the percentage of it in use or not in use at any time). One particular case is that of updating the counters of parameters of pointer type which are passed to functions that execute only for a short time. These counters are allocated and, after a particularly short time, have their value returned to zero.

8.11 Garbage Collection

253

Fig. 8.13 Circular structures with reference counts

8.11.2 Mark and Sweep The mark and sweep method takes its name from the way in which the two abstract phases we mentioned at the start are implemented: • Mark. To recognize that something is unused, all the objects in the heap are traversed, marking each of them has “not in use”. Then, starting from the pointers which are active and present on the stack (the root set), all the data structures present in the heap are traversed recursively (the search is usually performed depth-first) and every object that is encountered is marked as “in use”. • Sweep. The heap is swept—all blocks marked “in use” are left alone, while those marked “not in use” are returned to the free list. It can be seen that to implement both phases, it is necessary to be able to recognize allocated blocks in the heap. Descriptors might be necessary to give the size (and organisation) of every allocated block. Unlike the reference-counting garbage collector, a mark and sweep collector is not incremental. It it will be invoked only when the free memory available in the heap is close to being exhausted. The user of the program can therefore experience a significant degradation in response time while waiting for the garbage collector to finish. The mark and sweep technique suffers from three main defects. In the first place, and this is also true for reference counting, it is asymptotically the cause of external fragmentation (see Sect. 5.4.2): live and no longer live objects are arbitrarily mixed in the heap which can make allocating a large object difficult, even if many small blocks are available. The second problem is efficiency. It requires time proportional to the total length of the heap, independent of the percentages of used and free space. The third problem relates to locality of reference. Objects that are “in use” remain in their place, but it is possible that objects contiguous with them will be collected and new objects allocated in their place. During execution, we find that objects with very different ages appear next to each other. This, in general, drastically reduces locality of reference, with the usual degradation in performance observed in systems with memory hierarchies.

254

8 Structuring Data

Fig. 8.14 A stack is necessary for depth-first traversal

8.11.3 Interlude: Pointer Reversal Without some precautions, every marking technique runs the risk of being completely unusable in a garbage collector. The collector, indeed, goes into action when the memory is near to being exhausted, while the marking phase consists of the recursive traversal of a graph, which requires the use of a stack to store the return pointers.19 It is necessary, when marking a graph under these circumstances, to use carefully the unused space present in pointers, using a technique called pointer reversal. As shown in Fig. 8.14, when visiting a chained structure, it is necessary to mark a node and recursively visit the substructures whose pointers are part of that node. In this recursive scheme, it is necessary to store the addresses of blocks when they are visited in a stack, so that they can be revisited when the end of the structure is reached. In the Figure, using depth-first search, node E has been reached (marked blocks are indicated with a tick). The stack contains nodes A, B and C. After visiting E, it takes C from the stack and follows any pointers leading from this node; since there are none, it takes B from the stack and follows the remaining pointer, pushing B onto the stack, and visiting D. Using pointer reversal, this stack is stored in the pointers that form the structure, as shown in Fig. 8.15. When the end of a substructure is reached, (and a pop of the stack is required), the pointer is returned to its original value, so that at the end of the visit, the structure is exactly the same as it was at the start (apart from marking, clearly). In the figure, we are visiting node E. It can be seen how the stack in Fig. 8.14 is stored in space internal to the structure itself (pointers marked with a grey background). Only two pointers (p_prec and p_curr) are required to perform the visit. After visiting E, using p_prec, the structure is retraversed in a single step. Using the reversed pointer, we return to B, resetting the correct value of the pointer in C using p_curr. 19 In

many abstract machines, stack and heap are implemented in a single area of memory, with stack and heap growing in opposite directions starting from the two ends. In such a case, when there is no space in the heap, there is no space for the stack.

8.11 Garbage Collection

255

Fig. 8.15 Pointer reversal

8.11.4 Mark and Compact To avoid the fragmentation caused by the mark and sweep technique, we can modify the sweep phase and convert it into a compaction phase. Live objects are moved so that they are contiguous and thereby leave a contiguous block of free memory. Compaction can be performed by moving linearly across the heap, moving every live block encountered and making it contiguous with the previous block. At the end, all free blocks are contiguous, as are all unused blocks. This is a technique which, like mark and sweep, requires more than one pass over the heap (and the time required is therefore proportional to the heap size). Compaction, on its own, requires two or three passes. The first is to compute the new position to be taken by the live blocks; a second updates the internal pointers and a third actually moves objects. It is, therefore, a technique that is substantially more expensive than mark and sweep if there are many objects to be moved. On the other hand, compaction has optimal effect on fragmentation and on locality. It supports treating the free list as a single block. New objects are allocated from the free list by a simple pointer subtraction.

8.11.5 Copy In garbage collectors based on copy there is no phase during which the “garbage” is marked. There is just the copying and compaction of live blocks. The lack of an explicit mark phase and the completely different way space is handled make its costs substantially different from those of algorithms based on marking. In the simplest copy-base garbage collector (called a stop and copy collector), the heap is divided into two equally-sized parts (two semi-spaces). During normal execution, only one of the two semi-spaces is in use. Memory is allocated at one end of the semi-space, while free memory consists of a unique contiguous block which reduces its size every time there is an allocation (see Fig. 8.16). Allocation is extremely efficient and there is no fragmentation.

256

8 Structuring Data

Fig. 8.16 Stop and copy before a call to the garbage collector

Fig. 8.17 Stop and copy after the execution of the garbage collector

When the memory in the semi-space is exhausted, the garbage collector is invoked. Starting with pointers in the stack (the root set), it begins visiting the chain of structures held in the current semi-space (the fromspace), copying the structures one by one into the other semi-space (the tospace), compacting them at one end of the latter (see Fig. 8.17). At the end of this process, the role of the two semi-spaces is swapped and execution returns to the user program. The visit and copy of the live part can be executed in an efficient manner using the simple technique known as Cheney’s algorithm (Fig. 8.18). Initially, all the objects which are immediately reachable from the root set are copied. This first set of

8.11 Garbage Collection

257

Fig. 8.18 Cheney’s algorithm

objects is copied in a contiguous fashion into the tospace; it is handled as if it were a queue. Consider now the first of these objects, and add to the end of the queue (that is, copy into the tospace) the objects pointed to by the pointers present in the first object, while, at the same time, these pointers are modified. In this way, we have copied into the tospace all the first object’s children. We keep processing the queue until it remains empty. At this point, in the tospace we have a copy of the live objects in the fromspace.20 20 Some precautions must be taken to prevent objects accessible via multiple pointers being copied more than once.

258

8 Structuring Data

A stop and copy garbage collector can be made arbitrarily efficient, provided that there is enough memory for the two semi-spaces. In fact, the time required for a stop and copy is proportional to the number of live objects present in the heap. It is not unreasonable to assume that this quantity will be approximately constant at any moment during the execution of the program. If we increase the memory for the two semi-spaces, we will decrease the frequency with which the collector is called and, therefore, the total cost of garbage collection.

8.12 Chapter Summary This chapter has dealt with a crucial aspect in the definition of programming languages: the organisation of data in abstract structures called data types. The main points can be summarised as follows. • Definition of type as a set of values and operations and the role of types in design, implementation and execution of programs. • Type systems as the set of constructs and mechanisms that regulate and define the use of types in a programming language. • The distinction between dynamic and static type checking. • The concept of type-safe systems, that is safe with respect to types. • The primary scalar types, some of which are discrete types. • The primary composite types, among which we have discussed records, variant records and unions, arrays and pointers in detail. For each of these types, we have also presented the primary storage techniques. • The concept of type equivalence, distinguishing between equivalence by name and structural equivalence. • The concept of compatibility and the related concepts of coercion and conversion. • The concept of overloading, when a single name denotes more than one object and static disambiguation. • The concept of universal polymorphism, when a single name denotes an object that belongs to many different types, finally distinguishing between parametric and subtype polymorphism. • Type inference, that is mechanisms that allow the type of a complex expression to be determined from the types of its elementary types. • Techniques for runtime checking for dangling references: tombstones and locks and keys. • Techniques for garbage collection, that is the automatic recovery of memory, briefly presenting collectors based on reference counters, mark and sweep, mark and compact and copy. Types are the core of a programming language. Many languages have similar constructs for sequence control but are differentiated by their type systems. It is not possible to understand the essential aspects of other programming paradigms, such as object orientation, without a deep understanding of the questions addressed in this chapter.

8.13 Bibliographic Notes

259

8.13 Bibliographic Notes Ample treatments of programming language types can be found in [14] and the rather older [4]. Review articles which introduce the mathematical formalisms necessary for research in this area are [2, 11]. A larger treatment of the same arguments is to be found in [13]. On overloading and polymorphism in type systems, a good, clear review is [3] (which we have largely followed in this chapter). Tombstones originally appeared in [8] (also see, by the same author, [9]). Fisher and Leblanc [5] proposed locks and keys, as well as techniques so that an abstract Pascal machine can make variant records secure. The official definition of A LGOL 68 (which is quite a read) is [15]. A more accessible introduction can be found in [12]. The definition of ML can be found in [10], while an introductory treatment of type inference is to be found in [1]. There is a large literature on garbage-collection techniques. A detailed description of a mark and sweep algorithm can be found in many algorithm books, for example [6], while [16] is a good summary of classical techniques. For a book entirely devoted to the problem, that contains pseudocode and a more-or-less complete bibliography (up to the time of publication), [7] is suggested.

8.14 Exercises 1. Consider the declaration of the multi-dimensional array: int A[10][10][10]

We know that an integer can be stored in 4 bytes. The array is stored in row order, with increasing memory addresses (that is, if an element is at address i, its successor is at i + 4, and so on). The element A[0][0][0] is stored at address 0. State the address at which element A[2][2][5] is stored. 2. Instead of the contiguous multidimensional array allocation that we discussed in Sect. 8.4.3, some languages allow (e.g., C), or adopt (Java), a different organisation, called row-pointer. Let us deal with the case of a 2-dimensional array. Instead of storing rows one after the other, every row is stored separately in some region of memory (for example on the heap). Corresponding to the name of the vector, a vector of pointers is allocated. Each of the pointers points to a proper row of the array. (i) Give the formula for accessing an arbitrary element A[i][j] of an array allocated using this scheme. (ii) Generalise this memory technique to arrays of more than 2 dimensions. (iii) Discuss the advantages and disadvantages of this organisation in the general case. (iv) Discuss the advantages and disadvantages of this technique for the storage of 2-dimensional arrays of characters (that is, arrays of strings). 3. Consider the following (Pascal) declarations: type string = packed array [1..16] of char;

260

8 Structuring Data type string_pointer = ˆstring; type person = record name : string; case student: Boolean of true: (year: integer); false: (socialsecno: string_pointer) end;

and assume that the variable C contains a pointer to the string “LANGUAGES”. Describe the memory representation for the person record after each of the following operations: var pippo : person; pippo.student := true; pippo.year := 223344; pippo.student := true; pippo.socialsecno := C;

4. Show that the integer type can be defined as a recursive type starting with just the value null. Then write a function that checks if two integers defined in this way are equal. 5. Given the following type definitions in a programming language which uses structural type equivalence: type T1 = struct{ int a; bool b; }; type T2 = struct{ int a; bool b; } type T3 = struct{ T2 u; T1 v; } type T4 = struct{ T1 u; T2 v; }

In the scope of the declarations T3 a and T4 b, it is claimed that the assignment a = b is permitted. Justify your answer. 6. Which type is assigned to each of the following functions using polymorphic type inference? fun G(f,x){return f(f(x));} fun H(t,x,y){if (t(x)) return x; else return y;} fun K(x,y){return x;}

8.14 Exercises

261

7. Using tombstones, it is necessary to invalidate a tombstone when its object is no longer meaningful. The matter is clear if the object is on the heap and is explicitly deallocated. It is less clear when the tombstone is associated with an address on the stack. In this case, indeed, it is necessary for the abstract machine to be able to determine all the tombstones that are potentially associated with an activation record. Design a possible organisation which makes this operation reasonably efficient (recall that tombstones are not allocated in activation records but in the cemetery). 8. Consider the following fragment in a pseudo-language with reference-based variables and which uses locks and keys (C is a class whose structure is of no importance): C foo C bar C fie bar =

= new C(); = new C(); = foo; fie;

// object OG1 // object OG2

Give possible values after the execution of the fragment for all the keys and all the locks involved. 9. Under the same assumptions as in Exercise 8, consider the following code fragment in which free(p) denotes the explicit deallocation of the object referred to by the pointer p: class C { int n; C next;} C foo = new C(); // object OG1 C bar = new C(); // object OG2 foo.next = bar; bar.next = foo; free(bar);

For all the pointers in the fragment, give possible key values. For each object in the fragment, give possible lock values. In both cases, the values should be those after execution of the fragment terminates. After execution of the fragment, also execute the code foo.n = 1; foo.next = 0;. State what a possible result of this execution might be. 10. Consider the following fragment which is written in a pseudo-language with a reference-model for variables and a reference-counting garbage collector. If OGG is an arbitrary object in the heap, indicate by OGG.cont its (hidden) contents: class C { int n; C next;} C foo(){ C p = new C(); // object OGG1 p.next = new C(); // object OGG2 C q = new C(); // object OGG3 q.next = p.next; return p.next; } C r = foo();

262

8 Structuring Data

State what are the values of the reference counters for the three objects after execution of line 6 and then of line 9. 11. Under the same assumptions as in Exercise 10, state what the values of the reference counters are for the two objects after the execution of the following fragment. Which of the two can be returned to the free list? C foo C bar C fie bar =

= new C(); = new C(); = foo; fie;

// object OG1 // object OG2

12. Under the same assumptions as in Exercise 10, state what the reference-counter values for the three objects after execution of the following fragment are. Which of them can be returned to the free list? class C { int n; C next;} C foo = new C(); // object OG1 bar = new C(); // object OG2 foo.next = bar; bar = new C(); // object OG3 foo = bar;

13. Using your favourite programming language, define the data structures required to represent a binary tree. Then write detailed code that performs a preorder traversal of a tree without using the system stack and instead using the pointerreversal technique.

References 1. L. Cardelli. Basic polymorphic typechecking. Science of Computer Programming, 8(2):147– 172, 1987. citeseer.ist.psu.edu/cardelli88basic.html. 2. L. Cardelli. Type systems. In A. B. Tucker, editor, The Computer Science and Engineering Handbook. CRC Press, Boca Raton, 1997. citeseer.ist.psu.edu/cardelli97type.html. 3. L. Cardelli and P. Wegner. On understanding types, data abstraction, and polymorphism. ACM Computing Surveys, 17(4):471–522, 1985. citeseer.ist.psu.edu/cardelli85understanding.html. 4. J. C. Cleaveland. An Introduction to Data Types. Addison-Wesley, Reading, 1986. 5. C. N. Fisher and R. J. LeBlanc. The implementation of run-time diagnostics in Pascal. IEEE Trans. Softw. Eng., 6(4):313–319, 1980. 6. E. Horowitz and S. Sahni. Fundamentals of Data Structures in Pascal. Freeman, New York, 1994. 7. R. Jones and R. Lins. Garbage Collection: Algorithms for Automatic Dynamic Memory Management. Wiley, New York, 1996. 8. D. B. Lomet. Scheme for invalidating references to freed storage. IBM Journal of Research and Development, 19(1):26–35, 1975. 9. D. B. Lomet. Making pointers safe in system programming languages. IEEE Trans. Softw. Eng., 11(1):87–96, 1985. 10. R. Milner, M. Tofte, R. Harper, and D. MacQueen. The Definition of Standard ML—Revised. MIT Press, Cambridge, 1997.

References

263

11. J. C. Mitchell. Type Systems for Programming Languages, pages 365–458, 1990. ISBN: 0-444-88074-7. 12. F. Pagan. A Practical Guide to Algol 68. Wiley Series in Computing. Wiley, London, 1976. 13. B. Pierce. Types and Programming Languages. MIT Press, Cambridge, 2002. 14. D. A. Schmidt. The Structure of Typed Programming Languages. MIT Press, Cambridge, 1994. 15. A. van Wijngaarden, B. J. Mailloux, J. E. L. Peck, C. H. A. Koster, M. Sintzoff, C. H. Lindsey, L. G. L. T. Meertens, and R. G. Fisker. Revised report on the algorithmic language ALGOL 68. Acta Informatica, 5:1–236, 1975. 16. P. R. Wilson. Uniprocessor garbage collection techniques. In Proc. Int. Workshop on Memory Management, LNCS, volume 637. Springer, Berlin, 1992. Extented version online ftp://ftp.cs.utexas.edu/pub/garbage/bigsurv.ps. citeseer.ist.psu.edu/wilson92uniprocessor. html.

Chapter 9

Data Abstraction

The physical machine manipulates data of only one type: bit strings. The types of a high-level language impose an organisation on this undivided universe, giving each value a sort of “wrapping”. Each value is wrapped in an encapsulation (its type) which provides the operations that manipulate it. The type system for a language establishes how transparent this encapsulation is. In type-safe languages, the encapsulation is completely opaque, in the sense that it does not allow access to the representation (or better: every access can only take place using or by means of the encapsulation itself). The last chapter presented in detail many of the predefined types and the principal mechanisms for defining new ones. The latter, however, are fairly limited: finite homogeneous aggregations (arrays) and heterogeneous ones (records), recursive types and pointers. The operations possible on these composite types are predefined by the language and the programmer is restricted to use them. It is clear that the programmer, using just the mechanisms we discussed in Chap. 8, cannot really define a new type, when it is understood, using our definition, as a collection of (homogeneous and effectively presented) values equipped with a set of operations. The user of a language can only make use of the existing capsules and only has highly limited ways to define new types: there are few data abstraction mechanisms. In this chapter, we will present some of the main ways in which a language can provide more sophisticated mechanisms for defining abstractions over data. Among these, we will discuss the so-called abstract data type, which in different forms is provided by several languages. We then look at modules, a largely similar concept, but which mainly applies to programming in the large. These abstraction mechanisms also constitute an introduction to some themes that we will encounter again with object-oriented programming. The key concepts that we will investigate in this chapter are the separation between interface and implementation and the concepts associated with information hiding.

9.1 Abstract Data Types The introduction of a new type using the mechanisms discussed in the last chapter M. Gabbrielli, S. Martini, Programming Languages: Principles and Paradigms, Undergraduate Topics in Computer Science, DOI 10.1007/978-1-84882-914-5_9, © Springer-Verlag London Limited 2010

265

266

9 Data Abstraction type Int_Stack = struct{ int P[100]; // the stack proper int top; // first readable element } Int_Stack create_stack(){ Int_Stack s = new Int_Stack(); s.top = 0; return s; } Int_Stack push(Int_Stack s, int k){ if (s.top == 100) error; s.P[s.top] = k; s.top = s.top + 1; return s; } int top(Int_Stack s){ return s.P[s.top]; } Int_Stack pop(Int_Stack s){ if (s.top == 0) error; s.top = s.top - 1; return s; } bool empty(Int_Stack s){ return (s.top == 0); }

Fig. 9.1 Stack of integers

does not permit the user of a language to define types at the same level of abstraction as that enjoyed by the predefined types in these languages. By way of an example, Fig. 9.1 shows one possible definition in our pseudolanguage of the stack of integers data type. We assume a reference model for variables. When defining a type of this kind, it is probably intended that a stack of integers will be a data structure that can be manipulated by the operations of creation, insertion, access to the top element, removal of the top element. However, the language does not guarantee that these are the only ways in which a stack can be manipulated. Even if we adopt a strict type equivalence by name discipline (so that a stack is introduced by a declaration of the type Int_Stack) nothing prevents us from directly accessing its representation as an array: int second_from_top()(Int_Stack c){ return c.P[s.top - 1]; }

From a general viewpoint, therefore, while languages provide predefined data abstractions (types) which hide implementations, the programmer cannot do this for themselves. To avoid this problem, some programming languages allow the definition of data abstractions which behave like predefined types as far as the (in)accessibility of representations is concerned. This mechanism is called an abstract data type (ADT). It is characterised by the following primary characteristics:

9.1 Abstract Data Types

267

1. A name for the type. 2. An implementation (or representation) for the type. 3. A set of names denoting operations for manipulating the values of the type, together with their types. 4. For every operation, an implementation that uses the representation provided in point 2. 5. A security capsule which separates the name of the type and those of the operations from their implementations. One possible notation for the stack of integers ADT in our pseudo-language could be that depicted in Fig. 9.2. abstype Int_Stack{ type Int_Stack = struct{ int P[100]; int n; int top; } signature Int_Stack create_stack(); Int_Stack push(Int_Stack s, int k); int top(Int_Stack s); Int_Stack pop(Int_Stack s); bool empty(Int_Stack s); operations Int_Stack create_stack(){ Int_Stack s = new Int_Stack(); s.n = 0; s.top = 0; return s; } Int_Stack push(Int_Stack s, int k){ if (s.n == 100) error; s.n = s.n + 1; s.P[s.top] = k; s.top = s.top + 1; return s; } int top(Int_Stack s){ return s.P[s.top]; } Int_Stack pop(Int_Stack s){ if (s.n == 0) error; s.n = s.n - 1; s.top = s.top - 1; return s; } bool empty(Int_Stack s){ return (s.n == 0); } } Fig. 9.2 ADT for stacks of integers

1

3

5

7

9

11

13

15

17

19

21

23

25

27

29

31

33

35

37

39

268

9 Data Abstraction

A definition of this kind must be interpreted as follows. The first line introduces the name of the abstract data type. Line 2 provides the representation (or concrete type) for the abstract type Int_Stack. Lines 7 to 12 (introduced by signature) define the names and types of the operations that can manipulate an Int_Stack. The remaining lines (introduced by operations) provide the implementation of the operations. The important point of this definition is that inside the declaration of type, Int_Stack is a synonym for its concrete representation (and therefore the operations manipulate a stack as a record containing an array and two integer fields), while outside (and therefore in the rest of the program), there is no relation between an Int_Stack and its concrete type. The only possible ways to manipulate an Int_Stack are provided by its operations. The function second_from_top(), which we defined above, is now impossible because type checking does not permit the application of a field selector to an Int_Stack (which is not a record outside of its definition.) An ADT is an opaque capsule. On the outside surface, visible to anyone, we find the name of the new type and the names and types of the operations. Inside, invisible to the outside world, there are the implementations of the type and its operations. Access to the inside is always controlled by the capsule which guarantees the consistency of the information it encloses. This external surface of the capsule is called the signature or interface of the ADT. On its inside is its implementation. Abstract data types (in languages that support them, for example ML, and CLU1 ) behave just like predefined types. It is possible to declare variables of an abstract type and to use one abstract type in the definition of another, as has been done, by way of example, in Fig. 9.3. The code in Fig. 9.3 implements (very inefficiently) a variable of type integer using a stack. Inside the implementation of Int_Var, the implementation of Int_Stack is invisible because it was completely encapsulated when it was defined.

9.2 Information Hiding The division between interface and implementation is of great importance for software development methods because it allows the separation a component’s use from its definition. We also saw this distinction when we looked at control abstraction. A function abstracts (that is, hides) the code constituting its body (the implementation), while it reveals its interface, which is composed of its name and of the number and types of its parameters (that is, its signature). Data abstraction generalises this somewhat primitive form of abstraction. Not only is how an operation is implemented hidden but so is the way in which the data is represented, so that the language (with its type system) can guarantee that the abstraction cannot be violated. This phenomenon is called information hiding. One of the more interesting 1 In object-oriented languages, we will see that it is possible to obtain the same abstraction goal using a similar but more flexible method.

9.2 Information Hiding

269

Constructors, transformers and observers In the definition of an abstract data type, T, the operations are conceptually divided into three separate categories: • Constructors. These are operations which construct a new value of type T, possibly using values of other known types. • Transformers or operators. These are operations that compute values of type T, possibly using other values (of the same ADT or of other types). A fundamental property of a transformer t of type S1 × · · · × Sk -> Y is that, for every argument value, it must be the case that t(s1 ,. . .,sk ) is a value constructable using only constructors. • Observers. These are operations that compute a value of a known type that is different from T, using one or more values of type T. An ADT without constructors is completely useless. There is no way to construct a value. In general, an ADT must have at least one operation in each of the above categories. It is not always easy to show that an operation is really a transformer (that is, that each of its values is in reality a value that can be obtained from a sequence of constructors). In the integer stack example, create_stack and push are constructors, pop is a transformer and top and empty are observers.

abstype Int_Var{ type Int_Var = Int_Stack; signature Int_Var create_var(); int deref(Int_Var v); Int_Var assign(Int_Var v, int n); operations Int_Var create_var(){ return push(create_stack(),0); } int deref(Int_Var v){ return top(v); } Int_Var assign(Int_Var v, int n){ return push(pop(v),n); } } Fig. 9.3 An ADT for an integer variable, implemented with a stack

consequences of information hiding is that, under certain conditions, it is possible to substitute the implementation of one ADT for that of another while keeping the interface the same. In the stack example, we could opt to represent the concrete type as a linked list (ignoring deallocation) allocated in the heap. This is de-

270

9 Data Abstraction abstype Int_Stack{ type Int_Stack = struct{ int info; Int_stack next; } signature Int_Stack create_stack(); Int_Stack push(Int_Stack s, int k); int top(Int_Stack s); Int_Stack pop(Int_Stack s); bool empty(Int_Stack s); operations Int_Stack create_stack(){ return null; } Int_Stack push(Int_Stack s, int k){ Int_Stack tmp = new Int_Stack(); // new element tmp.info = k; // chain on tmp.next = s; return tmp; } int top(Int_Stack s){ return s.info; } Int_Stack pop(Int_Stack s){ return s.next; } bool empty(Int_Stack s){ return (s == null); } }

Fig. 9.4 Another definition of the Int_Stack ADT

fined as in Fig. 9.4. Under certain assumptions, by substituting the first definition of Int_Stack by that in Fig. 9.4, there should be no observable effect on programs that use the abstract data type. These assumptions centre on what the clients of the interface expect from the operations. Let us say that the description of the semantics of the operations of an ADT is a specification, expressed not in terms of concrete types but general abstract relations. One possible specification for our ADT Int_Stack could be: • create_stack creates an empty stack. • push inserts an element into the stack. • top returns the element at the top of the stack without modifying the stack itself. The stack must not be empty. • pop removes the top elements from the stack. The stack must not be empty. • empty is true if and only if the stack is empty.

Every client that uses Int_Stack making use of this specification only, will see no difference at all in the two definitions. This property has come to be called the principle of representation independence.

9.3 Modules

271

The specification of an abstract data type can be given in many different ways, ranging from natural language (which we have done) to semi-formal schemata, to completely formalised languages that can be manipulated by theorem provers. A specification is a kind of contract between the ADT and its client. The ADT guarantees that the implementation of the operations (which are unknown to the client) matches the specification; that is, all the properties stated in the specification are satisfied by the implementation. When this happens, it is also said that the implementation is correct with respect to the specification.

9.2.1 Representation Independence We can state the representation independence property as follows: Two correct implementations of a single specification of an ADT are observationally indistinguishable by the clients of these types.

If a type enjoys representation independence, it is possible to replace its implementation by an equivalent (e.g., more efficient) one without causing any (new) errors in clients. It should be clear that a considerable (and not at all obvious) part of representation independence consists of the guarantee that both implementations are correct with respect to the same specification. This can be hard to show, particularly when the specification is informal. There is, however, a weak version of the representation independence property that concerns only correctness with respect to the signature. In a type-safe language with abstract data types, the replacement of one ADT by another with the same signature (but different implementation) does not cause type errors. Under the assumptions we have made (of type safety and ADT), this property is a theorem which can be proved by type inference. Languages like ML and CLU enjoy this form of representation independence.

9.3 Modules Abstract data types are mechanisms for programming in the small. They were designed to encapsulate one type and its associated operations. It is much more common, however, for an abstraction to be composed of a number of inter-related types (or data structures) of which it is desired to give clients a limited (that is, abstract) view (not all the operations are revealed and there is concealment of the implementation). The linguistic mechanisms which implement this type of encapsulation are called modules or packages. They belong to that part of a programming language dealing with programming in the large, that is with the implementation of complex systems using composition and assembly of simpler components. The module mechanism allows the static partitioning of a program into separate parts, each of which is equipped with data (types, variables, etc.) as well as with operations (functions, code, etc.). A module groups together a number of declarations (of data and/or

272

9 Data Abstraction

functions) as well as defining visibility rules for these declarations by means of which a form of encapsulation and information hiding is implemented. Considering semantic principles, there is not much of a difference between modules and ADTs, mostly the ability to define more than one type at a time (according to the definitions we have given, an ADT is a particular case of a module). Pragmatically, on the other hand, the module mechanism affords greater flexibility, both in the ability to state how permeable its encapsulation is (indeed, it is possible to indicate on an individual basis which operations are visible or to choose the level of visibility), or in the possibility of defining generic (polymorphic) modules (recall Sect. 8.8). Finally, module constructs are often related to separate compilation mechanisms for modules themselves.2 Even given the enormous variety among existing languages, we can state the important linguistic characteristics of a module by discussing the example shown in Fig. 9.5. It is expressed, as usual, in an suitable pseudo-language. First of all, a module is divided, as is an ADT, into a public part (which is visible to all the module’s clients) and a private part (which is invisible to the outside world). The private part of a module can contain declarations that do not appear at all in the public part (for example, the bookkeep function inside Queue). A module can mention some of its own data structures in the public part, so that anyone can use or modify them (the variable c in Buffer, for example). A client module can use the public part of another module by importing it (the imports clause). In our example, Buffer has an additional import clause in its private part. We will not continue with this discussion, both because we would have to go into the details of the mechanisms in a specific language, and because we will return to many points when considering object-oriented programming. To conclude, let us merely observe that the module mechanism is often associated with some form of parametric polymorphism which requires link-time resolution. In our example, we could have defined a buffer of type T, rather than a buffer of integer, making the definition generic and then suitably instantiating it when it is used. Figure 9.6 shows the generic version of the buffer example. It can be seen how the buffer and the code are both generic. When the private part of Buffer imports Queue, it specifies that it must be instantiated to the same type (which is not specified) as Buffer.

9.4 Chapter Summary This short chapter has presented a first introduction to data abstraction, which turns on the key concepts of interface, implementation, encapsulation, data hiding.

2 Keep

in mind that modules and separate compilation are independent aspects of a language. In Java, for example, it is not the module (package, in Java terminology) which is the unit of compilation, rather the class is.

9.4 Chapter Summary

module Buffer imports Counter{ public type Buf; void insert(reference Buf f, int n); int get(Buf b); Count c; // how many times buffer has been used private imports Queue{ type Buf = Queue; void insert(reference Buf b, int n){ inqueue(b,n); inc(c); } int get(Buf b){ return dequeue(b); inc(c); } // module initialisation part init_counter(c); } module Counter{ public type Count; void init_counter(reference Count c); int get(Count c); void inc(reference Count c); private type Count = int; void init_counter(reference Count c){ c=0; } int get(Count c){ return c; } void inc(reference Count c){ c = c+1; } } module Queue{ public type Queue; inqueue(reference Queue q, int n); int dequeue(reference Queue q); ... private void bookkeep(reference Queue q){ ... } ... } Fig. 9.5 Modules

273

274

9 Data Abstraction

module Buffer imports Counter{ public type Buf; void insert(reference Buf f, n); get(Buf b); Count c; // how many times buffer has been used private imports Queue{ type Buf = Queue; void insert(reference Buf b, n){ inqueue(b,n); inc(c); } get(Buf b){ return dequeue(b); inc(c); } } module Counter{ public type Count; void init_counter(reference Count c); int get(Count c); void inc(reference Count c); private type Count = int; void init_counter(reference Count c){ c=0; } int get(Count c){ return c; } void inc(reference Count c){ c = c+1; } init_counter(c); // module initialisation } module Queue{ public type Queue; inqueue(reference Queue q, n); dequeue(reference Queue q); ... private void bookkeep(reference Queue q){ ... } ... } Fig. 9.6 Generic modules

9.5 Bibliographical Notes

275

From a linguistic viewpoint, we have presented the following: • Abstract data type mechanisms. • Mechanisms to hide information and their consequences; that is, the Principle of representation independence. • Modules which apply the concepts of encapsulation to programming in the large. All of these concepts are treated in more depth in texts on software engineering. As far as this book is concerned, they are devices to help understanding objectoriented programming which is the subject of the next chapter.

9.5 Bibliographical Notes The concept of module probably appears for the first time in the Simula language [1, 4], the first object-oriented language (see Chap. 13). The development of modules in programming languages is due to the work of Wirth [6], which includes the Modula and Oberon [7] projects. The concept of information hiding made its first appearance in the literature in a classic paper by Parnas [5]. Abstract data types originate in the same context, as a mechanism guaranteeing abstraction that is different from modules. Among the languages that include ADTs, the most influential is certainly C LU [3] which is also the basis for the book [2].

9.6 Exercises 1. Consider the following definition of an ADT in our pseudo-language: abstype LittleUse{ type LittleUse = int; signature LittleUse prox(LittleUse x); int get(LittleUse x); operations LittleUse prox(LittleUse x){ return x+1; } int get(LittleUse x){ return x; } }

Why this type is useless?

276

9 Data Abstraction

References 1. G. Birtwistle, O. Dahl, B. Myhrtag, and K. Nygaard. Simula Begin. Auerbach Press, Philadelphia, 1973. 2. B. Liskov and J. Guttag. Abstraction and Specification in Program Development. MIT Electrical Engineering and Computer Science Series. MIT Press, Cambridge, 1986. 3. B. Liskov, A. Snyder, R. Atkinson, and C. Schaffert. Abstraction mechanisms in CLU. Commun. ACM, 20(8):564–576, 1977. 4. K. Nygaard and O.-J. Dahl. The development of the SIMULA languages. In HOPL-1: The First ACM SIGPLAN Conference on History of Programming Languages, pages 245–272. ACM Press, New York, 1978. 5. D. L. Parnas. On the criteria to be used in decomposing systems into modules. Commun. ACM, 15(12):1053–1058, 1972. 6. N. Wirth. The module: A system structuring facility in high-level programming languages. In Language Design and Programming Methodology. LNCS, volume 79, pages 1–24. Springer, Berlin, 1979. 7. N. Wirth. From Modula to Oberon. Softw. Pract. Exp., 18(7):661–670, 1988.

Chapter 10

The Object-Oriented Paradigm

In this chapter, we present the important aspects of object-oriented languages, a paradigm which has its roots in Simula (during the 60s) and Smalltalk (in the 70s). It achieved enormous success, including commercial success, in the two following decades (C++ and Java are only two of the most known languages among the many that are in use today). “Object oriented” is by now an abused slogan, which can be found applied to languages, to databases, operating systems, and so on. Here, we attempt to present the linguistic aspects which concern objects and their use, making the occasional reference to object-oriented design techniques (but we can only refer the reader to the (extended) literature for details). Even after restricting the subject, there are many ways to proceed to the concepts that interest us. We will follow the approach we believe the simplest: we will present objects as a way to gain data abstraction in a way that is flexible and extensible. We will begin our study, then, by showing some limits to the techniques that we introduced in Chap. 9. These limits will suggest to us some concepts, which, in fact, form the basics of an object-oriented language. Having examined these characteristic aspects in detail, we will study some extensions to linguistic solutions that are available in commercial languages, referring, in particular, to the concepts of subtype, polymorphism and genericity. Following the style that we have maintained thus far in this text, we will seek to remain independent of any specific programming language, even if this will not always be possible. The language that will mostly inspire us will be Java, for its coherence of design, which will allow us to discuss some concepts (and not linguistic details) in a clearer way and in a way that allows us to summarise the properties of other languages.

10.1 The Limits of Abstract Data Types Abstract data types are a mechanism that guarantees the encapsulation and hiding of information in a clean and efficient manner. In particular, the have the excellent characteristic of uniting in a single construct both data and the methods for legally M. Gabbrielli, S. Martini, Programming Languages: Principles and Paradigms, Undergraduate Topics in Computer Science, DOI 10.1007/978-1-84882-914-5_10, © Springer-Verlag London Limited 2010

277

278

10 The Object-Oriented Paradigm

manipulating it. This is a very important methodological principle, which is obtained at the cost of a certain rigidity of use, which shows up when it is wanted to extend or reuse an abstraction. We will discuss these problems using a simple and certainly not realistic example, but one which exposes the most important questions. So that we do not overload the notation with the call-by-reference, it is convenient to use a language that uses a reference model for variables. The following ADR implements a simple counter: abstype Counter{ type Counter = int; signature void reset(Counter x); int get(Counter x); void inc(Counter x); operations void reset(Counter x){ x = 0; } int get(Counter c){ return x; } void inc(Counter c){ x = x+1; } }

The concrete representation of the Counter type is the integer type. The only operations possible are zeroing of a counter, reading and incrementing its value. We want now to define a counter that is enriched by some new operations. For example, we want to take into account the number of calls the reset operation has had in a given counter. We have a choice of 2 approaches: the first is that of defining a completely new ADT which is similar in many respects to the one just defined with the addition of new operations, as in: abstype NewCounter1{ type NewCounter1 = struct{ int c; int num_reset = 0; } signature void reset(NewCounter1 x); int get(NewCounter1 x); void inc(NewCounter1 x); int howmany_resets(NewCounter1 x); operations void reset(NewCounter1 x){ x.c = 0; x.num_reset = x.num_reset+1; } int get(NewCounter1 x){ return x.c;

10.1 The Limits of Abstract Data Types

279

} void inc(NewCounter1 x){ x.c = x.c+1; } int howmany_resets(NewCounter1 x){ return x.num_reset; } }

This is a solution that is acceptable as far as encapsulation goes, but we were required to redefine the operations what we have already defined for a simple counter (they are operations with the same name but with different argument types; names are therefore overloaded which the compiler has to differentiate using the context). In this academic example, we have only a few lines of code but the negative effect on a real situation can be quite significant.1 More important again is what happens when, for whatever reason, it is desired to change the implementation of a simple counter. There being no relationship between Counter and NewCounter, modifications such as these are not felt by another counter: a NewCounter will still continue to work perfectly. But if the modification were due to reasons of usefulness or efficiency (for example, we found an excellent new way to implement an inc), such a modification must be performed by hand on the definition of a NewCounter, with all the known problems that this brings (find all the places where a variant of the old inc is used, do not introduce any syntactic errors, etc.). The second possibility that we have is one that makes use of Counter to define an enriched counter: abstype NewCounter2{ type NewCounter2 = struct{ Counter c; int num_reset = 0; } signature void reset(NewCounter2 x); int get(NewCounter2 x); void inc(NewCounter2 x); int howmany_resets(NewCounter2 x); operations void reset(NewCounter2 x){ reset(x.c); x.num_reset = x.num_reset+1; } int get(NewCounter2 x){ return get(x.c); } void inc(NewCounter2 x){ inc(x.c); 1 This is a negative effect not only on the writing of the program, but also in the size of the code produced because there are two copies of each operation!

280

10 The Object-Oriented Paradigm } int howmany_resets(NewCounter2 x){ return x.num_reset; }

}

The solution is clearly better than the previous one. The operations that do not have to be modified are only called from inside a NewCounter (with its usual name overloading), so that the last problem mentioned above is solved. There remains the task of performing the calls explicitly even for the operations (such as get and inc) that have not been modified: it would be preferable to have an automatic mechanism with which to inherit the implementations of these two operations from Counter. There remain problems, though, of how to handle in a uniform fashion the values of Counter and of NewCounter2. Let us assume, in fact, that are dealing with a series of counters, some simple, some enriched, and that we want to reset them all to their initial value. To fix ideas, we can imagine an array of counters; we want to reset each element of this array to its initial value. A first problem arises immediately when we try to work out what the type of this array is. If we declare it as: Counter V[100];

we cannot store NewCounter2s there because the two types are distinct. The same thing happens when the array is declared as being of type NewCounter2. To solve the problem, we need a concept of compatibility between the 2 types. Let us remember that among the various forms of compatibility we discussed in Sect. 8.7, we find the following: T is compatible with S when all the operations over values of type S are also possible over values of type T.

We have exactly a case of this kind: all the operations on a Counter are possible also on a NewCounter2 (on which we can apply an additional operation). It is, therefore, sensible to require that a hypothetical language should relax the rigidity of ADTs, admitting this form of compatibility. Let us therefore assume that NewCounter2 is compatible with Counter and is therefore permitted to have a vector declared as Counter V[100] in which are stored simple and extended counters. We now come to the main point, which is to reset the initial value of each one of these counters. The obvious idea is: for (int i=1; ig() prints B.

A obj_a = obj_b; print(obj_a.f()); print(obj_a.a);

where print denotes a method which outputs the integer value passed as an argument. The first two invocations of print produce the value 2 twice, as should be obvious. The third call will also print the value 2, given that, as already seen above, the method f has been redefined in class B. In fact the object created (with new B()) is an instance of B, and hence every access to it, even those through a variable of type A (as in the case of obj_a), uses the redefined method (which is obviously using the redefined fields in class B). The last occurrence of print, instead, produces the value 1. In this case, in fact, given that we are not dealing with the invocation of a method but accessing a field, it is the type of the current reference

10.3 Implementation Aspects

301

Multimethod languages In the languages we have considered so far, a method invocation has the form: o.m(parameters);

Dynamic method lookup uses the run-time type of the object receiving the method, while uses the static types of the parameters. In some other languages (for example, CLOS), this asymmetry is removed. Methods are no longer associated with classes but are global names. Each method name is overloaded by a number of implementations (which in this case are called multimethods) and the object on which the method is invoked is passed to every multimethod. When invoking a multimethod, the code that must be executed is chosen dynamically on the basis of the (dynamic) type of both the receiver and all the arguments. In these languages, we speak of multiple dispatch rather than single dispatch in languages where there exists a privileged receiver. In languages with multiple dispatch, the analogy between (multiple) dynamic dispatch and “dynamic overloading” is more evident; multiple dispatch consists in the (runtime) resolution of an overloading on the basis of dynamic type information.

which determines which field is to be considered. Given that obj_a is of type A, when we write obj_a.a, the field in question is the one in class A (initialised to one). This distinction between overriding and shadowing, is explained at the implementation level using the fact that the instance object of class B also contains all the fields of the superclasses of B, as we will make clear in the next section.

10.3 Implementation Aspects Every language has its own implementation model which is optimised to the specific features that the language provides. We can, however, indicate some common lines which indicate the main problems and their solutions. Objects An instance object of class A can be used as the value of any superclass of A. particular, it is possible to access not just the instance variables (data fields) explicitly defined in A, but also those defined in its superclasses. An object can be represented as if it were a record, with as many fields as there are variables in the class of which it is an instance, in addition to all those appearing in its superclasses. In a case of shadowing, or rather when a name of an instance variable of the class is used with the same type in a subclass, the object contains additional fields, each one corresponding to a different declaration (often, the name used in the superclass

302

10 The Object-Oriented Paradigm

Fig. 10.6 A simple implementation of inheritance

is not accessible in the subclass, if not using particular qualifications, for example super). The representation also contains a pointer to the descriptor of the class of which it is an instance. In the case of a language with a static type system, this representation allows the simple implementation of subtype compatibility (in the case of single inheritance). For each instance variable, the offset from the start of the record is statically recorded. If access to an instance object of a class is performed using a (static) reference having as type one of the superclasses of that object, static type checking ensures that access can be made only to a field defined in the superclass, which is allocated in the initial part of the record. Classes and inheritance The representation of classes is the key to the object orientation abstract machine. The simplest and most intuitive implementation is the one which represents the class hierarchy using a linked list. Each element represents a class and contains (pointers to) the implementation of the methods that are either defined or redefined in that class. The elements are linked using a pointer which points from the subclass to the immediate superclass. When a method m of an object o which is an instance of a class C is invoked, the pointer stored in o is used to access the descriptor of C and determine whether C contains an implementation of m. If it does not, the pointer is set to the superclass and the procedure is repeated (see Fig. 10.6). This approach is used in Smalltalk, although it is inefficient because every method invocation requires a linear scan of the class hierarchy; the advantage of the technique is its simplicity. We will shortly discuss more efficient implementations after we have seen how to access instance variables from within a method invocation.

10.3 Implementation Aspects

303

Late binding of self A method is executed in a way similar to a function. An activation record for the method’s local variables, parameters and all the other information is pushed onto the stack. Unlike a function, though, a method must also access the instance variables of the object on which it is called; the identity of the object is not known at compile time. However, the structure of such an object is known (it depends on the class) and, therefore, the offset of every instance variable in an object’s representation is statically known (subject to conditions depending upon the language). A pointer to the object which received the method is also passed as a parameter when a method is invoked. During execution of the body of the method, this pointer is the method’s this. When the method is invoked on the same object that invokes it, this still is passed as a parameter. During the execution of the method, every access to an instance variable uses the offset from this pointer (instead of having an offset from a pointer into the activation records, as is the case for local variables of functions). From a logical point of view, we can assume that the this pointer is passed through the activation record typically with all other parameters, but this would cause a doubly-indirect access for every instance variable (one to access the pointer using the activation record pointer and one to access the variable using this). More efficiently, the abstract machine will maintain the current value of this in a register.

10.3.1 Single Inheritance Under the hypothesis that the language have a static type system, the implementation using linked lists can be replaced by another, more efficient one, in which method selection requires constant time (rather than time linear in the depth of the class hierarchy). If types are static, the set of methods that any object can invoke is known at compile time. The list of these methods is kept in the class descriptor. The list contains not just the methods that are explicitly defined or redefined in the class but also all the methods inherited from its superclasses.14 Following C++’s terminology, we will use the term vtable (virtual function table) to refer to this data structure. Each class definition has its own vtable and all instances of the same class share the same vtable. When a subclass, B, of the class A is defined, B’s vtable is generated by copying the one for A, replacing all the methods redefined in B and adding the new methods that B defines at the bottom (this is shown in Fig. 10.7). The fundamental property of this data structure is, that, if B is a subclass of A, B’s vtable contains a copy of A’s vtable as its initial part; redefined methods are appropriately modified. In this way, the method invocation costs only two indirect accesses, the offset of every method in the vtable being statically known. It can be 14 We

are assuming that dynamic lookup applies to all methods. In cases like C++, where only virtual methods can be redefined, the descriptor contains only the latter, while ordinary method calls are treated like normal function calls.

304

10 The Object-Oriented Paradigm

Fig. 10.7 Implementation of simple inheritance

seen that this implementation obviously takes into account the fact that it is possible to access an object with a reference that belongs statically to one of its superclasses. In the example in Fig. 10.7, when method f is invoked, the compiler computes an offset that remains the same whether f is invoked on an object of class A or on an object of class B. Different implementations of f defined in the two classes are located at the same offset into the vtables of A and B. On the whole, if we have a static reference pa of class A to some object of one of its subclasses, we can compile a call to method f (which, we assume to be the nth in A’s vtable) as follows (we have assumed that the address of a method occupies w bytes): R1 := pa R2 := *(R1) R3 := *(R2 + (n − 1) × w) call *(R3)

// // // //

access the object vtable indirect to f call f

Ignoring support for multiple inheritance, this implementation scheme is almost the same as used in C++. Downcasting If a class’ vtable also contains the name of the class itself, the implementation we have discussed allows downward casts in the class hierarchy. This is called downcasting and is a fairly frequently used mechanism. It permits the specialisation of the type of object by running in the opposite direction to the subtype hierarchy. A canonical example of the use of this mechanism is found in some library methods which are defined to be as general as possible. The class Object might use the following signature to define a method for copying objects: Object clone(){...}

10.3 Implementation Aspects

305

The semantics is that clone returns an exact copy of the object which invoked it (same class, same values in its fields, etc.). If we have an object o of class A, an invocation of o.clone() will return an instance of A, but the static type as determined by the compiler for this expression is Object. In order to be able meaningfully to use this new copy, we have to “force” it to type A, which we can indicate with a cast: A a = (A) o.clone();

By this, we mean that the abstract machine checks that the dynamic type of the object really is A (in the opposite case, we would have a runtime type error).15

10.3.2 The Problem of Fragile Base Class In the case of simple inheritance, the implementation of the mechanism described above is reasonably efficient, given that all the important information, except the this pointer is statically determined. This staticity, though, can be shown to be the source of problems in a context known as the fragile base class problem. An object-oriented system is organised in terms of a very large number of classes using an elaborate inheritance hierarchy. Often some of these general classes are provided by libraries. Modifications to a class located very high in the hierarchy, can be felt in its subclasses. Some superclasses can, therefore, behave in a “fragile” manner because an apparently innocuous modification to the superclass can cause the malfunctioning of subclasses. It is not possible to identify fragility by analysing only the superclass. It is necessary to consider the entire inheritance hierarchy, something which is often impossible because whoever wrote the superclass generally does not have access to all subclasses. The problem can arise for a number of reasons. Here, we will only distinguish two main cases: • The problem is architectural. Some subclass exploit aspects of the superclass’ implementation which have been modified in the new version. This is an extremely important problem for software engineering. It can be limited by reducing the inheritance relation in favour of the subtype relation. • The problem is implementational. The malfunctioning of the subclass depends only on how the abstract machine (and the compiler) has represented inheritance. This case is sometimes referred to as the problem of fragile binary interface. In this text, the first case is not our main interest; the second is. A typical case shows up in the context of separate compilation where a method is added to a superclass, even if the new method interacts with nothing else. Starting from the following: 15 This

is Java notation. C++ allows the same notation to be used but, for compatibility with C, it accepts the expression at compile time without introducing dynamic checks. A cast with dynamic checks would be written dynamic_cast(o) in C++.

306

10 The Object-Oriented Paradigm

class Upper{ int x; int f(){..} } class Lower extending Upper{ int y; int g(){return y + f();} }

the super class is modified as: class Upper{ int x; int h(){return x;} int f(){..} }

If inheritance is implemented as described in Sect. 10.3.2, the subclass Lower (which is already compiled and linked to Super) ceases to function correctly because the offset used to access to method f has been changed, since it is determined statically. To solve this problem it is necessary to recompile all the subclasses of the modified classes, a solution which is not always easy to perform. To obviate this question, it is necessary to compute dynamically the offset of methods in the vtable (and also the offset of instance variables in the representation of objects), in some reasonably efficient manner. The next section describes one possible solution.

10.3.3 Dynamic Method Dispatch in the JVM In this section we present a simple description of the technique used by the Java virtual machine (JVM), the abstract machine which interprets the intermediate (bytecode) language generated by the standard Java compiler. For reasons of space, we cannot go into the details of the JVM’s architecture; we note that it is a stack-based machine (it does not have user-accessible registers and all operation operands are passed on a stack contained in the activation record of the function that is currently being executed). The JVM has modules for checking operation security. We limit ourselves to discussing the broad outlines of the implementation of inheritance and method dispatching. In Java, the compilation of each class produces a file which the abstract machine loads dynamically when the currently executing program refers to the class. This file containing a table (the constant pool) for symbols used in the class itself. The constant pool contains entries for instance variables, public and private methods, methods and fields of other classes used in the body of methods, names of other classes mentioned in the body of the class etc. With each instance variable and method name is recorded information such as the class where the names are

10.3 Implementation Aspects

307

defined and their type. Every time that the source code uses the name, the intermediate code of the JVM looks up the index of that name in the constant pool (to save space—it does not look up the name itself). When, during execution, reference is made to a name for the first time (using its index), it is resolved using the information in the constant pool, the necessary classes (for example the one in which the names are introduced) are loaded, visibility checks are performed (for example the invoked method must really exist in the class referring to it, is not a private, etc.); type checks are also performed. At this point, the abstract machines saves a pointer to this information so that the next time the same name is used, it is not necessary to perform resolution a second time. The representation of methods in a class descriptor can be thought of as being analogous to that in the vtable.16 The table for a subclass starts with a copy of the one for its superclass, where redefined methods have their new definitions instead of the old ones. Offsets, however, are not statically calculated. When a method is to be executed, four main cases can be distinguished (which correspond for distinct bytecode instructions): 1. The method is static. This is for a method associated with a class and not an instance. No reference (explicit or implicit) can be made to this. 2. The method must be dispatched dynamically (a “virtual” method). 3. The method must be dispatched dynamically and is invoked using this (a “special” method). 4. The method comes from an interface (that is from a completely abstract class which provides no implementation—an “interface” method). Ignoring the last case for the moment, the 3 other cases can be distinguished primarily by the parameters passed to the method. In the first case, only the parameters named in the call are passed. In the second case, a reference is passed to the object on which the method is called. In case 3, a reference to this is passed. Let us therefore assume that we can invoke method m on object o as: o.m(parameter )

Using the reference to o, the abstract machine accesses the constant pool of its class and extracts the name of m. At this point, it looks up this name in the class’ vtable and determines its offset. The offset is saved in case of a future use of the same method on the same object. However the same method could also be invoked on other objects, possibly belonging to subclasses of the one which o belongs to (e.g., a for loop in whose body a call to m is repeated on all the objects in an array). To avoid calculating the offset each time (which would be the same independent of the effective class of which the 16 In reality, the specification of the JVM does not prescribe any particular representation and limits itself to requiring that the search for the method to be executed is semantically equivalent to the dynamic search for the method name in the list of subclasses described above. The most common implementation, however, is of a table that is very similar to the vtable.

308

10 The Object-Oriented Paradigm

method m is called on is an instance), the JVM interpreter uses a “code rewrite” technique. It substitutes for the standard lookup instruction generated by the compiler an optimised form which takes as its argument the offset of the method in the vtable. In order to fix ideas (and simplifying a great deal), when translating the invocation of a virtual method m, the compiler might generate the byte code instruction: invokevirtual index

where index is the index of the name m in the constant pool. During execution of this instruction, the JVM interpreter calculates the offset d of m in its vtable and replaces the instruction above with the following: invokevirtual_quick d np

Here, np is the number of the parameters that m expects (and which will be found on the stack that is part of its activation record). Every time that the flow of control returns to this instruction, m is invoked without overhead. There remains the case of the invocation of an interface method (that is, case 4 above). In this case, the offset might not be the same in 2 invocations of the same method on objects in different classes. Consider the following situation (in which we use Java syntax rather than pseudocode): interface Interface{ void foo(); } public class A implements Interface{ int x; void foo(){...} } public class B implements Interface{ int y; int fie(){...} int foo(){...} }

Both A and B implement Interface and therefore are its subtypes. The offset of foo is different in the two classes, though. Consider our usual loop: Interface V[10]; ... for (int i = 0; i is the same thing as writing List but this is not the case because List is not a supertype, for example, of List, while List is really the supertype of all types List for all A. Using wildcards, the method drawAll could be written: void drawAll(List