The final major topic to be introduced is tasking. Ada is fairly unusual in having tasking constructions built in to the language. Some might argue that such matters are the concern of the operating system and are better done by calls from an otherwise sequential program. However, built-in constructions provide greater reliability; general operating systems do not provide the control and timing needed by many applications; and every operating system is different. Building tasking into the language also makes it easier to benefit from any parallelism in the machine and increases the potential for optimization.

This chapter concentrates on the key ideas. Further examples and details especially concerning the interaction between tasking and OOP are dealt with in Chapter 22 which also covers important facilities concerning timing which are actually defined in the Real-Time Systems annex.

Parallelism

So far we have only considered sequential programs in which statements are obeyed in order. In many applications it is convenient to write a program as several parallel activities which cooperate as necessary. This is particularly true of programs which interact in real time with physical processes in the real world, simulation programs (which mimic parallel activities in the real world), and programs which wish to exploit multiprocessor architectures directly.

In Ada, parallel activities are defined by means of tasks. A task is lexically described by a form very similar to a package. It consists of a task specification describing the interface presented to other tasks and a task body describing the dynamic behaviour of the task.

In some cases a task presents no interface to other tasks in which case the specification reduces to just

As a simple example of parallelism, consider a family going shopping to buy ingredients for a meal. Suppose they need meat, salad and wine and that the purchase of these items can be done by calling procedures Buy_Meat, Buy_Salad and Buy_Wine respectively. The whole expedition could be represented by

However, this solution corresponds to the family buying each item in sequence. It would be far more efficient for them to split up so that, for example, mother buys the meat, the children buy the salad and father buys the wine.

This first example of a complete program pulls together various aspects of the type Object and its descendants which were discussed in Chapter 3. This opening description is followed by the text of the program and then some notes on specific points.

The program is in two phases. It first reads in the dimensions of a number of objects and then computes and prints out a table of their properties.

The root package Geometry contains the abstract type Object together with various abstract operations. The function MI is the moment of inertia of the object about its centre (see Exercise 3.3(5)). The function Name returns a string describing the type of the object. Each of the concrete types is then declared in its own child package.

The child package Geometry.Circles declares the type Circle which is derived from the abstract type Object and has one additional component, Radius. It also declares concrete functions Area, MI and Name which implement the corresponding abstract operations of the root type Object.

The child packages Geometry.Points, Geometry.Triangles, and Geometry.Squares then similarly declare types Point, Triangle, and Square with appropriate concrete functions.

There are also a number of other child packages containing related material. The package Geometry.Magic contains the class wide functions Moment and MO; Moment gives the vertical moment about the origin whereas MO gives the moment of inertia about the origin. The package Geometry.Lists contains entities for defining and manipulating lists of objects.

In this final introductory chapter we consider the important topic of putting together a complete program. Such a program will inevitably use predefined material such as that for input and output and we therefore also briefly survey the structure and contents of the extensive predefined library.

The hierarchical library

A complete program is put together out of various separately compiled units. In developing a very large program it is inevitable that it will be conceived as a number of subsystems themselves each composed out of a number of separately compiled units.

We see at once the risk of name clashes between the various parts of the total system. It would be very easy for the designers of different parts to reuse popular package names such as Error_Messages or Debug_Info and so on.

In order to overcome this and other related problems, Ada has a hierarchical naming scheme at the library level. Thus a package Parent may have a child package with the name Parent.Child.

We immediately see that if our total system breaks down into a number of major parts such as acquisition, analysis and report then name clashes will be avoided if it is mapped into three corresponding library packages plus appropriate child units. There is then no risk of a clash between the names Analysis.Debug_Info and Report.Debug_Info since they are now quite distinct.

The naming is hierarchical and can continue to any depth.

The final major topic to be introduced is tasking. Ada is fairly unusual in having tasking constructions built in to the language. Some might argue that such matters are the concern of the operating system and are better done by calls from an otherwise sequential program. However, built-in constructions provide greater reliability; general operating systems do not provide the control and timing needed by many applications; and every operating system is different. Building tasking into the language also makes it easier to benefit from any parallelism in the machine and increases the potential for optimization.

This chapter concentrates on the key ideas. Further examples and details especially concerning the interaction between tasking and OOP are dealt with in Chapter 22 which also covers important facilities concerning timing which are actually defined in the Real-Time Systems annex.

Parallelism

So far we have only considered sequential programs in which statements are obeyed in order. In many applications it is convenient to write a program as several parallel activities which cooperate as necessary. This is particularly true of programs which interact in real time with physical processes in the real world, simulation programs (which mimic parallel activities in the real world), and programs which wish to exploit multiprocessor architectures directly.

In Ada, parallel activities are defined by means of tasks. A task is lexically described by a form very similar to a package.

The previous chapters have covered the intrinsic aspects of the Ada language; that is all the various syntactic forms. This chapter and the next two chapters describe the predefined library which comes with every implementation of Ada. As outlined in Chapter 4, the predefined library is structured as three packages: Ada, System and Interfaces with numerous child packages. These three packages are themselves (like all root library units) considered to be child units of Standard. This chapter is largely about the packages Standard and Ada, apart from the huge package Ada.Containers which is described in Chapter 24; System and Interfaces are discussed in Chapter 25.

The main facilities provided by the package Ada are string and character handling, the mathematical library including elementary functions and random number generation, various forms of input–output and communication with the operational environment.

The package Standard

As mentioned earlier, certain entities are predefined through their declaration in the special package Standard. It should not be thought that this package necessarily actually exists; it is just that the compiler behaves as if it does. Indeed, as we shall see, some entities notionally declared in Standard cannot be truly declared in Ada at all. The general effect of Standard is indicated by the outline specification below.

The predefined operators are given in comments since they are implicitly declared. Italics are used for identifiers not available to users (such as universal_real) and for implementation-defined information.

This chapter contains a survey of the scope of the six specialized annexes. These annexes are optional and many implementations will not support them in full. Validation of an Ada compiler will state which of the annexes, if any, is supported. A compiler which is not validated for an annex may provide partial support for that annex but if it does the material must conform to the annex.

It is a general principle that the annexes contain no new syntax but only additional packages, attributes, aspects and pragmas. They are thus not intrinsically hard to understand especially if the reader is familiar with the application area concerned. We thus briefly catalogue the principles and main facilities with just a few examples and refer the reader to the ARM for the full details. But note that some of the more interesting tasking features were described in Chapter 22.

The annexes are generally independent but the Real-Time Systems annex requires that the Systems Programming annex be supported.

Systems Programming

This annex covers access to machine code, interrupt handling, some extra requirements on representations and preelaboration, a pragma for discarding names at run time, the pragmas for shared variables and packages for general task identification, per task attributes and the detection of task termination.

Interrupt handling is important. The general idea is that an interrupt handler is provided by a parameterless protected procedure which is called by some mythical external task. The protected procedure can be attached statically to the interrupt by the aspect Attach_Handler or it can be attached dynamically by a procedure of the same name in the package Ada.Interrupts. This package also defines the type Interrupt_Id which is used to identify the interrupts which are declared as constants in the package Ada.Interrupts.Names. Thus

The aspect specification statically attaches the procedure Response to the interrupt identified by the constant Contact_Int. Dynamic attachment is performed by using the aspect Interrupt_Handler to indicate that the protected procedure is to be used as a handler and then calling the procedure Attach_Handler thus

where the first parameter of Attach_Handler is of the access type

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.

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.

This appendix lists the reserved words and predefined attributes, aspects, pragmas, and restriction identifiers. An implementation may not define additional reserved words but may define additional attributes, aspects, pragmas, and restriction identifiers.

The lists do not include obsolete items such as pragmas which are now replaced by aspect specifications. Moreover, although certain aspects such as Pure can be given by an aspect specification, the preferred style is to use a pragma; accordingly such aspects are only listed under pragmas.

Predefined attributes

This section lists all the predefined attributes. Most attributes are dealt with in detail in the body of this book and so the descriptions are generally brief.

X'Access: Applies to an object or subprogram. Yields an access value designating the entity. (See 11.4, 11.8)

X'Address: Applies to an object, program unit or label. Denotes the address of the first storage element associated with the entity. Of type System.Address. (See 25.1)

S'Adjacent: Applies to a floating point subtype S of a type T and denotes function S'Adjacent(X, Towards: T) return T; which returns the machine number adjacent to X in the direction of Towards.

S'Aft: Applies to a fixed point subtype. Yields the number of decimal digits needed after the point to accommodate the subtype S, unless the delta of the subtype S is greater than 0.1, in which case it yields the value one. (S'Aft is the smallest positive integer N for which (10**N)*S'Delta is greater than or equal to one.) Of type universal_integer. (See 23.6)

X'Alignment: Applies to a subtype or object. Zero means that an object is not necessarily aligned. Otherwise, the Address of an object is an integer multiple of this attribute. Of type universal_integer. (See 25.1)

S'Base: Applies to a scalar subtype S and denotes an unconstrained subtype of its type. (See 27.2)

S'Bit_Order: Applies to a record subtype and denotes the bit ordering. Of type System.Bit_Order. (See 25.1)

P'Body_Version: Applies to a program unit and returns a String. Used by the Distributed Systems annex.

T'Callable: Applies to a task. Yields true unless the task is completed, terminated or abnormal. Of type Boolean. (See 20.8)

E'Caller: Applies to an entry. Yields the identity of the task calling the entry body or accept statement. Of type Task_Identification.Task_ID. (See 26.1)

S'Ceiling: Applies to a floating point subtype S of a type T and denotes function S'Ceiling(X: T) return T;

This chapter lays the foundations for the small-scale aspects of Ada. We start by considering the declaration of objects and the assignment of values to them and briefly discuss the ideas of scope and visibility. We then introduce the important concepts of type, subtype and constraints. As examples of types, the remainder of the chapter discusses the numeric types Integer and Float, enumeration types in general, the type Boolean in particular, and the operations on them.

Object declarations and assignments

Values can be stored in objects which are declared to be of a specific type. Objects are either variables, in which case their value may change (or vary) as the program executes, or they may be constants, in which case they keep their same initial value throughout their life.

A variable is introduced into the program by a declaration which consists of the name (that is, the identifier) of the variable followed by a colon and then the name of the type. This can then optionally be followed by the := symbol and an expression giving the initial value. The declaration terminates with a semicolon. Thus we might write

The first declaration introduces the variable J of type Integer but gives it no particular initial value. The second introduces the variable P and gives it the specific initial value of 38.

We can introduce several variables at the same time in one declaration by separating them by commas thus

In the second case all of P, Q and R are given the initial value of 38.

If a variable is declared and not given an initial value then great care must be taken not to use the undefined value of the variable until one has been properly given to it. If a program does use the undefined value in an uninitialized variable, its behaviour will be unpredictable; the program is said to have a bounded error as described in Section 2.6.

A common way to give a value to a variable is by using an assignment statement. In this, the name of the variable is followed by := and then some expression giving the new value. The statement terminates with a semicolon. Thus

and

The purpose of this program is to illustrate the declaration of storage pools. It implements the well known Tower of Hanoi in which a tower of graduated discs is moved from one pole to another pole using a third pole as ‘temporary storage’ without any disc ever being on a smaller disc.

Each pole is represented by a stack and, in order to add variety, two kinds of stack are implemented much as in Exercise 14.9(3). One is a linked list and the other is an array. The choice of stack is made by the user and the program dispatches to the relevant subprograms Push and Pop as necessary.

The package Pools declares the type Pond and its associated operations Allocate, Deallocate, Initialize, Finalize, and Storage_Size. The package Heap then declares the one storage pool used in this example with the discriminant giving its size.

There is then a root package Stacks defining the limited interface Stack and abstract operations Push and Pop. The child packages Stacks.Linked and Stacks.Vector then declare the derived types L_Stack and V_Stack which implement the two kinds of stacks.

The package Tower declares the three poles and procedures Start and Move. The procedure Move implements the familiar recursive algorithm.

Two access types are involved, Stack_Ptr in the package Tower for the class wide pointers to the three stacks and Cell_Ptr in the package Stacks.Linked for the cells making up the linked stack. Both use the same storage pool, The_Pool, declared in the package Heap.

Finally, the main subprogram interacts with the user and asks for the size of the stack and the kinds of stack for the three poles; it then calls Start and Move as requested.

This chapter describes the main composite types which are arrays and records. It also completes our discussion of enumeration types by introducing characters and strings. At this stage we discuss arrays fairly completely but consider only the simplest forms of records. Tagged records and interfaces which permit extension and polymorphism are discussed in Chapter 14 and discriminated records which include variant records are deferred until Chapter 18. Tasks and protected types which are also classified as composite are discussed in Chapter 20.

Arrays

An array is a composite object consisting of a number of components all of the same type (strictly, subtype). An array can be of one, two or more dimensions. A typical array declaration might be

This declares A to be a variable object which has six components, each of which is of type Float. The individual components are referred to by following the array name with an expression in parentheses giving an integer value in the discrete range 1 .. 6. If this expression, known as the index value, has a value outside the bounds of the range, then the exception Constraint_Error will be raised. We could set zero in each component of A by writing

An array can be of several dimensions, in which case a separate range is given for each dimension. So

is an array of 12 components in total, each of which is referred to by two integer index values, the first in the range 0 .. 2 and the second in the range 0 .. 3. The components of this two-dimensional array could all be set to zero by a nested loop thus

The discrete ranges do not have to be static; one could have

and the value of N at the point when the declaration of B is elaborated would determine the number of components in B.

This third part is the core of the book and is largely about abstraction. As mentioned in Chapter 1, the evolution of programming languages is essentially about understanding various aspects of abstraction and here we look in depth at the facilities for data abstraction, object oriented programming and programming by contract.

Chapter 12 shows how packages and private types are the keystone of Ada and can be used to control visibility by giving a client and server different views of an object. This chapter also introduces the simplest ideas of type derivation and inheritance and the very important notion of a limited type which is a type (strictly a view of a type) for which copying is not permitted. Limited types are important for modelling those real-world objects for which copying is inappropriate. Chapter 13 then discusses the hierarchical library structure and the facilities for separate compilation. As mentioned earlier, these enable a program to be compiled in distinct units without any loss of strong typing between units.

A third complete program follows Chapters 12 and 13 and illustrates the use of the hierarchical library in the construction of an abstract data type and associated operations.

The basic facilities for object oriented programming are then introduced in Chapter 14. This covers type extension and inheritance, dynamic polymorphism, dispatching, class wide types, abstract types and interfaces. This chapter concentrates very much on the basic nuts and bolts, and a further discussion of OOP is deferred until Chapter 21 when other aspects of the language have been introduced.

Chapter 15 then covers exceptions and is followed by Chapter 16 which discusses the very important topic of contracts which are perhaps the most important new feature introduced in Ada 2012.

Chapter 17 is a detailed discussion of numeric types including modular types and the rather specialized fixed point types which were not discussed in Chapter 6.

Chapters 18 and 19 return to the theme of abstraction by considering two forms of parameterization. Chapter 18 discusses the parameterization of types by discriminants. Chapter 19 discusses genericity which enables both subprograms and packages to be parameterized in many different ways. Genericity provides static polymorphism checked at compile time in contrast to the dynamic polymorphism of type extension.

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.

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 following glossary of terms is adapted from Annex N of the ARM.

Abstract type An abstract type is a tagged type intended for use as an ancestor of other types, but which is not allowed to have objects of its own.

Access type An access type has values that designate aliased objects. Access types correspond to ‘pointer types’ or ‘reference types’ in some other languages.

Aliased An aliased view of an object is one that can be designated by an access value. Objects allocated by allocators are aliased. Objects can also be explicitly declared as aliased with the reserved word aliased. The Access attribute can be used to create an access value designating an aliased object.

Ancestor An ancestor of a type is the type itself or, in the case of a type derived from other types, its parent type or one of its progenitor types or one of their ancestors. Note that ancestor and descendant are inverse relationships.

Array type An array type is a composite type whose components are all of the same type. Components are selected by indexing.

Aspect An aspect is a specifiable property of an entity. An aspect may be specified by an aspect specification on the declaration of the entity. Some aspects may be queried via attributes.

Assertion An assertion is a Boolean expression that appears in any of the following: a pragma Assert, a predicate, a precondition, a postcondition, an invariant, a constraint, or a null exclusion.

A major feature of the predefined library of Ada 2012 is the container library. This is rather extensive and merits this separate chapter on its own.

The main part of the library comprises several generic packages for the manipulation of various kinds of important data structures. These structures are vectors, doubly linked lists, maps and sets (both hashed and ordered), multiway trees, a holder (or wrapper), and various task safe queues. There are also generic packages for sorting arrays and other general structures.

Organization of library

The container library comprises a root package Ada.Containers plus various child generic packages. The main generic packages form three groups. The first group concerns objects of definite types; the second group concerns indefinite types, and the third group has bounded capacity for objects of definite types.

It will be remembered that an indefinite (sub)type is one for which we cannot declare an object without giving a constraint (either directly or indirectly from its initial value).

The reason for distinct containers for definite and indefinite types concerns efficiency. It is much easier to manipulate definite types and although the packages for indefinite types can be used for definite types, this would be rather inefficient.

Another consideration is reliability. For high integrity applications it is generally unacceptable to use dynamic storage allocation. Accordingly, a separate group of containers with bounded capacity is provided for definite types.