This program illustrates the use of a hierarchical library to create an abstract data type and its associated operations. It is based on the type Rational of Exercise 12.2(3).

The root package Rational_Numbers declares the type Rational and the usual arithmetic operations. The private child package Rational_Numbers.Slave contains the functions Normal and GCD as in Exercise 13.4(1). Thus Normal cancels any common factors in the numerator and denominator and returns the normalized form. It is called by various operations in the parent package. It would be possible to restructure Normal so that it was a private child function.

Appropriate input-output subprograms are declared in the public child Rational_Numbers.IO.

In order to exercise the rational subsystem a simple interpretive calculator is added as the main subprogram. This enables the user to read in rational numbers, perform the usual arithmetic operations upon them and print out the result.

The numbers are held in a stack which is operated upon in the reverse Polish form (Polish after the logician Jan/Lucasiewicz). The root package Rat_Stack contains subprograms Clear, Push and Pop. The private child package Rat_Stack.Data contains the actual data, and the public child procedure Rat_Stack.Print_Top prints the top item. This structure is somewhat similar to that described in Section 13.4 and enables the stack size to be changed with minimal effect on the rest of the system.

The main subprogram is decomposed into subunits Process and Get_Rational in order to isolate the dependencies and clarify the structure.

This chapter describes the three bracketed sequential control structures of Ada. These are the if statement, the case statement and the loop statement. These three statements enable programs to be written with a clear flow of control without using goto statements and labels. However, for pragmatic reasons, Ada does have a goto statement and this is also described in this chapter.

The three control structures exhibit a similar bracketing style. There is an opening reserved word if, case or loop and this is matched at the end of the structure by the same reserved word preceded by end. The whole is, as usual, terminated by a semicolon. So we have

In the case of the loop statement the word loop can be preceded by an iteration scheme commencing with for or while.

Corresponding structures for expressions such as if expressions and case expressions which are introduced in Ada 2012 are described in Chapter 9.

If statements

The simplest form of if statement starts with the reserved word if followed by a Boolean expression and the reserved word then. This is then followed by a sequence of statements which will be executed if the Boolean expression turns out to be True. The end of the sequence is indicated by the closing end if. The Boolean expression can, of course, be of arbitrary complexity and the sequence of statements can be of arbitrary length.

A simple example is

In this, Hungry is a Boolean variable and Cook, Eat and Wash_Up are various subprograms describing the details of the activities. The statement Eat; merely calls the corresponding subprogram (subprograms are dealt with in detail in Chapter 10).

The effect of this if statement is that if variable Hungry is True then we call the subprograms Cook, Eat and Wash_Up in sequence and otherwise we do nothing. In either case we then obey the statement following the if statement.

Note how we indent the statements to show the flow structure of the program. This is most important since it enables the program to be understood so much more easily. The end if should be underneath the corresponding if and the then is best placed on the same line as the if.

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).

Syntactically, a name typically starts with an identifier such as Fred or an operator symbol such as “+” and can then be followed by one or more of the following in an arbitrary order

• • one or more index expressions in parentheses; this denotes a component of an array,

• • a discrete range in parentheses; this denotes a slice of an array,

• • an apostrophe plus an identifier, possibly indexed; this denotes an attribute,

• • a dot followed by an identifier, operator or all; this denotes a record component, an object designated by an access value, or an entity in a package, task, protected object, subprogram, block or loop,

• • an actual parameter list in parentheses; this denotes a function call.

Type conversions, qualified expressions, and character literals are also treated as names in the syntax. Character literals are considered to be parameterless functions and can be renamed. In addition, generalized references and generalized indexing, which were discussed in Section 21.6, are also considered to be names.

Names are just one of the primary components of an expression.

This program is a variation of the Sieve of Eratosthenes for finding prime numbers described in Section 22.1. The concept of primality applies to many algebraic structures and not just to the integers and so this program includes a generic form of the sieve and three instantiations.

One instantiation gives the normal primes and so is based on the type Integer.

The second is based on complex or Gaussian integers of the form p + iq where p and q are integers and i is of course the square root of minus one.

The third is based on polynomials whose coefficients are integers modulo 2, that is can only be zero or one. Examples of such polynomials are x + 1 and x3 + x + 1.

The program asks the user to identify the kind of primes to be searched for and how many values to test. It prints the primes as they are found and concludes by noting the total number found.

The generic package Eratosthenes contains the various tasks. It has a number of generic parameters defining the algebraic structure. There is also a private generic package Eratosthenes.Frame containing the interface to the display mechanism. In this demonstration exercise the display mechanism is simplified to just printing out each new prime on a new line but the interface is retained for compatibility with the example in Chapter 22.

There are then three packages Integer_Stuff, Complex_Stuff and Poly_Stuff containing the types and subprograms required for the three algebraic structures. These are followed by three corresponding instantiations of the generic package Eratosthenes which are Integer_Sieve, Complex_Sieve and Poly_Sieve.

Finally, the main subprogram calls the procedure Do_It of the instantiation of Eratosthenes according to the algebraic structure chosen by the user.

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.

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.

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.

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.

This chapter describes the mechanisms for defining and enforcing contracts introduced in Ada 2012. The general idea is that we add aspects defining certain requirements on the behaviour of an entity such as a subprogram and then, when the subprogram is executed, if any of these requirements are not met, an exception is raised.

As well as specifying pre- and postconditions on subprograms, we can also specify invariant properties of private types, and additional restrictions on the values of subtypes. These properties are all given by the use of aspect specifications briefly mentioned in Section 5.6.

Indeed, it was the introduction of pre- and postconditions that triggered the introduction of aspect specifications into Ada 2012. Moreover, as mentioned in Chapter 9, these in turn triggered the introduction of conditional and quantified expressions.

We start by giving further details of the rules regarding aspect specifications.

Aspect specifications

As we saw in Section 15.5 we can apply an aspect such as No_Return to a procedure using an aspect specification. We can supply several aspects by a series of aspect specifications as follows

In the general case an aspect specification supplies an expression for the aspect following =>. In the case of both Inline and No_Return, these aspects take a Boolean value so we could pedantically write

There is a general rule that if an aspect requires a Boolean value then it can be omitted and by default is taken to be true. But this does not apply to the aspects Default_Value and Default_Component_Value, see Sections 6.8 and 8.2.

As we see, aspect specifications are introduced by the reserved word with and if there are several they are separated by commas. The word with is used for a number of purposes (we have already met with clauses and type extensions) and this might be considered confusing. However, with a sensible layout there should be no problems.

In the case of a subprogram without a distinct specification, the aspect specification goes in the subprogram body before is thus

This arrangement is because the aspect specification is very much part of the specification of the subprogram.

In this chapter we describe the generic mechanism which allows a special form of parameterization at compile time which can be applied to subprograms and packages. The generic parameters can be types of various categories (access types, limited types, tagged types and so on), subprograms and packages as well as values and objects.

Genericity is important for reuse. It provides static polymorphism as opposed to the dynamic polymorphism provided by type extension and class wide types. Being static it is intrinsically more reliable but usually less flexible. However, in the case of subprogram parameters it does not have the convention restrictions imposed by access to subprogram types and thus is particularly useful where the parameter is an operation.

Package parameters enable the composition of generic packages while ensuring that their instantiations are compatible. They can also be used to group together the parameters of other generic units to provide signatures.

Declarations and instantiations

We often get the situation that the logic of a piece of program is independent of the types involved and it therefore seems unnecessary to repeat it for all the different types to which we might wish it to apply. A simple example is provided by the procedure Swap of Exercise 10.3(1)

It is clear that the logic is independent of the type Float. If we also wanted to swap integers or dates we could write other similar procedures but this would be tedious. The generic mechanism allows us to avoid this. We declare

The subprogram Exchange is a generic subprogram and acts as a kind of template. The subprogram specification is preceded by the generic formal part consisting of the reserved word generic followed by a (possibly empty) list of generic formal parameters. The subprogram body is written exactly as normal but note that, in the case of a generic subprogram, we always have to give both the specification and the body separately.

A generic procedure is not a real procedure and so cannot be called; but from a generic procedure we can create an actual procedure by a mechanism known as generic instantiation.

This program is a variation of the Sieve of Eratosthenes for finding prime numbers described in Section 22.1. The concept of primality applies to many algebraic structures and not just to the integers and so this program includes a generic form of the sieve and three instantiations.

One instantiation gives the normal primes and so is based on the type Integer.

The second is based on complex or Gaussian integers of the form p + iq where p and q are integers and i is of course the square root of minus one.

The third is based on polynomials whose coefficients are integers modulo 2, that is can only be zero or one. Examples of such polynomials are x + 1 and x3 + x + 1.

The program asks the user to identify the kind of primes to be searched for and how many values to test. It prints the primes as they are found and concludes by noting the total number found.

The generic package Eratosthenes contains the various tasks. It has a number of generic parameters defining the algebraic structure. There is also a private generic package Eratosthenes. Frame containing the interface to the display mechanism. In this demonstration exercise the display mechanism is simplified to just printing out each new prime on a new line but the interface is retained for compatibility with the example in Chapter 22.

Chapter 20 covered the basic concepts concerning tasking. This chapter provides a number of further examples of tasks and protected objects in order to illustrate how the various facilities work together.

An important topic which was only briefly alluded to earlier is the use of synchronized interfaces which pull together two very important features of programming namely OOP and concurrency.

Some topics covered in this chapter are in fact defined in the Systems Programming or Real-Time Systems annexes and thus might not be available in all implementations. However, they seem worthy of more detail than would otherwise be given in the brief notes on the specialized annexes in Chapter 26.

Dynamic tasks

The first example is an interesting demonstration of the dynamic creation of task objects. The objective is to find and display the first few prime numbers using the Sieve of Eratosthenes. (Eratosthenes was a Greek mathematician in the 3rd century BC and a friend of Archimedes of Eureka fame.) This ancient algorithm works using the observation that if we have a list of the primes below N, then N is also prime if none of these divide exactly into it. So we try the existing primes in turn and as soon as one divides N we discard N and try again with N set to N+1. If we get to the end of the list of primes without dividing N, then N must be prime, so we add it to the list and start again with N+1.

This 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.

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.

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.

This short chapter describes additional forms of expressions introduced in Ada 2012. These are related to the three bracketed sequential control structures of Ada described in the previous chapter. Thus, corresponding to the if statement there is the if expression and corresponding to the case statement there is the case expression. There are also quantified expressions and these are related to loop statements. We also discuss the new forms of membership tests in Ada 2012.

It is perhaps very surprising that Ada did not have conditional forms of expressions right from the beginning. Even Algol 60 had conditional expressions. However, perhaps there was a feeling that conditional expressions could lead one astray by loosening the crisp distinction between statements and expressions.

The incentive to introduce conditional expressions into Ada was triggered by the addition of pre- and postconditions which are described in Chapter 16. Without adding conditional forms of expressions these pre- and postconditions would have been cumbersome and required lots of small functions. However, these additional forms of expressions are applicable in other situations as well and it seems appropriate to describe them here.

Membership tests

Membership tests were introduced in Section 6.9 where we showed how they could be used to check whether a value lies within a specified range or satisfies a constraint implied by a subtype.