Programming In Ada 2012 1st Edition Barnes John Gilbert Presslie

Programming In Ada 2012 1st Edition Barnes John
Gilbert Presslie download
https://ebookbell.com/product/programming-in-ada-2012-1st-
edition-barnes-john-gilbert-presslie-6747800
Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.
Programming In Ada 2012 With A Preview Of Ada 2022 2nd Edition John
Barnes
https://ebookbell.com/product/programming-in-ada-2012-with-a-preview-
of-ada-2022-2nd-edition-john-barnes-43325070
Programming In Ada 2012 1st Edition John Barnes
https://ebookbell.com/product/programming-in-ada-2012-1st-edition-
john-barnes-5524932
Programming In Ada 2022 John Barnes
https://ebookbell.com/product/programming-in-ada-2022-john-
barnes-163034396
Concurrent And Realtime Programming In Ada 3rd Alan Burns Andy
Wellings
https://ebookbell.com/product/concurrent-and-realtime-programming-in-
ada-3rd-alan-burns-andy-wellings-2539272

Kotlin Programming In 8 Hours For Beginners Swift Ada R Yao
https://ebookbell.com/product/kotlin-programming-in-8-hours-for-
beginners-swift-ada-r-yao-232065404
Programming In Two Semesters Using Python And Java Quentin Charatan
https://ebookbell.com/product/programming-in-two-semesters-using-
python-and-java-quentin-charatan-46494972
Programming In Lua 4th Edition Roberto Ierusalimschy
https://ebookbell.com/product/programming-in-lua-4th-edition-roberto-
ierusalimschy-49119332
Programming In C Volume 2 Composite Data Structures And Modularization
https://ebookbell.com/product/programming-in-c-volume-2-composite-
data-structures-and-modularization-50338946
Programming In C Volume 1 Basic Data Structures And Program Statements
Xingni Zhou
https://ebookbell.com/product/programming-in-c-volume-1-basic-data-
structures-and-program-statements-xingni-zhou-50339330

Programming
in Ada 2012
JOHN BARNES

University Printing House, Cambridge CB2 8BS, United Kingdom
Cambridge University Press is part of the University of Cambridge.
It furthers the University’s mission by disseminating knowledge in the pursuit of
education, learning and research at the highest international levels of excellence.
www.cambridge.org
Information on this title: www.cambridge.org/9781107424814
© John Barnes 2014
This publication is in copyright. Subject to statutory exception
and to the provisions of relevant collective licensing agreements,
no reproduction of any part may take place without the written
permission of Cambridge University Press.
First published 2014
Printed in the United Kingdom by Clays, St Ives plc
Typeset By John Barnes Informatics
A catalogue record for this publication is available from the British Library
Library of Congress Cataloguing in Publication data
ISBN 978-1-107-42481-4 Paperback
Cambridge University Press has no responsibility for the persistence or accuracy
of URLs for external or third-party internet websites referred to in this publication,
and does not guarantee that any content on such websites is, or will remain,
accurate or appropriate.

Contents
vii
Foreword xv
Preface xix
Part 1 An Overview 1
1 Introduction 3
1.1 Standard development 3
1.2 Software engineering 4
1.3 Evolution and abstraction 6
1.4 Structure and objectives of this book 8
1.5 References 10
2 Simple Concepts 11
2.1 Key goals 11
2.2 Overall structure 12
2.3 The scalar type model 17
2.4 Arrays and records 19
2.5 Access types 22
2.6 Errors and exceptions 23
2.7 Terminology 26
3 Abstraction 27
3.1 Packages and private types 27
3.2 Objects and inheritance 30
3.3 Classes and polymorphism 34
3.4 Genericity 40
3.5 Object oriented terminology 41
3.6 Tasking 43
4 Programs and Libraries 47
4.1 The hierarchical library 47
4.2 Input–output 49

4.3 Numeric library 52
4.4 Running a program 54
Program 1 Magic Moments 59
Part 2 Algorithmic Aspects 63
5 Lexical Style 65
5.1 Syntax notation 65
5.2 Lexical elements 66
5.3 Identifiers 67
5.4 Numbers 68
5.5 Comments 71
5.6 Pragmas and aspects 71
6 Scalar Types 73
6.1 Object declarations and assignments 73
6.2 Blocks and scopes 75
6.3 Types 77
6.4 Subtypes 79
6.5 Simple numeric types 81
6.6 Enumeration types 87
6.7 The type Boolean 90
6.8 Categories of types 93
6.9 Expression summary 95
7 Control Structures 101
7.1 If statements 101
7.2 Case statements 105
7.3 Loop statements 108
7.4 Goto statements and labels 114
7.5 Statement classification 111
8 Arrays and Records 117
8.1 Arrays 117
8.2 Array types 122
8.3 Array aggregates 127
8.4 Characters and strings 132
8.5 Arrays of arrays and slices 135
8.6 One-dimensional array operations 138
8.7 Records 143
9 Expression structures 149
9.1 Membership tests 149
9.2 If expressions 151
9.3 Case expressions 155
viii Contents

9.4 Quantified expressions 157
10 Subprograms 161
10.1 Functions 161
10.2 Operators 169
10.3 Procedures 171
10.4 Aliasing 177
10.5 Named and default parameters 179
10.6 Overloading 181
10.7 Declarations, scopes and visibility 182
11 Access Types 189
11.1 Flexibility versus integrity 189
11.2 Access types and allocators 191
11.3 Null exclusion and constraints 198
11.4 Aliased objects 200
11.5 Accessibility 204
11.6 Access parameters 206
11.7 Anonymous access types 210
11.8 Access to subprograms 214
11.9 Storage pools 220
Program 2 Sylvan Sorter 223
Part 3 The Big Picture 227
12 Packages and Private Types 229
12.1 Packages 229
12.2 Private types 234
12.3 Primitive operations and derived types 241
12.4 Equality 247
12.5 Limited types 251
12.6 Resource management 257
13 Overall Structure 263
13.1 Library units 263
13.2 Subunits 266
13.3 Child library units 268
13.4 Private child units 272
13.5 Mutually dependent units 279
13.6 Scope, visibility and accessibility 283
13.7 Renaming 287
13.8 Programs, partitions and elaboration 292
Program 3 Rational Reckoner 297
Contents ix

14 Object Oriented Programming 301
14.1 Type extension 301
14.2 Polymorphism 307
14.3 Abstract types and interfaces 315
14.4 Primitive operations and tags 318
14.5 Views and redispatching 328
14.6 Private types and extensions 334
14.7 Controlled types 342
14.8 Multiple inheritance 347
14.9 Multiple implementations 353
15 Exceptions 361
15.1 Handling exceptions 361
15.2 Declaring and raising exceptions 364
15.3 Checking and exceptions 370
15.4 Exception occurrences 372
15.5 Exception pragmas and aspects 376
15.6 Scope of exceptions 381
16 Contracts 385
16.1 Aspect specifictions 385
16.2 Preconditions and postconditions 388
16.3 Type invariants 399
16.4 Subtype predicates 405
16.5 Messages 413
17 Numeric Types 417
17.1 Signed integer types 417
17.2 Modular types 423
17.3 Real types 425
17.4 Floating point types 427
17.5 Fixed point types 430
17.6 Decimal types 436
18 Parameterized Types 439
18.1 Discriminated record types 439
18.2 Default discriminants 443
18.3 Variant parts 449
18.4 Discriminants and derived types 453
18.5 Access types and discriminants 456
18.6 Private types and discriminants 463
18.7 Access discriminants 465
19 Generics 469
19.1 Declarations and instantiations 469
19.2 Type parameters 475
x Contents

19.3 Subprogram parameters 485
19.4 Package parameters 492
19.5 Generic library units 498
20 Tasking 501
20.1 Parallelism 501
20.2 The rendezvous 503
20.3 Timing and scheduling 508
20.4 Protected objects 513
20.5 Simple select statements 521
20.6 Timed and conditional calls 524
20.7 Concurrent types and activation 527
20.8 Termination, exceptions and ATC 534
20.9 Signalling and scheduling 540
20.10 Summary of structure 546
21 Object Oriented Techniques 551
21.1 Extension and composition 551
21.2 Using interfaces 554
21.3 Mixin inheritance 560
21.4 Linked structures 562
21.5 Iterators 565
21.6 Generalized iteration 570
21.7 Object factories 577
21.8 Controlling abstraction 581
22 Tasking Techniques 587
22.1 Dynamic tasks 587
22.2 Multiprocessors 590
22.3 Synchronized interfaces 598
22.4 Discriminants 609
22.5 Task termination 614
22.6 Clocks and timers 617
22.7 The Ravenscar profile 626
Program 4 Super Sieve 627
Part 4 Completing the Story 631
23 Predefined Library 633
23.1 The package Standard 633
23.2 The package Ada 637
23.3 Characters and strings 640
23.4 Numerics 659
23.5 Input and output 663
23.6 Text input–output 669
Contents xi

23.7 Streams 678
23.8 Environment commands 684
Program 5 Wild Words 695
24 Container Library 699
24.1 Organization of library 699
24.2 Doubly linked lists 701
24.3 Vectors 709
24.4 Maps 713
24.5 Sets 725
24.6 Trees 737
24.7 Holder 747
24.8 Queues 749
24.9 Bounded containers 757
24.10 Indefinite containers 761
24.11 Sorting 767
24.12 Summary table 769
25 Interfacing 781
25.1 Representations 781
25.2 Unchecked programming 785
25.3 The package System 788
25.4 Storage pools and subpools 790
25.5 Other languages 797
Program 6 Playing Pools 803
26 The Specialized Annexes 807
26.1 Systems Programming 807
26.2 Real-Time Systems 809
26.3 Distributed Systems 813
26.4 Information Systems 815
26.5 Numerics 815
26.6 High Integrity Systems 820
27 Finale 823
27.1 Names and expressions 823
27.2 Type equivalence 827
27.3 Overall program structure 830
27.4 Portability 834
27.5 Penultimate thoughts 836
27.6 SPARK 839
xii Contents

Appendices 851
A1 Reserved Words, etc. 851
A1.1 Reserved words 851
A1.2 Predefined attributes 852
A1.3 Predefined aspects 859
A1.4 Predefined pragmas 862
A1.5 Predefined restrictions 864
A2 Glossary 867
A3 Syntax 873
A3.1 Syntax rules 873
A3.2 Syntax index 891
Answers to Exercises 901
Bibliography 929
Index 931
Contents xiii

Foreword
xv
Programming Languages and Software practice are always engaged in a game of
leapfrog: a forward looking programming language introduces new ways of
thinking about software development, and its constructs shape the way
programmers think about their craft; creative programmers invent new idioms and
patterns to tackle ever more complex programming tasks, and these idioms become
incorporated in the next generation of programming languages.
The latest version of Ada, whose description we owe once again to the
inimitable expository talents of John Barnes, has exemplified this dynamic
repeatedly over the last 30 years.
• Ada 83 showed programmers how programming in the large should be
organized (packages, strong typing, privacy) and convinced them that indices
out of range were not a common pitfall of programming but elementary errors
that could be controlled with proper declarations and constraint checking. Ada
83 also put concurrent programming in a mainstream programming language.
• Ada 95 benefited from a decade-long development in object-oriented
programming techniques, and successfully grafted the ideas of polymorphism
and dynamic dispatching onto a strongly-typed language with concurrency. It
enhanced programming-in-the large capabilities with child units and their
generic incarnations.
• Ada 2005 showed how data-based synchronization (protected types) and
concurrency (task types) could be unified through a novel use of interface
inheritance, and adopted a conservative model of multiple inheritance of
interfaces that has proved more robust than the more unrestricted models of MI.
Ada 2005 also introduced into the language an extensive container library,
following here the example of other established languages and many earlier
experimental high-level languages that showed the usefulness of reasoning over
data aggregates.
And now – Ada 2012, the latest version of the language whose description you are
holding, reflects both aspects of this dialectic process: it introduces new ways of
thinking about program construction, and it reflects developments in software
practice that hark back to the earlier days of our profession but that have seldom, if
ever, found their way into well-established programming languages.

The general rubric for these new/old ideas is Programming by Contract. The term
became well-known through the pioneering work of Bertrand Meyer and the design
of Eiffel, but it probably found more significant use in the SPARK community, in the
design of critical software for applications that require a real measure of formal
verification for their deployment.
Ada 2012 offers the programmer a wealth of new tools for specifying the intent
of a program: preconditions, postconditions, type invariants, subtype predicates. All
of these allow the software architect to present more clearly the intent of a piece of
software, and they allow the compiler and/or the run-time system to verify that the
software behaves as intended. The use of pre- and postconditions was proposed a
generation ago by E. DIkjstra and C.A.R .Hoare, but their pioneering efforts were
not widely adopted by the software community, among other things because good
language support for these mechanisms was lacking. Their introduction in a
language whose user community is particularly concerned with mission-critical
software reflects the fact that concerns about safety and security are more urgent
than ever. We can expect that these techniques will be adopted early and
enthusiastically by the aerospace and automotive software development
community, as they have been in the small and dedicated SPARK community.
Preconditions, postconditions, type invariants and type predicates are logical
assertions about the behavior of a given construct. When these assertions involve
data aggregates (vectors, sets, and other container types) it is particularly
convenient to use notations from first-order logic, namely quantified expressions.
An important syntactic innovation of Ada 2012 is the introduction of quantified
expressions both in their universal form (all elements of this set are French Cheeses)
and their existential form (some element of this vector is purple). As a result, the
language includes the new keyword some. These quantified expressions are of
course implicit loops over data aggregates, and in parallel with their introduction,
Ada 2012 has extended considerably the syntax of iterators over containers. A
generalized notion of indexing now allows the programmer to define their own
iterable constructs, as well as mapping between arbitrary types.
Contracts, quantified expressions, and generalized indexing may appear to be
miscellaneous additions to an already large language; in fact they are elegantly
unified under the umbrella of a new construct: the Aspect Specification, which also
generalizes and unifies the earlier notions of attributes and pragmas. The coherence
of the language has thus been enhanced as well.
Programming languages must also respond to developments in Computer
Hardware. The most significant development of the last decade has been the
appearance of multicore architectures, which provide abundant parallelism on a
single chip. Making efficient use of the computer power now available on a single
processor has been the goal of much development in language design. Ada 2012
provides tools for describing multicore architectures, and for mapping computing
activities onto specific cores or sets of them.These are novel capabilities for a
general-purpose programming language, and we can expect them to have a
profound impact on the practice of parallel programming.
This thumbnail description of the high points of the new version of the language
is intended to whet your appetite for the pages that follow. Once again, John Barnes
has provided a wonderfully lucid, learned, and insightful description of the latest
version of Ada. He has been the tireless explicator of the design and evolution of
the language over more than three decades, and the Ada community has acquired its
xvi Foreword

understanding and love of the language from his prose. A programming language is
a tool for thought, and most Ada users have learned how to think about programs
from John Barnes’s books. I can only hope that the widest possible audience will
learn to think straight from the exciting descriptions that follow.
The design of Ada 2012 is once again the result of the collective effort of the
Ada Rapporteur group, an extremely talented group of language designers who
combine deep industrial experience with an equally deep knowledge of
programming language semantics and theoretical computer science. The ARG, of
which John Barnes has been an invaluable member from the inception of Ada, has
once again created a modern and elegant programming language that addresses the
needs of a new generation of software designers. It has been an enormous privilege
to work with them. I trust the reader will enjoy the result of their work for years to
come. Happy Programming!
Ed Schonberg
AdaCore
Chairman, Ada Rapporteur Group
New York, March 2014
Foreword xvii

Preface
xix
Welcome to Programming in Ada 2012 which has been triggered by the recent
ISO standardization of Ada 2012.
The original language, devised in the 1980s, is known as Ada 83 and was
followed by Ada 95, Ada 2005, and now Ada 2012. Ada has gained a reputation as
being the language of choice when software needs to be correct. And as software
pervades into more areas of society so that ever more software is safety critical or
security critical, it is clear that the future for Ada is bright. One observes, for
example, the growth in use of SPARK, the Ada based high integrity language widely
used in areas such as avionics and signalling.
Ada 83 was a relatively simple but highly reliable language with emphasis on
abstraction and information hiding. It was also notable for being perhaps the first
practical language to include multitasking within the language itself.
Ada 95 added extra flexibility to the strongly typed and secure foundation
provided by the Software Engineering approach of Ada 83. In particular it added the
full dynamic features of Object Oriented Programming (OOP) and in fact was the
first such language to become an ISO standard. Ada 95 also made important
structural enhancements to visibility control by the addition of child units, it greatly
improved multitasking by the addition of protected types, and added important basic
material to the standard library.
Ada 2005 then made improvements in two key areas. It added more flexibility
in the OOP area by the addition of multiple inheritance via interfaces and it added
more facilities in the real-time area concerning scheduling algorithms, timing and
other matters of great importance for embedded systems. It also added further
facilities to the standard library such as the ability to manipulate containers.
Ada 2012 makes further important enhancements. These include features for
contracts such as pre- and postconditions, tasking facilities to recognize multicore
architectures, and major additions and improvements to the container library.
In more detail, the changes include
• Contracts – pre- and postconditions, type invariants, and subtype predicates
are perhaps the most dramatic new features. The introduction of these features
prompted a rethink regarding the specification of various properties of entities
in general. As a consequence the use of pragmas has largely been replaced by
the elegant new syntax of aspect specifications which enables the properties
to be given with the declaration of the entities concerned.

• Expressions – the introduction of the contract material showed a need for more
flexible expressions. Accordingly, Ada now includes conditional expressions,
case expressions, quantified expressions and more flexible forms of
membership tests. A new form of function is also introduced in which the body
is essentially given by a single expression.
• Structure and visibility – perhaps the most startling change in this area is
allowing functions to have parameters of all modes. This removes the need for
a number of obscure techniques (dirty tricks really) which had been used.
Other important improvements concern incomplete types.
• Tasking – Ada 2012 has new features describing the allocation of tasks to
individual processors and sets of processors; these additions were prompted
by the rapid growth in the use of multicore architectures.
• Generally – new flexible forms of iterators and dereferencing are introduced
mainly for use with containers. Better control of storage pools is permitted by
the introduction of subpools.
• Predefined library – some improvements are made concerning directories
and a feature is added for the identification of locale. However, the most
important improvement is the addition of many new forms of containers.
These include multiway trees and task-safe queues. There are also bounded
forms of all containers which are important for high integrity systems where
dynamic storage management is often not permitted.
This book follows the tradition of its predecessors. It presents an overall
description of Ada 2012 as a language. Some knowledge of the principles of
programming is assumed but an acquaintance with specific other languages is by no
means necessary.
The book comprises 27 chapters grouped into four parts as follows
• Chapters 1 to 4 provide an overview which should give the reader an
understanding of the overall scope of the language as well as the ability to run
significant programs as examples – this is particularly for newcomers to Ada.
• Chapters 5 to 11 cover the small-scale aspects such as the lexical details, scalar,
array and simple record types, control and expression structures, subprograms
and access types.
• Chapters 12 to 22 discuss the large-scale aspects including packages and private
types, contracts, separate compilation, abstraction, OOP and tasking as well as
exceptions and the details of numerics.
• Chapters 23 to 27 complete the story by discussing the predefined library,
interfacing to the outside world and the specialized annexes; there is then a
finale concluding with some ruminations over correctness and a brief
introduction to SPARK.
The finale includes, as in its predecessors, with the fantasy customer in the shop
trying to buy reusable software components and whose dream now seems as far
away or indeed as near at hand as it did many years ago when I first toiled at this
book. The discussion continues to take a galactic view of life and perhaps echoes
the cool cover of the book which depicts the Ice Comet.
xx Preface

Those familiar with Programming in Ada 2005 might find the following
summary of key changes helpful
• The number of chapters has grown from 25 to 27. The new chapter 8 covers the
new forms of expressions such as if expressions, case expressions, and
quantified expressions. The new chapter 16 discusses the material on contracts.
The chapter on containers (now chapter 24) has grown because of the
introduction of containers for multiway trees, single indefinite objects, and
various forms of queues. A number of existing chapters have additional sections
such as that on aliasing.
• The revisions to produce Ada 2012 have impacted to a greater or lesser extent
on many aspects of the language. Most chapters conclude with a checklist
summarizing important points to remember and listing the main additions in
Ada 2012.
• As a consequence the book is now some 120 pages longer. It would have been
even longer had I not decided that it was unnecessary to include the answer to
every exercise. Accordingly, the printed answers cover just the introductory
chapters (for the benefit of those entirely new to Ada) and those exercises that
are referred to elsewhere in the book. But all the answers are on the associated
website.
The website also includes the six sample programs both in text form and as
executable programs, some material from earlier versions of this book which now
seem of lesser importance but which I nevertheless was reluctant to lose completely.
More details of the website will be found below.
And now I must thank all those who have helped with this new book. The
reviewers included Janet Barnes, Alan Burns, Rod Chapman, Jeff Cousins, Bob
Duff, Stuart Matthews, Ed Schonberg, Tucker Taft, and Andy Wellings. Their much
valued comments enabled me to improve the presentation and to eliminate a number
of errors. Some of the new material is based on parts of the Ada 2012 Rationale and
I must express my special gratitude to Randy Brukardt for his painstaking help in
reviewing that document.
Finally, many thanks to my wife Barbara for help in typesetting and proof-
reading and to friends at Cambridge University Press for their continued guidance
and help.
John Barnes
Caversham, England
March 2014
Notes on the website
The website is www.cambridge.org/barnes. It contains three main things: the full
answers to all the exercises, some obscure or obsolete material on exceptions,
discriminants, and iterators which were in previous versions of the book, and
additional material on the six sample programs.
I do hope that readers will find the sample programs on the website of interest.
I am aware that they are a bit intricate. But this seems almost inevitable in order to
Preface xxi

illustrate a broad range of features of Ada in a reasonably concise manner.
However, in most cases they build on examples in preceding chapters and so should
not be difficult to follow.
Each example commences with some remarks about its purpose and overall
structure. This is followed by the text of the program and then some notes on
specific details. A desire to keep the program text short means that comments are at
a minimum. However, the corresponding source text on the website includes much
additional commentary. The website also includes further discussion and
explanation and suggestions for enhancement. In general the programs use only
those features of the language explained in detail by that point in the book.
The first program, Magic Moments, illustrates type extension and dispatching.
It shows how the existence of common components and common operations enable
dispatching to compute various geometrical properties almost by magic.
The Sylvan Sorter is an exercise in access types and basic algorithmic
techniques including recursion.
The Rational Reckoner provides two examples of abstract data types – the
rational numbers themselves and the stack which is the basis of the calculator part
of the program.
The Super Sieve illustrates multitasking and communication between tasks both
directly through entry calls and indirectly through protected objects. For added
interest it is made generic so that more general primes than the familiar integers
may be found. This provides the opportunity to use a discriminated record type and
a modular type to represent binary polynomials.
The program Wild Words is probably the hardest to follow because it is not
based on any particular example described in the preceding chapters. It illustrates
many of the facilities of the character and string handling packages as well as the
generation of random numbers.
The final program, Playing Pools, shows how users might write their own
storage allocation package for the control of storage pools. The example shown
enables the user to monitor the state of the pool and it is exercised by running the
familiar Tower of Hanoi program which moves a tower of discs between three
poles. Variety is provided by implementing the stack structures representing the
three poles (and defined by an interface) in two different ways and dispatching to
the particular implementation. The website includes an extended version which uses
three different ways.
Information on many aspects of Ada such as vendors, standards, books and so
on can be obtained from the websites listed in the Bibliography.
xxii Preface

Part 1
T
his first part covers the background to the Ada language and an
overview of most of its features. Enough material is presented
here to enable a programmer to write complete simple
programs.
Chapter 1 contains a short historical account of the origins and
development of various versions of Ada from Ada 83 through Ada 95
and Ada 2005 and leading to Ada 2012 which is the topic of this book.
There is also a general discussion of how the evolution of abstraction
has been an important key to the development of programming
languages in general.
Broadly speaking, the other three chapters in this part provide an
overview of the material in the corresponding other parts of the book.
Thus Chapter 2 describes the simple concepts familiar from languages
such as C and Pascal and which form the subject of the seven chapters
which comprise Part 2. Similarly Chapter 3 covers the important topic
of abstraction which is the main theme of Part 3. And then Chapter 4
rounds off the overview by showing how a complete program is put
together and corresponds to Part 4 which covers material such as the
predefined library.
An Overview
1
Chapter 1 Introduction 3
Chapter 2 Simple Concepts 11
Chapter 3 Abstraction 27
Chapter 4 Programs and Libraries 47
Program 1 Magic Moments 59

Chapter 3 includes a discussion of the popular topic of object
oriented programming and illustrates the key concepts of classes as
groups of related types, of type extension and inheritance as well as
static polymorphism (genericity) and dynamic polymorphism leading
to dynamic binding. It also includes a brief comparison between the
terminology used by Ada and that used by some other languages. This
chapter concludes with an introduction to tasking which is a very
important aspect of Ada and is a topic not addressed by most
programming languages at all.
This part concludes with the first of a number of complete programs
designed to give the reader a better understanding of the way the
various components of the language fit together. This particular
program illustrates a number of aspects of type extension and
polymorphism.
Those not familiar with Ada will find that this part will give them
a fair idea of Ada’s capabilities and lays the foundation for
understanding the details presented in the remainder of the book.
2

1 Introduction
3
1.1 Standard development
1.2 Software engineering
1.3 Evolution and abstraction
1.4 Structure and objectives
of this book
1.5 References
Ada 2012 is a comprehensive high level programming language especially suited
for the professional development of large or critical programs for which
correctness and robustness are major considerations. In this introductory chapter we
briefly trace the development of Ada 2012 (and its predecessors Ada 83, Ada 95,
and Ada 2005), its place in the overall language scene and the general structure of
the remainder of this book.
1.1 Standard development
Ada 2012 is a direct descendant of Ada 83 which was originally sponsored by the
US Department of Defense for use in the so-called embedded system
application area. (An embedded system is one in which the computer is an integral
part of a larger system such as a chemical plant, missile or dishwasher.)
The story of Ada goes back to about 1974 when the United States Department
of Defense realized that it was spending far too much on software, especially in the
embedded systems area. To cut a long story short the DoD sponsored the new
language through a number of phases of definition of requirements, competitive and
parallel development and evaluation which culminated in the issue of the ANSI
standard for Ada in 19831
. The team that developed Ada was based at CII
Honeywell Bull in France under the leadership of Jean D Ichbiah.
The language was named after Augusta Ada Byron, Countess of Lovelace
(1815–52). Ada, the daughter of the poet Lord Byron, was the assistant and patron
of Charles Babbage and worked on his mechanical analytical engine. In a very real
sense she was therefore the world’s first programmer.
Ada 83 became ISO standard 8652 in 1987 and, following normal ISO practice,
work leading to a revised standard commenced in 1988. The DoD, as the agent of
ANSI, the original proposers of the standard to ISO, established the Ada project in

1988 under the management of Christine M Anderson. The revised language design
was contracted to Intermetrics Inc. under the technical leadership of S Tucker Taft.
The revised ISO standard was published on 15 February 1995 and so became Ada
952
.
The maintenance of the language is performed by the Ada Rapporteur Group
(ARG) of ISO/IEC committee SC22/WG9. The ARG under the leadership of Erhard
Plödereder identified the need for some corrections and these were published as a
Corrigendum on 1 June 20013
.
Experience with Ada 95 and other modern languages such as Java indicated that
further improvements would be very useful. The changes needed were not so large
as the step from Ada 83 to Ada 95 and so an Amendment was deemed appropriate
rather than a Revised standard. The ARG then developed the Amended language
known as Ada 2005 under the leadership of Pascal Leroy4
.
Further experience with Ada 2005 showed that additions especially in the area
of contracts and multiprocessor support would be appropriate. Moreover, it was
decided that this time a consolidated Edition should be produced. This was
accordingly done under the leadership of Ed Schonberg with the editor being Randy
Brukardt and resulted in the version known as Ada 2012 which is the subject of this
book. Ada 2012 became an ISO standard towards the end of 20125.
1.2 Software engineering
It should not be thought that Ada is just another programming language. Ada is
about Software Engineering, and by analogy with other branches of engineering
it can be seen that there are two main problems with the development of software:
the need to reuse software components as much as possible and the need to establish
disciplined ways of working.
As a language, Ada (and hereafter by Ada we generally mean Ada 2012) largely
solves the problem of writing reusable software components – or at least through its
excellent ability to prescribe interfaces, it provides an enabling technology in which
reusable software can be written.
The establishment of a disciplined way of working seems to be a Holy Grail
which continues to be sought. One of the problems is that development
environments change so rapidly that the stability necessary to establish discipline
can be elusive.
But Ada is stable and encourages a style of programming which is conducive to
disciplined thought. Experience with Ada shows that a well designed language can
reduce the cost of both the initial development of software and its later
maintenance.
The main reason for this is simply reliability. The strong typing and related
features ensure that programs contain few surprises; most errors are detected at
compile time and of those that remain many are detected by run-time constraints.
Moreover, the compile-time checking extends across compilation unit boundaries.
This aspect of Ada considerably reduces the costs and risks of program
development compared for example with C and its derivatives such as C++.
Moreover an Ada compilation system includes the facilities found in separate tools
such as ‘lint’ and ‘make’ for C. Even if Ada is seen as just another programming
4 Introduction

language, it reaches parts of the software development process that other languages
do not reach.
Ada 95 added extra flexibility to the inherent reliability of Ada 83. That is, it
kept the Software Engineering but allowed more flexibility. The features of Ada 95
which contributed to this more flexible feel are the extended or tagged types, the
hierarchical library facility and the greater ability to manipulate pointers or
references. Another innovation in Ada 95 was the introduction of protected types to
the tasking model.
As a consequence, Ada 95 incorporated the benefits of object oriented
languages without incurring the pervasive overheads of languages such as Smalltalk
or the insecurity brought by the weak C foundation in the case of C++. Ada 95
remained a very strongly typed language but provided the benefits of the object
oriented paradigm.
Ada 2005 added yet further improvements to the object model by adding
interfaces in the style of Java and providing constructor functions and also
extending the object model to incorporate tasking. Experience has shown that a
standard library is important and accordingly Ada 2005 had a much larger library
including predefined facilities for containers.
Ada has always been renowned as the flagship language for multitasking
applications. (Multitasking is often known as multithreading.) This position was
strengthened by the addition of further standard paradigms for scheduling and
timing and the incorporation of the Ravenscar profile into Ada 2005. The Ravenscar
profile enables the development of real-time programs with predictable behaviour.
Further improvements which have resulted in Ada 2012 are in three main areas.
First there is the introduction of material for ‘programming by contract’ such as pre-
and postconditions somewhat on the lines of those found in Eiffel. There are also
additions to the tasking model including facilities for mapping tasks onto
multiprocessors. Other important extensions are additional facilities in the container
library enabling further structures (such as trees and queues) to be addressed; other
improvements also simplify many operations on the existing container structures.
Two kinds of application stand out where Ada is particularly relevant. The very
large and the very critical.
Very large applications, which inevitably have a long lifetime, require the
cooperative effort of large teams. The information hiding properties of Ada and
especially the way in which integrity is maintained across compilation unit
boundaries are invaluable in enabling such developments to progress smoothly.
Furthermore, if and when the requirements change and the program has to be
modified, the structure and especially the readability of Ada enable rapid
understanding of the original program even if it is modified by a different team.
Very critical applications are those that just have to be correct otherwise people
or the environment get damaged. Obvious examples occur in avionics, railway
signalling, process control and medical applications. Such programs may not be
large but have to be very well understood and often mathematically proven to be
correct. The full flexibility of Ada is not appropriate in this case but the intrinsic
reliability of the strongly typed kernel of the language is exactly what is required.
Indeed many certification agencies dictate the properties of acceptable languages
and whereas they do not always explicitly demand a subset of Ada, nevertheless the
properties are not provided by any other practically available language. The SPARK
language which is based around a kernel subset of Ada illustrates how special tools
1.2 Software engineering 5

can provide extra support for developing high integrity systems. A SPARK program
includes additional information regarding data flow, state and proof. In the original
versions of SPARK this was done in the form of Ada comments. However, in SPARK
2014 this information is presented using new features of Ada including pre- and
postconditions and additional assertions. This information is processed by the
SPARK tools and can be used to show that a program meets certain criteria such as
not raising any predefined exceptions. Much progress has been made in the area of
proof in recent years. A brief introduction to SPARK will be found in the very last
section of this book.
1.3 Evolution and abstraction
The evolution of programming languages has apparently occurred in a rather ad
hoc fashion but with hindsight it is now possible to see a number of major
advances. Each advance seems to be associated with the introduction of a level of
abstraction which removes unnecessary and harmful detail from the program.
The first advance occurred in the early 1950s with high level languages such as
Fortran and Autocode which introduced ‘expression abstraction’. It thus became
possible to write statements such as
X = A + B(I)
so that the use of the machine registers to evaluate the expression was completely
hidden from the programmer. In these early languages the expression abstraction
was not perfect since there were somewhat arbitrary constraints on the complexity
of expressions; subscripts had to take a particularly simple form for instance. Later
languages such as Algol 60 removed such constraints and completed the
abstraction.
The second advance concerned ‘control abstraction’. The prime example was
Algol 60 which took a remarkable step forward; no language since then has made
such an impact on later developments. The point about control abstraction is that the
flow of control is structured and individual control points do not have to be named
or numbered. Thus we write
if X = Y then P := Q else A := B
and the compiler generates the gotos and labels which would have to be explicitly
used in early versions of languages such as Fortran. The imperfection of early
expression abstraction was repeated with control abstraction. In this case the
obvious flaw was the horrid Algol 60 switch which has now been replaced by the
case statement of later languages.
The third advance was ‘data abstraction’. This means separating the details of
the representation of data from the abstract operations defined upon the data.
Older languages take a very simple view of data types. In all cases the data is
directly described in numerical terms. Thus if the data to be manipulated is not
really numerical (it could be traffic light colours) then some mapping of the abstract
type must be made by the programmer into a numerical type (usually integer). This
mapping is purely in the mind of the programmer and does not appear in the written
program except perhaps as a comment.
6 Introduction

Pascal introduced a certain amount of data abstraction as instanced by the
enumeration type. Enumeration types allow us to talk about the traffic light colours
in their own terms without our having to know how they are represented in the
computer. Moreover, they prevent us from making an important class of
programming errors – accidentally mixing traffic lights with other abstract types
such as the names of fish. When all such types are described in the program as
numerical types, such errors can occur.
Another form of data abstraction concerns visibility. It has long been
recognized that the traditional block structure of Algol and Pascal is not adequate.
For example, it is not possible in Pascal to write two procedures to operate on some
common data and make the procedures accessible without also making the data
directly accessible. Many languages have provided control of visibility through
separate compilation; this technique is adequate for medium-sized systems, but
since the separate compilation facility usually depends upon some external system,
total control of visibility is not gained. The module of Modula is an example of an
appropriate construction.
Ada was probably the first practical language to bring together these various
forms of data abstraction.
Another language which made an important contribution to the development of
data abstraction is Simula 67 with its concept of class. This leads us into the
paradigm now known as object oriented programming. There seems to be no precise
definition of OOP, but its essence is a flexible form of data abstraction providing
the ability to define new data abstractions in terms of old ones and allowing
dynamic selection of types.
All types in Ada 83 were static and thus Ada 83 was not classed as a truly object
oriented language but as an object based language. However, Ada 95, Ada 2005,
and Ada 2012 include the essential functionality associated with OOP such as type
extension and dynamic polymorphism.
We are, as ever, probably too close to the current scene to achieve a proper
perspective. Data abstraction in Ada 83 seems to have been not quite perfect, just
as Fortran expression abstraction and Algol 60 control abstraction were imperfect
in their day. It remains to be seen just how well Ada now provides what we might
call ‘object abstraction’. Indeed it might well be that inheritance and other aspects
of OOP turn out to be unsatisfactory by obscuring the details of types although not
hiding them completely; this could be argued to be an abstraction leak making the
problems of program maintenance even harder.
A brief survey of how Ada relates to other languages would not be complete
without mention of C and C++. These have a completely different evolutionary trail
to the classic Algol–Pascal–Ada route.
The origin of C can be traced back to the CPL language devised by Strachey,
Barron and others in the early 1960s. This was intended to be used on major new
hardware at Cambridge and London universities but proved hard to implement.
From it emerged the simple system programming language BCPL and from that B
and then C. The essence of BCPL was the array and pointer model which abandoned
any hope of strong typing and (with hindsight) a proper mathematical model of the
mapping of the program onto a computing engine. Even the use of := for assignment
was lost in this evolution which reverted to the confusing use of = as in Fortran.
Having hijacked = for assignment, C uses == for equality thereby conflicting with
several hundred years of mathematical usage. About the only feature of the elegant
1.3 Evolution and abstraction 7

CPL remaining in C is the unfortunate braces {} and the associated compound
statement structure which was abandoned by many other languages in favour of the
more reliable bracketed form originally proposed by Algol 68. It is again tragic to
observe that Java has used the familiar but awful C style. The very practical
problems with the C notation are briefly discussed in Chapter 2.
Of course there is a need for a low level systems language with functionality
like C. It is, however, unfortunate that the interesting structural ideas in C++ have
been grafted onto the fragile C foundation. As a consequence although C++ has
many important capabilities for data abstraction, including inheritance and
polymorphism, it is all too easy to break these abstractions and create programs that
violently misbehave or are exceedingly hard to understand and maintain. Java is
free from most of these flaws but persists with anarchic syntax.
The designers of Ada 95 incorporated the positive dynamic facilities of the kind
found in C++ onto the firm foundation provided by Ada 83. The designers of Ada
2005 and Ada 2012 have added further appropriate good ideas from Java. But the
most important step taken by Ada 2012 is to include facilities for ‘programming by
contract’ which in a sense is the ultimate form of abstraction.
Ada thus continues to advance along the evolution of abstraction. It
incorporates full object abstraction in a way that is highly reliable without incurring
excessive run-time costs.
1.4 Structure and objectives of this book
Learning a programming language is a bit like learning to drive a car. Certain key
things have to be learnt before any real progress is possible. Although we need
not know how to use the cruise control, nevertheless we must at least be able to start
the engine, select gears, steer and brake. So it is with programming languages. We
do not need to know all about Ada before we can write useful programs but quite a
lot must be learnt. Moreover, many virtues of Ada become apparent only when
writing large programs just as many virtues of a Rolls-Royce are not apparent if we
only use it to drive to the local store.
This book is not an introduction to programming but an overall description of
programming in Ada. It is assumed that the reader will have significant experience
of programming in some other language such as Pascal, C or Java (or earlier
versions of Ada). But a specific knowledge of any particular language is not
assumed.
It should also be noted that this book strives to remain neutral regarding
methods of program design and should therefore prove useful whatever techniques
are used.
This book is primarily about programming in Ada 2012, but in order to aid
transition from earlier versions of Ada, most chapters contain a summary of where
Ada 2012 differs from Ada 95 and Ada 2005 in the area concerned.
This book is in four main parts. The first part, Chapters 1 to 4, is an extensive
overview of most of the language and covers enough material to enable a wide
variety of programs to be written; it also lays the foundation for understanding the
rest of the material.
The second part, Chapters 5 to 11, covers the traditional algorithmic parts of the
language and roughly corresponds to the domain addressed by Pascal or C although
8 Introduction

the detail is much richer. The third part, Chapters 12 to 22, covers modern and
exciting material associated with data abstraction, programming in the large, OOP,
contracts, and parallel processing.
Finally, the fourth part, Chapters 23 to 27, completes the story by discussing the
predefined environment, interfacing to the outside world and the specialized
annexes; the concluding chapter also pulls together a number of threads that are
slightly dispersed in the earlier chapters and finishes with an introduction to SPARK.
There are also six complete program examples which are interspersed at various
points. The first follows Chapter 4 and illustrates various aspects of OOP. Others
follow Chapters 11, 13, 22, 23 and 25 and illustrate access types, data abstraction,
generics and tasking, string handling, and storage pools respectively. These
examples illustrate how the various components provided by Ada can be fitted
together to make a complete program. The full text of these programs including
additional comments and other explanatory material will be found on the associated
website.
Most sections contain exercises. It is important that the reader does most, if not
all, of these since they are an integral part of the discussion and later sections often
use the results of earlier exercises. Solutions to key exercises will be found at the
end of the book and solutions to them all will be found on the website.
Most chapters conclude with a short checklist of key points to be remembered.
Although incomplete, these checklists should help to consolidate understanding.
Various appendices are provided in order to make this book reasonably self-
contained. They cover matters such as reserved words, attributes, aspects, pragmas,
and restrictions. There is also a glossary of terms and the complete syntax organized
to correspond to the order in which the topics are introduced. The book concludes
with a Bibliography and Index
This book includes occasional references to Ada Issues. These are the reports of
the Ada Rapporteur Group (ARG) which analyses technical queries and drafts the
new Ada standards from time to time. Since Ada 2012 became an ISO standard, a
small number of improvements to the language have been made. For example,
AI12-33 concerns the addition of new facilities for grouping processors. The
relevant Issues are listed in the Index.
This book covers all aspects of Ada but does not explore every pathological
situation. Its purpose is to teach the reader the effect of and intended use of the
features of Ada. In a few areas the discussion is incomplete; these are areas such as
system dependent programming, input–output, and the specialized annexes. System
dependent programming (as its name implies) is so dependent upon the particular
implementation that only a brief overview seems appropriate. Input–output,
although important, does not introduce new concepts but is rather a mass of detail;
again a simple overview is presented. And, as their name implies, the specialized
annexes address the very specific needs of certain communities; to cover them in
detail would make this book excessively long and so only an overview is provided.
Further details of these areas can be found in the Ada Reference Manual (the
ARM) which is referred to from time to time. The appendices are mostly based upon
material drawn from the ARM. A related document is the Ada 2012 Rationale which
aims to explain the reasons for the upgrade from Ada 2005 to Ada 2012. Many of
the examples in this book are derived from those in the Rationale. There is also an
extended form of the reference manual known as the Annotated Ada Reference
Manual (the AARM) – this includes much embedded commentary and is aimed at
1.4 Structure and objectives of this book 9

the language lawyer and compiler writer. Readers transitioning from Ada 95 will
also find the Ada 2005 Rationale of interest. These documents will all be found on
the Ada website as described in the Bibliography. Traditional paper editions of most
of these documents are also available as well.
1.5 References
The references given here are to the formal standardization documents describing
the various versions of the Ada Programming Language. References to other
documents will be found in the Bibliography.
1 United States Department of Defense. Reference Manual for the Ada
Programming Language (ANSI/MIL-STD-1815A). Washington DC, 1983.
2 International Organization for Standardization. Information technology –
Programming languages – Ada. Ada Reference Manual. ISO/IEC
8652:1995(E).
Programming languages – Ada. Technical Corrigendum 1. ISO/IEC
8652:1995/COR.1:2001.
Programming languages – Ada. Amendment 1. ISO/IEC
8652:1995/AMD.1:2006.
Programming languages – Ada. Ada Reference Manual. ISO/IEC
8652:2012(E).
10 Introduction

2 Simple Concepts
11
2.1 Key goals
2.2 Overall structure
2.3 The scalar type model
2.4 Arrays and records
2.5 Access types
2.6 Errors and exceptions
2.7 Terminology
This is the first of three chapters covering in outline the main goals, concepts and
features of Ada. Enough material is given in these chapters to enable the reader
to write significant programs. It also allows the reader to create a framework in
which the exercises and other fragments of program can be executed, if desired,
before all the required topics are discussed in depth.
The material covered in this chapter corresponds approximately to that in
simple languages such as Pascal and C.
2.1 Key goals
Ada is a large language since it addresses many important issues relevant to the
programming of practical systems in the real world. It is much larger than
Pascal which is really only suitable for training purposes and for small personal
programs. Ada is similarly much larger than C although perhaps of the same order
of size as C++. But a big difference is the stress which Ada places on integrity and
readability. Some of the key issues in Ada are
• Readability – professional programs are read much more often than they are
written. So it is important to avoid a cryptic notation such as in APL which,
although allowing a program to be written down quickly, makes it almost
impossible to be read except perhaps by the original author soon after it was
written.
• Strong typing – this ensures that each object has a clearly defined set of values
and prevents confusion between logically distinct concepts. As a consequence
many errors are detected by the compiler which in other languages (such as C)
can lead to an executable but incorrect program.

• Programming in the large – mechanisms for encapsulation, separate
compilation and library management are necessary for the writing of portable
and maintainable programs of any size.
• Exception handling – it is a fact of life that programs of consequence are
rarely perfect. It is necessary to provide a means whereby a program can be
constructed in a layered and partitioned way so that the consequences of
unusual events in one part can be contained.
• Data abstraction – extra portability and maintainability can be obtained if the
details of the representation of data are kept separate from the specifications of
the logical operations on the data.
• Object oriented programming – in order to promote the reuse of tested code,
the type flexibility associated with OOP is important. Type extension
(inheritance), polymorphism and late binding are all desirable especially when
achieved without loss of type integrity.
• Tasking – for many applications it is important to conceive a program as a
series of parallel activities rather than just as a single sequence of actions.
Building appropriate facilities into a language rather than adding them via calls
to an operating system gives better portability and reliability.
• Generic units – in many cases the logic of part of a program is independent of
the types of the values being manipulated. A mechanism is therefore necessary
for the creation of related pieces of program from a single template. This is
particularly useful for the creation of libraries.
• Communication – programs do not live in isolation and it is important to be
able to communicate with systems possibly written in other languages.
An overall theme in the design of Ada was concern for the programming
process as a human activity. An important aspect of this is enabling errors to be
detected early in the overall process. For example a single typographical error in
Ada usually results in a program that does not compile rather than a program that
still compiles but does the wrong thing. We shall see some examples of this in
Section 2.6.
2.2 Overall structure
An important objective of software engineering is to reuse existing pieces of
program so that detailed new coding is kept to a minimum. The concept of a
library of program components naturally emerges and an important aspect of a
programming language is therefore its ability to access the items in a library.
Ada recognizes this situation and introduces the concept of library units. A
complete Ada program is conceived as a main subprogram (itself a library unit)
which calls upon the services of other library units. These library units can be
thought of as forming the outermost lexical layer of the total program.
The main subprogram takes the form of a procedure of an appropriate name.
The service library units can be subprograms (procedures or functions) but they are
more likely to be packages. A package is a group of related items such as
subprograms but may contain other entities as well.
12 Simple concepts

Suppose we wish to write a program to print out the square root of some
number. We can expect various library units to be available to provide us with a
means of computing square roots and performing input and output. Our job is
merely to write a main subprogram to use these services as we wish.
We will suppose that the square root can be obtained by calling a function in
our library whose name is Sqrt. We will also suppose that our library includes a
package called Simple_IO containing various simple input–output facilities. These
facilities might include procedures for reading numbers, printing numbers, printing
strings of characters and so on.
Our program might look like
with Sqrt, Simple_IO;
procedure Print_Root is
use Simple_IO; -- declarations here
X: Float;
begin
Get(X); -- statements here
Put(Sqrt(X));
end Print_Root;
The program is written as a procedure called Print_Root preceded by a with clause
giving the names of the library units which it wishes to use. Between is and begin
we can write declarations, and between begin and end we write statements. Broadly
speaking, declarations introduce the entities we wish to manipulate and statements
indicate the sequential actions to be performed.
We have introduced a variable X of type Float which is a predefined language
type. Values of this type are a set of floating point numbers and the declaration of
X indicates that X can have values only from this set. A value is assigned to X by
calling the procedure Get which is in our package Simple_IO.
Writing
use Simple_IO;
gives us immediate access to the facilities in the package Simple_IO. If we had
omitted this use clause we would have had to write
Simple_IO.Get(X);
in order to indicate where Get was to be found.
The program then calls the procedure Put in the package Simple_IO with a para-
meter which in turn is the result of calling the function Sqrt with the parameter X.
Some small-scale details should be noted. The various statements and
declarations all terminate with a semicolon; this is like C but unlike Pascal where
semicolons are separators rather than terminators. The program contains various
words such as procedure, Put and X. These fall into two categories. A few (73 in
fact) such as procedure and is are used to indicate the structure of the program;
they are reserved words and can be used for no other purpose. All others, such as
Put and X, can be used as identifiers for whatever purpose we desire. Some of these,
such as Float in the example, have a predefined meaning but we can nevertheless
reuse them although it might be confusing to do so. For clarity in this book we write

the reserved words in lower case bold and use leading capitals for all others. This is
purely a matter of style; the language rules do not distinguish the two cases except
when we consider the manipulation of characters themselves. Note also how the
underline character is used to break up long identifiers to increase readability.
Finally, observe that the name of the procedure, Print_Root, is repeated between
the final end and the terminating semicolon. This is optional but is recommended
so as to clarify the overall structure although this is obvious in a small example such
as this.
Our program is very simple; it might be more useful to enable it to cater for a
whole series of numbers and print out each answer on a separate line. We could stop
the program somewhat arbitrarily by giving it a value of zero.
with Sqrt, Simple_IO;
procedure Print_Roots is
use Simple_IO;
X: Float;
begin
Put("Roots of various numbers");
New_Line(2);
loop
Get(X);
exit when X = 0.0;
Put(" Root of "); Put(X); Put(" is ");
if X < 0.0 then
Put("not calculable");
else
Put(Sqrt(X));
end if;
New_Line;
end loop;
New_Line;
Put("Program finished");
New_Line;
end Print_Roots;
The output has been enhanced by calling further procedures New_Line and Put
in the package Simple_IO. A call of New_Line outputs the number of new lines
specified by the parameter (of the predefined type Integer); the procedure New_Line
has been written in such a way that if no parameter is supplied then a default value
of 1 is assumed. There are also calls of Put with a string as argument. This is a
different procedure from the one that prints the number X. The compiler
distinguishes them by the different types of parameters. Having more than one
subprogram with the same name is known as overloading. Note also the form of
strings; this is a situation where the case of the letters does matter.
Various new control structures are also introduced. The statements between
loop and end loop are repeated until the condition X = 0.0 in the exit statement is
found to be true; when this is so the loop is finished and we immediately carry on
after end loop. We also check that X is not negative; if it is we output the message
‘not calculable’ rather than attempting to call Sqrt. This is done by the if statement;
14 Simple concepts

if the condition between if and then is true, then the statements between then and
else are executed, otherwise those between else and end if are executed.
The general bracketing structure should be observed; loop is matched by end
loop and if by end if. All the control structures of Ada have this closed form rather
than the open form of Pascal and C which can lead to poorly structured and
incorrect programs.
We will now consider in outline the possible general form of the function Sqrt
and the package Simple_IO that we have been using.
The function Sqrt will have a structure similar to that of our main subprogram;
the major difference will be the existence of parameters.
function Sqrt(F: Float) return Float is
R: Float;
begin
... -- compute value of Sqrt(F) in R
return R;
end Sqrt;
We see here the description of the formal parameters (in this case only one) and
the type of the result. The details of the calculation are represented by the comment
which starts with a double hyphen. The return statement is the means by which the
result of the function is indicated. Note the distinction between a function which
returns a result and is called as part of an expression, and a procedure which does
not have a result and is called as a single statement.
The package Simple_IO will be in two parts: the specification which describes
its interface to the outside world, and the body which contains the details of how it
is implemented. If it just contained the procedures that we have used, its
specification might be
package Simple_IO is
procedure Get(F: out Float);
procedure Put(F: in Float);
procedure Put(S: in String);
procedure New_Line(N: in Integer := 1);
end Simple_IO;
The parameter of Get is an out parameter because the effect of a call such as Get(X);
is to transmit a value out from the procedure to the actual parameter X. The other
parameters are all in parameters because the value goes in to the procedures. The
parameter mode can be omitted and is then taken as in by default. There is a third
mode in out which enables the value to go both ways. Both functions and
procedures can have parameters of all modes. We usually give the mode in for
procedures explicitly but omit it for functions.
Only a part of the procedures occurs in the package specification; this part is
known as the procedure specification and just gives enough information to enable
the procedures to be called.
We see also the two overloaded specifications of Put, one with a parameter of
type Float and the other with a parameter of type String. Finally, note how the
default value of 1 for the parameter of New_Line is indicated.

The package body for Simple_IO will contain the full procedure bodies plus any
other supporting material needed for their implementation and is naturally hidden
from the outside user. In vague outline it might look like
with Ada.Text_IO;
package body Simple_IO is
procedure Get(F: out Float) is
...
end Get;
... -- other procedures similarly
end Simple_IO;
The with clause shows that the implementation of the procedures in Simple_IO
uses the more general package Ada.Text_IO. The notation indicates that Text_IO is
a child package of the package Ada. It should be noticed how the full body of Get
repeats the procedure specification which was given in the corresponding package
specification. (The procedure specification is the bit up to but not including is.)
Note that the package Ada.Text_IO really exists whereas Simple_IO is a figment of
our imagination made up for the purpose of this example. We will say more about
Ada.Text_IO in Chapter 4.
The example in this section has briefly revealed some of the overall structure
and control statements of Ada. One purpose of this section has been to stress that
the idea of packages is one of the most important concepts in Ada. A program
should be conceived as a number of components which provide services to and
receive services from each other.
Finally, note that there is a special package Standard which exists in every
implementation and contains the declarations of all the predefined identifiers such
as Float and Integer. Access to Standard is automatic and it does not have to be
mentioned in a with clause. It is discussed in detail in Chapter 23.
Exercise 2.2
1 Suppose that the function Sqrt is not on its own but in a package Simple_Maths
along with other mathematical functions Log, Ln, Exp, Sin and Cos. By analogy
with the specification of Simple_IO, write the specification of such a package.
How would the program Print_Roots need to be changed?
2.3 The scalar type model
We have said that one of the key benefits of Ada is its strong typing. This is well
illustrated by the enumeration type. Consider
declare
type Colour is (Red, Amber, Green);
type Fish is (Cod, Hake, Salmon);
X, Y: Colour;
A, B: Fish;
begin
16 Simple concepts

2.3 The scalar type model 17
X := Red; -- ok
A := Hake; -- ok
B := X; -- illegal
...
end;
This fragment of program is a block which declares two enumeration types
Colour and Fish, and two variables of each type, and then performs various
assignments. The declarations of the types give the allowed values of the types.
Thus the variable X can only take one of the three values Red, Amber or Green. The
fundamental rule of strong typing is that we cannot assign a value of one type to a
variable of a different type. So we cannot mix up colours and fishes and thus our
(presumably accidental) attempt to assign the value of X to B is illegal and will be
detected during compilation.
Four enumeration types are predefined in the package Standard. One is
type Boolean is (False, True);
which plays a key role in control flow. Thus the predefined relational operators such
as < produce a result of this type and such a value follows if as in
if X < 0.0 then
The other predefined enumeration types are Character, Wide_Character and Wide_
Wide_Character whose values are the 8-bit ISO Latin-1, the 16-bit ISO Basic
Multilingual Plane and the full 32-bit ISO 10646 characters; these types naturally
play an important role in input–output. Their literal values include the printable
characters and these are represented by placing them in single quotes thus 'X' or 'a'
or indeed '''.
The other fundamental types are the numeric types. One way or another, all
other data types are built out of enumeration types and numeric types. The two
major classes of numeric types are the integer types and floating point types (there
are also fixed point types which are rather obscure and deserve no further mention
in this overview). The integer types are further subdivided into signed integer types
(such as Integer) and unsigned or modular types. All implementations have the
types Integer and Float. An implementation may also have other predefined numeric
types, Long_Integer, Long_Float, Short_Float and so on. There will also be specific
integer types for an implementation depending upon the supported word lengths
such as Integer_16 and unsigned types such as Unsigned_16.
One of the problems of numeric types is how to obtain both portability and
efficiency in the face of variation in machine architecture. In order to explain how
this is done in Ada it is convenient to introduce the concept of a derived type. (We
will deal with derived types in more detail in the next chapter when we come to
object oriented programming.)
The simplest form of derived type introduces a new type which is almost
identical to an existing type except that it is logically distinct. If we write
type Light is new Colour;
then Light will, like Colour, be an enumeration type with literals Red, Amber and
Green. However, values of the two types cannot be arbitrarily mixed since they are

logically distinct. Nevertheless, in recognition of the close relationship, a value of
one type can be converted to the other by explicitly using the destination type name.
So we can write
declare
type Light is new Colour;
C: Colour;
L: Light;
begin
L := Amber; -- the light amber, not the colour
C := Colour(L); -- explicit conversion
...
end;
whereas a direct assignment
C := L; -- illegal
would violate the strong typing rule and this violation would be detected during
compilation.
Returning now to the numeric types, if we write
type My_Float is new Float;
then My_Float will have all the operations (+, - etc.) of Float and in general can be
considered as equivalent. Now suppose we transfer the program to a different
computer on which the predefined type Float is not so accurate and that Long_Float
is necessary. Assuming that the program has been written using My_Float rather
than Float then replacing the declaration of My_Float by
type My_Float is new Long_Float;
is the only change necessary. We can actually do better than this by directly stating
the precision that we require, thus
type My_Float is digits 7;
will cause My_Float to be based on the smallest predefined type with at least 7
decimal digits of accuracy.
A similar approach is possible with integer types so that rather than using the
predefined types we can give the range of values required thus
type My_Integer is range -1000_000 .. +1000_000;
The point of all this is that it is not good practice to use the predefined numeric
types directly when writing professional programs which may need to be portable.
However, for simplicity, we will generally use the types Integer and Float in
examples in most of this book. We will say no more about numeric types for the
moment except that all the expected operations apply to all integer and floating
types.
18 Simple concepts

2.4 Arrays and records
Ada naturally enables the creation of composite array and record types. Arrays
may actually be declared without giving a name to the underlying type (the
type is then said to be anonymous) but records always have a type name.
As an example of the use of arrays suppose we wish to compute the successive
rows of Pascal’s triangle. This is usually represented as shown in Figure 2.1. The
reader will recall that the rows are the coefficients in the expansion of (1 + x)n
and
that a neat way of computing the values is to note that each one is the sum of the
two diagonal neighbours in the row above.
Suppose that we are interested in the first ten rows. We could declare an array
to hold such a row by
Pascal: array (0 .. 10) of Integer;
and now assuming that the current values of the array Pascal correspond to row n–1,
with the component Pascal(0) being 1, then the next row could be computed in a
similar array Next by
Next(0) := 1;
for I in 1 .. N-1 loop
Next(I) := Pascal(I-1) + Pascal(I);
end loop;
Next(N) := 1;
and then the array Next could be copied into the array Pascal.
This illustrates another form of loop statement where a controlled variable I
takes successive values from a range; the variable is automatically declared to be of
the type of the range which in this case is Integer. Note that the intermediate array
Next could be avoided by iterating backwards over the array; we indicate this by
writing reverse in front of the range thus
Pascal(N) := 1;
for I in reverse 1 .. N-1 loop
Pascal(I) := Pascal(I-1) + Pascal(I);
end loop;
We can also declare arrays of several dimensions. So if we wanted to keep all
the rows of the triangle we might declare
Figure 2.1 Pascal’s triangle.
1
1 1
1 2 1
1 3 3 1
1 4 6 4 1
1 5 10 10 5 1

Pascal2: array (0 .. 10, 0 .. 10) of Integer;
and then the loop for computing row n would be
Pascal2(N, 0) := 1;
for I in 1 .. N-1 loop
Pascal2(N, I) := Pascal2(N-1, I-1) + Pascal2(N-1, I);
end loop;
Pascal2(N, N) := 1;
We have declared the arrays without giving a name to their type. We could
alternatively have written
type Row is array (0 .. Size) of Integer;
Pascal, Next: Row;
where we have given the name Row to the type and then declared the two arrays
Pascal and Next. There are advantages to this approach as we shall see later.
Incidentally the bounds of an array do not have to be constant, they could be any
computed values such as the value of some variable Size.
We conclude this brief discussion of arrays by noting that the type String which
we encountered in Section 2.2 is in fact an array whose components are of the
enumeration type Character. Its declaration (in the package Standard) is
type String is array (Positive range <>) of Character;
and this illustrates a form of type declaration which is said to be indefinite because
it does not give the bounds of the array; these have to be supplied when an object is
declared
A_Buffer: String(1 .. 80);
Incidentally the identifier Positive in the declaration of the type String denotes
what is known as a subtype of Integer; values of the subtype Positive are the positive
integers and so the bounds of all arrays of type String must also be positive – the
lower bound is of course typically 1 but need not be.
A record is an object comprising a number of named components typically of
different types. We always have to give a name to a record type. If we were
manipulating a number of buffers then it would be convenient to declare a record
type containing the buffer and an indication of the start and finish of that part of the
buffer actually containing useful data.
type Buffer is
record
Data: String(1 .. 80);
Start, Finish: Integer;
end record;
An individual buffer could then be declared by
My_Buffer: Buffer;
20 Simple concepts

and the components of the buffer can then be manipulated using a dotted notation
to select the individual components
My_Buffer.Start := 1;
My_Buffer.Finish := 3;
My_Buffer.Data(1 .. 3) := "XYZ";
Note that the last statement assigns values to the first three components of the array
My_Buffer.Data using a so-called slice.
Whole array and record values can be created using aggregates which are
simply a set of values in parentheses separated by commas.
Thus we could assign appropriate values to Pascal and to My_Buffer by
Pascal(0 .. 4) := (1, 4, 6, 4, 1);
My_Buffer := (Data => ('X', 'Y', 'Z', others => ' '), Start => 1, Finish => 3);
where in the latter case we have in fact assigned all 80 values to the array
My_Buffer.Data and used others so that after the three useful characters the
remainder of the array is padded with spaces. Note the nesting of parentheses and
the optional use of named notation for the record components.
This concludes our brief discussion on simple arrays and records. In the next
chapter we will show how record types can be extended.
Exercise 2.4
1 Write statements to copy the array Next into the array Pascal.
2 Write a nested loop to compute all the rows of Pascal’s triangle in the two-
dimensional array Pascal2.
3 Declare a type Month_Name and then declare a type Date with components
giving the day, month and year. Then declare a variable Today and assign
Queen Victoria’s date of birth to it (or your own).
2.5 Access types
The previous section showed how the scalar types (numeric and enumeration
types) may be composed into arrays and records. The other vital means for
creating structures is through the use of access types (the Ada name for pointer
types); access types allow list processing and are typically used with record types.
The explicit manipulation of pointers or references has been an important
feature of most languages since Algol 68. References rather dominated Algol 68
and caused problems and the corresponding pointer facility in Pascal is rather
austere. The pointer facility in C on the other hand provides raw flexibility which is
open to abuse and quite insecure and thus the cause of many wrong programs.
Ada provides both a high degree of reliability and considerable flexibility
through access types. A full description will be found in Chapter 11 but the
following brief description will be useful for discussing polymorphism in the next
chapter.

22 Simple concepts
Ada access types must explicitly indicate the type of data to which they refer.
The most general form of access types can refer to any data of the type concerned
but we will restrict ourselves in this overview to applications which just refer to
data declared in a storage pool (the Ada term for a heap).
For example suppose we wanted to declare various buffers of the type Buffer in
the previous section. We might write
Handle: access Buffer;
...
Handle := new Buffer;
This allocates a buffer in the storage pool and sets a reference to it into the variable
Handle. We can then refer to the various components of the buffer indirectly using
the variable Handle
Handle.Start := 1;
Handle.Finish := 3;
and we can refer to the complete record as Handle.all. Note that Handle.Start is
strictly an abbreviation for Handle.all.Start.
Access types are of particular value for list processing where one record
structure contains an access value to another record structure. The classic example
which we will encounter in many forms is typified by
type Cell is
record
Next: access Cell;
Value: Data;
end record;
The type Cell is a record containing a component Next which can refer to
another similar record plus a component of some type Data. An example of the use
of this sort of construction will be found in the next chapter.
Sometimes it is important to give a name to an access type. We can rewrite the
above example so that the component Next is of a named type by first using an
incomplete type thus
type Cell; -- incomplete declaration
type Cell_Ptr is access Cell;
type Cell is -- the completion
record
Next: Cell_Ptr;
Value: Data;
end record;
Using this two stage approach and naming the access type is necessary if we are
doing our own control of storage as described in Section 25.4.
Access types often refer to record types as in these examples but can refer to
any type. Access types may also be used to refer to subprograms and this is
particularly important for certain repetitive operations and when communicating
with programs in other languages.

2.6 Errors and exceptions
We introduce this topic by considering what would have happened in the
example in Section 2.2 if we had not tested for a negative value of X and
consequently called Sqrt with a negative argument. Assuming that Sqrt has itself
been written in an appropriate manner then it clearly cannot deliver a value to be
used as the parameter of Put. Instead an exception will be raised. The raising of an
exception indicates that something unusual has happened and the normal sequence
of execution is broken. In our case the exception might be Constraint_Error which
is a predefined exception declared in the package Standard. If we did nothing to
cope with this possibility then our program would be terminated and no doubt the
Ada Run Time System will give us a rude message saying that our program has
failed and why. We can, however, look out for an exception and take remedial
action if it occurs. In fact we could replace the conditional statement
if X < 0.0 then
else
Put(Sqrt(X));
end if;
by the block
begin
Put(Sqrt(X));
exception
when Constraint_Error =>
end;
If an exception is raised by the sequence of statements between begin and
exception, then control immediately passes to the one or more statements following
the handler for that exception and these are obeyed instead. If there were no handler
for the exception (it might be another exception such as Storage_Error) then control
passes up the nested sequence of calls until we come to an appropriate handler or
fall out of the main subprogram, which then becomes terminated as we mentioned
with a message from the Run Time System.
The above example is not a good illustration of the use of exceptions since the
event we are guarding against can easily be tested for directly. Nevertheless it does
show the general idea of how we can look out for unexpected events, and leads us
into a brief consideration of errors in general.
From the linguistic viewpoint, an Ada program may be incorrect for various
reasons. There are four categories according to how they are detected.
• Many errors are detected by the compiler – these include simple punctuation
mistakes such as leaving out a semicolon or attempting to violate the type rules
such as mixing up colours and fishes. In these cases the program is said to be
illegal and will not be executed.

• Other errors are detected when the program is executed. An attempt to find the
square root of a negative number or divide by zero are examples of such errors.
In these cases an exception is raised as we have just seen.
• There are also certain situations where the program breaks the language rules
but there is no simple way in which this violation can be detected. For example
a program should not use a variable before a value is assigned to it. In cases like
this the behaviour is not predictable but will nevertheless lie within certain
bounds. Such errors are called bounded errors.
• In more extreme situations there are some kinds of errors which can lead to
quite unpredictable behaviour. In these (quite rare) cases we say that the
behaviour is erroneous.
Finally, there are situations where, for implementation reasons, the language
does not prescribe the order in which things are to be done. For example, the order
in which the parameters of a procedure call are evaluated is not specified. If the
behaviour of a program does depend on such an order then it is not considered to be
incorrect but just not portable.
We mentioned earlier that an overall theme in the design of Ada was concern
for correctness and that errors should be detected early in the programming process.
As a simple example consider a fragment of program controlling the crossing gates
on a railroad. First we have an enumeration type describing the state of a signal
type Signal is (Danger, Caution, Clear);
and then perhaps
if The_Signal = Clear then
Open_Gates;
Start_Train;
end if;
It is instructive to consider how this might be written in C and then to consider
the consequences of various simple programming errors. Enumeration types in C
are not strongly typed and essentially just provide names for integer (int) constants
with values 0, 1 and 2 representing the three states. This has potential for errors
because there is nothing in C that can prevent us from assigning a silly value such
as 4 to a signal whereas it is not even possible to attempt such a thing when using
the Ada enumeration type.
The corresponding text in C might be
if (the_signal == clear)
{
open_gates();
start_train();
}
It is interesting to consider what would happen in the two languages if we make
various typographical errors. Suppose first that we accidentally type an extra
semicolon at the end of the first line. The Ada program then fails to compile and the
error is immediately drawn to our attention; the C program however still compiles
and the condition is ignored (since it then controls no statements). The C program
24 Simple concepts

consequently always opens the gates and starts the train irrespective of the state of
the signal!
Another possibility is that one of the = signs might be omitted in C. The equality
then becomes an assignment and also returns the result as the argument for the test.
The program still compiles, the signal is set clear, the condition is true (since clear
is not 0) and so the gates are always opened and the train started on its perilous
journey. The corresponding error in Ada might be to write := instead of = and of
course the program will then not compile.
Of course, many errors cannot be detected at compile time. For example using
My_Buffer and a variable Index of type Integer, we might write
Index := 81;
...
My_Buffer.Data(Index) := 'x';
which attempts to write to the 81st component of the array which does not exist.
Such assignments are checked in Ada at run time and Constraint_Error would be
raised so that the integrity of the program is not violated.
The corresponding instructions in C would undoubtedly overwrite an adjacent
piece of storage and probably corrupt the value in My_Buffer.Start.
It often happens that variables such as Index can only sensibly have a certain
range of values; this can be indicated by introducing a subtype
subtype Buffer_Index is Integer range 1 .. 80;
Index: Buffer_Index;
or by indicating the constraint directly
Index: Integer range 1 .. 80;
Applying a constraint to Index has the advantage that the attempt to assign 81
to it is itself checked and prevented so that the error is detected even earlier.
The reader may feel that such checks will make the program slower. This is not
usually the case as we shall see in Chapter 15.
2.7 Terminology
We conclude this first introductory chapter with a few remarks on terminology.
Every subject has its own terminology or jargon and Ada is no exception.
(Indeed in Ada an exception is a kind of error as we have seen!) A useful glossary
of terms will be found in Appendix 2.
Terminology will generally be introduced as required but before starting off
with the detailed description of Ada it is convenient to mention a few concepts
which will occur from time to time.
The term static refers to things that can be determined at compilation, whereas
dynamic refers to things determined during execution. Thus a static expression is
one whose value can be determined by the compiler such as
2 + 3
and a statically constrained array is one whose bounds are known at compilation.

The term real comes up from time to time in the context of numeric types. The
floating point types and fixed point types are collectively known as real types.
(Fixed point types are rather specialized and not discussed until Chapter 17.)
Literals such as 2.5 are known as real literals since they can be used to denote values
of both floating and fixed point types. Other uses of the term real will occur in due
course.
The terminology used with exceptions in Ada is that an exception is raised and
then handled. Some languages say that an exception is thrown and then caught.
We talk about statements being executed and expressions being evaluated.
Moreover, declarations can also require processing and this is called being
elaborated.
Object oriented programming has its own rather specialized terminology and a
section is devoted to this in the next chapter. One particular term that seems to be
overused is interface. We use interface in a very general sense to mean the
description of a means of communication. As we noted in Section 2.2, the
specification of a package describes its interface to the outside world. But interface
also has a highly technical meaning in OOP as we shall see in the next chapter. As
usual in any language, the context should clarify the intended meaning.
26 Simple concepts

3 Abstraction
27
3.1 Packages and private types
3.2 Objects and inheritance
3.3 Classes and polymorphism
3.4 Genericity
3.5 Object oriented terminology
3.6 Tasking
As mentioned in Chapter 1, abstraction in various forms seems to be the key to
the development of programming languages. In this chapter we survey various
aspects of abstraction with particular emphasis on the object oriented paradigm.
3.1 Packages and private types
In the previous chapter we declared a type for the manipulation of a buffer as
follows
type Buffer is
record
Data: String(1 .. 80);
Start: Integer;
Finish: Integer;
end record;
in which the component Data actually holds the characters in the buffer and Start
and Finish index the ends of the part of the buffer containing useful information. We
also saw how the various components might be updated and read using normal
assignment.
However, such direct assignment is often unwise since the user could inadver-
tently set inconsistent values into the components or read nonsense components of
the array.
A much better approach is to create an Abstract Data Type (ADT) so that the
user cannot see the internal details of the type but can only access it through various
subprogram calls which define an appropriate protocol.

This can be done using a package containing a private type. Let us suppose that
the protocol allows us to reload the buffer (possibly not completely full) and to read
one character at a time. Consider the following
package Buffer_System is -- visible part
type Buffer is private;
procedure Load(B: out Buffer; S: in String);
procedure Get(B: in out Buffer; C: out Character);
private -- private part
Max: constant Integer := 80;
type Buffer is
record
Data: String(1 .. Max);
Start: Integer := 1;
Finish: Integer := 0;
end record;
end Buffer_System;
package body Buffer_System is -- package body
procedure Load(B: out Buffer; S: in String) is
begin
B.Start := 1;
B.Finish := S'Length;
B.Data(B.Start .. B.Finish) := S;
end Load;
procedure Get(B: in out Buffer; C: out Character) is
begin
C := B.Data(B.Start);
B.Start := B.Start + 1;
end Get;
end Buffer_System;
Note how the package comes in two parts, the specification and the body.
Basically the specification describes the interface to other parts of the program and
the body gives implementation details.
With this formulation the client can only access the information in the visible
part of the specification which is the bit before the word private. In this visible part
the declaration of the type Buffer merely says that it is private and the full
declaration then occurs in the private part. There are thus two views of the type
Buffer; the external client just sees the partial view whereas within the package the
code of the server subprograms can see the full view. The specifications of the
server subprograms are naturally also declared in the visible part and the full bodies
which give their implementation details are in the package body.
The net effect is that the user can declare and manipulate a buffer by simply
writing
My_Buffer: Buffer;
...
28 Abstraction

Exploring the Variety of Random
Documents with Different Content

McAdoo, William G.,
biography, ix: 329-331;
Director General, U. S. Railroad Administration, xii: 88.
McAlexander, Brig.-Gen. U. G.,
as colonel commands 38th Inf. Regt. in second battle of the Marne, July, '18, v: 152;
commands 180th Inf. Brig, at St. Mihiel, Sept. 12—15, '18, v: 209;
biography, ix: 216.
McAndrew, Maj.-Gen. James W.,
succeeds Gen. Harbord as Chief of Staff, A. E. F., Aug., '17, v: 102;
Pershing's appreciation, v: 403-404;
biography, ix: 216.
McCaw, Brig.-Gen. Walter D., Chief Surgeon, A. E. F., v: 346.
McLemore Resolution,
warning to Americans not to travel on belligerent ships, i: 327;
President Wilson opposes, i: 327;
defeated, i: 328.
McLeod, Marguerite Gertrude Zelle, German spy, discloses tank secret, x: 360.
McMahon, Maj.-Gen. James E.,
in command of 5th Div., May, '18, v: 128;
at St. Mihiel, Sept. 12, '18, v: 202;
relieved of command of 5th Div., Oct., '18, v: 252.
McMurtry, Capt. George C., gets Congressional Medal of Honor, x: 399.
McRae, Maj.-Gen. James H.,
in command of 78th Div., June, '18, v: 144;
at St. Mihiel, Sept. 12, '18, v: 202.
Meat packers, profits before and during War, xii: 56.
Mecca, captured by Arabs, July 15, '16, i: 386.
Medeah Farm, captured by 67th French Div., Oct. 3, '18, v: 256.
Medical Corps, U. S., see U. S., Army.
Medical science,
use of X-ray, vii: 221, viii: 373-376;
development under war needs, viii: 361-365, xi: 286-291;
rifle and shell wounds, relative dangers of, viii: 361;
French medical service for wounded, viii: 362-365;
danger of infection in shell wounds, viii: 362, 367;
treatment of head wounds, viii: 365;
treatment of face wounds, viii: 366;
treatment of body wounds, viii: 366;
treatment of blood vessel lesions, viii: 366;
treatment of nerve cord lesions, viii: 366;
treatment of fractures, viii: 367;
new method of amputation, viii: 367;

prevention of tetanus infection, viii: 367, xi: 287;
prevention of gas gangrene, viii: 367, xi: 287-288;
treatment of shell shock, viii: 368;
causes of infection, viii: 369;
Carrel-Dakin treatment, viii: 369-372, xi: 288-289;
mechanical treatments for injured limbs, viii: 381-384;
artificial arms for war cripples, viii: 384-388;
artificial legs for war cripples, viii: 388-390;
reconstructing mutilated faces, viii: 390;
use of ambrine in treatment of burns, viii: 390;
artificial eyes for war blind, viii: 391;
prevention of infectious diseases among troops, viii: 392-397;
anti-typhoid immunization, viii: 393;
making drinking water safe for army, viii: 394-396;
see also:
Disease;
Infection;
Reconstruction of disabled;
Sanitation;
Surgery.
Medwa, Turks defeated at, by British, Jan., '16, iii: 191.
Mehun, U. S. Ordnance repair shop at, v: 350.
Memel,
captured by Russians, Mar. 19, '15, i: 378;
evacuated by Russians, Mar. 21, '15, i: 378;
raided by Russian fleet, Mar., '15, iv: 365;
Peace Treaty provisions concerning, xii: 203.
Men of Harlech, Welsh national hymn, xi: 330.
Menoher, Maj.-Gen. Charles T.,
commander 42nd Div., '17, v: 109;
at St. Mihiel, Sept., '18, v: 202.
Mensheviki, Russian political party, doctrines of, vi: 148.
Menshikov, Russian imperialist, outlines plan of conquest, '14, vi: 134.
Merchant marine, see Shipping.
Mercier, Cardinal Désiré, biography and war-time activities, ix: 341-343.
Mersey, British monitor, in Flanders and East Africa, iv: 281.
Mersey, Lord, official report on Lusitania sinking, i: 362-365.
Merville salient, evacuation of, by Germans, iii: 98.
Mesopotamia,
German dream of acquisition, ii: 27;
British irrigation schemes in, ii: 295;
terrain and climate, iii: 178;

historic background of modern battlefields, iii: 329-334;
disposition under secret treaties of '16—'17, vi: 334;
area and population, xii: 279.
Mesopotamian Campaign,
strategic importance and Allied plan of operations, ii: Intro. xvi, 87-91, iii: 178-180;
British land troops at Fao to protect oil fields, Nov., '14, ii: Intro. xvi, iii: 180;
Gen. Nixon pursues Turks and threatens Bagdad, '15, ii: Intro. xvi, 91, iii: 180-182;
British defeated at Ctesiphon and driven into Kut-el-Amara, Dec., '15, ii: Intro. xvi,
91, 182-183;
siege of Kut and Gen. Townshend's surrender, Dec. 7, '15—Apr. 29, '16, ii: Intro.
xvii, 91, iii: 183-185, 363, 364;
British reorganize campaign after Kut disaster, ii: Intro. xviii, 92, iii: 185;
British capture Bagdad, Mar. 11, '17, ii: Intro. xviii, 92, iii: 187;
British landing force advances to Basra and Kurna, Dec., '14, iii: 180;
British capture Kut-el-Amara, Sept., '15, iii: 181;
unsuccessful attempts to relieve siege of Kut, iii: 184-185;
Gen. Maude placed in command of British, '16, iii: 185;
causes of and responsibility for British disaster, report of Royal Commission, iii:
185, 363-370;
battle of Sannyat, iii: 185-187;
bibliography, iii: 187;
personnel of Commission of inquiry, iii: 363;
conditions in Kut during siege, iii: 364;
casualties in attempts to relieve Kut, iii: 364.
Messines Ridge,
British mine and blow up German positions, June, '17, ii: 56, iii: 74, 76-77, viii: 310;
nature of German defenses, iii: 77;
casualties, British and German, iii: 77;
recaptured by Germans, Apr., '18, iii: 360.
Messudiyeh, Turkish warship, blown up in Dardanelles, Dec. 13, '14, i: 376, x: 317.
Mestrovitch, Sgt. James I., gets Congressional Medal of Honor, x: 393.
Meteor, German raider in Baltic, iv: 197.
Metternich, Prince, theory of government, i: 33.
Metz,
bombarded by British airmen, Jan. 14, '18, i: 393;
entered by French, Nov. 19, '18, i: 400;
Allied plan for capture of, Nov., '18, v: 274.
Meurer, Vice-Adm., German delegate to arrange for surrender of German fleet, iv: 384.
Meurthe River, line of defense before Nancy, iii: 19.
Meuse River,
French forced to retire from, Aug., '14, iii: 20;
German attempt to invade France through valley of, '14, v: 199.

Meuse-Argonne Offensive,
concentration of A. E. F. for, Sept., '18, ii: 84, v: 75, 218, 388;
objectives, ii: 84, 214, 387;
topography of battleground, ii: 214, v: 73-74, 90, 217-218;
strategic importance, ii: 215, v: 214-216, 387;
breakdown of A. E. F. supply service, ii: 215;
Ludendorff's comment on, ii: 334;
detailed account of battle, Sept. 25—Nov. 11. '18, iii: 100, v: 72-95, 213-253, 260-279;
extent of A. E. F. front, v: 72-73, 217, 390;
Allied plan of campaign, v: 73, 75, 216, 218;
A. E. F. divisions participating, with positions in line, v: 74, 219-222, 388;
German defenses, position and strength, v: 74, 217-218, 388;
A. E. F. advance to Kriemhilde position, v: 78-82;
Allies break through Kriemhilde line, v: 83-88;
Germans dislodged and thrown across the Meuse, Nov., '18, v: 88-95;
number of French troops participating, v: 220, 388;
German strength, v: 220, 388;
day by day account of operations, Sept. 25—Oct. 3, v: 222-233;
number of Allied airplanes, v: 223, 388;
day by day account, Oct. 4—31, v: 234-253;
day by day account of last phase, Nov. 1—11, v: 260-279;
Argonne Forest cleared of Germans, Nov. 3, '18, v: 266;
number of Allied tanks used, v: 315, 388;
sector assigned to A. E. F., v: 385;
Pershing's official report, v: 386-393;
Allies' artillery strength, v: 388;
strength of First Army, A. E. F., v: 390, xii: 280;
desperate nature of fighting, v: 390-391;
Germans appeal for Armistice, Nov. 6, '18, v: 391;
German guns captured, v: 393;
German prisoners captured, v: 393;
casualties of First Army, v: 393, xii: 280;
magnitude of operations, v: 393.
Mexico, German plot to involve in war with U. S., i: 347.
Meyer-Waldeck, Capt., German governor of Tsing-Tau, iii: 257.
Mézières,
captured by Germans, Aug. 27, '14, i: 375;
Allied objective in final drive, Nov., '18, iii: 103;
captured by French, Nov. 9,. '18, iii: 103;
fortified French frontier town, v: 215.
Mézières-Sedan railroad, key to German lines of communication on Western Front, v:
216, 387.

Mezy, Germans force passage of Marne at, July 15, '18, v: 150.
Mice, uses in war, vii: 229.
Michael, Grand Duke,
designated as successor by Czar on abdication, vi: 156;
renounces succession to Russian throne Mar., '17, vi: 156.
Michaelis, Georg,
statement of German war aims, ii: 14;
appointment as German Chancellor, July, '17, vi: 266.
Michel position, section of Hindenburg Line on St. Mihiel Front, v: 69.
Michitch, Gen., Serbian commander, stops advance of Austrian invaders, Dec., '14, iii:
394.
Michler, Gen., decorated for Somme campaign, iii: 60.
Microphone,
instrument for detection of U-boats, iv: 308, xi: 241;
see also Hydrophones.
Milan, bombarded by Austrian airmen, Feb. 14, '16, i: 384.
Miles, Capt. Wardlaw L., gets Congressional Medal of Honor, x: 399.
Militarism, German, see Germany, Militarism.
Military commandments, by Kitchener and Foch, xi: 55.
Military training, universal,
advocated by Dr. Chas. W. Eliot, i: Intro. xii;
German system of, i: 71;
Bernhardi's defense of, i: 162;
Roosevelt's advocacy of, for U. S., i: 326;
abolition of, in Germany under Peace Treaty, xii: 211.
Milk supply, German, ii: 18.
Miller, Lieut. John Q., observation pilot, story of, x: 232-235.
Miller, Major Oscar F., gets Congressional Medal of Honor, x: 402.
Millicent Sutherland Ambulance, vii: 107.
Milne, Adm., commander of British fleet in Mediterranean, Aug., '14, iv: 13.
Milne, Pvt. W. J., awarded Victoria Cross for gallantry at Vimy Ridge, iii: 349.
Milyukov, Paul M., Russian statesman,
exposes treachery of Stürmer, Nov., '16, vi: 142;
assails Government distribution of food, Feb., '17, vi: 144;
Minister of Foreign Affairs in Provisional Government, Mar., '17, vi: 158;
statement of loyalty to Allied cause, vi: 158, 159;
biography, ix: 102-103.
Mines, submarine,
North Sea mine barrage, iv: Intro. xi, 324, viii: 274;
use of trawlers for sweeping, iv: 292;
use in fighting U-boats, iv: 312;
use of Paravanes as protection against, iv: 313;

methods of laying, iv: 326.
Mining, in land operations,
blowing up of Messines Ridge by British, iii: 74, 76-77, viii: 310;
of Austrian positions in Alps by Italians, viii: 311.
Minkler, C. T., inventor of depth bomb, iv: 330.
Miraumont, evacuated by Germans, iii: 64.
Mirbach, Count von, assassinated by Bolsheviki, vi: 187.
Missionaries, European, as colonial pioneers in East, i: 17.
Missions, German Christian, continuity guaranteed by Peace Treaty, xii: 263.
Missy,
scene of hard fighting by 1st Div., July, '18, v: 55;
1st Div. makes first capture of German guns by A. E. F., v: 174.
Mitau, captured by Germans, Aug. 2, '15, i: 381.
Mitrovitza, captured by Germans, Nov. 23, '15, i: 382.
Mixed Arbitral Tribunal, establishment and functions under Peace Treaty, xii: 243.
Mkwawa, Sultan, skull of, Peace Treaty provision for return of, by Germany, xii: 225.
Mobile ordnance repair shops, description and functions, v: 350, viii: 294-298.
Moewe, German raider, activities, iv: 197.
Moffat, John,
systematizes American war relief, vii: 87;
decorated for relief work, vii: 87.
Moffett, Capt. Wm. A., commander of Great Lakes Naval Training Station, iv: 318.
Moltke, German cruiser in battle of Dogger Bank, iv: 246.
Moltke, Field-Marshal von, views on German strategy, ii: 14.
Moltke, Lieut.-Gen. Helmuth von, biography, ix: 264.
Monarch, Austrian battleship torpedoed by Italians at Trieste, x: 290.
Monastir,
evacuated by Serbs, Dec. 3, '15, i: 382;
retaken by Allies, Nov. 19, '16, i: 388, iii: 208.
Moncy Wood, captured by 26th Inf., Oct. 5, '18, v: 240.
Mondement, Germans driven back at, in first Marne battle, iii: 33.
Mondragon, Gen., of Mexico, designer of self-loading rifle, viii: 90.
Money,
effect of unsecured paper money on prices, Intro. viii;
inflation chief cause of high prices, Intro. xii, 27;
war-time inflation in U. S., Intro. xii;
inflation throughout world, Intro. xiii;
functions, Intro. xv;
standardized dollar as remedy for fluctuating cost of living, Intro. xv;
inflation defined, xii: 28;
effects of inflation, xii: 29;
revaluation of gold standard, xii: 31;

see also Prices.
Monfalcone, captured by Italians, June 9, '15, iii: 244.
Monge, French submarine, rammed by Austrian warship, x: 295.
Monitors,
revival of discarded naval type, iv: 280;
description of British type, iv: 281;
service at Dardanelles, iv: 282;
service at Trieste, iv: 283;
service in Serbia, iv: 283;
construction of, iv: 284.
Monmouth, British cruiser,
in battle off Coronel, armament, iv: 65;
struck during battle, iv: 66;
sunk by Nürnberg, iv: 67, ix: 308.
Monneaux, location, v: 133.
Monro, Gen., Sir Charles,
sent to India to develop military resources, ii: Intro. xviii;
succeeds Gen. Hamilton at Gallipoli, iii: 174;
conducts evacuation of Gallipoli, iii: 174.
Monroe Doctrine,
barrier against European expansion in America, i:37;
interpretation under Roosevelt, i: 84;
upheld by Roosevelt against German coercion of Venezuela, i: 86.
Mons,
captured by Germans, Aug. 21—23, '14, i: 375;
British retreat from, Aug., '14,
Viscount French's account, ii: 162;
John Buchan's description, iii: 277-281;
British gallantry at, xi: 10.
Monsard, taken by Fourth Corps, Sept. 12, '18, v: 206.
Mont Blanc, captured by 2nd Div., v: 393.
Mont Mare Wood, passage by 89th Div., Sept. 12, '18, v: 210.
Mont St. Père-Chartèves, location, v: 133.
Mont St. Quentin, captured by British, Mar. 18, '17, iii: 68.
Mont Sec, dominating position on St. Mihiel sector, v: 65, 116, 199.
Mont Wood, captured by 90th Div., Nov. 2, '18, v: 264.
Montauban, captured by British in Somme battle, iii: 58.
Montblainville, captured by 28th Div., Sept. 26, '18, v: 325.
Montdidier,
captured by French, Aug. 11, '18, i: 397;
1st Div. relieves French near, v: 29.
Montdidier-Noyon defensive,

by Allies, June 9—15, '18, iii: 94, v: 129, 139-141;
conditions leading to German attack, v: 139;
Allied use of artillery during, v: 139.
Monte Nero, captured by Italians, iii: 244.
Montecuccoli, Adm., responsible for development of Austrian navy, iv: 364.
Montenegro,
declares war on Austria, Aug. 7, '14, i: 375;
declares war on Germany, Aug. 10, '14, i: 375;
forced to surrender to Austria, Feb., '16, vi: 358-359;
joins Jugoslav union, vi: 366;
battle deaths, xii: 288.
Montfaucon,
German stronghold in Meuse-Argonne sector, v: 78, 218;
captured by 79th Div., Sept. 27, '18, v: 224-225.
Montfaucon Wood, captured by 37th Div., Sept. 26, '18, v: 224.
Montmédy, captured by Germans, Aug. 27, '14, i: 375.
Montmirail,
German objective in last drive on Paris, v: 36;
headquarters of 28th Div., June, '18, v: 143.
Montrebeau Wood, captured by 1st Div., Oct. 4, '18, v: 237.
Montrieul-aux-Lions, headquarters of 2nd Div., June, '18, v: 143.
Moore, Rear-Adm. Sir Archibald, second in command of British in battle of Dogger
Bank, iv: 246.
Morale,
Allied and German during winter, '17—'18, v: 1;
German, weakened by failure of great offensive, July, '18, v: 53;
American, under hardships of Meuse-Argonne Offensive, v: 87, 232;
Allied and German, Sept., '18, v: 213.
Moranville, taken by 322nd Inf., Nov. 9, '18, v: 277.
Morava-Maritza Valley, approach to Constantinople through Serbia, iii: 150.
Moravia,
early history, vi: 396;
nationalistic aspirations, vi: 396.
Moresnet, ceded to Belgium under Peace Treaty, vi: 89, xii: 188.
Moreuil salient,
military operations in, Aug.—Sept., '18, iii: 98;
Allied attack on Albert-Montdidier line, iii: 98;
Albert captured by British, Aug., '18, iii: 98;
British attack on the Scarpe, Sept., '18, iii: 98.
Morgan, Miss Anne, war relief activities, vii: 92.
Morine Wood, captured by 32nd Div., Oct. 5, '18, v: 240.
Morocco,

French control of, recognized by Great Britain, '04, i: 99, 202;
Kaiser's famous speech at Tangier on German policy, Mar., '05, i: 99, 202;
European crisis on dispatch of German gunboat Panther to Agadir, July, '11, i: 104,
203;
storm center of European diplomacy, i: 202;
Prince Lichnowsky's views on German policy, i: 204;
German rights in, surrendered under Peace Treaty, xii: 208.
Mort Homme,
see
Dead Man's Hill;
Verdun.
Mortars, see Artillery.
Morton, Maj.-Gen. Charles G.,
commands 29th Div., June, '18, v: 146;
takes command of sector on right bank of Meuse, Oct. 10, '18, v: 246.
Moscow,
municipal elections annulled by reactionary Protopopov, '17, vi: 143;
Conference called by Kerensky, '17, vi: 167;
meeting of Soviet Congress, Mar., '18, vi: 185.
Moselle River, German attempt to enter France through valley of, '14, v: 199.
Mosley, Brig.-Gen. G. Van H., Chief of Co-ordination, G. H. Q., A. E. F., Sept., '17, v: 102.
Motors,
airplane, production in U. S., xii: 285;
Liberty, production figures, xii: 285.
Motor Transport Corps, U. S., see U. S., Army.
Motor trucks,
important function in Verdun defense, iii: 50, viii: 289-291;
mobile ordnance repair shops, description and functions, v: 350, v: 294-298;
armored cars, viii: 286;
Paris buses as war transports, viii: 286;
use as ambulances, viii: 287;
number in use by belligerents, Aug., '14, viii: 288;
number in use at front, June, '15, viii: 288;
number shipped to France from U. S., viii: 288, xii: 95, xii: 286;
Liberty truck, development and description, viii: 291-294.
Mott, Dr. John R., General Secretary, Y. M. C. A. War Work Council, vii: 261.
Mount Vernon, U. S. transport torpedoed, Sept. 5, '17, iv: 337.
Mousquet, French destroyer sunk by Emden, Oct. 28, '14, iv: 181.
Mouzay, captured by 5th Div., Nov. 9, '18, v: 94, 272.
Mücke, Lieut. Hellmuth von, account of exploits of German raider Emden, iv: 167-187,
190-194.
Mudros, British advance base for Gallipoli campaign, iii: 164, iv: 30.

Mühlon, Dr. William, disclosures of German complicity in forcing War, i: 133-136, 250-
254.
Muir, Maj.-Gen. Charles H.,
commands 28th Div., May, '18, v: 128;
in Meuse-Argonne Offensive, Sept., '18, v: 220.
Mules, number shipped to France by U. S., xii: 95, xii: 286.
Mülhausen, captured by French, Aug. 8, '14, iii: 16.
Müller, Capt. Karl von, commander of German raider Emden, iv: 166.
Munich,
murder of Kurt Eisner and Spartacide uprising in, Feb., '19, vi: 298;
Spartacides establish Soviet, vi: 300;
Soviet overthrown by Noske, May, '19, vi: 301.
Münsterberg, Prof. Hugo, on "Russian Peril," vi: 250.
Murfin, Capt. O. G., in charge of U. S. Navy mine bases, iv: 325.
Murman Region,
Military Government of, established, July, '18, xii: 279;
Murmansk, fighting between Allies and Bolsheviki at, vi: 187.
Murray, Gen., commands British troops defending Suez, iii: 191.
Mush,
captured by Russians, Feb. 18, '16, i: 384, iii: 263;
evacuated by Russians, Aug. 8, '16, i: 386.
Mushi, captured by British, Mar. 13, '16, i: 384.
Mustard gas,
use in chemical warfare, v: 321, viii: 171-172, xi: 321;
use of "Sag Paste," as protection against, v: 324;
manufacture of, at U. S. Edgewood Arsenal, viii: 186.
N
Namazieh Battery, at Gallipoli, iv: 45.
Namur, forts of,
constructed, 1890, i: 143;
captured by Germans, Aug., '14, i: 375, iii: 14-15.
Nancy,
German advance on, checked, Aug., '14, iii: 19;
important frontier fortress, v: 199, 215.
Nantillois, captured by 315th Inf., Sept. 28, '18, v: 228.
Napier, Rear-Adm. T. D. W., commander of British 3rd Light Cruiser Squadron at
Jutland, iv: 120.
Naples, bombed by German aviators, Mar. 11, '18, i: 395.
Napoleon, Fort, at Gallipoli, bombarded by French battleship Gaulois, Mar. 2, '15, iv: 43.
Narew, Russian Army of the, invades East Prussia, iii: 111.

Narodna Odbrana, Serbian patriotic society, accused of responsibility for murder of
Archduke Francis Ferdinand, i: 112.
Narodni Savetz, Bulgarian patriotic organization, vi: 341.
Narrows, at Dardanelles, defenses of bombarded by Allies, Mar. 5, '15, iv: 45.
Narva, captured by Germans, Mar. 5, '18, i: 393.
Nasarie, taken by British, '15, iii: 181.
Nasmith, Lieut.-Com., captain of British submarine E-11 in Sea of Marmora, iv: 210.
Nasrullah Khan, instigator of Habibullah Khan's assassination, vi: 80.
National Allied Relief Committee, vii: 87;
see also War relief.
National anthems, words and histories of, xi: 325-332.
National Council of Austrian Women, peace appeals, '17, vi: 314.
National Guard,
U. S., federalized, Aug. 5, '17, i: 390;
see also U. S., Army.
National Volunteers, Irish organization enlisted to aid British, vi: 57.
National War Work Council,
of American Y. M. C. A., formation, vii: 262;
see also Y. M. C. A.
Nationalism,
problems of, i: 23;
development in Europe since 1648, i: 26;
factor in racial unification, v: Intro. viii;
growth during 19th century, v: Intro. ix;
see also under name of country.
Nations of the world, political positions in 1871, i: 44-60.
Naumann, Friedrich, author of Mittel Europa,
statement of German war aims, vi: 258;
views on trench frontiers, viii: 126.
Nautilus, submarine invented by Robert Fulton, 1800, iv: 202.
Naval Batteries, U. S., on Western Front, v: 306, viii: 42-45.
Naval power,
influence on result of War, i: 13;
function as protector of supply routes, i: 15;
development as adjunct to colonization, i: 28.
Naval raids, German bombardment of English coast towns, iv: 244-246.
Naval stations, British, around the world, i: 15.
Navarino, battle of, 1827, i: 34.
Navies, see under each country.
Navigation, freedom of, for Allies,
over German waterways, Peace Treaty provisions, xii: 247-253;
Elbe, Oder, Niemen, and Danube internationalized under Peace Treaty, xii: 248.

"Navy Hut," American "Y" center at Brest, vii: 302.
Nazareth, captured by British, Sept. 21, '18, iii: 198.
N-C Flying Boats,
development and description, viii: 236-240;
N-C-4 first airplane to cross Atlantic, iv: 288, viii: 240.
Near East,
European rivalries in, i: 38;
German policy, i: 80, 207, ii: 89;
see also
Balkans;
Germany, Foreign policy.
"Near victories," of the War, ii: 206.
Nebraskan, S. S., American steamer attacked by German submarine, May 25, '15, i: 320.
Neibaur, Pvt. Thomas C., gets Congressional Medal of Honor, x: 399.
Nembo, Italian destroyer, battle with Austrian U-boat, Oct. 16, '16, iv: 369.
Nesle, occupied by French cavalry Mar., '17, iii: 68.
Netherlands,
international position in '14, i: 61;
refuses to cede Dutch Flanders to Belgium, vi: 89;
strength of army, '14, vi: 375, 378;
maintains armed neutrality, vi: 375-377;
neutrality condemned by British press, vi: 376;
effect of submarine warfare on, vi: 377-378;
merchant marine seized by Allies, Mar., '18, vi: 378;
claims Scheldt and Maastricht area, '18, vi: 378;
generous host to Belgian refugees, vii: 168-175;
war-time increase in shipping, xii: 101.
"Netherlands Overseas Trust," vi: 377.
Neufchateau, training area for 26th and 42nd Divs., v: 6.
Neutrals,
increase in shipping, xii: 100;
trade with Germany, xii: 100.
Neuve Chapelle,
captured by British, Mar. 9—10, '15, i: 378, iii: 41;
faulty British generalship at, iii: 375.
Neuve Eglise, captured by British, Sept. 2, '18, i: 397.
Newbolt, Sir Henry, account of Smith-Dorrien's battle at Le Cateau, Aug. 26, '14, ii: 176-
182.
New Guinea, German, captured by Australians, '14, vi: 38.
New Mexico, U. S. battleship, propelled by electricity, iv: 322.
New Zealand,
war casualties, iii: 404, 405;

strength of army, iii: 405;
area and population, vi: 37;
loyalty to Great Britain, vi: 46;
war cost, Aug., '14—Mar., '19, xii: 107, xii: 114;
Peace Conference delegates, xii: 179.
New Zealand, British cruiser,
in battle of Heligoland Bight, iv 241;
in battle of Dogger Bank, iv: 246.
Niblack, Rear-Adm. Albert P., biography, ix: 295.
Nicaragua, delegate to Peace Conference, xii: 180.
Nicholas, Grand Duke,
Commander-in-Chief of Russian armies, iii: 119;
removed as Commander-in-Chief and sent to Caucasus, Sept., '15, iii: 140, 262;
Nicholas, King of Montenegro,
surrenders to Austrians, Feb., '16, vi: 359;
deposed, vi: 366.
Nicholas II, Czar of Russia,
takes personal command of army, Sept., '15, iii: 140, vi: 141;
influence of Rasputin over court, vi: 141;
issues undated order for dismissal of Duma, '17, vi: 144;
abdicates, Mar. 15, '17, vi: 156;
Nicholson U. S. destroyer, captures German submarine, iv: 350.
Niemen, Russian Army of the, invades East Prussia, iii: 110.
Niemen River, internationalized by Peace Treaty, xii: 248.
Nietzsche, Friedrich,
German apostle of gospel of force, i: 67, ii: 2;
striking quotations from, i: 179-180.
Nieuport, captured by Germans, Oct. 24, '14, i: 376.
Nieuport scout planes, viii: 192.
Nightingale, Florence, pioneer army nurse, vii: 11.
1914, by Viscount French, account of military operations of year, summary with
extracts, ii: 159-174.
Nish, captured by Bulgars, Nov. 5, '15, i: 382, iii: 158; retaken by Allies, Oct. 13, '18, iii:
213.
Nish-Salonika Railroad, cut by Bulgarians, iii: 158.
Nitrogen, asphyxiating properties, viii: 166.
Nitti, Francesco S., Italian minister, opposes policy of aggrandizement, vi: 366.
Nivelle, Gen. Robert,
succeeds Joffre as French Commander-in-Chief, ii: Intro. xx, iii: 62;
in supreme command of Allied forces on Western Front, '16, ii: 54;

plans campaign of '17, ii: 54;
defends Verdun, '16, iii: 54, 61, 310;
Nixon, Gen. Sir John,
commands British troops in Mesopotamia, iii: 182;
responsibility for Mesopotamian failure, iii: 364, 367.
"No Man's Land," definition, v: 17.
Nolan, Brig.-Gen. D. E.,
Chief of Intelligence (G-2), G. H. Q., A. E. F., Sept., '17, v: 101;
in Meuse-Argonne Offensive, Sept., '18, v: 221.
Nonsard, captured by 1st Div., Sept. 12, '18, v: 211.
Norman Compensating Foresight, use in range-finding, viii: 211.
North German Confederation, formation, i: 43, ii: 1.
North German Lloyd Line, tonnage and capital, i: 264.
North Pacific Islands,
German, acquired by Japan, xii: 279;
North Sea,
Allied mine barrage, iv: Intro. xi, 324-330, viii: 274;
problem of belligerents in, iv: 86, 91;
German naval raids, iv: 136.
Northern Pacific, S. S., speed record as transport, v: 358.
Norway, pro-Ally sympathies, vi: 394.
Noske, Gen.,
suppresses Berlin Spartacides, vi: 289;
overthrows Munich Soviet, vi: 300-301.
Nottingham, British cruiser,
sunk, Aug. 19, '16, i: 386;
in battle of Heligoland Bight, iv: 241.
Nouart, captured by 89th Div., Nov. 2, '18, v: 264.
Novo Georgievsk,
Russian attack at, Oct., '14, iii: 126;
captured by Germans, Aug., '15, iii: 138.
Noyon,
captured by French, Aug. 28, '18, i: 397, ii: 158;
occupied by French, March 18, '17, iii: 68;
see also Montdidier-Noyon defensive.
Nugent, Gen., commander of 36th Ulster Div., iii: 377.
Nur-el-Bahr, British cruiser sunk off Sollum, Nov. 6, '15, ii: 190.
Nürnberg,
German cruiser in battle off Coronel, iv: 65;
sunk in battle of Falkland Islands, iv: 70, 74.

Nurses,
U. S. Army Nurse Corps, vii: 203;
see also
Red Cross;
War relief.
O
O Patria, O Rei, O Povo, Portuguese national hymn, xi: 329.
Obrenovatz, captured by Austrians, Oct. 18, '15, i: 382.
O'Brien, Lieut. Pat, escape from German prison, x: 257.
Observation balloons, see Aeronautics.
Ocean, British battleship at Gallipoli, iv: 31, 35, 48.
Oches, taken by 77th Div., Nov. 4, '18, v: 266.
Oder River, internationalized by Peace Treaty, xii: 248.
Odessa, importance as military base, iii: 161.
Ogons Wood, captured by A. E. F., Oct. 5, '18, v: 230, 237, 239.
Oh, How I Hate to Get Up in the Morning, American soldiers' song, xi: 337.
O'Kelly, J. T., Irish representative to Peace Conference, vi: 65.
Okuma, Count,
influence on Japanese foreign policy, vi: 384;
biography, ix: 87.
"Old Dutch Cleansers," nickname for 9.2-in. British howitzers, v: 308.
Old Hickory (30th) Division, see U. S., Army.
O'Leary, Jeremiah, pro-German propagandist in U. S., x: 345.
O'Leary, Sgt. Michael, wins Victoria Cross, x: 71.
Oman,
acquired by Allies, '13, xii: 279;
Omsk, capital of All-Russian Government, vi: 191.
Onslow, British destroyer at battle of Jutland, iv: 121.
"Open Door" policy in China, i: 57;
see also China.
Opium Convention, Jan. 23, '12, put into force by Peace Treaty, xii: 232.
Opium War, against China, 1840, i: 38.
"Oppy Line," captured by British in Arras battle, iii: 72.
Optical glasses, for A. E. F., viii: 326.
Orange Free State,
becomes part of Union of South Africa, 1899, vi: 47;
opposition to Great Britain, vi: 50-52;
see also South Africa, Union of.
Orders in Council,
British, establish blockade of Germany, i: 312, 318, ii: 16, 21;
see also Germany, Blockade of.

Orientator, for testing aviators, viii: 356-358.
Orlando, Vittorio Emanuele,
Italian statesman, forms coalition cabinet, Oct., '17, vi: 129;
foreign policy, vi: 362, 366;
demands Fiume for Italy, vi: 368;
withdraws from Peace Conference on Fiume crisis, vi: 368;
Orly, U. S., aircraft factory at, v: 313.
Ornes, captured by Germans, '16, iii: 48.
Orphans, see War relief.
Orsova,
captured by Rumanians, Sept. 7, '16, i: 386, iii: 218;
evacuated by Rumanians, Nov. 24, '16, i: 389, iii: 222.
Orsova Railway, captured by Germans in Wallachian campaign, iii: 221.
O'Ryan, Maj.-Gen. John F.,
commander, 27th Div., v: 196, 281;
account of history of 27th Div., v: 281-300.
O'Shea, Corp. Thomas E., gets Congressional Medal of Honor, x: 393.
Ossowetz,
besieged by Germans, iii: 118, 130;
captured, Aug., '15, iii: 138.
Ostend,
seat of Belgian government moved to, Oct. 5, '14, i: 376;
occupied by Germans, Oct. 13, '14, i: 376, iii: 38;
raided by British May, '18, iv: 279;
evacuated by Germans, xi: 52.
Ostrovo, Lake, Allied counter-attack against Bulgars at, Sept., '16, iii: 208.
Otranto, British auxiliary cruiser in battle off Coronel, iv: 65.
Ourcq River,
crossed by 42nd Div. in pursuit of Germans, July, '18, v: 50, 187;
course and topography of region, v: 133;
A. E. F. fighting at, commended by Gen. Degoutte, v: 192.
Over There, American soldier song, xi: 336.
Over-There Theater League, organization and activities, vii: 277, 339-342.
Ovillers, captured by Allies in Somme battle, iii: 58.
Oxygen, for gas victims, iii: 320.
Oxygen helmets as defense against poison gas, viii: 173.
P
Paderewski, Ignace Jan,
returns to Poland as popular hero, vi: 220;
becomes Prime Minister, vi: 223;
defeated for presidency, vi: 225;

Paës, Dr. Sidonio, President of Portugal, assassinated, Dec., '18, vi: 374.
Paget, Sir Ralph, Chairman, International Sanitary Commission for Serbian typhus
relief, iii: 398.
Painlevé, Paul, succeeds Ribot as French premier, '17, vi: 105.
"Pal" regiments, British recruiting device, vi: 6.
Palestine,
strategic importance, ii: Intro. xviii, xxi, 87-90;
conquered by Gen. Allenby, ii: Intro. xx, 92-94, 218, iii: 192-200, 322-326;
capture of Gaza, Mar. 26—27, '17, ii: 92, iii: 192;
capture of Jerusalem, Dec. 11, '17, ii: 92, iii: 193-196;
description of Allenby's entry, iii: 322-326;
British and Turkish manpower, ii: 93, iii: 200;
destruction of Turkish army, Sept., '18, ii: 94, 218, iii: 198;
Damascus captured, Oct. 1, '18, iii: 199;
Aleppo captured, Oct. 25, '18, iii: 200;
bibliography, iii: 200;
disposition under secret treaties, '16—'17, vi: 334;
Y. M. C. A. in, vii: 322;
Palmer, Frederick,
comment on Marne fighting, July, '18, v: 158;
tribute to 1st Div., v: 234.
Pan-Germanism, see Germany.
Pan-Slavism, aspirations, i: 244;
"Greater Serbia" propaganda, i: 244;
fight for control of Ukraine by Russia, vi: 241;
Russia aims at annexation of Ruthenia, '14, vi: 241;
Bulgaria's attitude toward, vi: 340;
see also Slavs.
Panama,
declares war on Germany, Apr, 7. '17, i: 389;
Peace Conference delegate, xii: 180.
Panama Canal, U. S. gains control of, i: 84.
Pannes, captured by 42nd Div., v: 211.
Panther, German gunboat sent to Agadir, July, '11, i: 104, 203.
Paolucci, Dr., helps Lieut.-Col. Rossetti to sink Austrian warship Viribus Unitis, x: 297-
303.
Papacy, relation to Italian government, i: 61.
Papeete, bombarded by German fleet, Sept. 22, '14, iv: 62.
Papen, Capt. Franz von,
German Military Attaché in U. S., dismissed for unneutral conduct, i: 276;

share in passport frauds, i: 314;
activities as arch-spy in U. S., x: 328-329.
Parachutes, use by military balloonists, viii: 260-263.
Parades,
first American troops in Paris, July 4, '17, v: 107;
Allied troops on Bastille Day in Paris, July 14, '18, v: 147;
27th Div. in New York City, Mar. 25, '19, v: 299.
Parajd, captured by Rumanians, Oct. 5, '16, i: 388.
Paravane, protective device against submarine mine, iv: 313.
Paris,
air raids on,
Jan. 29—30, '16, i: 384;
Mar. 11, '18, i: 395;
German advance on, '14, ii: 6, iii: 28, vi: 97;
bombarded by long-range gun from St. Gobain Forest, ii: 154, iii: 88, viii: 45-47;
welcome to Gen. Pershing, June 13, '17, v: 97;
German drive on, May 27—Aug. 6, '18, battles in Marne salient, v: 129-139, 141, 147;
parade of Allies, July 14, '18, v: 147;
panic in, during German drive, '18, v: 378;
May Day rioting, May, '19, vi: 111.
Paris Conference, 1856, guarantees Turkish power in Europe, i: 39.
"Paris Group," organization of, Medical Department, A. E. F., v: 346.
Pasha Dagh,
Australian objective in Gallipoli attack, iii: 170;
see also Gallipoli Campaign.
Pashitch, Nicholas, Premier of Serbia,
negotiations with Italy for settling Adriatic rivalry, vi: 362;
biography, ix: 120.
Passchendaele Ridge,
captured by British, Oct.—Nov., '17, ii: 56, 79;
recaptured by Germans, Apr., '18, iii: 377.
Passenheim, Russians defeated at, Aug. 28, '14, i: 375, iii: 116.
Passport frauds, German activities in U. S., i: 314, x: 333.
Patriotic songs, xi: 332-335.
Patrol boats, work in combating submarines, iv: 292.
Patrolling, training A. E. F. in, v: 117.
Patrols, German system of, in the Vosges, v: 26.
Patterson, Miss Hannah J., awarded D. S. M. for work on Woman's Committee, Council
of National Defense, xii: 125.
Pau, Gen. Paul, commands French forces invading Alsace, Aug. 14, '14, iii: 16.
Peace Conference, Paris,
U. S. delegates sail for, Dec. 4, '18, i: 400;

conciliatory attitude of Austrian delegates, vi: 321;
negotiation with Hungarian Soviet, Apr., '19, vi: 326;
Fiume crisis, vi: 366-370, xii: 159;
prestige of Japanese delegation, vi: 388;
dispute over Teschen district, vi: 400;
inside story of, by Thos. W. Lamont, financial adviser to U. S. delegation, xii: 149-
163;
complexity of task, xii: 149;
rapidity of work, xii: 149;
open diplomacy, xii: 149;
Supreme Council, members and method of evolving Peace Treaty, xii: 150-153;
"Big Four," xii: 150, xii: 152;
"Big Three," xii: 150;
Conference procedure, xii: 156;
commissions, xii: 156;
delays, xii: 156;
language difficulties, xii: 157;
Reparations Commission, organization and work, xii: 158, xii: 219-221;
Shantung controversy, xii: 160;
Germans excluded from negotiation, xii: 161;
Belgian demands, xii: 161;
signing of Peace Treaty with Germany, ceremonies, xii: 165-169;
list of delegates, xii: 179-182;
see also Peace Treaty with Germany, Versailles, '19.
Peace moves,
President Wilson asks belligerents to state war aims, Dec. 18, '16, i: 335;
response to Wilson's note, i: 336;
Wilson's "Peace without victory" speech, i: 336;
Pope Benedict's appeal, Aug. 15, '17, i: 390, ix: 405;
Germany accepts Pope's offer, Sept. 21, '17, i: 390;
text of letter from Emperor Charles of Austria-Hungary to Prince Sixtus making
secret offer of peace, Mar., '17, ii: 63;
German attempts in '16 and '17 fail, ii: 270, 316, vi: 263;
German moves condemned by Ludendorff, ii: 303;
Kaiser orders proposals through Queen of Holland, ii: 331;
Russian Provisional Government urges Allies to revise peace aims, May, '17, vi:
161;
German Socialists demand peace without annexations, '15, vi: 258;
Bethmann-Hollweg proposes peace of understanding, '16—'17, vi: 262;
German popular demand for "peace without annexations or indemnities," vi: 266-
268;
Emperor Charles forces offer by Teutonic allies, Dec. 12, '16, vi: 313;

demonstrations in Sofia, vi: 346;
see also
Armistice;
and under each country.
Peace Treaty with Germany,
Versailles, '19, criticism by British liberal press, vi: 22;
terms presented to Germans, May 7, '19, vi: 302, xii: 161;
condemned by German press, vi: 302-304;
Germany consents to sign, June 22, '19, vi: 304, xii: 163;
how drafted, described by Thos. W. Lamont, financial adviser to U. S. delegation,
xii: 149-161;
text, work of technicians, xii: 150;
French demands, xii: 153;
evolution of Covenant of League of Nations, xii: 155;
Belgian demands, xii: 161;
ceremonies of signing, xii: 165-169;
analysis by Geo. W. Wickersham, xii: 170-178;
signed June 28, '19, xii: 179;
text in full, xii: 179-263;
preamble, giving list of nations allied against Germany, and their delegates to
Peace Conference, xii: 179-182;
League of Nations, text of Covenant, xii: 182-185;
boundaries of Germany, xii: 186;
provisions concerning Luxemburg, xii: 189;
demolition of German fortifications, xii: 189, xii: 205, xii: 211, xii: 214;
Sarre Basin settlement, xii: 189-194;
Alsace-Lorraine, provisions for return to France, xii: 194-197;
Germany acknowledges independence of Austria, xii: 197;
provisions for independence of Czechoslovak State, xii: 197;
independence and boundaries of Poland, xii: 198-200;
plebiscite for East Prussia, xii: 200;
provisions concerning Memel, xii: 203;
Danzig made free city, xii: 203;
plebiscite provisions for Schleswig, xii: 204;
Heligoland, destruction of fortifications on, xii: 205;
provisions concerning Russo-German relations, xii: 205;
Brest-Litovsk Treaties abrogated, xii: 205;
German colonies surrendered to Allies, xii: 206;
German rights in China surrendered, xii: 206;
German rights in Siam surrendered, xii: 208;
German rights in Liberia surrendered, xii: 208;
German rights in Morocco surrendered, xii: 208;

Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.
More than just a book-buying platform, we strive to be a bridge
connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.
Join us on a journey of knowledge exploration, passion nurturing, and
personal growth every day!
ebookbell.com

Programming In Ada 2012 1st Edition Barnes John Gilbert Presslie

More Related Content

Similar to Programming In Ada 2012 1st Edition Barnes John Gilbert Presslie (20)

Recently uploaded (20)

Programming In Ada 2012 1st Edition Barnes John Gilbert Presslie