This final part completes the story and largely describes the predefined library and other material which enable the Ada program to communicate with various aspects of its environment.

In essence the predefined environment comprises the four packages Standard, Ada, System and Interfaces. Chapters 23 and 24 cover Standard and Ada which are essentially independent of the underlying system whereas Chapter 25 covers System and Interfaces which very much depend upon the underlying system. The discussions in Chapters 23 and 24 are reasonably comprehensive and cover all the points necessary for normal use; the container library is rather large and has been factored off into Chapter 24. The discussion in Chapter 25 is less thorough because it depends upon the implementation.

Chapters 23 and 25 are each followed by a complete program. The first illustrates the use of the string handling and random number generation features provided by the predefined library and the second illustrates how users can provide their own storage pools.

Chapter 26 is an overview of the scope of the six specialized annexes. Although this book does not attempt serious coverage of these annexes nevertheless a brief overview of their scope seems appropriate. In particular enough information is given to use the complex number and vector and matrix facilities of the Numerics annex. Some material on task termination and timers from the Systems Programming and Real-Time annexes was covered in detail in Chapter 22.

The final Chapter 27 pulls together a small number of loose threads, considers the problems of portability and some thoughts on matters such as design and the construction of programs from components and concludes with an introduction to SPARK.

There are then three appendices. Appendix 1 lists the reserved words, attributes, aspects, pragmas, and restrictions; Appendix 2 contains a brief glossary; and Appendix 3 gives the complete syntax plus index.

The book concludes with answers to selected exercises; the reader is encouraged to study these and especially any discussion which often covers minor but nevertheless important points. Note that the answers to all the exercises and other supplementary material will be found on the web.

This last chapter concerning the small-scale aspects of Ada is about access types. These are often known as pointer types, reference types or simply addresses in other languages and provide indirect access to other entities.

Playing with pointers is like playing with fire. Fire is perhaps the most important tool known to man. Carefully used, fire brings enormous benefits; but when fire gets out of control, disaster strikes. Pointers have similar characteristics but are well tamed in the form of access types in Ada.

This taming is done through the notion of accessibility which is discussed in some detail in Sections 11.5 and 11.6. Parts of these sections might be found hard to digest and could well be skipped at a first reading.

There are two forms of access types, those which access objects and those which access subprograms. Their type may be named or anonymous. Of particular importance are parameters of an anonymous access type. The related access discriminants are discussed in Chapter 18.

Flexibility versus integrity

The manipulation of objects by referring to them indirectly through values of other objects is a common feature of most programming languages. It is also a contentious topic since, although the technique provides considerable flexibility, it is also the cause of many programming errors and moreover, used incautiously, can make programs very hard to understand and maintain. It is worth a historical digression in order to place Ada in perspective.

Algol 68 was an early language to use indirection and used the term references. Indeed the definition of Algol 68 revolved around references to such an extent that it created the impression that the language was academically elaborate. There were also technical difficulties of dangling references, that is variables pointing to objects that no longer exist.

BCPL, from which C was derived, used references or pointers as the foundation of its storage model. Arrays were just seen as objects that could be referred to dynamically by adding an index to a base address. Thus the natural implementation model was made visible in the language itself. This almost negative abstraction was perhaps a great mistake and a step backwards in the evolution of abstraction as the driving force in language design.

C has inherited the BCPL model and it is considered quite normal practice in C to add integers to pointers (addresses) thereby creating implementation dependencies and complete freedom to do silly things.

In the previous chapters, we introduced some concepts of Ada and illustrated the general appearance of Ada programs with some simple examples. However, we have so far only talked around the subject. In this chapter we get down to serious detail.

Regrettably it seems best to start with some rather unexciting but essential material – the detailed construction of things such as identifiers and numbers which make up the text of a program. However, it is no good learning a human language without getting the spelling sorted out. And as far as programming languages are concerned, compilers are usually very unforgiving regarding such corresponding and apparently trivial matters.

We also take the opportunity to introduce the notation used to describe the syntax of Ada. In general we will not use this syntax notation to introduce concepts but, in some cases, it is the easiest way to do so. Moreover, if the reader wishes to consult the ARM then knowledge of the syntax notation is necessary. For completeness and easy reference the full syntax is given in Appendix 3.

Syntax notation

The syntax of Ada is described using a variant of Backus–Naur Form (BNF). In this notation, syntactic categories are represented by lower case names; some of these contain embedded underlines to increase readability. A category is defined in terms of other categories by a sort of equation known as a production. Some categories are atomic and cannot be decomposed further – these are known as terminal symbols. A production consists of the name being defined followed by the special symbol ::= and its defining sequence.

Other symbols used are

Sometimes the name of a category is prefixed by a word in italics. In such cases the prefix aims to convey some semantic information and can be treated as a form of comment as far as the context free syntax is concerned. Where relevant, a production is presented in a form that shows the recommended layout.

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. An assertion is expected to be True at run time at certain specified places.

Category (of types) A category of types is a set of types with one or more common properties, such as primitive operations. A category of types that is closed under derivation is also known as a class.

Character type A character type is an enumeration type whose values include characters.

Class (of types) A class of types is a set of types that is closed under derivation, which means that if a given type is in the class, then all types derived from that type are also in the class. The set of types of a class share common properties, such as their primitive operations.

Compilation unit The text of a program can be submitted to the compiler in one or more compilations.

In this chapter we discuss the hierarchical library structure and other mechanisms for separate compilation which were outlined in Chapter 4.

Many languages ignore the simple fact that programs are written in pieces, compiled separately and then joined together. Indeed large programs should be thought of as being composed out of a number of subsystems which themselves have internal structure. There are in fact two distinct requirements.

There is a requirement for decomposing a large coherent program into a number of internal subcomponents. Such a decomposition has particular advantages when a large program is being developed by a team.

There is also a requirement for the creation of a program library where subsystems are written for general use and consequently are written before the programs that use them. Within this structure it is convenient to decompose the interface presented to future clients so that they may select only those parts of a system that are required.

This chapter also contains a further discussion on scope and visibility and summarizes the curious topic of renaming.

Library units

We will start by considering which units of Ada can be compiled separately and the general idea of dependency.

The most common units of compilation are package specifications and bodies and subprograms. Such units may be compiled individually or for convenience several could be submitted to the compiler together. Thus we could compile the specification and body of a package together but, as we shall see, it may be more convenient to compile them individually. As usual a subprogram body alone is sufficient to define the subprogram fully.

A library unit can also be a generic package or subprogram or an instantiation of one as discussed further in Section 27.3.

Compilation units are kept in a program library in some form. We will describe the behaviour in general terms but an implementation may use any model that satisfies two major requirements: a program cannot be built out of units that are not consistent, and a unit cannot be compiled until all units upon which it depends are present in the library.

There are two obvious compilation models according to the form in which the compiler needs the information regarding dependency.

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.

Packages and private types

In the previous chapter we declared a type for the manipulation of a buffer as follows

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 inadvertently 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

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 chapter we describe the parameterization of types by what are known as discriminants. Discriminants are components which have special properties. All composite types other than arrays can have discriminants. In this chapter we deal with the properties of discriminants in general and their use with record types (both tagged and untagged); their use with task and protected types is discussed in Chapter 20.

Discriminants can be of a discrete type or an access type. In the latter case the access type can be a named access type or it can be anonymous. A discriminant of an anonymous access type is called an access discriminant by analogy with an access parameter.

We start by dealing with discrete discriminants of untagged types.

Discriminated record types

In the record types we have seen so far there was no formal language dependency between the components. Any dependency was purely in the mind of the programmer as for example in the case of the private type Stack in Section 12.4 where the interpretation of the array S depended on the value of the integer Top.

In the case of a discriminated record type, some of the components are known as discriminants and the remaining components can depend upon these. The discriminants can be thought of as parameterizing the type and the syntax reveals this analogy.

As a simple example, suppose we wish to write a package providing various operations on square matrices and that in particular we wish to write a function Trace which sums the diagonal elements of a square matrix. We could contemplate using the type Matrix of Section 8.2

but the function would then have to check that the matrix passed as an actual parameter was indeed square. We would have to write something like

This is somewhat unsatisfactory; we would prefer to use a formulation which ensured that the matrix was always square and had a lower bound of 1. We can do this using a discriminated type. Consider

We now come at last to a more detailed discussion of numeric types. There are two categories of numeric types in Ada: integer types and real types. The integer types are subdivided into signed integer types and modular types (these are unsigned). The real types are subdivided into floating point types and fixed point types; the fixed point types are further subdivided into ordinary fixed point types and decimal types.

There are two problems concerning the representation of numeric types in a computer. First, the range will inevitably be restricted and indeed many machines have hardware operations for various ranges so that we can choose our own compromise between range of values and space occupied by values. Secondly, it may not be possible to represent accurately all the possible values of a type. These difficulties cause problems with program portability because the constraints vary from machine to machine. Getting the right balance between portability and performance is not easy. The best performance is achieved by using types that correspond exactly to the hardware. Perfect portability requires using types with precisely identical range and accuracy and identical operations.

Ada recognizes this situation and provides numeric types in ways that allow a programmer to choose the correct balance for the application. High performance can thus be achieved while keeping portability problems to a minimum.

We start by discussing integer types because these are somewhat simpler since they are parameterized only by their range whereas the real types are parameterized by both range and accuracy.

Signed integer types

All implementations of Ada have the predefined type Integer. In addition there may be other predefined types such as Long_Integer, Short_Integer and so on with a respectively longer or shorter range than Integer (could actually be the same). The range of values of these predefined types will be symmetric about zero except for an extra negative value in two's complement machines (which now seem to dominate over one's complement machines). All predefined integer types have the same predefined operations that were described in Chapter 6 as applicable to the type Integer (except that the second operand of “**” is always of type Integer).

We have now introduced all the main features of Ada 2012 and illustrated them with many examples. An important topic which has arisen in various forms is object oriented programming. Chapter 14 introduced type extension and dynamic polymorphism using tagged types. Chapter 18 discussed type parameterization by discriminants. Chapter 19 covered static polymorphism through genericity. And finally Chapter 20 on tasking discussed concurrent objects which some might feel are the only true objects anyway.

However, the linear exposition has prevented us from exploring a number of important interactions between these features. Accordingly this chapter addresses a number of examples which further illustrate the various techniques and show how they fit together. The next chapter addresses further examples of tasking.

Extension and composition

We start this chapter on object oriented techniques with some general remarks about type composition.

There are a number of ways in which types can be put together. An array type is composed of two other types, the index type and the component type. A record type is composed of the several types of its components. Type extension is a special form of composition in which a record type has the same components as another type plus additional components at the same level.

As an example consider the following two declarations of the type Circle

Although both have three eventual components, the structure and naming are quite different. The fundamental difference is between ‘X is a Y’ and ‘X has a Y’. The circle is an object and so the type extension is the appropriate form.

It is interesting to contrast this with

briefly introduced in Section 14.1. This type Cylinder is foolish; a cylinder is not a circle although it does have a circle as part of its structure.

In deciding the correct approach, a good test is to check that class wide operations still apply – especially since they cannot be overridden. But clearly Distance is curious because the distance to the centre of the cylinder will depend upon whether we are thinking of the cylinder as standing on the plane or not.

This final chapter summarizes various overall aspects of Ada. The first three sections cover some general topics which have been introduced in stages throughout the book. There is then a section on the important issue of portability. The penultimate section airs a few philosophical thoughts about programming in general and Ada in particular. And then the last section is an introduction to the SPARK language which is based on Ada and is used for those essential high integrity systems where life and limb and the environment are at risk if the software is incorrect.

Names and expressions

The idea of a name should be carefully distinguished from that of an identifier. An identifier is a syntactic form such as Fred which is used for various purposes including introducing entities when they are declared. An operator has a similar status to an identifier; operators and identifiers are collectively referred to as direct names in the syntax. A name, on the other hand, may be more complex and is the form used to denote entities in general. The reader might find it helpful to consult the syntax in Appendix 3 and especially items 41 (name), 42 (direct_name), and 55 (primary).

This second part covers the small-scale algorithmic features of the language in detail. These correspond to the areas covered by simple languages such as Pascal and C although Ada has much richer facilities in these areas.

Chapter 5 deals with the lexical detail which needs to be described but can perhaps be skimmed on a first reading and just referred to when required. It also briefly introduces aspect specifications which are an important new feature of Ada 2012.

Chapter 6 is where the story really begins and covers the type model and illustrates that model by introducing most of the scalar types. Chapter 7 then discusses the control structures which are very straightforward. Chapter 8 covers arrays in full but only the simplest forms of records; it is also convenient to introduce characters and strings in this chapter since strings in Ada are treated as arrays of characters. Chapter 8 is quite long compared with a corresponding discussion on Pascal or C largely because of the named notation for array aggregates which is an important feature for writing readable programs.

Chapter 9 discusses the more elaborate forms of expressions introduced in Ada 2012, namely if expressions, case expressions and quantified expressions.

Subprograms are discussed in Chapter 10 and at this point we can write serious lumps of program. Again the named notation enriches the discussion and includes the mechanism for default parameters.

Chapter 11 contains a discussion on access types which correspond to pointers in Pascal and C.

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.

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. A good example of the use of this hierarchical naming scheme is found in the standard libraries which are provided by every implementation of Ada.

We have already mentioned the package Standard which is an intrinsic part of the language. All library units can be considered to be children of Standard and it should never (well, hardly ever) be necessary to explicitly mention Standard at all (unless you do something crazy like redefine Integer to mean something else; the original could then still be referred to as Standard.Integer).

In order to reduce the risk of clashes with users’ own names the predefined library comprises just three packages each of which has a number of children. The three packages are System, which is concerned with the control of storage and similar implementation matters; Interfaces, which is concerned with interfaces to other languages and the intrinsic hardware types; and finally Ada which contains the bulk of the predefined library.

In this chapter we describe the parameterization of types by what are known as discriminants. Discriminants are components which have special properties. All composite types other than arrays can have discriminants. In this chapter we deal with the properties of discriminants in general and their use with record types (both tagged and untagged); their use with task and protected types is discussed in Chapter 20.

Discriminants can be of a discrete type or an access type. In the latter case the access type can be a named access type or it can be anonymous. A discriminant of an anonymous access type is called an access discriminant by analogy with an access parameter.

We start by dealing with discrete discriminants of untagged types.

Discriminated record types

In the record types we have seen so far there was no formal language dependency between the components. Any dependency was purely in the mind of the programmer as for example in the case of the private type Stack in Section 12.4 where the interpretation of the array S depended on the value of the integer Top.

In the case of a discriminated record type, some of the components are known as discriminants and the remaining components can depend upon these. The discriminants can be thought of as parameterizing the type and the syntax reveals this analogy.

This chapter considers various aspects of how an Ada program interfaces to the outside world. One area is the mapping of the abstract Ada program onto the computer; how the data structures are represented and so on. Another important aspect is communication with programs in other languages. (Communication with the outside world through interrupts is dealt with in Section 26.1.) However, the discussion in this chapter cannot be exhaustive because many details of this area will depend upon the implementation. The intent, therefore, is to give the reader a general overview of the facilities available.

Representations

When compiling a program, the compiler needs to decide how the various data items are to be represented. Certain uses or occurrences of entities require that their representation be known; such occurrences are called freezing points. We can provide explicit information about certain aspects of an entity and that of course determines that aspect. If no such information is provided then the compiler has to make some default decision at the first freezing point.

An obvious example is that declaring an object requires that its type be frozen. This does not apply to deferred constants since in the case of private types the freezing is deferred until the full type declaration. If we wish to provide our own representation then this must be done before the entity is otherwise frozen. Note that the end of a declarative part freezes all the items declared in it anyway (except for incomplete types) and so any representation information must be in the same declarative part as the entity to which it applies.

In most cases the freezing rules are very much a fringe aspect of the language and intuitively obvious and have little impact on the normal programmer. One important interaction with other rules was however noted in Section 14.6 when we discussed type extension and primitive operations. We noted that we cannot add further primitive operations after a tagged type is frozen and moreover that a tagged type is frozen when a type is derived from it.

In summary, a type must be fully defined, including all aspect clauses and dispatching operations, before it is frozen. Declaring an object of a type or extending a type freezes it.

We can provide our own representations using aspect clauses which can take various forms or (in Ada 2012) in most cases by using aspect specifications.

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.