Chapter 1: Introduction

Let us begin with why do we need another revision, when Ada has been used to successfully deliver so many projects around the world, indeed across the solar system?

The world has moved on. The most significant external factor has probably been the growth of the number of cores on a processor. Making use of the first multi-core processors was relatively easy for Ada compared with other languages as tasking had been included from the outset. Maybe latent timing problems would emerge when tasks were truly running on different processors instead of just pretending to, but these problems were small scale compared with, say, elaboration order problems when moving between different vendors' compilers.

These days a processor may have dozens of cores, maybe in the future it will be hundreds. Thus the first improvement given in the list of instructions (see below) from WG 9 (the ISO/IEC Working Group responsible for Ada), to the Ada Rapporteur Group (ARG), was finer grained control of parallelism.

The ARG follows the following instructions from WG 9, extracted from ISO/IEC JTC 1/SC 22/WG 9 N571:

“The ARG is requested to pay particular attention to the following two categories of improvements:

Improvements that will maintain or improve Ada's advantages, especially in those user domains where safety and security are prime concerns;

Improvements that will remedy shortcomings in Ada.

Improvements of special interest in these categories are:

Improving the capabilities of Ada on multi-core and multi-threaded architectures;

Improving the ability to write and enforce contracts for Ada entities (for instance, via preconditions);

Improving the use and functionality of the predefined containers;

Improving support for Unicode in the language and predefined libraries.

These are all examples of improvements in category A, except for the last which is an example of an improvement in category B.”

New real-time features have also arisen, primarily from recommendations from the series of International Real-Time Ada Workshops (IRTAW).

As always, there is the balancing act to be struck between keeping the language stable and backwardly compatible, and adding new features to keep with the times.

Each topic is organized in terms of the relevant Ada Issue(s). When appropriate, a reference to the Reference Manual subclause that primarily defines the feature is also included.

An Ada Issue is an investigation of a comment raised on the Ada standard. These are first worked on and approved by the ARG. They are then passed to WG 9 for consideration and approval before eventually being consolidated and sent to ISO for formal processing to create a revised internation standard. Ada Issues raised on Ada 2012 were assigned numbers of the form AI12-nnnn-aa, where aa is the alternative number. These AIs may be found at http://www.ada-auth.org/AI12-SUMMARY.HTML (for HTML versions of this document, the numbers link to the appropriate AI as well). The relevant AI title and number are quoted in the following sections, omitting the alternative number if there is only one alternative.

Thanks to Randy Brukardt for his many suggestions, and to John Barnes for his review comments, and to the rest of the ARG, especially Tucker Taft, for their examples.

NOTE 1 Contemporary English is used where possible, but where a word is quoted from the RM, then of necessity the US spelling is used.

NOTE 2 RM references give the location of the primary definition of a features; rules defining the feature may occur in other parts of the RM as well. An RM reference is not given when a feature does not have a obvious primary definition; the feature may be defined in multiple places or implicitly in rules defining other concepts.