cient

a-2 &A-3

AESOP. AIMACO
ALGY
ALGOL
AMBIT
ALTRAN
AMTRAN
APL
An imated Movie
APL/360 APT
BACAIC BASEBALL

BUGSYS C—10
BASIC
CLP COBOL
CLIP
COGO COLASL
COGENT
COLINGO COMIT

Commercial Translator
Computer Compiler

CORAL CORC
Computer Design
Culler—Fried DAS
ces
DIALOG | DIAMAG
DATA-TEXT DEACON
DSL/90 DYANA
DIMATE DOCUS
DYSAC English
DYNAMO n NA zo
Extended ALGOL
FLAP
FACT TRAN
473L Query ALGOL aay GECOM
GPl
FORMAC For a
mul Kler er- May
FSL
FORTRANSIT Graphic
pss |} GRAE informatt
on Algebra
d
ICES IDS \6 Laning
JOVIAL
JOSS

Line olin Reckoner

LDT LOIS
LOLITA MATHLAB

Magic paper META 2

Matrix COmpPUe! OMNITAB
OCAL
: PRINT Short Code
NELIAC
eze5-ALGOL
PENCIL PL SIMSCRIPT } { SIMULA
IKTRAN SNOBOL SOL Speedcoding
Simul. Dig. Syst-
SPRINT STRESS STROBES Symbolic Math. Lab.
TRAC TRANDIR TREET UNCOL UNICODE
PROGRAMMING LANGUAGES :
History and Fundamentals
Prentice-Hall Series in Automatic Computation
George Forsythe, editor

ARBIB, Theories of Abstract Automata

BATES AND DOUGLAS, Programming Language/One
BAUMANN, FELICIANO, BAUER, AND SAMELSON, Introduction to ALGOL
BLUMENTHAL, Management Information Systems
BOBROW AND SCHWARTZ, editors, Computers and the Policy-Making Community: Applica-
tions to International Relations
BOWLES, editor, Computers in Humanistic Research
CESCHINO AND KUNTZMANN, Numerical Solution of Initial Value Problems
CRESS, DIRKSEN, AND GRAHAM, Fortran IV with Watfor
DESMONDE, A Conversational Graphic Data Processing System: The IBM 1130/2250
DESMONDE, Computers and Their Uses
DESMONDE, Real-Time Data Processing Systems: Introductory Concepts
EVANS, WALLACE, AND SUTHERLAND, Simulation Using Digital Computers
FIKE, Computer Evaluation of Mathematical Functions
FORSYTHE AND MOLER, Computer Solution of Linear Algebraic Systems
GOLDEN, Fortran IV: Programming and Computing
GOLDEN AND LEICHUS, IBM 360: Programming and Computing
GORDON, System Simulation
GREENSPAN, Lectures on the Numerical Solution of Linear, Singular and Nonlinear Differential
Equations
GRISWOLD, POAGE, AND POLONSKY, Zhe SNOBOL4 Programming Language
GRUENBERGER, editor, Computers and Communications—Toward a Computer Utility
GRUENBERGER, editor, Critical Factors in Data Management
HARTMANIS AND STEARNS, Algebraic Structure Theory of Sequential Machines
HULL, Introduction to Computing
LOUDEN, Programming the IBM 1130 and 1800
MARTIN, Design of Real-Time Computer Systems
MARTIN, Programming Real-Time Computer Systems
MARTIN, Jelecommunications and the Computer
MARTIN, Jeleprocessing Network Organization
MINSKY, Computation: Finite and Infinite Machines
MOORE, Interval Analysis
SAMMET, Programming Languages: History and Fundamentals
SCHULTZ, Digital Processing: A System Orientation
SNYDER, Chebyshev Methods in Numerical Approximation
STERLING AND POLLACK, Introduction to Statistical Data Processing
STROUD AND SECREST, Gaussian Quadrature Formulas
TRAUB, Iterative Methods for the Solution of Equations
VARGA, Matrix Iterative Analysis
VAZSONYI, Problem Solving by Digital Computers with PL/I Programming
WILKINSON, Rounding Errors in Algebraic Processes
ZIEGLER, Time-Sharing Data Processing Systems

PRENTICE-HALL INTERNATIONAL, INC., London

PRENTICE-HALL OF AUSTRALIA, PTY. LTD., Sydney
PRENTICE-HALL OF CANADA, LTD., Toronto
PRENTICE-HALL OF INDIA PRIVATE LTD., New Delhi
PRENTICE-HALL OF JAPAN, INC., Tokyo
PROGRAMMING LANGUAGES :
History and Fundamentals

JEAN E. SAMMET

Programming Language Technology Manager

Federal Systems Division
IBM Corporation

PRENTICE-HALL, INC.
ENGLEWOOD CLIFFS, N. J.
Concept of the tower of BABEL to represent a large set
of programming languages is due to the Communications
of the ACM, a publication of the Association for Com-
puting Machinery, Inc. The illustration appears on the
front endpaper.

© 1969 by Prentice-Hall, Inc.

Englewood Cliffs, New Jersey

All rights reserved. No part of this book

may be reproduced in any form
or by any means without permission
in writing from the publisher.

Current printing (last digit):

10 9 8 7 6 5 4 3

Library of Congress Catalog Card No. 68-28110

Printed in the United States of America

. And the LORD said, Behold the people is one, and they have all one language;
and this they begin to do; and now nothing will be restrained from them, which
they have imagined to do.
. Go to, let us go down, and there confound their language, that they may not
understand -one another’s speech.
. So the LORD scattered them abroad from thence upon the face of all the earth;
and they left off to build the city.
. Therefore is the name of it called Babel; because the LORD did there confound
the language of all the earth; and from thence did the LORD scatter them
abroad upon the face of all the earth.

Gen. XI
 PREFACE

The primary purpose of this book is to serve as a reference for an overall

view of higher level languages. The book brings together in one place, and
in a consistent fashion, fundamental information on programming lan-
guages, including history, general characteristics, similarities, and differences.
A second purpose of the book is to provide specific basic information
on all the significant, and most of the minor, higher level languages developed
in the United States.
The third purpose of the book is to provide history and perspective for
this particular aspect of the programming field. Comments on both are the
responsibility of the author and are not necessarily accepted by all the people
concerned. Because of the rapidly changing nature of this type of work,
new languages appear daily (literally) and so this book represents a snapshot
of—and an (indirect) explanation of how we arrived at—the situation at
a given point in time, namely the fall of 1967. In a few instances, major
happenings of 1968 which could be inserted into galley or page proofs were
included, but in general the text and bibliography cover the period through
1967.
The most well known language (FORTRAN) is merely one of approxi-
mately /20 languages described in this book. (Of this total, approximately
20 are completely dead or on obsolete computers, about 35 are receiving
very little usage, about 50 are for specialized application areas, and about
15 are widely used and/or implemented.) No major attempt has been made
to include languages which are known or used only within a single organi-
zation. Most of those discussed here have been described in published
literature. However, a few languages discussed only in reports issued by the
developing organization have been included.

vi
 PREFACE Vii

Other purposes are to provide an extensive bibliography of relevant

material, to show various philosophies of language design, to describe a
number of the key factors involved in choosing a language, and to provide
the reader with enough information so that he can decide which languages
he wishes to examine in detail.
It is not the purpose of this book to teach how to program in any of the
languages described, nor is the purpose to provide specific or detailed com-
parisons of related languages, nor is it meant to provide a cookbook for
selecting a language for a particular application. A discussion of implemen-
tation techniques is also outside the scope of this book. Except for a few
special cases, only languages which have been developed in the United States,
and which have been implemented, are described. This restriction applies also
to comments of the type “there has not been anything of this kind done”;
such remarks apply to U.S. work only and might be invalid when consider-
ing other countries. Furthermore, some of these remarks are very time
dependent and because of the rapidly changing nature of the field become
invalid when considering work done after 1967.
Since even the very definition of a programming language is debatable,
it is clear that inclusion or exclusion in the book is based on my view of
the meaning of the phrase programming language. This is discussed in
Chapter I. The amount of space given to each language in the book is
usually dependent on both the complexity of the language and the author’s
judgment of its importance (either past, present, or future). Every effort
has been made to ensure that the descriptions are accurate and not mislead-
ing. (See the Acknowledgments.)
The reader is assumed to have had experience, or at least one course,
in programming. In many places, more than this minimum is needed for
full understanding although the basic points should be comprehensible to
readers with little experience.
Although not written as a textbook, this book could be used as the
basic source for course 12 (Programming Languages) in Curriculum 68
as described by the ACM Curriculum Committee on Computer Science.
It might be used for background reading in courses B1 (Introduction to
Computing), 11 (Data Structures), 15 (Compiler Construction), Al (Formal
Languages and Syntactic Analysis), A8 (Large-scale Information Processing
Systems), and A9 (Artificial Intelligence and Heuristic Programming). Since
this book was not available at the time that the committee made its report,
obviously the book could not appear in any of the bibliographies suggested
for the courses.
Chapter I provides a general introduction to the subject of programming
languages, advantages and disadvantages, various classifications, and factors
involved in the choice of a language. Chapters II and III discuss respectively
the functional (i.e., non-technical) and technical characteristics of program-
viii PREFACE

ming languages. Most of the language descriptions are based on the outline
and concepts established in those two chapters, and so a careful reading of
Chapters II and III is required in order to understand the rest of the book.
This admittedly has the disadvantage of not necessarily being the best way
to describe a specific language, but has the advantage of providing some
consistency throughout the discussions. However, some of the flavor and
style of the individual language descriptions have been allowed to creep in,
and serve as a preview of what would be encountered in a more detailed
study. In a very few instances, minor inexact statements have been made
because the accurate language description would require details beyond the
scope of this book.
The remaining chapters and sections are relatively independent, and
in most cases a specific language description can be read without knowledge
of any other languages. Chapter IV deals with languages used primarily for
numerical scientific problems. Chapter V discusses those used for business
data processing. Chapter VI discusses the list and string processing languages,
and Chapter VII describes languages used for doing formal algebraic mani-
pulation. Chapter VIII describes languages which can be effectively used in
more than one of the areas covered in the preceding four chapters. Sample
programs for most of the languages in Chapters IV through VIII have been
included; they are meant solely to illustrate the syntactic style of the lan-
guages, and they are not guaranteed to be either correct or efficient. A few
problems have been coded in several different languages to provide an easy
comparison.
Chapter IX describes about 50 languages which are used in more
specialized application areas. Because greater specific knowledge of those
areas is needed to appreciate the languages, the discussions are very brief
and superficial. The criteria for judging these languages is less stringent
than those used for languages in preceding chapters, so that some of the
languages included are not conceptually very different from older ones which
were deliberately omitted, and they do not necessarily satisfy all the defining
characteristics of Chapter I. The criteria have been reduced to make clear
the great need for specialized languages.
Chapter X discusses a few significant unimplemented concepts. Finally,
Chapter XI contains the author’s personal views on future long range
developments in programming languages.
The philosophy and arrangement of references 1s described in Appendix
A, which also contains a list of authors of included citations. The beginning
of this Appendix should be read before looking at any of the reference lists.
Appendix B contains a list of each language described in this book, the
meaning of its acronym, a very brief description, and the one or two best
references for it.
The book outline was constructed with great care and is shown com-
 PREFACE 1X

pletely in the Table of Contents. A significant amount of fundamental

information is contained there and it should serve as a basic outline to the
subject as viewed by the author.
The process of preparing this manuscript for printing actually required
the solution of some technical problems in language description, not all of
which I successfully solved. In order to make the reading of the text easier,
it was necessary to settle on a distinctive type style to represent actual words
in a language. Thus, specific statements which would be legal in a program,
such as normal arithmetic and control statements, are written as A = B + C
and GO TO HECK. However, in those cases where the format of a state-
ment was being described, it was necessary to distinguish between the fixed
words in the language, and the variable names which are to be supplied by
the programmer. This was settled by writing GO TO statementiabel or
MOVE A TO B where A and B represent variables. However, there is
clearly a difference between the two occurrences of the phrase “GO TO
statement” in the following sentence, and the distinction is handled as
follows: The GO TO statement in FORTRAN is of the form GO TO statement.
More specifically the style used in the book 1s the following: Fixed words
appearing in a definition of the format of a command, and all words in a
specific example, are set THIS WAY or this way. Words or letters representing
characters to be supplied by the programmer (metalinguistic variables as
described in Chapter II) are set THIS WAY or this way. (Thus the letters A
and B would be set as A, B if used in an example, and as A, B if used in the
definition of a format.) In a discussion about a statement or a Jist of state-
ment names, the name of the statement is set THiS WAY or this way. The
use of upper and lower case letters have no significance and are merely
those most commonly used in descriptions of the particular language in-
volved. In ALGOL based languages, the tradition of boldface was used
with the above concepts, resulting in this style or this style. The character
‘has been used to represent the prime or apostrophe available on printer
chains or typewriters.
Another problem which exists is the variable size of the characters and
spaces used in setting this book. In input/output media for computers, all
characters require the same amount of space, and there is either a blank
between them, or there is not. To simulate this a specific size space was
used to represent the computer blank character; however, this space could
not always be maintained in programs where vertical alignment of columns
was critical. Thus, in material that represents specific examples, the spacing
is critical and is shown as well as possible; on the other hand, it is essential
to realize that in many languages the presence of one, many, or no spaces
is immaterial and the reader should not conclude that because a space was
present or absent that this is a requirement of the language. The language
description specifies whether or not the blank character is significant.
X PREFACE

While these ideas may appear confusing here, it is hoped that the type
styles will be clear in the text. However, the really careful reader will find
that my scheme breaks down in many minor places, and it is left as an
exercise for the reader to find the actual places and to propose a solution.
The subject of programming languages 1s quite controversial and even
includes debate on what should be included or excluded. Therefore, this
book reflects the author’s personal opinions to a much larger extent than
would a book on a more stable or well defined area. It should be clearly
understood that the specific views expressed in the text, and the implied
views represented by the selection and arrangement of the languages, are
solely those of the author.

Jean E. Sammet
Cambridge, Massachusetts
 ACKNOWLEDGMENTS

As stated in the preface, every effort has been made to ensure that the lan-
guage descriptions are accurate and not misleading. In order to accomplish this,
virtually every individual language writeup was sent to one or more experts
in that particular language. Because a large majority of these people spent
significant time in reviewing more than one draft and making constructive
comments, it seems appropriate to list the names of the languages or sections
with the individuals who commented on them, and to take this opportunity
to express my deep thanks. It must be emphasized that any errors, omissions,
or misleading statements in the text are completely and solely my respon-
sibility, and not those of the people listed here. They are also not necessarily
in agreement with the views I have expressed about various aspects of the
language or its contributions to the technology.

Languages marked with an asterisk were also included in a review of

a larger section. Languages that are marked with an asterisk but for which
no reviewer is listed were reviewed only as part of a larger section.

Language Reviewer(s) Language Reviewer‘(s)

A-2 & A-3* Hopper, G. M. APL Iverson, K.
ADAM* Lafferty, E. APL/360 Falkoff, A. D.
AED* Ross, D. T. APT* Ross, D. T.
AESOP* Hazle, M. BACAIC*
AIMACO Hopper, G. M.; BASEBALL*
Jones, J. L. BASIC Kurtz, T. E.
ALGOL Ingerman, P. Z. C-10* Lafferty, E. L.
ALTRAN Brown, W. S. CLIP*
AMBIT* Christensen, C. CLP*
AMTRAN Seitz, R. N. COBOL Betscha, R. F.

xi
Xii ACKNOWLEDGMENTS

Language Reviewer(s) Language Reviewer(s)

COGENT* LISP 1.5* Abrahams, P. W.;
COGO* Logcher, R. Edwards, D.
COLASL Carter, G. L. LISP 2 Abrahams, P. W.;
COLINGO* Lafferty, E. L. Barnett, J. A.
COMIT* Bennett, J. L.; MAD Galler, B. A.
Yngve, V. MADCAP Wells, M. B.
Commercial Magic Paper Clapp, L. C.
Translator Goldfinger, R. MAP Brackett, J.
CORAL* MATHLAB Engelman, C.
CPS Rochester, N.; MATH-MATIC* — Hopper, G. M.
Schroeder, D. A. META 5*
DEACON?* MILITRAN*
DYNAMO* MIRFAC Gawilik, H. J.
473L Query* NELIAC Halstead, M. H.
FACT Clippinger, R. F. OPS-3* Jones, M.
FLAP Morris, A. H., Jr. PL/I Beech, D.; Cundall, P.;
FLOW-MATIC Hopper, G. M. Hankam, E. V.;
FORMAC Tobey, R. G. Mitchell, R.
Formula ALGOL Perlis, A. J. PRINT*
FORTRAN Heising, W.; Protosynthex*
Ridgeway, R. QUIKTRAN Morrissey, J.
FORTRANSIT* Short Code*
FSL* | SIMSCRIPT*
GAT* Galler, B. SIMULA*
GPSS* Krasnow, H. SNOBOL* Bennett, J. L.;
GRAF Johnson, C. Griswold, R. E.
ICES* Logcher, R. SOL*
IPL-V* Newell, A. Speedcoding*
IT Galler, B. A.; STRESS* Logcher, R.
Perlis, A. J. Symbolic Math.
JOSS Shaw, J.C. Lab. Martin, W. A.
JOVIAL Perstein, M.; TMG*
Shaw, C. J. TRAC* Mooers, C.
Klerer-May Klerer, M. TRANDIR*
L6* Knowlton, K. TREET* Haines, E. C.
Laning and Zierler* UNICODE* Hopper, G. M.
Lincoln Reckoner Wiesen, R.

Section Reviewer(s) Section Reviewer(s)

IV.1 andIV.2 Hopper, G. M. IX.3.1 Jones, M.; Krasnow, H.
Chapter VI Bobrow, D.G.; Raphael, B. 3.2 Walker, D.
IX.2.1 Ross, D. T. 3.4 Ross, D. T.
2.2 Logcher, R. 3.5 Walker, D.
2.5 Cheatham, T. E., Jr. 3.6 Walker, D.

In addition to the above, Patricia Cundall and Peter Ingerman carefully

reviewed most of the manuscript and made valuable comments. I am
particularly grateful to Robert Tabory not only for his review of several
manuscript drafts but also for many constructive discussions on detailed
 ACKNOWLEDGMENTS Xi

and general points. Other people too numerous to cite individually, including
students in various courses who saw successive drafts, made constructive
suggestions On various sections.
Each sample program not taken from a printed source was coded by
a person with much experience in the language, although no guarantees
of either correctness or efficiency are made. I am grateful to the following
people for the coding of one or more of the sample programs: J. Andrada,
F. Bequaert, J. Bennett, C. Engelman, H. J. Gawlik, E.C. Haines, W.
Harrison, M. H. Halstead, K. Knowlton, T. Kurtz, C. Mooers, M. Perstein,
B. Raphael.
Most of the material used in figures and sample programs came from
publications of the Association for Computing Machinery, Inc., the Inter-
national Business Machines Corporation, and various Proceedings of the
AFIPS Joint Computer Conferences. I particularly appreciate the coopera-
tion of these organizations, as well as all others who permitted the use of
copyrighted material.
My appreciation to the IBM Corporation—specifically the Systems
Development Division and the Federal Systems Division—is unbounded,
both for providing me with the majority of the time I used for preparing
this book, and for supplying all the typing support, as well as the computer
time and telephone lines for the use of ATS (Administrative Terminal
System) which was used for typing and correcting most of the drafts. J am
specifically very grateful for the continued support and encouragement of
my managers, Nathaniel Rochester and Joel D. Aron.
Last but not least, a devoted crew of typists struggled with my manu-
script and having to learn an unfamiliar system of typing and correcting
(namely, ATS). They include Josephine Auterio, Margaret Mahoney, Carrie
Jo Clausen, and Dorothy Pearlman. The last two did a Herculean task
in helping prepare the initial reference lists. Finally, my secretaries Beatrice
Roffman and Carolyn Willet cheerfully coped not only with the book typing
but with a myriad of other chores as well.
 CONTENTS

GENERAL
INTRODUCTION

anh
1. Machine Language Programming

NN NO
UWWwW
2. Symbolic Assembly Language Programming
. Early Development of Better Tools
3.1. Specific needs to be met
3.2. Brief history of early efforts
. Definition of Programming Languages

CO
4.1. Definition problem
O00COO
4.2. Defining characteristics
1. Machine code knowledge is unnecessary
2. Potential for conversion to other computers
3. Instruction explosion
4. Problem-oriented notation
4.3. Basic terminology
1. Source program
. Object program
WN

. Compiler
. Interpreter
&

. Automatic coding
Mm

6. Automatic programming
4.4. Difference between programming language and application
package 13
. Advantages and Disadvantages of Higher Level Languages 14
5.1. Advantages 14
. Ease of learning 14
—

. Ease of coding and understanding 15

bh

. Ease of debugging 15
WY

. Ease of maintaining and documenting 16

RB

. Ease of conversion 16
Nan

. Reduce elapsed time for problem-solving 17

XiV
 CONTENTS XV

5.2. Disadvantages 17
1. Advantages do not always exist 17
2. Time required for compiling 17
3. Inefficient object code 18
4. Difficulties in debugging without learning machine language 18
5. Inability of the language to express all needed operations 18
5.3. Overall evaluation 19
. Classifications of Programming Languages and Proposed Definitions 19
6.1. Procedure-oriented language 19
6.2. Nonprocedural language 20
6.3. Problem-oriented language 21
6.4. Application-oriented language 21
6.5. Special purpose language 21
6.6. Problem-defining language 21
6.7. Problem-describing language 22
6.8. Problem-solving language 22
6.9. Reference language 22
6.10. Publication language 22
6.11. Hardware language 23
7. Factors in Choice of a Language 23
7.1. Suitability of language for problem area and projected users 23
7.2. Availability on desired computer 24
7.3. History and evaluation of previous use 25
7.4. Efficiency of language implementation 25
7.5. Compatibility and growth potential 25
7.6. Functional (= nontechnical characteristics) 26
7.7. Technical characteristics 26
References 26

FUNCTIONAL CHARACTERISTICS
OF PROGRAMMING LANGUAGES 30

1. Description of the Concept of Functional Characteristics 30

2. Properties of Languages 31
3. Purpose of Language 32
3.1. Application area 33
3.2. Type of language 34
3.3. Type of user 34
3.4. Physical environment 36
. Conversion and Compatibility 36
4.1. Types of compatibility 37
1. Machine independence 37
. Compiler independence 38
Ww NO

. Dialects and language L-like 39

nf

. Subsetting and extensions 40

. Relation to language definition 41
XVi CONTENTS

4.2. Ease of conversion

1. Based on compatibility
2. Ease of SIFTing to another language
3. Ease of translating to another language
5. Standardization
5.1. Purposes
5.2. Problems
1. Conceptual problems
2. Technical problems
3. Procedural problems
5.3. Method of establishing standards
5.4. Overall status
. Types and Methods of Language Definition
6.1. Administrative
1. Who designed the language?
2. What were the objectives of the language?
3. Who implemented the language?
4. Who maintains the language?
6.2. Technical
1. Syntax, semantics, and pragmatics
2. Formalized notation
6.3. Types of documentation
. Evaluation Based on Use
7.1. Availability on differing computers
7.2. Evaluation of language versus evaluation of compiler
7.3. Usage relative to objectives
7.4. Advantages
7.5. Disadvantages
7.6. Mistakes to be avoided in the future
References

TECHNICAL CHARACTERISTICS
OF PROGRAMMING LANGUAGES 65

1. Description of Concept of Technical Features 65

1.1. Introduction 65
1.2. Major parts of language 66
.
Data and its description 66
—

.
Operators 66
kh wWN

67
NO

.
Commands
.
Declarations 67
.
Compiler directives 68
.
Delimiters 68
7. Program structure 68
2. Form of Language 68
2.1. Character set 69
2.2. Types of basic elements (= tokens) 70
1. System-defined 70
2. User-defined and restrictions 71
 CONTENTS

2.3. Identifier definition 72

1. Types of identifiers 72
2. Formation rules 72
3. Use of reserved words 73
4. Data names for aggregates (subscripts, qualification) 74
2.4. Definition and usage of other basic elements 77
. Operators 77
. Delimiters
Wh 77
. Use and meaning of punctuation 78
. Significance of blanks 79
Nah

. Use of noise words 79

. Literals 80
2.5. Type of input form used 80
1. Physical input form 81
2. Conceptual form 82

3. Structure of Program 82
3.1. Types of subunits 83
. Nonexecutable: declarations and compiler directives 83
—

. Smallest executable unit 83

WN

. Sets of smallest executable units 84

. Loops 85
h

. Functions, subroutines and procedures 85

A

. Comments 86
HN

. Interaction with the operating system and environment 87

On

. Inclusion of other languages 87

. Complete program (including sequencing rules) 88
Oo

3.2. Characteristics of subunits 88

1. Methods of delimiting 89
2. Recursive 89
3. Parameter passage and differing types 90
4. Embedding 92

4. Data Types and Units and Computations with Them 92

4.1. Types of data variables and constants 93
. Arithmetic 93
. Logical (= Boolean) 93
93
OANNANNPWN

. Character
. Complex 93
. Formal (= algebraic) 94
String 94
. List of pointer 94
. Hierarchical 94
. Others 95
10. Combinations of variable and constant types 95
4.2. Accessible data units 95
1. Hardware data units 95
2. Language data units 97
4.3. Types of arithmetic 97
1. Integer, fixed point, mixed number 98
2. Floating point 98
3. Rational 98
XVili CONTENTS

. Complex numbers 99
. Double or multiple precision

CONN
99
. Logical 99
. Other 100
. Higher level data units 100
4.4. Rules on creation and evaluation of arithmetic and logical
expressions 100
1. Intermingling rules 100
2. Conversion rules 101
3. Precision and computation rules for various modes 102
4. Precedence and sequencing rules 102
4.5. Scope of data 103
. Executable Statement Types 104
5.1. Assignment 104
1. Methods of specifying computation 105
2. Conversion rules for results 105
5.2. Alphanumeric data handling 106
1. Editing statements 106
2. Conversion statements 106
3. Sorting statements 106
5.3. Sequence control and decision making 107
1. Control transfer statements 107
2. Conditional statements 108
3. Loop control statements 109
4. Error condition statements 110
5.4. Symbolic data handling 111
1. Algebraic expression manipulation statements 111
2. List-handling statements 111
3. String-handling statements 112
4. Pattern-handling statements 112
5.5. Interaction with operating system and/or equipment 112
1. Input/output statements 113
2. Library reference statements 113
3. Debugging statements 114
4. Storage and segmentation allocation statements 114
5. Operating system and machine feature statements 115
5.6. Others 115
. Declarations and Nonexecutable Statements 115
6.1. Data description 116
6.2. File description 117
6.3. Format description 118
6.4. Storage allocation 118
6.5. Environment or operating system descriptions 119
6.6. Procedure, subroutine, function declarations 119
6.7. Compiler directives 119
6.8. Others 120
. Structure of Language and Compiler Interaction 120
7.1. Self-modification of programs 120
7.2. Self-extension of the language 121
7.3. Ability to write the compiler for a language in that language 121
 CONTENTS XIX

7.4. Effect of language design on implementation efficiency 122

1. Compile time versus object time efficiency 122
2. Generality versus restrictions 123
3. Specific features with significant effect 124
4. Storage allocation requirements 124
5. Possibility for providing choice of tradeoffs 124
7.5. Debugging aids and error checking 125
8. Other Features Not Included 125
References 126

iV LANGUAGES FOR NUMERICAL

SCIENTIFIC PROBLEMS 128

1. Scope of Chapter 128

2. Languages of Historical Interest Only 128
2.1. Very early systems 129
1. SHORT CODE 129
2. Speedcoding 130
3. Laning and Zierler system 131
4. A-2 and A-3 132
5. BACAIC 133
6. PRINT 134
2.2. More widely used systems 134
1. MATH-MATIC (AT-3) 135
2. UNICODE 137
3. IT, FORTRANSIT, and GAT 139
4. ALGOL 58 (cross-reference only) 143
3. FORTRAN 143
3.1. History of FORTRAN 143
3.2. Functional characteristics of ASA (USASI) FORTRAN and
Basic FORTRAN 150
3.3. Technical characteristics of ASA (USASI) Basic FORTRAN 157
3.4. Technical characteristics of ASA (USASI) FORTRAN 165
3.5. Significant contribution to technology 169
3.6. Significant extensions of FORTRAN 170
1. Proposal Writing language 170
2. FORMAC (cross-reference only) 171
3. QUIKTRAN (cross-reference only) 172
4. GRAF (cross-reference only) 172
5. DSL/90 (cross-reference only) 172
4, ALGOL 172
4.1. History of ALGOL 172
1. ALGOL 58 172
2. ALGOL 60 175
3. Revised ALGOL 60 177
4. ALGOL 6X 178
4.2. Functional characteristics of Revised ALGOL 60—Proposed ISO
Standard 178
4.3. Technical characteristics of Revised ALGOL 60—Proposed ISO
Standard 182
XX CONTENTS

4.4. Significant contribution to technology 192

4.5. Extensions of ALGOL 194
. Formula ALGOL (cross-reference only) 194

=
. LISP 2 (cross-reference only) 195

Rh WN
. AED (cross-reference only) 195

CON
. SFD-ALGOL (cross-reference only) 195
NUM. SIMULA (cross-reference only) 195
. DIAMAG 195
GPL 195
. Extended ALGOL 196
. Languages Motivated by ALGOL 58 196
5.1. NELIAC 197
5.2. MAD 205
5.3. JOVIAL (cross-reference only) 215
. On-Line Systems 215
6.1. Introductory remarks 215
6.2. JOSS 217
6.3. QUIKTRAN 226
6.4. BASIC 229
6.5. CPS 232
6.6. MAP 240
6.7. Lincoln Reckoner 245
6.8. APL/360 and PAT 247
6.9. Culler-Fried System 253
6.10. DIALOG 255
6.11. AMTRAN 258
. Languages with Fairly Natural Mathematical Notation 264
7.1. Introductory remarks 264
7.2. COLASL 265
7.3. MADCAP 271
7.4. MIRFAC 281
7.5. Klerer-May system 284
. Miscellaneous 294
8.1. CORC 294
8.2. OMNITAB 296
8.3. More nonprocedural languages 299
References 300

LANGUAGES FOR BUSINESS

DATA PROCESSING PROBLEMS 314

1. Scope of Chapter 314

2. Languages of Primarily Historical Interest 316
2.1. FLOW-MATIC (and B-@) 316
2.2. AIMACO 324
2.3. Commercial Translator 324
2.4. FACT 327
2.5. GECOM 328
 CONTENTS XxXi

3. COBOL 330
3.1. History of COBOL 330
3.2. Functional characteristics of COBOL 334
3.3. Technical characteristics of COBOL 345
3.4. Significant contribution to technology 375
4. File Handling 376
4.1. Extensions of COBOL 376
1. IDS 376
4.2. General (cross-reference only) 376
References 377

VI STRING AND
PROCESSING
LIST
LANGUAGES 382

1. Scope of Chapter 382

2. Languages of Historical Interest Only 388
3. IPL-V : 388
3.1. History of IPL-V 388
3.2. Functional characteristics of IPL-V 389
3.3. Technical characteristics of IPL-V 393
3.4. Significant contribution to technology 400
4. L6 400
5. LISP 1.5 405
5.1. History of LISP 1.5 405
5.2. Functional characteristics of LISP 1.5 407
5.3. Technical characteristics of LISP 1.5 410
5.4. Significant contribution to technology 416
6. COMIT 416
6.1. History of COMIT 416
6.2. Functional characteristics of COMIT — 417
6.3. Technical characteristics of COMIT 421
6.4. Significant contribution to technology 435
7. SNOBOL 436
7.1. History of SNOBOL 436
7.2. Functional characteristics of SNOBOL 436
7.3. Technical characteristics of SNOBOL 438
7.4. Significant contribution to technology 448
8. TRAC 448
9. Languages Not Widely Used 454
9.1. AMBIT 454
9.2. TREET 457
9.3. Others 461
1. CLP 461
2. CORAL 462
3. SPRINT 462
4. LOLITA 464
References 464
XXil CONTENTS

Vil FORMAL ALGEBRAIC

MANIPULATION LANGUAGES 471

. Scope of Chapter 471

. Languages of Historical Interest Only 473
2.1. ALGY 473
. FORMAC 474
3.1. History of FORMAC 474
3.2. Functional characteristics of FORMAC 475
3.3. Technical characteristics of FORMAC 476
3.4. Significant contribution to technology 490
. MATHLAB 491
4.1. History of MATHLAB 491
4.2. Functional characteristics ofp MATHLAB 491
4.3. Technical characteristics of MATHLAB 493
4.4. Significant contribution to technology 501
. ALTRAN 502
6. FLAP 506
7. Systems Requiring Special Equipment 510
7.1. Magic Paper 510
7.2. Symbolic Mathematical Laboratory 514
References 520

Vill MULTIPURPOSE
LANGUAGES 523

1. Scope of Chapter 523

. Languages of Historical Interest Only 524
3. JOVIAL 524
3.1. History of JOVIAL 524
3.2. Functional characteristics of JOVIAL 526
3.3. Technical characteristics of JOVIAL 530
3.4. Significant contribution to technology 539
. PL/I 540
4.1. History of PL/I 540
4.2. Functional characteristics of PL/I 542
4.3. Technical characteristics of PL/I 548
4.4. Significant contribution to technology 582
5. Formula ALGOL 583
6. LISP 2 589
References 598
 CONTENTS

[ SPECIALIZED
LANGUAGES 603

1. Scope of Chapter 603

2. Languages for Special Application Areas 605
2.1. Machine tool control 605
1. APT 605
2. Others 606
2.2. Civil engineering 610
1. COGO 611
2. STRESS 612
3. ICES 615
2.3. Lo gical design 620
1. APL (Iverson) 620
. LOTIS 621
NY

LDT 621
WwW

622
An

. Langage for simulating digital systems

&

. Computer Compiler 623

. Computer Design Language 623
. SFD-ALGOL 623
2.4. Di gital simulation of block diagrams 627
1 . Introduction 625
2. DYANA 628
3. DYSAC 629
4. DAS 631
5 . DSL/90 632
2.5. Co mpiler writing 633
. Introduction 633
oN DAWN =

CLIP 635
TMG 636
COGENT 638
META 5 638
TRANDIR 640
FSL 641
. AED (cross-reference only) 641
2.6. Mi scellaneous 642
. Matrix computations: Matrix Compiler 642
mPwWN=

. Cryptanalysis: OCAL 642

. Movie creation: Animated Movie Language and BUGSYS 644
. Social science research: DATA-TEXT 646
. Equipment checkout: STROBES, DIMATE 647
an

3. Speciali zed Languages across Application Areas 650

3.1. Discrete simulation 650
1. Introduction 650
. DYNAMO 651
wWN

GPSS 653
. SIMSCRIPT 655
Mh

. SOL 656
XxivV CONTENTS

6. MILITRAN 657
7. SIMULA 657
8. OPS 660
3.2. Query 662
1. Introduction 662
2. COLINGO and C-10 664
3. 473L Query 665
4. ADAM 667
5. BASEBALL 668
6. DEACON 668
7. Protosynthex 669
8. AESOP 670
3.3. Graphic and on-line display languages 674
1. GRAF 674
2. PENCIL 677
3. Graphic 677
4. DOCUS 678
5. AESOP (cross-reference only) 678
3.4. Computer-aided design 678
1. General 678
2. AED 680
3.5. Text editing and processing 684
3.6. Control languages for on-line and operating systems 687
References 693

xX SIGNIFICANT
UNIMPLEMENTED CONCEPTS 707

1. Scope of Chapter 707

2. UNCOL 708
3. Information Algebra 709
4. APL (Iverson) 712
5. English 715
6. Hardware Implementation of Programming Languages 717
References 719

Xi FUTURE LONG-RANGE
DEVELOPMENTS 722

1. Introduction 722
2. Theory-Oriented Category 723
2.1. Language definition, translation, and creation 723
2.2. Next major conceptual step 725
2.3. Nonprocedural languages 726
2.4. Problem-describing languages 726
2.5. Use of mathematical concepts 727
 CONTENTS XXV

3. User-Oriented category 727

3.1. User-defined languages 727
3.2. Use of natural language 729
3.3. Communication with hardware and software 732
3.4. Languages for new application areas 733
3.5. Languages for writing software 734
4. Interrelationships among Some of These Concepts 734
5. Conclusions and Summary 736
References 736

BIBLIOGRAPHY ARRANGEMENTS
AND AUTHOR LIST 738

LANGUAGE
SUMMARY 753

NAME AND SYSTEMS INDEX 765

SUBJECT INDEX 776

 LIST OF FIGURES
AND SAMPLE PROGRAMS

CHAPTER |

I-1 List of automatic programming systems (1959) 6-7

CHAPTER Il

There are no figures in Chapter II.

CHAPTER lil

III-1 Example of tree and data layout 76

CHAPTER IV

IV-1 List of BACAIC facilities 133

IV-2 MATH-MATIC commands 136
IV-3 List of UNICODE instructions 138
IV-4 Table of FORTRAN I statements for the IBM 704 145
IV-5 Summary of FORTRAN II statements 146
IV-6 List of FORTRAN statements implemented on IBM computers,
circa 1961 149
IV-7 List of intrinsic functions in Basic FORTRAN 162
IV-8 List of basic external functions in Basic FORTRAN 162
IV-9 Rules for assignment of e to vin FORTRAN 167

XxVvi
 LIST OF FIGURES AND SAMPLE PROGRAMS XxVvii

IV-10 List of statements in Proposal Writing Language 171

IV-11 Program in Proposal Writing Language 172
IV-12 Format for changing operators and modes in MAD 215
IV-13 Short summary of JOSS I 220
IV-14 JOSS II commands and functions 224-225
IV-15 Summary of BASIC statements : 231
IV-16 Summary of CPS facilities (one-page summary with notes). 234-235
IV-17 Example of the use of Least Square command in MAP 243
IV-18 Standard scalar operators in APL 249
IV-19 Summary of DIALOG facilities 257
IV-20 List of AMTRAN operations 262-263
IV-21 The COLASL alphabet 266
IV-22 Example of COLASL program including heavy commentary 268
IV-23 Expressions in COLASL 270
IV-24 Two forms of the same MIRFAC program 283
IV-25a Page 1 of the Klerer and May Reference Manual 286
I1V-25b Page 2 of the Klerer and May Reference Manual 287
IV-25c “Addendum” to the Klerer and May Reference Manual 288
IV-26 Example of expressions with ambiguities in Klerer-May system 292
IV-27 Interpretation of ambiguities in expressions shown in Figure IV-26 293

CHAPTER V

V-1 Eight different ways to add three numbers . 315

V-2 FLOW-MATIC verb formats 317-322
V-3 FLOW-MATIC program 323
V-4 List of Commercial Translator commands 326
V-5 List of FACT verbs 328
V-6 Schematic diagram showing the structure of pUSASI COBOL 342
V-7 Formats of COBOL verbs 353-359
V-8 Flowchart represented by a single COBOL sentence 361
V-9 Data description (=Record description) skeleton in COBOL 366-367
V-10 Report description (RD) skeleton in COBOL 367
V-11 Report group skeleton in COBOL 368-369
V-12 File description (FD) skeleton in COBOL 370
V-13 Sort file description (SD) skeleton in COBOL 370
V-14 OBJECT—COMPUTER format in COBOL 371
V-15 SPECIAL—NAMES format in COBOL 372
V-16 FILE—CONTROL format in COBOL 373
V-17 [—O—CONTROL format in COBOL 374

CHAPTER VI

VI-1 Illustration of list 383

VI-2 Inserting element in a list 384
VI-3 List structure, i.e., list containing list as element 385
XXVili LIST OF FIGURES AND SAMPLE PROGRAMS

VI-4 Fairly complete list of basic processes in first Information Processing

Language 390-391
VI-5 List of IPL-V basic processes 398
VI-6 Summary of all L® instructions 403-404
VI-7 Syntactic definition of LISP S- and M-expressions 409
VI-8 Example of CORAL statements 463

CHAPTER VII

VII-1 7090/94 FORMAC verb formats with examples 481-484

VII-2 Example of use of MATHLAB on the AN/FSQ-32 492
VII-3 Typical executive control characters in first Magic Paper S11
VII-4 Format control characters in first Magic Paper 512

CHAPTER VIII

VIII-1 JOVIAL usage and compilers 526-527

VIII-2 Executable PL/I statement formats 558-561
VIII-3 List of On-conditions in PL/I 565
VITI-4 List of Built-in functions in PL/I 568

CHAPTER IX

IX-1 Example of APT program for specific part to be cut 607

IX-2 APT vocabulary list 608-610
IX-3 Small COGO program for figure shown 611
IX-4 List of 7090 COGO command names 612
IX-5 Specifications for a particular COGO command 613
IX-6 STRESS program for analysis of space truss shown in the diagram 614-615
IX-7 Partial listing of STRESS commands 616
IX-8 Some of the CDL commands in ICES 619
IX-9 Portion of LOTIS program defining a hypothetical computer 621
IX-10 Relationship between information flow on a block diagram and
LDT input 622
IX-11 System layout and data paths in a sample computer, and part of
computer compiler program 624
IX-12 Computer Design Language program to define multiplication 625
IX-13 SFD-ALGOL program to describe action of pushdown stack shown
in diagram 626-627
IX-14 Mechanical system and corresponding DYANA program 628
IX-15 DYSAC components 629
IX-16 DYSAC statements for input data sections 629
 LIST OF FIGURES AND SAMPLE PROGRAMS XXix

IX-17 Problem, diagram, and corresponding DYSAC program 630

IX-18 Mathematical problem, block diagram, and corresponding DAS
program 631
IX-19 Examples of some DSL/90 functional blocks, switching functions,
and function generators 632
TX-20 Differential equation, diagram, and corresponding DSL/90 program 633
IX-21 Example of part of TMG program 637
IX-22 Example of part of COGENT program 639
IX-23 META program to convert JOVIAL constants to PL/I constants 639
IX-24 Example of part of TRANDIR program 640
IX-25 Example of part of FSL program 642
TX-26 OCAL program for solving cryptanalysis problem 643
IX-27 Part of movie animation program 644
TX-28 Example of part of BUGSYS program 645
IX-29 Example of DATA-TEXT input data 646
IX-30 Example of defining new variables based on conditions 647
TX-31 DATA-TEXT program 647
IX-32 Example of STROBES program 648
IX-33 Program for testing equipment 649
IX-34 DYNAMO example of model of retail store 652
IX-35 Some of the GPSS block types and corresponding operations 653
IX-36 Example of harbor arrival problem and GPSS solution 654
IX-37 Names of SIMSCRIPT commands and phrases 655
IX-38 SIMSCRIPT program for order in machine shop 656
TX-39 Complete SOL program for the multiple console on-line
communication system shown in the diagram 657-658
IX-40 List of MILITRAN statements 659
IX-41 MILITRAN program for finite length queue 660
IX-42 Skeleton SIMULA description of job shop system 661
IX-43 OPS-3 program for multi-server queuing model 662
IX-44 List of basic commands in COLINGO 665
IX-45 Portion of a C-10 program 666
IX-46 Punctuation characters and key words in 473L Query language 667
TX-47 Examples of control statements, questions, and answers from
Protosynthex II 670
IX-48 Communication tree in AESOP 671
IX-49 AESOP commands used on typewriter 672-673
IX-50 Small GRAF program 674
IX-51 List of PENCIL primitives 675
IX-52 PENCIL program for diagram shown 676
IX-53 Example in Graphic language 677
IX-54 GOL, DOL, and PIL operations in DOCUS 679
TX-55 General structure of AED-1 compiler 683
TX-56 Examples of editing statements in ES-1 684
IX-57 List of DATATEXT commands 685
IX-58 Sample of DATATEXT usage 686
IX-59 Names of commands in CTSS context editor 686
IX-60 Sample of actual CTSS session 690
IX-61 Uses of Job Control Language: (a) catalogued procedure,
(b) changes to catalogued procedure, and (c) result of changing
catalogued procedure 692
XXX LIST OF FIGURES AND SAMPLE PROGRAMS

CHAPTER X

X-1 Use of UNCOL to reduce the number of compilers in going from M

languages to N machines 708
X-2 System information for payroll problem in Information Algebra 710
X-3 Payroll program written in Information Algebra 711
X-4 Partial list of APL notation 713
X-5 m-way merge sort written in APL 714

CHAPTER Xi

There are no figures in Chapter XI

SAMPLE PROGRAMS

ALGOL 60 178
ALTRAN 502
AMBIT 455
AMTRAN 259
APL/360 248
BASIC 230
COBOL 336-337
COLASL (Fig. I[V-22) 268
COMIT II 418
CPS 233
FLAP 507
FORMAC (PL/I-FORMAC) 477
Formula ALGOL 583
FORTRAN 151
IPL-V 392
JOSS II 218
JOVIAL 528
Klerer-May System 285
L6 401
LISP 1.5 407
LISP 2 591
MAD 207
MADCAP 272
MAP (Fig. IV-17) 243
MATHLAB 68 499
MIRFAC 282
NELIAC 199
OMNITAB 297
PL/I 544-545
PL/I-FORMAC 477
Proposal Writing Language (Fig. IV-11) 172
QUIKTRAN 227
SNOBOL3 437
Symbolic Mathematical Laboratory 315
TRAC 449
TREET 458
I GENERAL INTRODUCTION

Programming languages have become the major means of communication

between the person with a problem and the digital computer used to help
solve it. In fact, it would be impractical to solve most problems if the com-
puter had to be instructed in machine language. This has come about
because most machines tend to operate in binary, and this is clearly an
unsatisfactory method of communication for humans; hence the primary
interface between the computer user and the computer itself has become
the programming language used. In this context, language has the broadest
possible meaning and includes not only the description of the problem to be
solved but also the needed instructions to the operator or operating system.
It should be noted that throughout this book the terms programming language
and higher level language will be used synonymously, with the former being
my preferred term. In particular, as noted later in this chapter, I do not
consider an assembly language (even a very sophisticated one) to be a pro-
gramming language. This view differs from that held by some people who
maintain that anything in which programs are written is a programming
language.
The main function of this chapter is to motivate the need for program-
ming languages, and to define and characterize them. One section discusses
the advantages and disadvantages of programming languages; however,
in spite of the disadvantages, the net evaluation is that programming
languages are here to stay. Finally, there is a lengthy list of types of program-
ming languages, together with some proposed definitions. This provides
one way of classifying programming languages. Many of these types are
overlapping, i.e., a language can fall into several categories simultaneously.

1
2 GENERAL INTRODUCTION

1.1. MACHINE LANGUAGE PROGRAMMING

Every computer has a specific set of instructions which it can execute once
the instruction is placed into the appropriate part of the machine. The actual
set of symbols which the hardware can interpret for execution is the direct
machine language. Since most computers are designed so that their storage
locations and registers contain binary characters (i.e., bits), the most com-
mon machine language 1s actually binary. Thus the sequence
011011 O00000 000000 000000 000001 000000
might mean place the contents of storage location 64 in the accumulator. To
write one instruction, let alone many of them, in this form is clearly imprac-
tical, and this was recognized very rapidly in the early days of computers.
A partial step to alleviate this problem involved the use of mnemonic codes
to represent the instruction, while the rest of the information was left in
binary. Thus, the sequence
CLA 000000 000000 000000 000001 000000
might have the same meaning as the binary string given earlier. While this
was a partial improvement, it was still far from easy to write even one in-
struction correctly. The next step forward came when the numbers (repre-
senting the storage locations or registers in the computer) were allowed to be
written in decimal form. Thus the sequence CLA 0 0 0 O 64 might have
the same meaning as the earlier strings.
The border line between machine language and symbolic assembly
language is not well defined. Some people would choose to refer to the
format given just above as assembly language. At the present time, it is not
worth debating the merits of either view.

1.2. SYMBOLIC ASSEMBLY LANGUAGE PROGRAMMING

The biggest disadvantage to machine language as described in the previous

section, even in the form CLA O O O O 64, was that the insertion or elimina-
tion of a single instruction (or piece of data) caused many—if not all—of
the addresses in other instructions to be incorrect. This situation could be
improved somewhat by a scheme of relative addressing or regional addressing,
in which the program was divided into sections, each of which started in
a fixed location. Addresses within each section were given relative to the
starting location. Thus CLA 0 O O O R64 might refer to the 64th location
within the R section of code.
While this was an obvious improvement, it was the development of
completely symbolic notation and addressing for both instructions and
data that freed the programmer from worrying about changing all occur-
rences of R64 to R63. A preliminary step in this direction was the work
 I.3. EARLY DEVELOPMENT OF BETTER TOOLS 3

done at MIT on Whirlwind in 1952, and by Rochester [RT53] which used

numeric symbolic addresses. These numbers had no mnemonic or numerical
significance but were merely used as symbols for addresses. The culmination
of this early work was the use of mnemonic symbols for both instructions
and data, thus permitting the user to write CLA TEMP where TEMP stands
for the location in memory of the value of a variable, e.g., temperature.
A whole generation of programmers thus learned to use the IBM 704 by
writing programs in SAP (Symbolic Assembly Program) [XY 56].

1.3. EARLY DEVELOPMENT OF BETTER TOOLS

1.3.1. Speciric NEEDS TO BE MET

The histories of automatic coding, programming languages, and the

development of better tools to assist programmers are almost—but not
completely—synonymous. As noted in the ensuing discussion, virtually all
the significant problems arising in the early days were, or have been, solved
by the increasing development of higher level languages (which are defined
and discussed in Section I.4). It was not until the existence of second genera-
tion computers (circa 1959) that the speed, cost, and difficulty of manually
changing jobs began to force the development of operating systems; this
latter is probably the one major area that is entirely distinct from program-
ming languages which has had, and is having, a major impact upon the
overall computing community. (Time-sharing is considered to be in the
broad category of operating systems.) One can go even further and say that
the development of operating systems was really to help the installation
managers rather than the individual programmers; the latter seldom see
a direct benefit from the operating system unless it greatly reduces their
turnaround time (which is not always true!). Time-sharing of course attempts
to bring to the programmer of third generation computers the advantages
of the on-line debugging which the user of the first computers usually had.
However, even this inherently nonlanguage development requires con-
sideration of the language with which the user will address the system.
The desirability of having a symbolic code forced the development
of symbolic assembly languages. However, that was not sufficient to meet
the growing demands of programmers. For one thing, programmers wanted
the ability to use other people’s code wherever it was appropriate. This
could not always be done because of differences in notation and lack of
an effective way to link the pieces together. One of the main motivations
for using other people’s code was that certain programs were being written
over and over again. For example, square root and trigonometric routines
were being written by the dozens. In some cases, this proliferation was
4 GENERAL INTRODUCTION

justifiable because one person was interested in saving space and therefore
wrote as short a subroutine as he could, while somebody else wanted to
save as much time as possible and therefore removed loops even at the
expense of using more storage locations. In another case, people had
differing requirements for precision, and this caused another whole set of
routines to be developed with varying degrees of precision. However,
eventually the individual effectiveness of a particular program became less
important and was subjugated to the overall effectiveness of a group of
programmers. Thus there developed the need for effective library facilities
and, in particular, library routines—many of them parameterized—that
could be invoked very easily by a programmer.
Another area where a need rapidly became apparent was in routines
which differed not in concept but only in specific cases or which had many
input parameters, not all of which were numbers. The best example of this
was the early sort routines, which used the same techniques but differed
in the coding because the key might be in the first word of the record or the
fifth or the ninth, and the key might be three characters long or eight, etc.
The early work of F. Holberton [HF54] in developing sort generators for
UNIVAC had a significant impact on this type of problem because she pro-
vided a set of routines which would partially write themselves once given
the necessary input parameters.
Programmers not only wanted the ability to use other people’s code,
but they wanted the capability of easily bringing together small sections
of a program. One of the earliest and most significant efforts along these
lines was the development of the subroutine library for the EDSAC as
represented and described by Wilkes, Wheeler, and Gill [WI51].
Finally, there was an increasing demand for being able to write short-
hands of various kinds. Once people had written sequences of code, they
were interested in finding a shorthand way to write the same or similar in-
formation, and calling the material from the library was not always appro-
priate. In addition, people wanted better and better notation, where they
implicitly defined “better” as “more natural”.
All these needs were attacked by different people in different ways.
In my opinion, Dr. Grace Hopper probably did as much as any other single
person to sell many of these concepts from an administrative and manage-
ment, as well as a technical, point of view. See, for example, Hopper [HP55].
One of the first meetings held to discuss the subject that was then called
automatic programming was sponsored by the Office of Naval Research in
May, 1954 and reported in [DN54]. At that time, a number of interesting
systems were described, some of which are covered in later sections.
Probably the most significant ideas that were mentioned at that early meeting
and that are not covered in this book are the concept of code generation
discussed by Holberton, the editing generator of Waite and Elmore, the
 1.3. EARLY DEVELOPMENT OF BETTER TOOLS 5

analytic differentiator of Kahrimanian, and the grandiloquent objective

(not yet achieved) of the universal code described by Gorn; all these are
described in [DN54].
The next significant meeting was the symposium on “Advanced Pro-
gramming Methods for Digital Computers” held under the joint sponsorship
of the Navy Mathematical Computing Advisory Panel and the Office of
Naval Research in June, 1956 [DN56]. About the only paper presented at
that meeting which had any significance as far as programming languages
are concerned was the paper by Thompson [TM56] which discussed
OMNICODE. This is sufficiently similar in principle to the PRINT system
discussed in Chapter IV so that it will not be mentioned here (although the
reader should realize that the details are significantly different).
The next meeting of major importance was the symposium on
“Automatic Coding” held in January, 1957 at the Franklin Institute in
Philadelphia [FK57]. The major items covered there were PRINT I, B-0,
[T, and the Matrix Compiler; they are described elsewhere in the book.

1.3.2. Brief HISTORY OF EARLY EFFORTS

A number of systems were developed in the early years (defined to be

prior to 1957) which made significant contributions to the development of
higher level Janguages. Chief among these, in approximate chronological
order, are Short Code (UNIVAC), Speedcoding (IBM 701), Laning and
Zierler system (Whirlwind), A-2 and A-3 (UNIVAC), BACAIC (701), and
PRINT (705). These are all described in Chapter IV, and the references are
given there. The early work of Rutishauser in Switzerland is also mentioned
there, even though this book is only attempting to deal with American
developments.
These systems generally provided some type of mathematically oriented
operation (e.g., addition, computation of sines) and control functions,
together with either fixed or variable operands. In each case, the information
written by the programmer in one line or statement was either interpreted
or was directly equivalent to several lines of actual machine code. However,
most of these systems had a fixed format and, in particular, did not permit
the writing of mathematical expressions in anything resembling natural
notation. Only the Laning and Zierler system and BACAIC had this latter
facility.
Figure I-1 is a list of the automatic programming systems of 1959. Note
that many of them would not be considered programming languages by the
criteria established later in this chapter.
No attempt has been made in this book to include those systems which
contributed strongly to the development of either better symbolic assembly
Computer In ACM Library Do Not Have

704 AFAC ADES

CAGE FORC
CORBIE
FORTRAN
KOMPILER 3
MYSTIC
NYAP
PACT IA
REG-SYMBOLIC
SAP

701 BACAIC BAP

DUAL-607 DOUGLAS
FLOP GEPURS
JCS-13 LT-2
KOMPILER 2 QUEASY
PACT I SO 2
QUICK SPEEDEX
SEESAW
SHACO
SPEEDCODING 3

705 ACOM FAIR

AUTOCODER
ELI
PRINT I
SOHIO
SYMBOLIC ASSEMBLY

702 AUTOCODER
ASSEMBLY
SCRIPT

650 ADES II BALITAC

APT ESCAPE
BACAIC FLAIR
BELL KISS
BELL L2, L3 MITILAC
CASE SOAP II OMNICODE
DRUCO I SPEEDCODING
EASE II SPUR
ELI
FAST
FOR TRANSIT
FORTRUNCIBLE
IT
IT 3
MYSTIC
RELATIVE
RUNCIBLE
SIR
SOAP I
SOAP I
650 GAT-2
RAMAC
NORC NORC COMPILER
7070 BASIC AUTOCODER

Figure I-1. List of automatic programming systems (1959).

Source: Comm. ACM, Vol. 2, No. 5 (May 1959), p. 16. By
permission of Association for Computing Machinery, Inc.

6
Computer In ACM Library Do Not Have

1103, 1103A APT TRANS-USE

BOEING
CHIP
FAP
FLIP-SPUR
MISHAP
MYSTIC
RAWOOP-SNAP
UNICODE
USE

UNIVAC I, Il AO, Al, A2 MJS

ARITHMATIC (A-3) RELCODE
BIOR
FLOWMATIC (B-0)
GP
GPX (IL ONLY)
MATHMATIC (AT-3)
MATRIX MATH
NYU, OMNIFAX
SHORTCODE
UNISAP
X-1

DATATRON APX Ill ANCP

201 DUMBO BELL
204 PURDUE COMPILER DATACODE I
205 SAC DOW COMPILER
SIMPLE SHELL
UGLIAC SPAR
STAR 0

DAISY 201 POGO

FLIP
INTERCOM 101
INTERCOM 1000

WHIRLWIND COMPREHENSIVE ALGEBRAIC

SUMMER SESSION

FERUT TRANSCODE

JOHNNIAC EASY FOX

ILLIAC ILLIAC

LGP-30 ERFPI
JAZ
SPEED

MIDAC EASIAC
MAGIC

LARC K5
SAIL

FERRANTI AUTOCODING
MERCURY MAC (NORWAY)

FERRANTI AUTOCODE
PEGASUS
$ GENERAL INTRODUCTION

programs or file-handling techniques. In particular, such systems as PACT

(see papers by Baker [BK56] and others in the same journal, and Steel
[ST57]), BIOR [RR55a], and SURGE [NMO00] are deliberately excluded.

1.4. DEFINITION OF PROGRAMMING LANGUAGES

1.4.1. DEFINITION PROBLEM

The ASA (now USASJ) standard Vocabulary for Information Processing

[AA66b] defines a programming language on page 23 as “A language used
to prepare computer programs”. The IFIP-ICC Glossary [IF66] defines
on page 79 a language as “A general term for a defined set of symbols and
rules or conventions governing the manner and sequence in which the
symbols may be combined into a meaningful communication,” with a note
that “An unambiguous language, intended for expressing programs, is
called a PROGRAMMING LANGUAGE.” This glossary also states that
the term pseudocode has been used in England to denote a programming
language which is not a computer language, but this usage is deprecated by
the IFIP-ICC Glossary.
While these definitions may be true from an overall abstract point of
view, they do not—in my opinion—reflect actual current usage. Furthermore,
neither glossary includes the term higher level language. It is intuitively clear
that there is a significant difference between symbolic assembly languages
and the languages which are discussed in this book. However, not only is
there a lack of a specific term for the items in this book but, furthermore,
a symbolic assembly program with a very powerful macro facility can
certainly be made to look very much like what is frequently called a pro-
gramming or higher level language. (See for example the XPOP system of
Halpern [HL64].) For the purposes of this book, and admittedly contrary
to the opinion of many, these two terms will be used interchangeably. One of
the prime differences between assembly and higher level languages is that
to date the latter do not have the capability of modifying themselves at
execution time. In one instance—namely, LISP 1.5 (see Section VI.5)—an
equivalent result can be achieved because the program is represented inter-
nally in the same form and can be acted on as data. However, no language
in this book has the facility for changing, e.g., a GO TO to an IF. The lack of
this capability has not proved much of a handicap and is cited merely because
it is one of the clear-cut distinctions between an assembly language and
a programming language.
Because there is no satisfactory definition, it seems more effective to
try to define a programming language through its characteristics rather
 1.4. DEFINITION OF PROGRAMMING LANGUAGES 9

than by a specific definition. Thus, in my opinion, a programming language

is a set of characters with rules for combining them which have the following
characteristics.

1.4.2. DEFINING CHARACTERISTICS

1. Machine Code Knowledge Is Unnecessary

A programming language requires no knowledge of the machine code

by the user. In other words, the user need only learn the particular program-
ming language and can use this quite independently of his (perhaps non-
existent) knowledge of any particular machine code. Thus he need not learn
about what registers are available on the computer, nor the specific hardware
instructions that are required to activate the computational and logical
processes. In many cases he can also remain ignorant of the internal
representation of numbers; thus he can avoid worrying about whether
numbers are represented internally as binary, hexadecimal, decimal, etc.
However, this should not be interpreted to mean that the user can completely
ignore the actual computer if he wants to obtain maximum (or even reason-
able) effectiveness from it. For example, he may wish to take advantage of
certain machine facilities (e.g., mass storage devices) which are known to
him and which can provide more efficient programs; even more specifically
he obviously cannot use input/output equipment which does not exist on
a particular computer configuration. He might conceivably wish to concern
himself with whether numbers were represented in binary or decimal fashion
because this could affect certain points of computational precision that
might be of concern to him.
In summary, the first characteristic of a programming language is that
the user can write a program without knowing much—if anything—about
the physical characteristics of the machine on which the program is to be
run. This same comment does not apply if he wishes to obtain maximum
efficiency.
A further constraint is that the user should be unable to affect directly
the machine registers and memory. This rules out such ideas as Wirth’s
PL360 [WT68] from being considered a higher level language (nor does he
claim it is).

2. Potential for Conversion to Other Computers

Since the first characteristic states that the user need not know the
details of the particular computer on which his program is to be run, it
follows that a programming language must have some significant amount
10. GENERAL INTRODUCTION

of machine independence. The whole question of compatibility and con-

version is discussed at some length in Section II.4. It is sufficient to say here
that a major characteristic of a programming language is that there must be
a reasonable potential of having a source program written in that language
run on two computers with different machine codes without rewriting the
source program. Again, we are dealing with both absolute and relative
quantities. In the absolute sense, the program may be able to be moved
from one machine to another with no rewriting. In most programming
languages, some—but often very little—rewriting of the source program is
necessary.

3. Instruction Explosion

When a source program [see the definition in Section I[.4.3(1)] written

in a programming language is translated to the actual machine code, there
is normally more than one machine instruction created for each statement
in the programming language. For example, a statement in a programming
language might be something of the form A = B + C * D or MOVE A TO B.
Normally each of these phrases requires more than one machine instruction
to execute it, and this is the major difference between a symbolic assembly
language and a higher level language. In fact, many compilers actually
translate the source program to a symbolic assembly language.
To be considered a programming language, there should be no need
for the user to write any sequence of machine code. This provision causes
the exclusion of macro assemblers from the category of programming
languages (by assuming that some user must write the machine instructions
for the macro).

4. Problem-Oriented Notation

A programming language must have a notation which is somewhat

closer to the specific problem being solved than is normal machine code.
It usually permits a relatively free format. Thus, for example, the first illustra-
tion given in Section 1.4.2(3) might be translated into a sequence of instruc-
tions such as

CLA C
MPY D
ADD B
STO A

which is clearly less understandable than the programming language form

A=B+C~xD. Again, this notational question is a relative one because
what is considered problem-oriented and relatively free in one case might
 I.4. DEFINITION OF PROGRAMMING LANGUAGES II

be considered quite rigid and unnatural in another. However, as in each of

the preceding discussions, the comparison that is being made is with a sym-
bolic assembly language and not between two types of higher level language.
To fall within the spirit of this concept of problem-oriented notation,
a programming language must not require that each statement type or
executable unit be specifically identified or flagged in a standard terminology
and location. Furthermore, a fixed format, or the existence of a form to be
filled out, is not considered problem-oriented notation. The first of these
requirements rules out the Autocoder series, e.g., [[B6la], from being
considered programming languages. The second rule excludes the class of
report generators, e.g., [I[B65d], and decision tables, e.g., [EP66], [K V60],
[UC61]. The exclusion of report generators, and to a lesser extent the exclu-
sion of the Autocoder languages, runs contrary to much of the popular
nomenclature. Very specifically, Report Program Generators (RPG) are
commonly referred to as programming languages. However, I believe my
classification is justified by the rigidness and lack of flexibility of the normal
RPG “programs” which consist primarily of filling in a preprinted form.
This in no way implies any failing or lack of importance of systems of this
type; it merely excludes them from the class of languages considered in this
book.

[.4.3. BAsic TERMINOLOGY

1. Source Program

The actual program written in a higher level language is called the

source program. This is the material that is put into the computer by the
user for the purpose of obtaining results. The source program contrasts
with the object program (which does not always exist), defined in the next
paragraph.

2. Object Program

A source program can usually be translated to an object program.

[Note the differences between compiler and interpreter in Sections I.4.3(3)
and I.4.3(4) below.] The object program can actually exist in many forms,
depending on the particular system involved. It can exist in pure binary
form, or it could actually exist in a fairly complex symbolic assembly lan-
guage form. The phrase object program, strictly speaking, relates only to the
final binary form that can be executed by the computer, but in common
conversation it is often used to denote the result of translating the source
program at least down to an assembly level.
12 GENERAL INTRODUCTION

3. Compiler

A compiler is a program, not a piece of hardware. A compiler is simply

a program which translates a source program written in a particular pro-
gramming language to an object program which is capable of being run on
a particular computer. A compiler is therefore both language and machine
dependent. The most important characteristic of a compiler is that its output
iS a program in some form or another and not an answer of any kind. This
contrasts with the interpreter defined in Section 1.4.3(4). The first completed
compiler seems to be the A-0 system developed by Dr. Grace Hopper and
her staff at Remington Rand in 1952; see [HP53] and [HP53a].
A compiler must perform at least the following functions: Analysis
of the source code, retrieval of appropriate subroutines from a library,
storage allocation, and creation of actual machine code. In current systems,
some or all of these functions (except the first) may actually be performed by
another part of the general operating system (e.g., a loader), but these
functions are conceptually part of the compiling process. Thus the com-
piler acts very much as an executive routine to obtain and combine the
necessary pieces of information to produce a machine-executable program.
The word translator has been in and out of vogue for years as a synonym
for compiler. In my opinion, translator is too general a term to use for the
specific process of turning a source program written in a higher level language
into machine code.

4. Interpreter

An interpreter is a program which executes a source program, usually

on a step-by-step, line-by-line, or unit-by-unit basis. In other words, an
interpreter will usually execute the smallest possible meaningful unit in the
programming language. The output of an interpreter 1s an actual answer,
1.e., the result of performing the actions designated in the program.
The greatest disadvantage of an interpreter is that certain phases of
work and analysis must be done repeatedly. In particular, the scan of a
statement which is to be executed for varying values of a particular parameter
must take place each time that a new value is to be used. This contrasts with
the compiler, which performs this translation function only once. On the
other hand, the disadvantage to the compiler is that it does not produce
answers; as soon as a change in the program is made, a recompilation must
be made.
The originally clear-cut distinctions between compilers and interpreters
have become quite blurred. Some systems (e.g., QUIKTRAN, see Keller,
Strum, and Yang [K R64]) compile partway, 1.e., translate the source program
to some other form and then interpret that information. This is an attempt
 1.4. DEFINITION OF PROGRAMMING LANGUAGES 13

to obtain the advantages of both concepts, while minimizing the disadvan-

tages of both.

5. Automatic Coding

In the very early stages of work in this area, the phrase automatic
programming was used to mean the process of writing the program in some
higher level language. As time went on, it became clear that this encoding
was only part of the entire process of programming since there were phases
of analysis, documentation, debugging, testing, etc. Hence, the term
automatic coding began to apply to the portion of the overall programming
effort that related specifically and only to the process of actually writing
the source program and having it translated to a form where it could be
run on a computer.

6. Automatic Programming

The term automatic programming, which as stated above was originally

used to cover anything to do with higher level languages, is defined on page
10 of the USASI Glossary [AA66b] as “The process of using a computer to
perform some stages of the work involved in preparing a program”. Thus,
automatic coding is a particular subset of automatic programming, which
is as it should be since coding is one of the many facets of programming.

1.4.4. DIFFERENCE BETWEEN PROGRAMMING LANGUAGE AND

APPLICATION PACKAGE

In the past few years there has been an increasing number of special
application packages developed. One of the earliest and most significant of
these was the work done on linear programming. More recent areas involve
type composition [IBOOf], demand deposit accounting [IB00e], traffic control
[IB66c], inventory management [IB00] and [IBOOd]. However, it is impor-
tant to realize that an application package and a programming language
are not the same. An application package tends to be a set of routines which
are heavily parameterized, so that an individual user can supply the specific
information which is needed for his particular direct usage. The information
is often supplied through tables or filling in a form. File formats are usually
specified by the application package. In some cases the execution sequence
of the routines is predetermined, e.g., student scheduling [IB66j]. In others,
the user decides which routines he needs and what the sequence should be,
e.g., bill of material processing [I1B66k]. In the latter situation, the user some-
times has to write a control program in an assembly or higher level language
to set up and call the necessary routines. A programming language, on the
other hand, provides flexibility in the way in which information is conveyed
14 GENERAL INTRODUCTION

and, more importantly, provides the tools with which the subroutines or
packages can be built-up. An application package is limited to use in a
narrow area. A programming language usually involves a wider potential
range of applications, although the languages discussed in Chapter IX are
designed for very specific—and sometimes quite narrow—applications.

1.5. ADVANTAGES AND DISADVANTAGES OF HIGHER LEVEL

LANGUAGES

As with any item, it is impossible to obtain something for nothing; therefore,

there are both advantages and disadvantages to programming languages,
where the alternative is some type of assembly language. It is essential to
realize that the comparison is being made between a symbolic assembly
language (which might but does not necessarily have macros) and some
type of higher level language which has the defining characteristics given
in Section 1.4.2. Furthermore, the comparison is being made between an
assembly and a higher level language of roughly equivalent orders of com-
plexity within their given classes. Thus, in examining the advantages and
disadvantages of a powerful (very simple) programming language, it is
tacitly being compared to a powerful (very simple) assembly language. This
point will be critical in several of the advantages given below. Furthermore,
the programming language must be appropriate to the task; thus a language
with notation well suited to scientific problems is not likely to be much help
in business data processing (although this has actually been done with
FORTRAN; see Robbins [RM62]).

1.5.1. ADVANTAGES

1. Ease of Learning

A very significant advantage to a higher level language is that it is

easier to learn than a machine-oriented language. This is probably the main
place in which the relative aspect referred to above is significant. An extremely
powerful programming language might be harder to learn than an assembly
language with only a dozen instructions. However, given programming and
assembly languages of approximately the same complexity in their relative
classes, the programming language will be easier to learn. This ease of learn-
ing actually has two facets to it. The programming language may itself be
complex, but its ease of learning often comes because the notation is some-
what more related to the problem area than is the machine code—this 1s
essentially the fourth defining characteristic given on page 10. The second
facet is that more attention can be paid to the language and the logic of the
 I.5. ADVANTAGES AND DISADVANTAGES OF HIGHER LEVEL LANGUAGES 15

program rather than to the idiosyncracies of the physical hardware which

are significant when one deals in machine code.
A further element of comparison in the ease of learning is that learning
a subset of a complex programming language may be, and probably will be,
very much easier than learning a subset of a complex assembly language.
Furthermore, the subset of the programming language will probably be
more useful and powerful than an equivalent subset of the assembly language.
Thus, although some programming languages have extremely thick manuals,
this is because they provide all the very detailed definitions that are needed
for writing compilers and sophisticated programs; the user who does not
wish to learn (or have) all the power available to him need not be bothered
with the full language.

2. Ease of Coding and Understanding

Because the notation is considerably more problem-oriented, the actual

coded program is generally easier to write. This 1s exemplified not only by
the case of algebraic expressions given on page 10 but by such things as
IF C IS GREATER THAN A+B, GO TO ALPHA OTHERWISE GO TO BETA.
which ts easier to write than an equivalent symbolic form which might look
like the following:

CLA A
ADD B (Calculate A+B)
SUB C (Calculate A+B—C)
TRN ALPHA (Transfer control to ALPHA if A+B—C
is less than O, 1.e., if C is greater than A+B)
JMP BETA (Transfer control to BETA)

The other half of the advantage is the ease of understanding the program
once it is written. These two aspects reflect the differences between actually
writing the program and trying to understand an already existing program
(either one’s own or, more likely, someone else’s). The higher level language
is clearly easier to read and understand, as seen from the example above.
In addition, the complexities of today’s large computers make it very
difficult to learn to program them at all, let alone effectively.

3. Ease of Debugging

A problem written in a programming language is generally easier to

debug than one written in a symbolic assembly language, for two major
reasons. First, there tends to be less material written because of the explo-
sion factor given as the third defining characteristic of a programming
language. Thus, in comparison with a program written in assembly language,
16 GENERAL INTRODUCTION

the source program will generally be physically shorter. Since the number of
errors is roughly proportional to the length of the program, obviously there
will be fewer errors. In some cases it might turn out that the program
written in the higher level language was actually longer if measured by the
number of characters actually written. (This happened in the example given
on p. 15.) However, the program is easier to debug because the notation
is so much more natural; more attention can be paid to the logic of the
program with less worry about the details of the machine code. For example,
although there might be more characters involved in writing READ NEXT
RECORD FROM TAPE ALPHA than in REDABC, ALPHA, the former is easier
to understand, particularly when there may be a whole sequence of six-letter
instructions which differ by at most one letter.

4. Ease of Maintaining and Documenting

One of the greatest advantages to a programming language is the fact

that it provides certain documentation automatically because of the nota-
tional advantages; it is also considerably easier to maintain. There are very
few programs which last very long without requiring some changes, and
a combination of reasonably natural notation plus shortness of program
make the higher level language quite advantageous. In addition, one of the
great difficulties in changing a program written in assembly language is to
make sure that a change in one instruction does not have major (and un-
pleasant) ramifications elsewhere. This factor applies not only to the logic
of the change (which must also be considered when dealing with the higher
level language) but, more significantly, to various tricky coding techniques
which might be forgotten by the time the change was made and result in
incorrect code.

5. Ease of Conversion

Since the second defining characteristic of a programming language is

the potential for conversion to other computers, it is not surprising that this
is considered an advantage. Since by now it 1s clear that programming costs
equal or exceed hardware costs, it is not surprising that the problem of con-
version is a very major one. In many cases, companies have been unable to
acquire new computers because of the enormous cost of converting their
existing programs to the new machines. This has forced the manufacturers
to pay much more attention to compatibility among the computers they
offer to their customers and to provide technically graceful ways of con-
verting programs from one machine to another. However, since programming
languages are relatively machine independent, the ease of conversion be-
comes an extremely important advantage. The various types of conversion,
and their significance, are discussed in Section II.4.
 1.5. ADVANTAGES AND DISADVANTAGES OF HIGHER LEVEL LANGUAGES 17

6. Reduce Elapsed Time for Problem-Solving

Probably the greatest single overall advantage to a programming

language is that it usually reduces the total amount of elapsed time from
inception of the problem to its solution. This is particularly true for one-
shot problems—problems in which a single or only a small number of cases
need to be run. Higher level languages have cut this elapsed time from
months to weeks in some cases and from days to hours in other cases.
Although sometimes one particular facet of the overall process might be
worse in a higher level language (specifically, the compilation time, discussed
in Section I.5.2.2), the overall problem solution time is greatly reduced.
This is somewhat less of an advantage for long-term production runs, such
as payroll. In that case, the advantages of ease of maintenance and docu-
menting probably overshadow the elapsed time advantage, although the
latter is still available.

1.5.2. DISADVANTAGES

1. Advantages Do Not Always Exist

There is a subtle point that the advantages stated above do not always
exist in specific cases, and a person might be worse off; however, this would
only tend to arise in a comparison of a complex and powerful programming
language versus a simple assembly language. Thus the programming lan-
guage might be extremely difficult and hard to learn; and unless proper
attention is paid to the compiler and other facets of the overall system, the
other advantages may not themselves accrue. Fortunately, this seldom
occurs.

2. Time Required for Compiling

A very obvious disadvantage to the use of a higher level language is

that the additional process of compilation requires more machine time
than the straight assembly process; the compilation time might, in fact,
require more than the machine time saved from easier debugging. This
additional machine time is most easily observed by recognizing the fact that
a very common compiling technique is to translate the source program to
an assembly language which already exists for the given computer and
letting the standard assembly program create the final object code.
(Naturally techniques have been developed to avoid this particular difficulty,
but they are not always applicable.) Compilation time is a particular dis-
advantage on one-shot problems in which the compilation time sometimes
exceeds the time actually required to produce the answers. Another dis-
18 GENERAL INTRODUCTION

advantage associated with compilation time is the necessity of recompiling

every time a change in the source program is made. However, sometimes
modern assemblers are so complex that they take “longer” than the transla-
tion of an equivalent program in a higher level language.

3. Inefficient Object Code

A disadvantage which significantly affects production runs occurs when

the compiler produces inefficient object code. When a program is to be run
repeatedly, it is important that the final program be efficiently coded be-
cause of the constant repetitive use. The counterargument to this, of course,
is that compilers nowadays generally produce code that is at least as good
as the average programmer, and there are only a limited number of really
expert programmers who can write the most efficient machine code. A
further counterargument is that it is usually possible to take very critical
routines, which are generally quite short and encapsulated, and code them
as efficiently as possible in machine code.
A disadvantage in this area which is sometimes unjustly blamed on the
compiler occurs when the programmer writes inefficient source programs
in the higher level language and obtains inefficient object programs as a
result. Although it is easier to code in a higher level language than in machine
code, there is still a difference between good and poor coding. A program
that has been written inefficiently (e.g., unnecessary control transfers and
extra computations) with respect to the programming language will produce
inefficient object code regardless of how good the compiler is.

4. Difficulties in Debugging Without Learning Machine Language

If a person does not know machine code, and the compiler does not
provide the proper type of diagnostics and debugging tools, the program
may actually be harder to debug than an assembly language program which
the user understands. A person who must look at an octal memory dump
will have a lot more trouble debugging his high level source program than
he would if he had written it in assembly language. Thus a compiler which
does not provide proper attention to this aspect may greatly reduce the
advantages of a higher level language or cause them to disappear entirely.

5. Inability of the Language to Express All Needed Operations

In some problems there are operations to be performed which cannot

be expressed in the programming language, or if they are available, they will
be so awkward as to be almost useless. Thus, to handle individual bits in
a language designed only to manipulate numeric quantities is virtually im-
possible, and certainly inefficient. The user may find himself trapped by
1.6. CLASSIFICATIONS OF PROGRAMMING LANGUAGES AND PROPOSED DEFINITIONS 19

being unable to do certain manipulations without resorting to machine code.

This usually occurs when he has chosen the language unwisely for his par-
ticular application. However, a more common problem is the poor match
between the older (and more popular) languages and third generation
hardware. For example, a language with no facilities for dealing with random
access memories requires the user to either ignore his equipment or resort
to machine language to deal with it.

1.5.3. OVERALL EVALUATION

In spite of the fact that higher level languages have been with us for
over 10 years, there has been relatively little quantitative or qualitative
analysis of their advantages and disadvantages. One very small study is given
by Shaw [SH66] and some information is given by Nelson et al. [NE65].
In spite of this paucity of definitive information, the current milieu
calls for the use of higher level languages. People who use assembly code
are—if not in an actual minority—considered somewhat archaic or old-fash-
ioned. The fact that there is a tremendous proliferation of languages (as
witnessed by all those described, plus others not even mentioned, in this
book) indicates that we have not yet solved the problem of knowing what
is really needed by the user. Some comments about possible future direc-
tions are given in Chapter XI. However, the net overall evaluation appears
to be that higher level languages have proved their worth and are definitely
here to stay.

1.6. CLASSIFICATIONS OF PROGRAMMING LANGUAGES AND

PROPOSED DEFINITIONS

As indicated earlier, it is very difficult to define a programming language.

However, it is a little easier to propose definitions for classes of programming
languages. The terms to be defined are the following: Procedure-oriented
and nonprocedural; problem-oriented, application-oriented, and special
purpose; problem-defining, problem-describing, and problem-solving;
hardware, publication, and reference. Note that some of these are over-
lapping and that a particular language may fall into more than one of these
categories.

1.6.1. PROCEDURE-ORIENTED LANGUAGE

A procedure-oriented |language is one in which the user specifies a set of

executable operations which are to be performed in sequence; the key factor
20 GENERAL INTRODUCTION

here is that these are definitely executable operations, and the sequencing
is already specified by the user. FORTRAN, COBOL, and PL/I are examples.

1.6.2. NONPROCEDURAL LANGUAGE

The term nonprocedural language has been bandied about for years
without any attempt to define it. It is my firm contention that a definition
is not really possible because nonprocedural is actually a relative term mean-
ing that decreasing numbers of specific sequential steps need be provided
by the user as the state of the art improves. The closer the user can come to
stating his problem without specifying the steps for solving it, the more
nonprocedural is the language. Furthermore, there can be an ordered
sequence of steps, each of which is “somewhat nonprocedural,” or a set of
executable operations whose sequence is not specified by the user. Both cases
contribute to “more nonproceduralness”. Thus, before the existence of such
languages as FORTRAN, the statement

Y=A+Bx*xC—
F/G

could be considered nonprocedural because it could not be written as one

executable unit and translated by any system. Right now, the sentences
CALCULATE THE SQUARE ROOT OF THE PRIME NUMBERS FROM
7 TO 91 AND PRINT IN THREE COLUMNS and PRINT ALL THE
SALARY CHECKS are nonprocedural because there is no compiler avail-
able that can accept these statements and translate them; the user must
supply the specific steps required. Another type of nonprocedural statement
is a higher level primitive operation, e.g., integration. Note that there is a
fundamental language difference between writing INTEGRATE F(X) FROM A
TO B USING SIMPSON’S RULE and CALL SIMP (F(X), A, B) although the
same subroutine could be used for both. In cases where subroutines do not
exist (as in the earlier two examples), then obviously the detailed steps
must be specified.
As compilers are developed to cope with increasingly complex sentences,
the nature of the term changes. Thus, what is considered nonprocedural
today may well be procedural tomorrow. The best examples of currently
available nonprocedural systems (not really languages) are report generators
and sort generators in which the individual supplies the input and the output
without any specific indication as to the procedures needed.
Specific attempts to raise the level of nonproceduralness in different
ways are discussed by Wilkes [WI64], Rice and Rosen [RI66], Klerer and
May [KL67], and Schlesinger and Sashkin [QL67]. General discussions of
some of the issues are given by Young [YJ65] and Whiteman [WF66].
1.6. CLASSIFICATIONS OF PROGRAMMING LANGUAGES AND PROPOSED DEFINITIONS 21

1.6.3. PROBLEM-ORIENTED LANGUAGE

The term problem-oriented has been used in many ways by different

people, but it seems that the most effective use of this term is to encompass
any language which is easier for writing solutions to a particular problem
than assembly language would be. Any current programming language
illustrates this; thus, the term problem-oriented is a general catchall phrase.

1.6.4. APPLICATION-ORIENTED LANGUAGE

The term application-oriented seems to apply best to a language which

has facilities and/or notations which are useful primarily for a single applica-
tion area. The best illustrations of this are such things as APT for machine
tool control and COGO for civil engineering applications, both of which
are discussed in Chapter IX. Notice that both of these are of course problem-
oriented languages. On the other hand, FORTRAN and COBOL are
problem-oriented but much less application-oriented than APT or COGO.
Here again, the term is somewhat relative because FORTRAN is suitable
for applications involving numerical mathematics, whereas COBOL is
obviously suited for business data processing and the overlap between these
is relatively small. The wider the application area, the more general the
language must be.

1.6.5. SPECIAL PURPOSE LANGUAGE

A special purpose language is one which is designed to satisfy a single

objective. The objective might involve the application area, the ease of use
for a particular application, or pertain to efficiency of the compiler or the
object code.

1.6.6. PROBLEM-DEFINING LANGUAGE

A problem-defining \anguage is one which literally defines the problem

and may specifically define the desired input and output, but it does not
define the method of transformation. There is a significant difference among
a problem (and its definition), the method (or procedure) used to solve it,
and the language in which this method is stated. The best current illustrations
are report and sort generators, although none of these involves languages
in the sense of Section I.4.
22 GENERAL INTRODUCTION

[.6.7. PROBLEM-DESCRIBING LANGUAGE

A much more general type of language classification is that referred

to as problem-describing, in which the objective is described only in very
general terms, e.g... CALCULATE PAYROLL. All this does is cite, in the
most general way, the problem which is to be solved but gives no indication
of its detailed characteristics, let alone how to solve it. We are an extremely
long way from this!

1.6.8. PROBLEM-SOLVING LANGUAGE

Finally, a problem-solving language is one which can be used to specify

a complete solution to a problem. Like the term nonprocedural, this is a
relative term which changes as the state of the art changes. All procedure-
oriented languages are problem-solving languages.

1.6.9. REFERENCE LANGUAGE

A reference language is the definitive character set and form of a lan-

guage. It usually has a unique character for each concept or character in the
language, 1s one-dimensional, and need not be suitable as computer input.
In some cases, English is the reference language; in other cases, a fixed set of
symbols is provided. The concept of having a reference language, as dis-
tinguished from a publication or hardware representation language (dis-
cussed below), was introduced by the ALGOL committee in their first report
[PR58]. In fact, ALGOL 1s the only language in this book with these three
forms. The reference language need not be particularly easy to read.

1.6.10. PUBLICATION LANGUAGE

A publication language is some well-defined variation of the reference

language which is suitable for publication. It is designed to be suitable for
printing and/or writing; therefore, it would have reasonable rules and
characters for such things as subscripts, exponents, spaces, and Greek
letters. The publication language would normally be the means of com-
munication between people (using printed media). There can be many
publication languages and they can contain different characters, but there
must be a well-defined mapping between the publication and reference
languages. An illustration of this is the use of an up arrow ft to denote
exponentiation in the ALGOL reference language, but the use of a raised
symbol in the publication language, e.g., A t 2, becomes A?.
 1.7. FACTORS IN CHOICE OF A LANGUAGE 23

1.6.11. HARDWARE LANGUAGE

A hardware language, sometimes called a hardware representation, is

a mapping of the reference language into a form which is suitable for direct
input to a computer. The number and type of characters used must be that
accepted by the computer involved. A hardware language must have a well-
defined mapping between itself and the reference language, e.g., ** might
be a hardware representation of the ¢ in the reference language.

1.7. FACTORS IN CHOICE OF A LANGUAGE

Assuming that a decision has been made not to use assembly language (see,
e.g., Shaw [SH66]), there is currently no scientific, or even logical, way to
choose the best programming language for a particular situation. Part of
the difficulty stems from the fact that the situation itself is usually defined
poorly, and potential for change in the application area is a factor which
must be taken into consideration. It is definitely not the purpose of this book
to provide all the information needed by a potential user to choose the
programming language most suited for his purposes. However, it is one of
the purposes to supply some of this information and to indicate the factors
which should be considered. The reader is cautioned to be very careful in
applying the items discussed in this section to a particular case. Not all factors
are relevant in all situations, nor are they all equally important. In virtually
all cases, no single language will be ideal for a particular application, let
alone for a particular installation, and probably not for an entire company.
An increasing amount of work is being done to develop some fairly
specific methods for evaluating languages and their compilers. Scientific
evaluations have seldom been made, and documented even less often, and
the few attempts to date seem to be without any quantitative measurements.
Questionnaires and comparisons have been developed by Shaw [SH62] and
Budd [QH66]; although the latter pertains only to FORTRAN and COBOL,
it is quite detailed for those languages. General discussions are given by
Haverty [HV64], Chapin [CZ65], and Schwartz [SC65]. A number of un-
published papers on evaluations for specific military applications also exist.
Some of the terms and/or concepts used below are defined and discussed
in some detail in Chapters II and III, particularly the former.

1.7.1. SUITABILITY OF LANGUAGE FOR PROBLEM AREA AND PROJECTED

USERS

The most important factor in the choice of a language is whether it

contains the elements needed to solve the particular class of problems for
24 GENERAL INTRODUCTION

which it is being considered. In the simplest case, a language which provides

good facilities for handling equations may not provide the character handling
and input/output facilities needed to process a payroll. Conversely, a lan-
guage which is too large, i.e., has many more facilities than are needed,
is not necessarily desirable since the user will be paying a heavy price because
of less efficiency in his specialized area. While these points are fairly obvious
at a gross level, there are other elements in the language suitability issue.
For example, if there is to be much array handling, then the type and amount
of subscripting which 1s permitted may be significant. Another case might
involve the types of data names which are permitted; for example, if the
application involves inventory and all the stock items are identified by
numbers, then it might be more convenient if these were allowed as names
in the program.
In addition to the capabilities of the language, the type of actual users
must be considered. There is an obvious difference among experienced
programmers, professionals in other fields, novice programmers, open
shop versus closed shop, etc. The amount of formalism or naturalness in
the language relative to the projected users is of vital importance.
In summary, the potential user must first examine the language at a
gross level to see whether it supplies the general capabilities he needs.
Then he must determine whether individual features which might be very
important in a particular situation are available. (See also Section I.7.7.)
Finally, he must consider the style of the language relative to the intended
users.

1.7.2. AVAILABILITY ON DESIRED COMPUTER

The most obvious question which must be asked (and which is also
raised in Section II.7.1) 1s whether there is an implementation of the language
on the desired computer (configuration). It is obviously useless to decide
on a superb language for a particular application and then find there is no
way to obtain running programs. Of course in some cases the language may
be deemed so worthwhile that a particular installation would choose to
finance a compiler if there was not one existing already.
If there is a compiler available, then a particular point to watch out for
is the exact computer configuration which it requires. It does not help to
find an excellent language and an efficient compiler if the latter requires
twice as much memory capacity as the installation possesses. Again, in this
case, if other factors warrant it, then there might be justification for obtain-
ing the extra memory.
 1.7. FACTORS IN CHOICE OF A LANGUAGE 25

1.7.3. HisTORY AND EVALUATION OF PREVIOUS USE

Once the user has found what he considers a suitable language and
there is a compiler available on his computer, then he should consider the
history of usage of this language. He should investigate such items as the
reactions of previous users, users’ views on its applicability in actual practice,
the efficiency of the implementation (see Section I.7.4.), its potential for
expansion into other (and probably unforeseen) application areas, ease or
difficulty of training and effectiveness of documentation, and problems of
conversion and compatibility. In short, he should consider the language
based on the practical experience of others with regard to the factors in
Chapter II.

1.7.4. EFFICIENCY OF LANGUAGE IMPLEMENTATION

In choosing a language, it is essential to understand the difference

between a language and a specific implementation of it. However good the
former may be, a very bad compiler may render the language almost useless.
The prospective user must investigate this situation very thoroughly. There
may be elements in the language (some are discussed in Chapter III) which
would prevent a good compiler from ever being developed. On the other
hand, the first compilers for a new language almost always tend to be ineffi-
cient and remain that way until better implementation techniques are found
and finances and time permit them to be used. Similarly, a language may
be very difficult to implement on a particular computer (configuration),
although it might have an excellent compiler on another. While this latter
point is obvious in considering small versus large computers, there are other
more subtle points which are relevant (e.g., type of input/output and type
of indexing permitted).
The user who finds a language which is well suited to his purpose may
choose to suffer the (presumably temporary) inconvenience of an inefficient
compiler for the sake of long-range benefits.

1.7.5. COMPATIBILITY AND GROWTH POTENTIAL

The meaning of compatibility and its applicability to problems in

programming languages is discussed in Section I1I.4. The prospective user
must understand what types of compatibility and conversion are available,
and how important they are to him. In addition, the potential use of the
language in new and unforeseen areas must be considered. While this is
26 GENERAL INTRODUCTION

obviously impossible in detail (since it would be self-contradictory to consider

unforeseen areas), some thought can be given to the matter. For example,
a scientific installation might consider whether it might ever be involved
with data processing. A large command and control project might consider
whether the application would grow into other areas. Finally, the language
should be viewed from the point of possible extensions to meet other needs.
In addition to looking ahead, the user may need to look behind if there
are existing applications. The consideration of a new language may involve
problems of compatibility with the old one.

[.7.6. FUNCTIONAL (= NONTECHNICAL CHARACTERISTICS)

There has tended to be much confusion in the past due to lack of

consideration of the difference between the nontechnical and the technical
characteristics of a programming language. It is my hope that the delineation
of these issues and a detailed discussion of them in two separate chapters
will alleviate this difficulty. It suffices to point out here that the prospective
user must consider the nontechnical characteristics (as discussed in Chapter
II) as carefully as he considers its technical elements in order to arrive at
a proper judgment.

1.7.7. TECHNICAL CHARACTERISTICS

While the nontechnical characteristics of a programming language may

tend to prevent it from being used in a particular application, an affirmative
choice can only be made if the language contains the necessary technical
features. Some relevant factors were mentioned in Section I.7.1. A careful
study of Chapter III should provide a complete checklist to be used against
a specific language. The importance of particular elements in a given situa-
tion is a value judgment to be made by the prospective user.

REFERENCES

[AA66b] American Standard Vocabulary for Information Processing, X3.12,

American Standards Association [now United States of America
Standards Institute], New York, 1966.
[AD54] Adams, C. W. and Laning, J. H., Jr., “The M.I.T. Systems of Automatic
Coding: Comprehensive, Summer Session, and Algebraic”, Symposium
on Automatic Programming for Digital Computers, Office of Naval
Research, Dept. of the Navy, Washington, D.C. (1954), pp. 40-68.
[BK56] Baker, C. L., “The PACT I Coding System for the IBM Type 701”,
J. ACM, Vol. 3, No. 4 (Oct., 1956), pp. 272-78.
 REFERENCES 27

[CZ65] Chapin, N., “What Choice of Programming Languages?”, Computers

and Automation, Vol. 14, No. 2 (Feb., 1965), pp. 12-14.
[DN54] Symposium on Automatic Programming for Digital Computers, Office of
Naval Research, Dept. of the Navy, Washington, D.C. (1954).
[DN56] Symposium on Advanced Programming Methods for Digital Computers
(Washington, D.C., June 28, 29, 1956). ONR Symposium Report ACR-
15, Office of Naval Research, Dept. of the Navy, Washington, D.C.
(Oct., 1956).
[EP66] “How to Use Decision Tables”, EDP Analyzer, Vol. 4, No. 5 (May,
1966), pp. 1-14.
[FK57] Automatic Coding (Proceedings of the Symposium on Automatic
Coding held January 24-25, 1957 at the Franklin Institute in Philadel-
phia), Jour. of the Franklin Inst., Monograph No. 3, Philadelphia, Pa.
(Apr., 1957).
[FR63] Ferguson, H. E. and Berner, E., “Debugging Systems at the Source
Language Level”, Comm. ACM, Vol. 6, No. 8 (Aug., 1963), pp. 430-32.
[HF54] Holberton, F. E., “Application of Automatic Coding to Logical Proc-
esses”, Symposium on Automatic Programming for Digital Computers,
Office of Naval Research, Dept. of the Navy, Washington, D.C. (1954),
pp. 34-39.
[HL64] Halpern, M. I., “XPOP: A Meta-Language Without Metaphysics’,
Proc. FJCC, Vol. 26, pt. 1 (1964), pp. 57-68.
[HM66] Homer, E. D., “An Algorithm for Selecting and Sequencing Statements
as a Basis for a Problem-Oriented Programming System”, Proc. ACM
2Ist Nat’! Conf., 1966, pp. 305-12.
[HP53] Hopper, G. M., “Compiling Routines”, Computers and Automation,
Vol. 2, No. 4 (May, 1953), pp. 1—S.
[HP53a] Hopper, G. M. and Mauchly, J. W., “Influence of Programming Tech-
niques on the Design of Computers”, Proc. IRE, Vol. 41, No. 10 (Oct.,
1953), pp. 1250-54.
[HP55] Hopper, G. M., Automatic Coding for Digital Computers (Talk presented
at The High Speed Computer Conference, Louisiana State University,
Feb. 16, 1955), Remington Rand Corp., ECD-1 (1955).
[HV64] Haverty, J. P., Programming Language Selection for Command and
Control Applications, RAND Corp., P-2967, Santa Monica, Calif. (Sept.,
1964).
[IB00] Management Operating System: Inventory Management and Materials
Planning— Detail, IBM Corp., E20-0050-0, Data Processing Division,
White Plains, N.Y.
[1B00d] Retail IMPACT—Inventory Management Program and Control Tech-
niques, IBM Corp., E20-0188, Data Processing Division, White Plains,
N.Y.
[1B00e] Demand Deposit, IBM Corp., 1140-FB-03X, Data Processing Division,
White Plains, N.Y.
[1BOOf] Type Composition, IBM Corp., 1130-DP-04X, Data Processing Division,
White Plains, N.Y.
[1B00j} The Bank Central Information System—Locate File, IBM Corp., E20-
0138, Data Processing Division, White Plains, N.Y.
28 GENERAL INTRODUCTION

{IB61la] IBM 7070 Series Programming Systems: Autocoder (Reference Manual),

IBM Corp., C28-6121-0, Data Processing Division, White Plains, N.Y.
(1961).
[1B65d] IBM System/360 Operating System Report Program Generator Speci-
fications, IBM Corp., C24-3337, Data Processing Division, White
Plains, N.Y. (1965).
[I1B66c] 1800 Traffic Control System: Application Description, IBM Corp., H20-
0212-0, Data Processing Division, White Plains, N.Y. (1966).
[1B66)] Student Scheduling System/360, Application Description, IBM Corp.,
H20-0202-0, Data Processing Division, White Plains, N.Y. (1966).
[1B66k] System/360 Bill of Material Processor (360-ME-06X), Programmer’s
Manual, IBM Corp., H20-0246-0, Data Processing Division, White
Plains, N.Y. (1966).
[1F66] IFIP-ICC Vocabulary of Information Processing (First English language
edition). North-Holland Publishing Co., Amsterdam, Netherlands,
1966.
[KL67] Klerer, M. and May, J., “Automatic Dimensioning”, Comm. ACM,
Vol. 10, No. 3 (Mar., 1967), pp. 165-66.
[KR64] Keller, J. M., Strum, E. C., and Yang, G. H., “Remote Computing: An
Experimental System Part 2: Internal Design”, Proc. SJCC, Vol. 25
(1964), pp. 425-43.
[K V60] Kavanagh, T. F., “TABSOL—A Fundamental Concept for Systems-
Oriented Languages”, Proc. FJCC, Vol. 18 (1960), pp. 117-36.
[LA54] Laning, J. H. and Zierler, W., A Program for Translation of Mathe-
matical Equations for Whirlwind I, M.1.T., Engineering Memorandum
E-364, Instrumentation Lab., Cambridge, Mass. (Jan., 1954).
[NE65] Nelson, E. A. et al., Research into the Management of Computer Pro-
gramming: Some Characteristics of Programming Cost Data from
Government and Industry, System Development Corp., TM-2704/000/00,
Santa Monica, Calif. (Nov., 1965).
[NMO00] SURGE: A Data Processing Compiler for the IBM 704, North American
Aviation, Inc., Columbus, Ohio.
[PR58] Perlis, A. J. and Samelson, K. (for the committee), “Preliminary
Report—International Algebraic Language”, Comm. ACM, Vol. 1,
No. 12 (Dec., 1958), pp. 8-22.
[QH66] Budd, A. E., A Method for the Evaluation of Software: Procedural
Language Compilers—Particularly COBOL and FORTRAN, MITRE
Corp., (DDC) AD 651142, Commerce Dept. Clearinghouse, Springfield,
Va. (Apr., 1966).
[QL67] Schlesinger, S. and Sashkin, L., “POSE: A Language for Posing Prob-
lems to a Computer”, Comm. ACM, Vol. 10, No. 5 (May, 1967), pp.
279-85.
[R166] Rice, J. R. and Rosen, S., “NAPSS—A numerical analysis problem
solving system”, Proc. ACM 21st Nat’l Conf. 1966, pp. 51-56.
[RM62] Robbins, D. K., “FORTRAN for Business Data Processing”, Comm.
ACM, Vol. 5, No. 7 (July, 1962), pp. 412-14.
[RR55a] BIOR (Business Input-Output Rerun) Compiling System, Remington
Rand Corp., ECD-2 (1955).
 REFERENCES 29

[RT53] Rochester, N., “Symbolic Programming”, Trans. IRE Professional

Group on Electronic Computers, Vol. EC-2, No. 1 (Mar., 1953), pp. 10-15.
[SC65] Schwartz, J. I., “Comparing Programming Languages”, Computers
and Automation, Vol. 14, No. 2 (Feb., 1965), pp. 15-16, 26.
[SH62] Shaw, C. J., An Outline/Questionnaire for Describing and Evaluating
Procedure-Oriented Programming Languages and Their Compilers,
System Development Corp., FN-6821/000/00, Santa Monica, Calif.
(Aug., 1962).
[SH64a] Shaw, C. J., “More Instructions ... Less Work”, Datamation, Vol. 10,
No. 6 (June, 1964), pp. 34-35.
[SH66] Shaw, C. J., “Assemble or Compile?”, Datamation, Vol. 12, No. 9
(Sept., 1966), pp. 59-62.
(ST57] Steel, T. B., Jr., “PACT IA”, J. ACM, Vol. 4, No. 1 (Jan., 1957), pp. 8-11.
([TM56] Thompson, C. E., “Development of Common Language Automatic
Programming Systems”, Symposium on Advanced Programming Methods
for Digital Computers (Washington, D.C., June 28, 29, 1956). ONR
Symposium Report ACR-15, Office of Naval Research, Dept. of the
Navy, Washington, D.C. (Oct., 1956), pp. 7-14.
[UC6]1] Grad, B., “Tabular Form in Decision Logic”, Datamation, Vol. 7, No. 7
(July, 1961), pp. 22-25.
[WF66] Whiteman, I. R., “New Computer Languages”, Internat’! Science and
Technology (Apr., 1966), pp. 62-68.
[W151] Wilkes, M. V., Wheeler, D. J., and Gill, S., The Preparation of Programs
for an Electronic Digital Computer. Addison-Wesley Press, Reading,
Mass., 1951.
[W164] Wilkes, M. V., “Constraint-Type Statements in Programming
Languages”, Comm. ACM, Vol. 7, No. 10 (Oct., 1964), pp. 587-88.
[WT68] Wirth, N., “PL360, A Programming Language for the 360 Computers”,
J. ACM, Vol. 15, No. 1 (Jan., 1968), pp. 37-74.
[XY56] “UA SAP 1 and 2”, SHARE Distribution No. 36 (Feb., 1956).
[YJ65] Young, J. W., Jr., “Non-Procedural Languages”, Presented at ACM
S. Calif. Chap. Seventh Annual Technical Symposium, Mar. 23, 1965.
 I I FUNCTIONAL CHARACTERISTICS
OF PROGRAMMING LANGUAGES

ll.1. DESCRIPTION OF THE CONCEPT OF FUNCTIONAL CHARACTERISTICS

This chapter concerns itself with the functional characteristics of program-

ming languages. The term functional characteristics is used to refer to those
aspects of programming languages which are primarily nontechnical and/or
which are not part of the language specifications themselves. The functional
aspects normally relate to economic and political factors and also to those
aspects of compilers which affect the use of the language in a significant
way. The actual elements of the language are considered technical charac-
teristics and are described in Chapter III.
Although the primary characteristics of a programming language are
its technical facilities and the way in which they are provided, these are far
from being the only features in determining the use and usability of a lan-
guage. Just as in the case of computer hardware selection there are factors
that transcend the physical characteristics, so there are multitudinous and
interlocking issues which apply to programming languages. For example,
originally the selection of a computer depended primarily on the speed of
individual instructions such as addition, multiplication, etc. After a while,
it became clear that the amount of time required for memory access was very
significant; still later it became apparent that speed of input/output, sizes
of secondary storage units, and the interrelationship of all these hardware
features were very important. Finally it became clear that the selection of hard-
ware depended not only on the hardware itself but on its relationship to the
software; so the concept of thruput became of paramount importance. Thus,
just as the total amount of productive work which could be done using a
particular piece of hardware and its associated software became the prime

30
 Il.2. PROPERTIES OF LANGUAGES 31

criterion in computer selection, so in the case of programming languages

there are factors beyond the immediate language definition which signifi-
cantly affect its selection and use. It is the function of this chapter to try to
describe these functional characteristics and to indicate their importance.
The items to be discussed include general properties of a language, the pur-
pose of a language, issues of conversion and compatibility, standardization,
types and methods of language definition, and evaluation.

11.2. PROPERTIES OF LANGUAGES

There are a number of language properties which are difficult to define

and which often appear to be subtle aesthetic qualities rather than tangible
characteristics. Although it is not possible to provide rigorous definitions
for these qualities, it is nevertheless worth trying to provide some brief in-
tuitive feel for each of them.
Two properties which may occur either in parallel or at opposite ends
of a scale are generality and/or simplicity. Generality really means a wide
scope, i.e., ability of the language to apply directly and effectively to a wide
class of problems (see Section II.3.1). Simplicity usually refers to ease of
learning, use, and implementation. These properties are at opposite ends
of the spectrum because putting a large number of capabilities into one
language, thus making it general, causes loss of simplicity by requiring many
different facilities to be learned. On the other hand, a very simple language
cannot provide too many facilities because in so doing it will lose that charac-
teristic. It will tend to provide a few very powerful primitives. The only way
in which generality and simplicity can exist together is when the ability to
handle a large number of differing application types is achieved by providing
a simple framework and allowing (and requiring) the user to build up the
larger capabilities that he needs. This is sometimes referred to as the core-
language concept. It is often difficult to separate the concept of generality
from the availability of many special purpose features.
Two properties which are often at opposite ends of a spectrum are suc-
cinctness and naturalness. An example of naturalness might be FIND
THE SQUARE ROOT OF 17 USING NEWTON-RAPHSON ITERATION, whereas
its succinct equivalent might be SQR (17, NR). To a person well trained in
formal notation, the succinct notation may even be more natural. Such a case
clearly arises in comparing the sentence ADD A TO B AND MULTIPLY THAT
RESULT BY C TO PRODUCE D with the equation D = C « (A +B). Both of
these are clearly within current technology. The choice is usually based both
on the type of intended users and the personal choice of the language
designers.
The notational properties of languages play at least as great a role as
32 FUNCTIONAL CHARACTERISTICS OF PROGRAMMING LANGUAGES

any other characteristic. A language notation can be succinct and/or natural

and/or formal. There is a significant difference between the facilities a lan-
guage provides and the notation by which they are invoked.
Consistency is a property which programming languages should have,
but often cannot. In this instance, consistency means the constant applica-
tion of the same rules in the same way throughout the entire language.
While it may seem both easy and obvious that this can and should be done,
sometimes achieving this objective is not worth the sacrifice. (The change
of optional key words in different divisions of COBOL illustrates such a
case. See Section V.3.)
The property of efficiency is seldom applied to a language, but it is an
appropriate one nevertheless. Unfortunately, the criteria for efficiency are
as widespread as the people who use or implement the language. For example,
efficiency could mean the number of pencil strokes required to write a pro-
gram or the ease of use by novice programmers or a language design which
permitted rapid compilation or the provision of a number of compiler aids
to provide optimal object code. There is no single measure of efficiency,
and the language examiner should be careful of what facet is being measured
in attempting to ascertain the efficiency of the language. It 1s also essential
to realize that efficiency of a language and a compiler are not the same thing;
the latter usually cannot be achieved without some appropriate language
design, but the best language in the world can have a very inefficient compiler
(see Section II.7.2).
Another very general property of a language is whether it is easy to write
and/or whether it is easy to read. These are not necessarily coexistent in a
single language, and one may in fact tend to militate against the existence of
the other. Thus a language which is extremely easy to read (e.g., some of the
languages discussed in Section IV.7) might be difficult to prepare for com-
puter input. A related property is whether the average user will be very
error prone. If the language has many specific and strict rules about spacing
and punctuation, there is more of a tendency for error in writing the program.
Finally, while one of the avowed advantages of programming languages
is that they are easier to learn than assembly languages, some higher level
languages may be designed to be very easy to learn while others do not have
that as a characteristic or objective. Being easy to learn is definitely not neces-
sarily the same as being easy to read, write, or avoid errors.

1I.3. PURPOSE OF LANGUAGE

In looking at a language, the first and most important characteristic is its

purpose. It is futile and foolhardy to look at languages and complain about
them for not accomplishing some particular task, when their avowed purpose
 11.3. PURPOSE OF LANGUAGE 33

was quite different. Defining the design objectives of a programming language

requires specifying the type of applications, the type of language, and the
type of potential user.

I1.3.1. APPLICATION AREA

Generality often breeds inefficiency, just as familiarity breeds contempt.

Thus, a language which is designed to be all things to all people will probably
be less successful than a language with somewhat narrower objectives, unless
the design is very carefully done. We must consider the application area for
which a language is designed; it may be aimed at a very narrow range of
endeavor such as machine tool control, or it may be designed for a wider
class of problems—for example, numerical scientific computations—or it
may be designed to cover the whole gamut of all problems to be run on a
computer. (There are not likely to ever be languages which satisfy the last
objective.) To date, most languages have dealt with application areas such
as numerical scientific computations (e.g., FORTRAN) and then more recent-
ly nonnumerical scientific computations (e.g., FORMAC), business data
processing (e.g., COBOL), simulation (e.g., SIMSCRIPT), or machine tool
control (e.g., APT). Some languages (see Chapter VIII) were designed to be
very wide in scope and encompass several of the items in the preceding list.
However, even in some of these cases—notably JOVIAL and PL/I—the types
of applications envisioned were fairly standard scientific and data processing.
It is essential to distinguish between the basic application area for which
the language was designed and the actual usage to which it may be put.
There are numerous examples of languages which were aimed at coping
with a given class of problems but which eventually were used for many
other things. The best example of this is FORTRAN, which was originally
designed for use in numerical scientific work but has been used for subjects
as widely separated as logical design and payroll writing. The important
factor in viewing the issue of application area is not so much what the lan-
guage has been or can be used for but what it is really designed to be good
at. To the extent that one extends beyond the hard core of the basic objective,
one finds the language may be more general and may be useful to a larger
class of people than originally intended. Any inefficiencies which result from
such extended usage should not be blamed on the language.
The objectives of a language are usually stated in the terminology of
the intended users. Thus COBOL is described as business oriented, although
it is restricted to administrative and financial areas of business. An operations
researcher might expect that COBOL would be useful in solving scientific
problems associated with business planning, whereas COBOL was never
intended for use in that class of problems. The person who is concerned
34 FUNCTIONAL CHARACTERISTICS OF PROGRAMMING LANGUAGES

with choosing the best language for his problem or his installation is strongly
advised to consider not only the stated objectives but the frame of reference
for the terminology. This can usually be achieved by considering the techni-
cal features in the language.

11.3.2. Type oF LANGUAGE

In addition to being concerned with the application area for which

a language is designed, it is necessary to consider the type of language within
the classifications described in Section 1.6. Obviously, a language can fall
into more than one of these categories. In fact, a person interested in cate-
gorizing a language can, in the manner of a Chinese menu, choose one from
each of columns A, B, and C and choose any number from column D, al-
though there do not exist languages for every possible combination.

A B C D
procedure-oriented problem-defining hardware problem-oriented
nonprocedural problem-describing publication application-oriented
problem-solving reference special purpose

11.3.3. Type oF USER

In designing a language, considerable attention must be given to the

kind of user for whom the language is designed. We can separate two very
broad classes—namely, professional programmers and, in contrast, people
who have a problem to be solved and must program it but consider their
profession to be the field in which the problem arose. If the objective is to
help the latter category (who will be called nonprofessional programmers),
then considerable effort must be made to make the languages easy to learn
and to use. Various tricks and quirks relative to the machine or even relative
to the language itself should be minimized, because the nonprofessional
programmer is more concerned with being able to state his problem easily
than he is with obtaining the maximum efficiency from a particular machine.
For a nonprofessional programmer, the distinction between writing the
program and reading it or using it after it is written is significant. It is well-
known that two of the major problems in administering any activity involving
programming are the need for program maintenance and the troubles arising
from personnel turnover. Thus one objective might be to make it very easy
for nonprofessional programmers (or for that matter, even professional
programmers) to pick up and understand somebody else’s program. For
example, one can envision a situation in which very succinct information
is fed into a compiler and much more elaborate and detailed information
 II.3. PURPOSE OF LANGUAGE 35

is put out, so that the program becomes easily understandable to a wide varie-
ty of people. (This has actually been done by developing the Rapidwrite
system for COBOL—see Humby [HY62], [H Y63].)
In the case of a language designed for use by a professional programmer,
a major characteristic is to provide maximum capability. In other words,
the programming language can and should aim at relieving the professional
programmer of many annoying details but still provide him with great flexi-
bility. Thus, for example, he should have some very nice way of stating the
beginning and ending points of loops and the increment to be used, but
he may want a large number of ways of specifying or controlling the loops
(e.g., incrementing or decrementing, varying several parameters in one state-
ment). In the case of the nonprofessional programmer, he may be satisfied
with one relatively simple way of handling this particular facility. Similarly,
the professional programmer will almost always want to be able to get at
the machine code. No programming language to date has been designed
so well that the professional programmer has been completely satisfied with
it; there are always things that he wants to do that seem to require resorting
to machine code. This facility does not generally interest the nonprofessional
programmer.
One other feature in considering this distinction between the profes-
sional and the nonprofessional programmer is in the type of debugging aids
that are made available. These are discussed in somewhat more detail in
Sections [1.5.5.3 and III.7.5, but it should be pointed out here that a pro-
gramming language which requires a nonprofessional programmer to under-
stand machine language in order to debug his higher level language
program is not much help. Only if the debugging can take place at the source
language level is he really aided. On the other hand, in very tricky cases
the professional programmer may want the ability to get memory dumps
and to examine contents of index registers. This is particularly true if the
language does not provide really good debugging aids.
In attempting to aim a language at a nonprofessional programmer,
one can give strong arguments for making the language as natural as possible.
In other words, if the user is concerned only with solving the problem, he
will presumably prefer to communicate with the computer in the language
which is most natural to him. He is not necessarily concerned with all the fine
points that the professional programmer wishes to be able to control. The
issue of what is meant by natural and how much is desirable and feasible
is a hotly debated one. (See Sammet [SM66b], Halpern [HL66], and Dijkstra
[DJ63] for further discussions of this point.)
An issue of vital concern to the nonprofessional is the amount of
“nonlanguage” material he must learn. Since the compilers are usually
part of an operating or time-sharing system, the user can seldom just “write
his program”. He ts often required to worry about such things as control
36 FUNCTIONAL CHARACTERISTICS OF PROGRAMMING LANGUAGES

cards, form of his object deck, etc. A discussion of these problems is beyond
the scope of this book.

11.3.4. PHysicAL ENVIRONMENT

A major defining purpose of a language 1s the physical environment

in which it is to be used. The most significant distinctions existing today
are between batch and on-line systems. However, on-line systems can be
further subdivided into those which are tru/y conversational and thus permit
significant man-machine interaction and those which are merely time-sliced
and provide only some additional facilities to an inherently batch-oriented
language. (There are actually many levels of gradation of these concepts.)
There is also a possibility that the language may be intended for use in real-
time situations. The actual size of the computer may be relevant since some
languages are clearly aimed at maximum effectiveness on large computers,
while others may be intended for small machines. The possibility of mul-
tiprocessing configurations could also affect the language.

11.4. CONVERSION AND COMPATIBILITY

Of all the characteristics of programming languages about which there has

been great confusion, the subject of compatibility and its associated factor
of conversion rank very high. These characteristics are of prime importance
from a management point of view, although they may be of very little concern
to the programmer himself. In some cases, the characteristics provide the
deciding factor in determining what languages should be used. The reason for
the importance of compatibility and conversion is easy to understand as
soon as one realizes that the investment in programs for a particular machine
may run into millions of dollars. In particular, by now the costs of program-
ming tend to equal or, in some cases, even exceed the actual cost of the hard-
ware. Thus, it 1s no light matter to ignore the question of what happens to
the programs if one wants to change machines. Hardware technology does
not stand still and is continually improving. This means that users can gener-
ally improve their economics by obtaining new equipment which permits them
to do the same jobs faster or cheaper, or both. However, the decision to obtain
new machines is usually influenced very strongly by the prior investment in
programming. Thus, if a large amount of money has been invested in pro-
grams which cannot be run on a new machine, it becomes necessary to think
very long and hard before obtaining new equipment, even though the new
machines could certainly do the job faster and cheaper. The timing cycles of
hardware and software development are such that by the time an installation
has its programs running satisfactorily on one machine, the manufacturers
 1.4. CONVERSION AND COMPATIBILITY 37

have usually come up with new and better hardware. There has been a great
deal of misinformation and misunderstanding on what is meant by compat-
ibility and what types of conversions are possible and meaningful. It is
the purpose of this section to try to clarify these issues.

11.4.1. Types oF COMPATIBILITY

1. Machine Independence

The first type of compatibility that people are concerned with is compat-
ibility across machines, i.e., how dependent on a particular machine or class
of machines Is a given programming language. Clearly, if the programming
language makes reference to hardware that is unique to a given machine
(e.g., sense lights, backward-reading tapes, and discs), then there is no hope
that a program written in this language can be directly handled on a machine
without these features, unless they are simulated; this is usually prohibitive in
cost. Similarly, if the language—as a language—makes particular use of the
fact that the machine 1s fixed word length versus variable word length, binary
versus decimal, or has a particular number of bits or characters per word, then
again there is no chance of having the program directly transferable to anoth-
er machine. A partial solution to this problem is to allow the user to state
in his program the precision he requires. (This is done in PL/I.) However,
this 1s a double-edged sword because the user may pay a heavy penalty
for the inefficiency caused by a precision which is grossly disparate from the
word size, e.g., specifying 11-digit precision on a computer with 10 decimal
digits per word. If the user is aware of these factors, he can make a more
intelligent choice.
Clearly if a language makes use of the hardware characteristics of a
specific computer, programs cannot possibly be directly compatible, i.e.,
directly usable on another machine. There might be exceptions to this but they
would depend on very clever programming on the part of the compilers,
and this has not yet been done. The true definition of machine compatibility
is the ability to take a deck of cards, or whatever other input media is used,
insert it into a different type of computer (1.e., not one “in the same family”),
and have the program run and produce the same answers. Anything less
than that capability is a partial or pseudo type of compatibility. We have not
yet achieved this facility for the languages, let alone for the extra information
required by the operating system.
Two of the machine features which tend to “ruin” compatibility most
are word size and collating sequence; actually both of these could be cor-
rected by the compiler—but at prohibitive cost. The word size affects the
precision and sometimes even the actual results of numeric calculations
38 FUNCTIONAL CHARACTERISTICS OF PROGRAMMING LANGUAGES

because numbers are usually stored in one or two machine words. Thus,
unless the actual number of characters (or bits) to be used is specified (and
implemented by the compiler), the arithmetic results will differ from machine
to machine whenever the word lengths are different. In many cases this does
not have a practical bad effect, but the potentiality is certainly there. In
the case of the collating sequence, the situation is actually worse because
incorrect results are easily obtained as a result of branches which operate
differently. If the collating sequence on one computer places letters before
numbers, but this is reversed on another machine, then any test of data based
on this sequencing information will produce opposite results in going from
one machine to another. Again, this could be corrected by having the lan-
guage specify the collating sequence and require the compiler to turn out
the correct code, but nobody has yet been willing to do this because of the
tremendous cost at object time.
Other facets of the data base problem, such as wordmarks, fixed versus
variable length words, and general record layouts, cause incompatibility.
This difficulty exists independently of the language characteristics.

2. Compiler Independence

It is clear that when one talks about machine independence, there is

an implied reliance on the ability of compilers to do the same things on dif-
ferent machines. In other words, a statement in the programming language
that causes an addition to be performed must be translated into the proper
instructions on all machines. That is quite obvious; what is not so obvious
is the amount of incompatibility which can actually be engendered by the
compilers themselves even on the same computer. One of the best examples
of this is the situation in which a compiler accepts and correctly handles a
statement which is not really legal in the language, but which is certainly
meaningful to anybody using the language; e.g., one of the early FORTRAN
compilers correctly translated a certain type of implied multiplication. What
happens in cases like these is that people tend to write programs knowing
the characteristics of their particular compiler, and they are in for a rude
shock when the same problem is translated by another compiler.
A second kind of incompatibility caused by compilers 1s much more
subtle and, therefore, much more difficult to track down. Because of the lack
of precision in defining programming languages, there are often ambiguous
rules relative to the meaning of certain statements in the language, and
every compiler writer must make a decision on how to interpret such state-
ments. This is bad enough, but what makes it even worse is that in many
cases the ambiguity is not even recognized as such. Thus two people looking
at a statement or sequence of statements in the language definition may,
in all good faith and in all clear conscience, come up with two entirely dif-
 II.4. CONVERSION AND COMPATIBILITY 39

ferent views of what is meant. On top of that, neither person may even
recognize that an alternative view is possible, until it is pointed out to him.
This causes the compilers to be incompatible in the sense that two different
compilers may accept the same source statement and not only produce
different object code but, more importantly, cause the source programs to
produce different results. Unfortunately there is no way around this incompat-
ibility until better means of defining languages are developed. It is because
of this problem that many people have taken the view that the only complete
definition of a language is a compiler for the language. My personal view
is that this is so impractical that I prefer the unpleasant alternative of admit-
ting that we do not yet know how to define programming languages rigorous-
ly.

3. Dialects and Language L-Like

One of the most difficult problems in the question of compatibility has

to do with the existence of dialects. A dialect means a minor variation on
a particular language. These variations may exist for any number of reasons.
One group may feel that they can obtain a more efficient compiler if they
simply make a minor change in the rules. An illustration of this involves
naming conventions, whereby the language definition may not require data
names and/or statement labels to start with a letter, but some particular
compiler writer may decide that his efficiency can be improved by an order
of magnitude if he imposes such a restriction. In other cases, minor devia-
tions may occur because one group does not like the actual notation used
by the language designers and substitutes a different one. The most common
reason for dialects is that for any language there is almost always somebody
who feels he can improve the language by making certain additions and/or
changes. A more laudable motive is the creation of modifications to meet
the needs of a particular application. It 1s important to notice that the diffi-
culty usually arises more from changes than from additions or restrictions,
although the latter two also present problems and are discussed in the next
section.
The phrase language L-like is frequently heard; it usually refers to a
language which is similar in spirit and notation to language L, but differs
from it markedly enough not to be considered a dialect. The deviations usual-
ly involve (1) some changes in notation, (2) some omissions of features
or some restrictions, and (3) some additions. As an illustration, LISP 2
(see Section VIII.6) is described as being an extended ALGOL-like language.
The prime distinction between being a dialect and being language
L-like is one of degree. If there are only minor variations, then the word
dialect is appropriate. Unfortunately, there is seldom universal agreement on
how minor the variations really are.
40 FUNCTIONAL CHARACTERISTICS OF PROGRAMMING LANGUAGES

4. Subsetting and Extensions

The issue of subsetting differs significantly from that of the dialects,

in the sense that dialects involve changes, whereas subsets imply incomplete-
ness but presumably no changes. Strictly speaking, a subset is a type of
deviation but usually one that is less severe in its implications for compati-
bility.
A language S is considered a proper subset of a language L if (1) there
are some programs which can be legally written in L which cannot be legally
written in S, (2) all legal S programs are legal L programs, and (3) the results
from a program written in S when executed with an S compiler are the same
as the results obtained from an L compiler on the same machine, except
for those aspects which are implementation dependent. Subsetting obviously
permits upward but not downward compatibility. That is, by definition,
programs written in S must run on L compilers, but the converse is not
true.!
Subsetting may take a number of forms. One is simply the nonability
to handle a certain class of features in the language. For example, if a
language allows both double and single precision, a subset of the language
might not allow double precision. Another form is to omit certain special
cases in a general feature; e.g., the subset might omit double-precision in-
tegers but not double-precision floating points. Another type of subsetting
involves placing additional restrictions that the language itself does not have,
such as requiring data names to begin with a letter, although the language
may not require this.
The primary motivations for subsetting are cost and time. Subsets permit
smaller compilers, which can be developed more cheaply and/or more rapidly.
Furthermore, subsets tend to compile faster.
Problems with regard to compatibility arise when nonnested subsets
exist. In other words, if there are several subsets of a given language, and there
is no hierarchy among them, then there is chaos for the user who tries to move
from one subset compiler to another. Clearly, if the overall language contains
features A, B, C, and D, and Compiler 1 eliminates feature A and Compiler
2 eliminates features A and B, then a hierarchy exists which permits upward
compatibility. On the other hand, if Compiler | eliminates feature A, whereas
Compiler 2 eliminates only feature B, then there is no relationship between
those two compilers. They can only be related back to the main compiler
which is implementing the entire language. Thus, nonnested subsets will
always lead to lack of compatibility among implementations of each other.
One interesting facet of subsetting occurs when the language is imple-
mented by bootstrapping, which means that a translator for a subset of the

1 This definition was essentially suggested to me by E.F. Codd.

 1.4. CONVERSION AND COMPATIBILITY 41

language is coded in machine language and the compiler is written in this

subset of the language. This can be done only for certain languages. Some-
times more than one level of subset is required to create the full compiler.
A language F is an extension of a language L if L is a subset of E. Types
of extensions might be the provision of additional facilities, such as new
variable types and commands to handle them or removal of restrictions
(e.g., on the ways in which data names can be defined). If L is the prime
language under consideration, then the existence of its extension, namely
E, is of no concern to the users of L. If E is a proper extension of L, then
the compiler for £ should accept legal programs written in L and produce
the correct results. Unfortunately this is seldom true in practice and, after
extending L to produce E£, restrictions are usually placed on L programs,
regardless of whether or not they use the additional facilities of the E language
(compiler). This happens because extending a language is seldom easy and
almost always requires some change—albeit minor—1in the original language.
A common occurrence is to start with a language L, create a subset
of it (called S), allow some minor deviations (say S’), and then put in some
extensions which are not in L (say S’+). The result is an L-like language.
If S’+ is significantly smaller than L, then it is really an L-like extended
subset and this term will be used throughout this book.

5. Relation to Language Definition

Many of the problems of compatibility are caused by the current in-

ability to define languages in a complete and accurate fashion. A good start
has been made on defining the syntax of the language, but only a little effec-
tive work has been done in defining semantics and virtually no work in defin-
ing pragmatics. These terms will be discussed in more detail later. The crucial
point is that the lack of compatibility across compilers and very often across
machines is related to the fact that the language definition may not have been
completely rigorous or understandable.

11.4.2. EASE OF CONVERSION

1. Based on Compatibility

As indicated earlier, there is great motivation to ease the conversion of

programs from one computer to another. The best way to do this is to main-
tain complete compatibility between a language acceptable to one machine
and the same language handled on another machine. Acceptability can be
achieved by hardware or software or a combination of both (i.e., emulation).
In that case, the conversion problem is negligible. Achieving compatibility
is one of the strongest motives for writing programs in a higher level
42 FUNCTIONAL CHARACTERISTICS OF PROGRAMMING LANGUAGES

language. Unfortunately, languages tend to change somewhat when imple-

mented on new machines for reasons indicated above, thus reintroducing
the dialect problem. The relevant factor becomes the amount of difficulty
that is involved. If only small changes are necessary to make the program
run on a different machine, then there has been a large amount of compati-
bility preserved and the conversion is very easy. On the other hand, if major
changes and difficulties are encountered, then the conversion is difficult.
(This is not meant to imply that conversion of programs from one machine
to another is the only factor in changing machines. However, it is the only
aspect under discussion here.’)

2. Ease of SIFTing to Another Language

The term S/FT stands for Share Jnternal FORTRAN Translator and
was first used in connection with the program to go from FORTRAN II
to FORTRAN IV on the 709/90/94 (see Allen, Moore, and Rogoway
[AX63]). In the development of FORTRAN IV, great attempts were made
to make FORTRAN II a proper subset of FORTRAN IV. However, there
were cases in which this was not possible, either because it would place too
great a restriction on the new version of the language or, in other cases,
because people had taken strong advantage of what the compilers of
FORTRAN II would do and these nonlanguage facilities were not applicable
to the larger and newer compilers. The term sift became used fairly generally
to refer to the partial translation of one higher level language to another
one which is fairly similar. This normally means the automatic conversion
of equivalent language elements and flagging the others for manual conver-
sion. This is a type of conversion, which again is dependent for its ease on
the amount of sifting which can be done. A particular illustration—namely,
of ALTAC to FORTRAN II—is described by Olsen [OL65].

3. Ease of Translating to Another Language

In the worst case, one may be faced with the problem of trying to have
one language, which has been implemented for a particular machine, trans-
lated into the form of another language for another machine. It is of course
assumed that such a translation will preserve the high level characteristics
of the original program and will not cause severe degradation of the even-
tually resulting object code. An almost useless translation (from an effici-
ency viewpoint) occurs when a less powerful language is translated on a
statement-by-statement basis to a more powerful one. This has actually
occurred in translating from powerful assembly programs (Autocoder)

2 See Datamation, Vol. 12, No. 6 (June, 1966) for several papers on this subject.
 11.5. STANDARDIZATION 43

to COBOL. It is an interesting—and as yet unsolved—problem as to what

general characteristics of languages are needed to permit one to be trans-
lated into the other automatically without severely losing the efficiency of
the original source program. The ease of conversion is dependent upon how
easily—if at all—this translation can be made.
One of the reasons for wanting an effective translation is that the newer
machine may not have available on it a compiler for the earlier language.
A second reason occurs when the installation managers wish to have every-
thing coded in the newer language and, therefore, want to have the old
programs translated automatically.

11.5. STANDARDIZATION

One of the key factors in the definition and use of a programming language
is the role played by standardization. The purpose of this section is to de-
scribe the purposes and problems in standardizing programming languages
and the procedures that are involved and to give a brief status report. More
details about the latter are shown in the individual language descriptions.

II.5.1. PURPOSES

The basic purpose of standardizing programming languages is to achieve

compatibility, which in turn reduces costs. Compatibility in programming
languages permits savings in training personnel because they do not need
to learn a new language. It also permits savings in documentation because the
number of new manuals that must be written is sharply reduced. Standardiza-
tion also minimizes—although it does not eliminate completely—the problem
of converting to new computers. (This assumes that a standard language
is implemented for a new set of machines.)
Even assuming a language standard exists, there is a management prob-
lem in enforcing the standard. This is not significantly different from the
problem of enforcing any standard or set of conventions in a programming
organization.

II.5.2. PROBLEMS

There are three main problem areas in standardization: Conceptual,

technical, and procedural. It should be recognized that the conceptual and
procedural problems are not unique to programming languages; they apply to
most technology.
44 FUNCTIONAL CHARACTERISTICS OF PROGRAMMING LANGUAGES

1. Conceptual Problems

The first conceptual problem is one of timing; 1.e., when should stan-
dardization of a language take place. Unless this is given careful considera-
tion, it is likely to come too soon or too late. If it 1s too soon, then the
standardization is premature; it is not clear what is needed, and there is a risk
of standardizing on a number of things that really are not very good. On the
other hand, if standardization is delayed too long, then there are dialects—
admittedly some of them very minor changes—and this in turn creates a num-
ber of vested interests which are reluctant to accept a standard which
deviates from their particular version.
A second conceptual problem is the risk of stifling progress. Somehow
the standardization process must avoid eliminating or preventing technical
progress. This is extremely difficult because there is no easy way of coping
with new and bright ideas if they come in after the standard is established,
or even while it is in the process of being established. An excellent example
of this arose in one subcommittee meeting which suggested a somewhat bet-
ter method for handling the proposed revised ASCII code. Unfortunately,
too much work had already been done by too many people to permit the
change, even though several groups agreed it was an improvement.

2. Technical Problems

The first technical problem in standardization is one of definition.

We do not yet know how to define a programming language rigorously.
No completely formal method exists, even for the purely syntactic defini-
tions, although tremendous strides have been made along these lines. There
are only beginning attempts at defining semantics rigorously, and no effort
has been made toward coping with the problem of pragmatics. (These terms
are defined in Section I1.6.2.) A verbal description is inadequate (although
used) because the English language is ambiguous and it is impossible to spell
out every possible contingency or interpretation. Some people would cope
with this problem by accepting the processor (i.e., the compiler) as the basic
definition of a language. This might work satisfactorily if there were only
one processor per language, but that clearly is not the case. It is certainly
not feasible to say that the first compiler written will be the formal defin-
tion of a language. Even if that were done, or some other compiler were
chosen, there would still arise the problem of requiring everybody to inves-
tigate the details of the compiler coding to find what a particular issue meant.
In some cases this would still not provide a complete definition for the entire
language.
A second technical problem ts to try to determine when a compiler (or
 11.5. STANDARDIZATION 45

a program) actually meets the standards. Since we do not have a completely

rigorous definition of the language, we clearly do not have a rigorous way
of testing whether or not a given compiler meets that language specification.
Even if we accept the unfeasible alternative that a particular compiler will
define a language, this still does not tell how to determine whether another
compiler actually meets the language specification. The use of test problems
is definitely not the answer because a particular compiler could easily be
designed to meet the test problems but still be very far from the standard.
A third technical problem is to determine how to do maintenance in an
orderly way and still not invalidate the compilers. This is tied in with the prob-
lem of the language definition because most of the maintenance involves
clarifying unclear points. The difficulty that arises here is the one pointed
out in Section II.4.1.2—namely, two different groups may have implemented
a particular point differently without even realizing that there was another
possible view on what they were doing. Once there is a large amount of money
invested in the implementation, it is very difficult to persuade any one group
to change its view on what should be done. Since in many cases maintenance
also involves extensions, these have to be looked at very carefully in the light
of present implementations. Certain extensions could invalidate all compilers
written for a particular language, even though the extension was extremely
desirable.
A fourth technical problem is the one of subsetting, which was discussed
earlier in Section II.4.1.4. Since a standard must achieve wide acceptance
in order to fulfill its purpose, a highly complex language may reduce the
number of groups which can implement the standard. On the other hand,
reducing the level of the standard to the smallest computer will lower the
value of the standard considerably. The best solutions for this problem seem
to be controlled subsetting and/or modularity of features.
The last technical problem is the multiplicity of standards for program-
ming languages. It is preposterous at this point and in the near future to
consider standardizing one language for all programming. The best we can
hope for is one language for each major application area and some languages
(e.g., PL/I) which cover more than one application area. However, it is impor-
tant to notice that FORTRAN and ALGOL were both standardized; yet
they covered very similar application areas, namely, the solution of scien-
tific numerical problems. The reason for the two standards was quite simple;
there were large investments in both languages, and neither group was willing
to retreat and disclaim all interest in having its language become standardized.
Thus, there has been a necessary regression from the mythical ideal of one
programming language standard to one for each major application area,
and a further regression to merely standardizing any “suitable” language
to prevent dialects of it from being developed and used.
46 FUNCTIONAL CHARACTERISTICS OF PROGRAMMING LANGUAGES

3. Procedural Problems

The procedural problems in establishing standards are enormous,

but this is necessary to prevent the promulgation of undesirable standards.
In this context, undesirable merely means not acceptable by virtually all
the groups to whom the standard will apply. The complexity of the pro-
cedures—which have been established to protect the rights of all those in-
volved—of necessity delays the establishment of a standard. This often causes
difficulty to those groups who are at a stage in their technological or manu-
facturing development where they are ready to implement the standard,
but it does not exist officially and may yet be changed.

11.5.3. METHOD OF ESTABLISHING STANDARDS

Most standards are adoptions or rework of existing practices. Some come

into being through a specific committee which does developmental work
and announces at the outset that their result 1s to be a standard of some
kind. (This was done with COBOL.) Other standards become what are called
de facto standards—i.e., they are so commonly used that by general agreement
and general practice they are a standard, even though no formal mechanism
whatsoever has been used to establish them as such. In most of these cases,
however, although there may be widespread agreement on the basic item,
there are almost always deviations which must be eliminated from an actual
standard. (FORTRAN is an illustration of this situation.) There is a very
formal and specific procedure for establishing official standards, and this
section will discuss this procedure in some detail.
The authority for industrial standardization in the United States is vested
in the United States of America Standards Institute (USASI), which replaced
the American Standards Association (ASA) in August 1966. Obviously
any group, e.g., government, professional societies, and user groups, can
(and does) standardize anything, but USASI 1s recognized as the central and
official source of activity for any type of industrial standardization in the
United States. Unlike European countries, standardization is a voluntary
process in the United States. Thus, nobody is obligated to obey a standard
just because it exists; whereas, in many European countries, once a standard
exists, it is a government regulation and must be followed. There are a num-
ber of factors which are relevant to the standardization process under USASI
and which are independent of programming language standardization per
se. It is worth noting these, so that the problems and procedures for program-
ming language standardization can be seen in perspective. (A more detailed
description of the procedures is given by Goodstat [GS67] and Steel [ST67].)
The USASI provides an elaborate structure with built-in checks to pre-
 1.5. STANDARDIZATION 47

vent “railroading” of anything as a standard; a broad basis of participation

is required both to do the work in establishing the standard as well as to
approve it. A consensus among all interested parties is required before some-
thing is approved as a standard, and a consensus is much more than a mere
majority. If a significant-sized minority objects to a standard, then it is
normally sent back for rework. It is characteristic of USASI in particular
(and most organizations in general) that if they provide an elaborate struc-
ture of the kind just indicated, then of necessity the committee procedures
and regulations will be long and complicated. In addition, there is also an
international standards organization which has different rules from USASI,
and groups in the United States usually wish to satisfy both standards organi-
zations.
The USASI normally asks some group to sponsor work in a particular
area. This is usually a trade association or similar group. In the case of the
computing industry they asked BEMA (Business Equipment Manufacturers
Association) to provide sponsorship. Thus, BEMA established the sectional
committee X3, which in turn established seven technical working commit-
tees as follows: (1) Optical character recognition, (2) coded character
sets and data formats, (3) data transmission, (4) common programming
languages, (5) glossary, (6) problem description and analysis, and (7)
magnetic character recognition.
The charter of X3.4 (which was formed in 1960) is “Standardization of
common programming languages of broad utility through standard methods
of specification, with provision for revision, expansion and improvement,
and for definition and approval of test problems”. At the time of this writing,
X.3.4 has established eight subcommittees. A list of these follows, with
a brief indication of the function and purpose of each subcommittee.

X3.4.1. Language theory. This committee has been dormant for a

long time but was responsible initially for investigating some of the technical
problems associated with standardization.

X3.4.2. Language specifications. This committee is concerned with

miscellaneous activities, which includes deciding what languages are appro-
priate candidates for standardization and the criteria involved. These tasks
are not as easy as they sound due to the need for being concerned with a
large number of vested interests. This committee also has the responsibility
for reviewing an actual proposed language standard for X3.4.

X3.4.3. FORTRAN. This committee defined the standard FORTRANs

and is responsible for their maintenance.

X3.4.4. COBOL. This committee is responsible for the definition of

the standard COBOL and for its maintenance.
48 FUNCTIONAL CHARACTERISTICS OF PROGRAMMING LANGUAGES

X3.4.5. ISO/TC97/SC5 secretariat and USA participation. This com-

mittee handles interaction with the international standards organization:
SC5 is roughly the equivalent of X3.4 at the international level.

X3.4.6. Glossary. This committee is responsible for determining and/or

reviewing glossary items which are particularly relevant to the subject of pro-
gramming languages.

X3.4.7. Machine tool control. This group was actually the latest
formed; it did not come into existence until the latter part of 1964. It is con-
cerned with the development of standards for machine tool control.

X3.4.8. ALGOL. This was actually a sub-subcommittee under X3.4.2

and was eventually formed into a subcommittee in its own right.

The main work of X3.4 has been in deciding what languages to try to
standardize and then actually attempting to do it. Because the maintenance
and definition are different for each language, the procedures need to be dif-
ferent.
Once X3.4 has created a proposed draft standard, it is submitted to the
parent body, X3, which arranges for its publication and wide distribution.
A period of approximately 6 months is then allowed for commentary by any
person or organization whatsoever. Following (and sometimes during)
this period, a ballot is taken according to USASI rules and procedures and,
based on that ballot, either the proposed standard is sent back to the commit-
tee for rework or it is submitted to the Information Processing Systems
Standards Board (IPSSB) for its determination that the proper procedures
were used and a consensus really exists. In almost all cases, IPSSB provides
final approval of the standard. (There is a still higher group, but it is seldom
needed.) Once the standard becomes promulgated, it is then recognized
as an American standard. Again it must be emphasized that adherence to
this standard is completely voluntary on the part of any organization. Experi-
ence to date has shown that such standards do play a very significant role
in the activities of computer manufacturers.

11.5.4. OVERALL STATUS

The descriptions of each language indicate the status of the standardi-

zation for that language and the process that was involved.

11.6. TYPES AND METHODS OF LANGUAGE DEFINITION

Fortunately or unfortunately, language definition is an administrative as

well as a technical issue. Many factors discussed below play an important
role in the creation, development, and usage of the language. These aspects
 11.6. TYPES AND METHODS OF LANGUAGE DEFINITION 49

tend to be ignored or misunderstood but they play a vital role in the overall
consideration of the language.

11.6.1. ADMINISTRATIVE

1. Who Designed the Language?

The first administrative question to be asked about any language is:

Who designed the language? Also, how was the group constituted? Who
was the sponsor or directing authority? What kind of pressures were they
under? Several languages have been designed by committees, where the com-
mittee consisted of participants from a number of organizations. This 1s not
necessarily bad since even when a language is designed within one organi-
zation, it is normally designed by more than one person and this group
could also be called a committee. It is not at all clear whether a committee
composed of people from different organizations fares significantly worse
than one formed solely within an organization. The main reason for this
is that current and past language design has been based very much on per-
sonal opinion, rather than just on fact or objectivity. Many of the properties
described in Section II.2 mean different things to different people, and cer-
tainly the method of applying them is nebulous. Language design is an art,
not a science. Furthermore, as in any endeavor, language designers also
tend to use their past experience even though it is not always applicable to the
current situation. The one factor that pervades intercompany language
design which generally does not affect intracompany work is a number of
political considerations. In particular, an intercompany committee may
have on it people who are under directives from their organization to try
to place into the language those features which are helpful to their equipment
(and possibly harmful to others) and, of course, to prevent the converse
from happening. These are all unfortunate facts of life which must be taken
into account in considering any language.

2. What Were the Objectives of the Language?

In examining any language, it 1s necessary to know the objectives. Just

as it would be silly to complain that an automobile is not a good device for
crossing an ocean, it is equally foolish to say that a language is a poor one
because it does not satisfy the person examining it. A language designed for
use by nonprogrammers may seem very loquacious or inefficient when viewed
by a professional programmer. Conversely, terminology or techniques that
are useful to a person with considerable programming experience may be
confusing or meaningless to a person who just wants to find answers quickly.
There are two legitimate questions which can be asked about a program-
ming language and its objectives. The most important is: Does the language
50 = FUNCTIONAL CHARACTERISTICS OF PROGRAMMING LANGUAGES

satisfy the objectives? The second is: Were the objectives worthwhile? The
first question is a very good one if it is applied honestly, and the prime cri-
terion of a good language is whether it achieves the goals specified for it.
The question about worthiness of objectives is a dangerous one. Using the
earlier analogy, a device good for crossing an ocean may be a silly idea to
someone who has no interest in moving off dry land. Too many criticisms
of programming languages tend to be made by people who have no knowl-
edge of, or interest in, the problem area; they insist that the objective is bad
when in reality they do not understand or care about it.

3. Who Implemented the Language?

The question of who implemented the language is another adminis-

trative facet which cannot be ignored. If the language is implemented by the
same people who designed it, then there 1s the greatest chance of success
because the language can be modified as the needs of the implementation
demand. Of course, a poorly conceived implementation design should not
be allowed to ruin the language by forcing unnecessary restrictions. There
are more difficulties when the implementation group differs significantly
from the language group and the latter must be consulted on every change
in the language. Making sure that the right kinds of interactions occur in both
cases is clearly an administrative problem. As mentioned earlier, very often
the definition of a language is not completed until the compiler is completed.
Implementation is normally done either by a group within one company
(usually a computer manufacturer, but sometimes a user with its own lan-
guage) or an outside software group (which is charged with the responsibility
for preparing a compiler for a particular machine or class of machines).
Even here, there are difficulties that depend on whether the implementation
for a given class of machines is under direct control at a low enough organi-
zational level to be effective. Thus, if a company has a class of machines
which are either similar or purportedly compatible in some sense, then the
question of how compatible the compilers are becomes another administra-
tive and management problem.

4. Who Maintains the Language?

The maintenance of a language is not the same as the maintenance of

a compiler or a program. The language maintenance is by far the stickiest
of the administrative problems. In some cases, the group who originally
designed the language retains the responsibility for its maintenance. This
maintenance has many facets, starting from answering the questions of the
implementers who do not understand a particular language specification to
responding to requests for changes on features that are difficult to implement
and, ultimately, making improvements and/or extensions to the language. As
 1.6. TYPES AND METHODS OF LANGUAGE DEFINITION 51

was true with the question of who designed the language, the maintenance
is sometimes done by an interorganization group and sometimes within
a single organization. However, when the maintenance of the language is
divorced from the implementation, a certain amount of chaos is likely to
arise. This occurs because the implementors usually need an immediate deci-
sion on what a particular point means; those who are maintaining the lan-
guage may not be ready to meet that week to answer the question; yet coding
must continue. Similarly, people who are pressing for improvements and/or
extensions to the language are apt to find a very responsive chord in the
maintenance group, but an unresponsive chord in the implementation group.
The latter will certainly resist improvements to the language if it invalidates
their compilers. Thus, if the maintainers of the language are significantly
separated from the implementers, they may make changes and/or decisions
and/or improvements which seriously affect the implementation. Even
if the two groups coincide, the thorniest of all the administrative problems
is to decide when to allow the language to be significantly improved, at the
cost of much compiler rewriting.

11.6.2. TECHNICAL

The technical issues in language definition are, of course, the very heart
of determining what the language actually is, 1.e., what its specifications are.
These issues are often mixed up with the notation (metalanguage) of the
definition, i.e., the actual way in which the language definition is written down
on one hand, and the questions of the rigorousness of the definition of the
syntax, semantics, and pragmatics on the other hand. In my opinion, too
much of the discussion of the actual features and qualities of a language
centers around the way in which the language is defined. While obviously
a poor and unrigorous definition makes it difficult if not impossible to deter-
mine what the language specifications really are, it should be kept in mind
that the language and the means of defining the language are not the same
thing. It is for this reason that the discussion of the technical methods of lan-
guage definition are included in this chapter, even though they are definitely
technical and this chapter is purportedly concerned with nontechnical charac-
teristics of programming languages. I would go even further and say that
many of the nontechnical problems exist because the computing community
has not yet solved satisfactorily the technical problems of defining program-
ming languages rigorously.

|. Syntax, Semantics, and Pragmatics

The three characteristics of a language definition are syntax, semantics,

and pragmatics. (These are discussed specifically by Zemanek [ZE66] and
52. FUNCTIONAL CHARACTERISTICS OF PROGRAMMING LANGUAGES

were largely the subject matter of the 1964 IFIP working conference, whose
proceedings appear in Steel [ST66a].
By syntax we mean a rigorous statement of what sequences of charac-
ters are considered correct in the language and, ultimately, what character
sequences constitute a (syntactically) legal program. Thus, the syntax could
specify that the sequence A + B is legal; whereas the sequences +AB or
A+B are not allowed. On the other hand, a different language might say
that the second or third (or both) of these was legal; whereas the first was not.
In any case, the syntax simply specifies the legitimate strings in the language.
The meaning of the string is determined by the semantics. Thus, for example,
the string A + B might mean addition if A and B were numbers; whereas
it might mean union if A and B were sets or logical conjunction if A and B
were truth values. Clearly, a single legal string can have a great many mean-
ings; the collection of all these meanings for each legal string is called the
semantics of the language. The pragmatics is the relationship of these strings
and their meanings to the user. Thus, the user himself must understand and
appreciate what is meant by arithmetic, set union, and logical conjunction.
Furthermore, there must be agreement between his intended use of a string
of symbols and its actual semantic interpretation by a compiler.
The following statements appear to be true: (1) There is sometimes a
hazy line between what is syntax and what is semantics; e.g., the rule that
the number of subscripts on a variable in FORTRAN must agree with the
information in the DIMENSION statement can be considered both syntactic
and semantic, although it is primarily syntactic. (2) There is no notation yet
developed which will express completely unambiguously all the syntax of a
programming language, even if there were agreement on what was purely
syntax. (3) Little work has been done on formalizing semantics, although
the work of the IBM groups in Hursley, England and Vienna, Austria has
made a good start on PL/I (see the reference lists at the end of this chapter
and Chapter VIII for numerous reports). (4) Nothing has been done about
formalizing pragmatics. Thus, the problem of rigorously defining a lan-
guage—assuming there is an intuitive idea of what the language should
be—is one in which a large amount of technical work needs to be done.
However, significant work in providing formal notation for syntax has been
done and has helped the language definition problem enormously. See Floyd’s
survey [FL64] and the other items in the list of references at the end of the
chapter.

2. Formalized Notation

Since the English language permits numerous ambiguities, it is desirable

to provide a formal or rigorous method for defining programming languages.
Considerable work has been done to provide such formalism for the syntax,
 II.6. TYPES AND METHODS OF LANGUAGE DEFINITION 53

but very little work has been done for the semantics; hence, the latter will
therefore not be discussed at all.
A complete discussion of the formalized notations used for describing
programming languages is beyond the scope of this book. However, the basic
principles can be stated rather simply. This whole area is the major interface
point between artificial languages and the work of linguists concerned with
natural languages. Further details can be found in the references in Floyd’s
paper [FL64].
To define a language, some language must be used for writing the defini-
tions. This latter is called a metalanguage. It is a general term which can
include any formal notation or even English itself. Metalanguage is a relative
term since it is itself a language which must be defined, and that requires
a metametalanguage. For the languages discussed in this book, we need only
be concerned about the single level of metalanguage.
The first, and still the most significant, contribution made in this area
was by John Backus in his paper [BS60] describing IAL (later called
ALGOL). After an informal description of the proposed language, Backus
states (page 129) “There must exist a precise description of those sequences
of symbols which constitute legal IAL programs... . For every legal program
there must be a precise description of its ‘meaning’, the process or transforma-
tion which it describes, if any ....” The second part of this objective has not
yet been carried out completely and successfully, although significant work
is well underway. The prime elements of the metalanguage are the concepts
of a metalinguistic formula or expression composed of metalinguistic vari-
ables (whose values are strings of symbols), a metalinguistic equivalence
symbol, and metalinguistic connectives. The metalinguistic variable (which
is also called a syntactic unit) normally has mnemonic meaning, although
this is not required; thus integer is a metalinguistic variable whose values
are the digits 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9. (Angular brackets < > are a com-
monly used notation for syntactic units.) The most important connectives
are or, concatenation (i.e., adjoining two strings to make one string), choice,
and optional. Not all these connectives are used in each metalanguage;
it is largely a matter of (1) personal choice and (2) structure of the language
being defined, as to which combinations are used. The concepts of recursion
within definitions and repetition of syntactic units are also widely used;
these are illustrated later.
The most common (although by no means the only) combinations of
symbols are those which have been used for the ALGOL 60 report (Naur
[NA60] or [NA63]) and for the COBOL report [US65].* In the former, com-
monly referred to as BNF for Backus Normal Form or Backus-Naur Form,
the metalinguistic symbols and their meanings are

3Citations are given in the reference lists at the ends of Chapters IV and V, respectively.
54. FUNCTIONAL CHARACTERISTICS OF PROGRAMMING LANGUAGES

Symbol Meaning
[= equivalence
< > surround metalinguistic variable
juxtaposition concatenation
| or
In the COBOL report,
Symbol Meaning
small letters metalinguistic variable
juxtaposition concatenation
{ } choice
[ ] optional
upper-case letters optional fixed words in language
upper-case letters underlined required fixed words in language
repeat previous syntactic unit

As a simple example using BNF (i.e. the “ALGOL metalanguage”), consider

the definition of an integer. We start by defining a digit by writing

<digit> := O0]1]/2/3]4/5161718]9

<integer> := <digit> | <integer> <digit>

The first line specifies that a metalinguistic variable called digit is one of the
characters 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9. The second line illustrates recursion
as part of the definition because it says that an <integer> is either a <digit>,
or an <integer> followed by a <digit>. A negative integer would be defined
by saying

<negint> := —<integer>

The following are integers (by the definition above):

3 32 0045 000000 2598600002 100900

Note that there is no limit stated on the number of digits allowed. From
the definition of negative integer, examples are

3 —32 — 000000 —05290600

but not

—32— —3—2

As a more abstract illustration, suppose

<ab> : (| * | <ab> )|<ab> <d>

<d> :; A|B|C|DIE
 II.6. TYPES AND METHODS OF LANGUAGE DEFINITION 55

Then the following are legitimate values for <ab>:

( (A
*))) *C
QE) QE))
() *)))ABCDE)ABCDE)
The following are not legitimate values for <ab>:

A A)

A( ABC)

((* *(
)x JE
Using the “COBOL metalanguage,” consider the following abstract
example:

integer K {Pipee| [bull] ...

where integer has the expected meaning, bibble represents a letter, bull
represents a digit, and the three dots ... indicate repetition of the immedi-
ately preceding syntactic unit, namely, bull, 1.e., digits. Note that it is the
syntactic unit which is repeated, not necessarily the individual value of the
unit. Then the following are legitimate values for the metalinguistic expres-
sion above (which is not actually given a name):

3K5 9KC3333

5B3259 AKAB

2KL 2B

Since the K is not underlined, it 1s optional. Note that in the first case it is
impossible to tell whether the K has come from the specific K, or from bibble.
In the last case, the B can be from either the bibble or from the AB. A lan-
guage with the characteristic that its strings can be broken apart in only one
way is called uniquely deconcatenable, and the example above defines a lan-
guage which is not uniquely deconcatenable.
56 FUNCTIONAL CHARACTERISTICS OF PROGRAMMING LANGUAGES

To show the difference between these two examples of metalanguages

more fully, each formula will be written both ways. The first one can be writ-

7
and the second as
ES}
<partial> := <integer> K <bibble> <bull> | <integer> K <bibble> |
<integer> K AB <bull> | <integer> K AB |
<integer> K B <bull> | <integer> <bibble> <bull> |
<integer> <bibble> | <integer> AB <bull> |
<integer> AB| <integer> B <bull> | <integer> B
<integer> KB

<full> := <partial> | <full> <bull>

The primary advantage to metalanguages similar to those used in the

ALGOL report is their ability to name a metalinguistic variable and use it
in a formula. The inetalanguages similar to those used in the COBOL report
do not have that facility. This often makes it very difficult to define certain
metalinguistic variables. On the other hand, in most cases where any compli-
cated choice is involved, the COBOL approach is simpler. However, the
COBOL approach involves two dimensions, while the ALGOL metalanguage
requires only one. A more detailed discussion of the differences between
the two general approaches is given in Sammet [SM6la]. A discussion of the
problems of two-dimensional syntax is given in Rochester [RT66].
While some readers may feel that such notation introduces undesirable
formalism, it certainly serves to eliminate a number of ambiguities. For
example, the following definition appears on page 5 of the COMIT Reference
Manual ([MT61]:

A name consists of a string of twelve or less characters chosen

from the letters of the alphabet, the numbers, an. period and hyphen in
medial position:

Characters for use in names:

ABC...2Z

012...9

_- except as first or last character

The question left unanswered by this definition is whether more than one
period and/or hyphen can appear in a name. Thus, it is not clear whether
or not A.B.C.D and A.B — C are legal names.
 II.6. TYPES AND METHODS OF LANGUAGE DEFINITION 57

The illustrations of metalanguages above should not be thought to

include all the major concepts. For other ways to define artificial languages,
see Gorn [GO6la] and Floyd [FL64]. However, the two above, and minor
variations of them, have proved to be most useful. They have also given
rise to the whole compilation technique known as syntax-directed compiling.
Very briefly, this is a method whereby languages are defined by providing
tables of their syntax and tables of the operations (e.g., convert to machine
code) which are to be performed on different syntactic units. Among the ear-
liest works along these lines were the independent efforts of Irons [IR61],
Glennie [GC60], and Brooker and Morris [BX62]. An overall description
of the technique of syntax-directed compilation is given by Cheatham and
Sattley [CH64].
In my opinion, if there is ever to be any hope of allowing users to define
their own artificial languages, it will most likely occur through the use of
formal methods of language description and processors which can accept
these definitions and either translate them to running code or interpret them
to produce answers directly.

11.6.3. TyPES OF DOCUMENTATION

It is a truism that a language or a program is only as good as its docu-

mentation. Without written specifications for an artificial language, there
is no language. The real problems exist in determining what type of documen-
tation should exist.
There are essentially four types of documentation for a programming
language. The first is the reference manual containing the exact specifica-
tions, using whatever metalanguage (including English) has been agreed
upon by the language designers. It is in this document that the real technical
troubles usually fall since, as discussed in Section II.6.2, there are-as yet
no Satisfactory techniques for defining programming languages rigorously.
The second type of document is a user’s manual, which can be tutorial
or introductory. Such manuals are usually replete with examples and often
omit many of the trickier points of the language. This usually causes the
individual who wishes to know all about the language to refer to the speci-
fication manual, which may be very difficult to read. In such a case, the tuto-
rial description has served its purpose, namely to allow individuals to learn
to use the language in a reasonable way but not necessarily with all the fine
points. Ideally, the tutorial manual would exist in stages, providing first
the most basic information and then progressing toward the most complex,
so that all points are covered.
The third type of document is written for a specific implementation
and often combines elements of the other two. Although ideally there should
58 FUNCTIONAL CHARACTERISTICS OF PROGRAMMING LANGUAGES

be no need for a new language description manual for each compiler, in

practice this has turned out to be necessary. Minor differences in implementa-
tion techniques or machines cause differences in such points as numbers
of variables allowed, precision of the arithmetic, special cases not handled,’
etc. Such manuals often contain information on how to write programs
most efficiently for the particular version involved. Sometimes the individual
implementation manuals are based on a more general manual which is as-
sumed to be the basic information. (See, for example, the IBM FORTRAN
manuals listed in the references.)
The fourth type of document is some form of summary or very short
(ideally 1-2 pages) document to be used as a ready reference by those rainiliar
with the language and needing only to refresh their memories. (See, for
example, the CPS summary in Section IV.6.5.)
For a general discussion of the problem of documenting programming
languages and the ways in which seven languages (ALGOL, COBOL,
COMIT, FORTRAN, IPL-V, JOVIAL, NELIAC) were documented,
see the series of articles edited by Yngve and Sammet [YN63a] and their
specific comments [Y N63]. In addition, there is a series of individual language
bulletins which have appeared independently and/or under the auspices
of the ACM SICPLAN Notices. The latter is an informal “news and notices”
bulletin edited by C.J. Shaw and has appeared monthly.

11.7. EVALUATION BASED ON USE

It is characteristic of the computer business that systems are often evaluated

on theory and personal preferences rather than on the basis of practical
usage. This is advantageous if the system is so obviously bad that nobody
ought to even try using it. Unfortunately, nobody has yet devised a fool-
proof way of making such judgments. It is always very easy—and much
more fun—to examine a language in an abstract condition that is independent
of its usage. This tends to relieve people of the problem of obtaining facts
to back up their contentions, and it allows them to operate continuously
in the realm of opinion. However, this is not the most effective way to pro-
ceed. It is essential that work be done to determine valid criteria for evalua-
tion based on usage, rather than on whim. We need to understand the
advantages and disadvantages of specific systems—evaluated against specific
objectives—so that mistakes can be avoided in the future.

II.7.1. AVAILABILITY ON DIFFERING COMPUTERS

The most obvious question for a prospective user is whether the language
has been implemented for his computer. The answers can range from yes
 IL.7. EVALUATION BASED ON USE 59

to in process now to never will be. Part of the evaluation of a language is its
availability and usage on one or more machines. If it has been widely imple-
mented, then there is more accumulated experience for both users and im-
plementers. There is also strong indication that the language has been used
successfully. If it has been available only on large machines and now is to
be used on a small computer for the first time, then certain new problems
will arise.
As discussed below, the usefulness of the language must be judged
independently of the compilers which implement it.

11.7.2. EVALUATION OF LANGUAGE VERSUS EVALUATION OF COMPILER

There are two ways of looking at a language—one is on paper and the

other is as implemented on a machine. In the first instance, an individual
can examine the language and decide whether or not it is easy for him to solve
his problem using that language. In making such an evaluation, he uses such
criteria as ease of learning, ease of writing, and applicability to his class of
problems. When he attempts to evaluate the implementation, however, he
has other characteristics he must be concerned with, such as rapidity of com-
pilation and effectiveness and efficiency of the object code which is produced.
Unfortunately, there are too many instances in which the evaluation of the
language is based primarily on the evaluation of the compilers. All too often
people say language X is no good, when what they really mean is the compiler
they are using for that language is very poor. Once the compiler is improved,
then their view of the language changes. It is extremely important to separate
these two aspects. (There are cases in which new languages received semi-
permanent black marks because the first compiler(s) for the language was
so bad.)
The two greatest criticisms of compilers are slow compilation and poor
object code. The latter can be considered bad because of slow running time
or large storage requirements or both. Secondary objections can be raised
about the diagnostics at compile or object time or both, inadequate listings
from the compiler, unavailability of load-and-go (i.e., compile and immedi-
ately execute), and poor debugging facilities. The language should not be
deemed poor unless it can be shown that its features would permanently
cause one or more of these faults. (This point is discussed in Section III.7.)

11.7.3. USAGE RELATIVE TO OBJECTIVES

The most important factor in evaluating a language is to compare its

achievements against its objectives. It is therefore necessary that the objec-
tives of the language be well understood before the language design begins.
60 FUNCTIONAL CHARACTERISTICS OF PROGRAMMING LANGUAGES

It is equally essential that prospective users understand the avowed objectives

of the language so that they do not try to use a language for the wrong pur-
pose. Unfortunately, the purposes are seldom clearly stated. Either they
are not realized when the language development ts started or the designers
try to claim too much for the language or else they try to claim a more sell-
able set of objectives than are actually intended or implemented. It is cer-
tainly fair to consider whether the objectives are worthwhile, but it is not
fair to complain about a language for not meeting some objective that was
never intended.
There are cases in which languages have been known to exceed their
objectives. One way in which this can occur is when a language becomes
useful outside its primary application area. The widespread use of
FORTRAN for a variety of problems that are not numerical scientific
makes it the outstanding example of this additional factor.

11.7.4. ADVANTAGES

Only after a language has been in use for a while can its advantages
be ascertained. The first thing to determine is whether or not it met its objec-
tives. If so, then the language can be considered to be successful. (The ques-
tion of whether the objectives were worthwhile is a separate issue and should
not be combined with the evaluation of the language.) However, there are
two other possible advantages which might exist. The first is that the language
may exceed its objectives by being useful for areas which were not originally
intended or by being particularly easy to implement or to learn (if these
were not part of the original objectives). A second advantage may occur if the
language has certain special features which turn out to be very valuable and
can be used in other areas. The concept of list processing is a good illustra-
tion of this; the basic list processing languages (IPL-V and LISP—see Chap-
ter VI) showed the value of list processing so successfully that it became
important for inclusion in newer languages (e.g., PL/I).
The most important thing to realize is that the full advantages (see Sec-
tion J.5.1) of a language cannot be determined without actually using it on
a computer. This is not true about the disadvantages, which can often be
found before going near a computer. Those advantages which can be ascer-
tained without actually using a machine are the ease in learning, ease in
coding in, documentation it provides, and ease in transferring a program
from one person to the next.

II.7.5. DISADVANTAGES

Obviously, the most important disadvantage to a particular language

is that it does not meet its objectives. This can sometimes be determined before
 REFERENCES 61

actually running on a computer, but there must be some honest attempt

to try using the language. For example, if one objective of the language is
to make it easy for nonprogrammers to use it, then a failure of this aspect
can be determined after appropriate training and attempts at program
writing. Similarly, if efficient compilation is an objective, the implementers
may discover the disadvantages very early in their work.
One important thing to keep in mind is that one cannot measure the
disadvantages of a language in a vacuum; one must consider them in the light
of the objectives. If the purpose of the language is to solve numerical scien-
tific problems, then one cannot say that the language has disadvantages
because it cannot do formal differentiation or integration.
The main disadvantages that can be discovered without actually using
a computer are that it fails to have the advantages cited in Section II.7.4
and it is not possible to express all the needed operations in the language.

11.7.6. MISTAKES TO BE AVOIDED IN THE FUTURE

Only after the language has been in use for a considerable period of time
can one determine what mistakes have been made. These mistakes might
be in the actual design objectives, in the sense that they were either too nar-
row or too broad and, therefore, incapable of achievement; or the mistakes
might be involved with the relationship between the language and the imple-
mentation; or it may be that the language was not suitably designed to meet
its objectives. Again, all these factors can be determined only after actual
uSage.

REFERENCES

H.1.—ll.3.

[DJ63] Dijkstra, E. W., “On the Design of Machine Independent Program-

ming Languages”, Ann. Rev. Automatic Programming, Vol.3 (R. Goodman,
ed.), Pergamon Press, New York, 1963, pp. 27-42.
[DT62] “The RAND Symposium: 1962, pt. 1”, Datamation, Vol. 8, No. 10 (Oct.,
1962), pp. 25—32.
[DT62a] “The RAND Symposium: 1962, pt. 2”, Datamation, Vol. 8, No. 11
(Nov., 1962), pp. 23-30.
[HL66] Halpern, M. I., “Foundations of the Case for Natural-Language Pro-
gramming”, Proc. FJCC, Vol. 29 (1966), pp. 639-49.
[HY62] Humby, E., “Rapidwrite—COBOL Without Tears”, Symbolic Languages
in Data Processing, Gordon and Breach, New York, 1962, pp. 573-83.
[HY63] Humby, E., “Rapidwrite”, Ann. Rev. Automatic Programming, Vol. 3
(R. Goodman, ed.), Pergamon Press, New York, 1963, pp. 299-310.
[SM66b] Sammet, J. E., “The Use of English as a Programming Language”,
Comm. ACM, Vol. 9, No. 3 (Mar., 1966), pp. 228-30.
62 FUNCTIONAL CHARACTERISTICS OF PROGRAMMING LANGUAGES

11.4. CONVERSION AND COMPATIBILITY

[AX63] Allen, J. J.. Moore, D. P., and Rogoway, H. P., “SHARE Internal
FORTRAN Translator”, Datamation, Vol. 9, No. 3 (Mar., 1963),
pp. 43-46.
[HL65] Halpern, M. I., “Machine Independence: Its Technology and Econo-
mics”, Comm. ACM, Vol. 8, No. 12 (Dec., 1965), pp. 782-85.
[OL65] Olsen, T. M., “Philco/IBM Translation at Problem-Oriented, Symbolic
and Binary Levels”, Comm. ACM, Vol. 8, No. 12 (Dec., 1965), pp.
762-68.

11.5. STANDARDIZATION
[AT64] Alt, F. L., “The Standardization of Programming Languages”, Proc.
ACM 19th Nat’l Conf. 1964, pp. B.2-1—B.2-6.
[GS67] Goodstat, P. B., “Standards in Data Processing”, Data Processing
Magazine, Vol. 9, No. 3 (Mar., 1967), pp. 22-25.
[ST67] Steel, T. B., Jr., “Standards for Computers and Information Process-
ing”, Advances in Computers, Vol. 8 (F.L. Alt and M. Rubinoff, eds.),
Academic Press, New York, 1967, pp. 103-52.

1.6. TYPES AND METHODS OF LANGUAGE DEFINITION

[AL67] Alber, K., Syntactical Description of PL[I Text and Its Translation into
Abstract Normal Form, IBM Corp., TR 25.074, Vienna Lab., Vienna,
Austria (Apr., 1967).
[AN66] Allen, C. D. et al., An Abstract Interpreter of PL/I, IBM Corp., TN
3004, Hursley, England (Nov., 1966).
[BA67] Bandat, K., On the Formal Definition of PL/I, IBM Corp., TR 25.073,
Vienna Lab. (Mar., 1967).
[BC66] Beech, D. et al., Concrete Syntax of PL/I, IBM Corp., TN 3001, Hursley,
England (Nov., 1966).
[BC66a] Beech, D., Nicholls, J. E., and Rowe, R., A PL/I Translator, IBM Corp.,
TN 3003, Hursley, England (Oct., 1966).
[BC67] Beech, D. et al., Abstract Syntax of PL/I, IBM Corp., TN 3002 (Version
2), Hursley, England (May, 1967).
[BS60] Backus, J. W., “The Syntax and Semantics of the Proposed International
Algebraic Language of the Zurich ACM-GAMM Conference”, Proc.
Ist Internat’] Conf. Information Processing, UNESCO, Paris, 1959,
R. Oldenbourg, Munich and Butterworth, London, 1960, pp. 125-32.
[BU65] Burkhardt, W. H., “Metalanguage and Syntax Specification”, Comm.
ACM, Vol. 8, No. 5 (May, 1965), pp. 304-305.
[BX62] Brooker, R. A. and Morris, D., “A General Translation Program for
Phrase Structure Languages”, J. ACM, Vol. 9, No. 1 (Jan., 1962), pp.
1-10.
 REFERENCES 63

[CH64] Cheatham, T. E., Jr. and Sattley, K., “Syntax Directed Compiling”,
Proc. SJCC, Vol. 25 (1964), pp. 31-57. (Also in [RO67].)
[FL64] Floyd, R. W., “The Syntax of Programming Languages—A Survey”,
IEEE Trans. Elec. Comp., Vol. EC-13 (Aug., 1964), pp. 346-53. (Also
in [RO67].)
[GC60] Glennie, A. E., On the Syntax Machine and the Construction of a Uni-
versal Compiler, Tech. Report No. 2, Carnegie Inst. Tech. Computation
Center (AD-240512) (July, 1960).
[GO61] Gorn, S., “Some Basic Terminology Connected With Mechanical
Languages and Their Processors”, Comm. ACM, Vol. 4, No. 8 (Aug.,
1961), pp. 336-39.
[GO6la] Gorn, S., “Specification Languages for Mechanical Languages and
Their Processors, A Baker’s Dozen”, Comm. ACM, Vol. 4, No. 12
(Dec., 1961), pp. 532-42.
[1B62] IBM 1620 FORTRAN (Reference Manual), IBM Corp., C26-5619-0,
Data Processing Division, White Plains, N.Y. (1962).
[1B64a] IBM Operating System/360: FORTRAN IV, IBM Corp., C28-6515-2,
Data Processing Division, White Plains, N.Y. (1964).
[1B66] FORMAL DEFINITION OF PL/I, IBM Corp., TR 25.071, Vienna
Lab., Vienna, Austria (Dec., 1966).
(IB66h] IBM 7090/7094 IBSYS Operating System-Version 13: FORTRAN IV
Language, IBM Corp., C28-6390-3, Data Processing Division, White
Plains, N.Y. (Apr., 1966).
[IR61] Irons, E. T., “A Syntax Directed Compiler for ALGOL 60”, Comm.
ACM, Vol. 4, No. 1 (Jan., 1961), pp. 51-55. (Also in [RO67].)
[1V64] Iverson, K. E., “A Method of Syntax Specification”, Comm. ACM,
Vol. 7, No. 10 (Oct., 1964), pp. 588-89.
[LW64] Landweber, P. S., “Decision Problems of Phrase-Structure Gram-
mars”, [EEE Trans. Elec. Comp., Vol. EC-13, No. 4 (Aug., 1964), pp.
354-62.
[MT61] COMIT Programmers’ Reference Manual, M.1.T. Research Lab. of
Electronics and the Computation Center, Cambridge, Mass. (Nov.,
1961).
[PU67]} Pursey, G., Concrete Syntax of Subset PL/I, IBM Corp., TN 3005,
Hursley, England (Feb., 1967).
[RT 66] Rochester, N., “A Formalization of Two Dimensional Syntax Descrip-
tion”, Formal Language Description Languages for Computer Program-
ming (Proc. of the IFIP Working Conference on Formal Language
Description Languages). (T. B. Steel, Jr., ed.), North-Holland Publishing
Co., Amsterdam, 1966, pp. 124-38.
[SM6la] Sammet, J. E., A Definition of the COBOL 61 Procedure Division Using
ALGOL 60 Metalinguistics. Summary in Preprints of 16th Nat’l Meeting
of the ACM (Sept., 1961), pp. 5B-1 (1)-(4).
[ST66a] Steel, T. B., Jr. (ed.), Formal Language Description Languages for
Computer Programming (Proceedings of the IFIP Working Conference
on Formal Language Description Languages). North-Holland Publish-
ing Co., Amsterdam, 1966.
64 FUNCTIONAL CHARACTERISTICS OF PROGRAMMING LANGUAGES

[UE67] deBakker, J. W., Formal Definition of Programming Languages With an

Application to the Definition of ALGOL 60. Mathematical Centre Tract
16 (Mathematisch Centrum), Amsterdam (1967).
[Y N63] Yngve, V. H. and Sammet, J. E., “Toward Better Documentation of
Programming Languages: Introduction”, Comm. ACM, Vol. 6, No. 3
(Mar., 1963), p. 76.
[Y N63a] Yngve, V. H. and Sammet, J. E. (eds.), “Toward Better Documentation
of Programming Languages”, Comm. ACM, Vol. 6, No. 3 (Mar., 1963),
pp. 76-92.
[ZE66] Zemanek, H., “Semiotics and Programming Languages”, Comm.
ACM, Vol. 9, No. 3 (Mar., 1966), pp. 139-43.
; I ; TECHNICAL CHARACTERISTICS
OF PROGRAMMING LANGUAGES

il.14. DESCRIPTION OF CONCEPT OF TECHNICAL FEATURES

III.1.1. INTRODUCTION

In Chapter II there was a discussion of those characteristics of program-

ming languages which were distinct from the detailed specifications of the
language itself. Many of those factors were avowedly nontechni