
1   Evolution of Ada 9X



Ada is a modern programming language suitable for those application
areas which benefit from the discipline of organized development,
that is, Software Engineering; it is a general purpose language with
special applicability to real-time and embedded systems.  Ada was
originally developed by an international design team in response to
requirements issued by the United States Department of Defense [DoD
78].
   Ada 9X is a revised version of Ada updating the 1983 ANSI Ada
standard [ANSI 83] and the equivalent 1987 ISO standard [ISO 87] in
accordance with ANSI and ISO procedures.  This present document
describes the overall Rationale for the revision.


1.1  The Revision Process

Although Ada was originally designed to provide a single flexible
yet portable language for real-time embedded systems to meet the
needs of the US DoD, its domain of application has expanded to
include many other areas, such as large-scale information systems,
distributed systems, scientific computation, and systems
programming.  Furthermore, its user base has expanded to include all
major defense agencies of the Western world, the whole of the
aerospace community and increasingly many areas in civil and private
sectors such as telecommunications, process control and monitoring
systems.  Indeed, the expansion in the civil sector is such that
civil applications now generate the dominant revenues of many
vendors.
   After some years of use and many implementations, a decision was
made in 1988 to undertake a revision to Ada, leading to an updated
ANSI/ISO standard.  It is normal practice to automatically
reconsider such standards every 5 or 10 years and to determine
whether they should be abandoned, reaffirmed as they are or updated.
In the case of Ada, an update was deemed appropriate.
   To understand the process it should be explained that ANSI, as
the US national standards body, originally proposed that Ada become
an ISO standard.  It is normal practice that ANSI, as the
originating body, should sponsor a revised standard as necessary.
The US DoD acted as the agent of ANSI in managing the development of
the revised standard.  Within the US DoD, the Ada Joint Program
Office (AJPO) is responsible for Ada and the Ada Board is a federal
advisory committee which advises the AJPO.
   The revision effort began in January 1988 when the Ada Board was
asked to prepare a recommendation to the AJPO on the most
appropriate standardization process to use in developing a revised
Ada standard, known in the interim as Ada 9X.  The recommendation
[DoD 88] was delivered in September 1988 to Virginia Castor, the
then Director of the Ada Joint Program Office, who subsequently
established the Ada 9X Project for conducting the revision of the
Ada Standard.  Christine M Anderson was appointed Project Manager in
October 1988.  Close consultation with ISO was important to ensure
that the needs of the whole world-wide Ada community (and not just
the defense community) were taken into account and to ensure the
timely adoption by ISO of the new standard.  Accordingly a
Memorandum of Understanding was established between the US DoD and
ISO [ISO 90].
   The Ada 9X program consists of three main phases: the
determination of the Requirements for the revised language; the
actual Development of the definition of the revised language; and
the Transition into use from Ada 83 to Ada 9X.
   The output of the Requirements Definition phase was the Ada 9X
Requirements document [DoD 90], which specifies the revision needs
which had to be addressed.  The Mapping/Revision phase defined the
changes to the standard to meet those requirements; it achieved this
in practice of course by defining the new standard.
   The scope of the changes was guided by the overall objective of
the Ada 9X effort [DoD 89a]

     Revise ANSI/MIL-STD-1815A-1983 to reflect current
     essential requirements with minimum negative impact and
     maximum positive impact to the Ada community.

   It is probably fair to observe that the changes which were deemed
necessary are somewhat greater than might have been foreseen when
the project first started in 1988.  However, technology and man's
understanding do not stand still and the changes now incorporated
are very appropriate to the foreseen needs of a modern language for
Software Engineering into the 21st Century.


1.2  The Requirements

The development of the requirements was a somewhat iterative process
with a number of sub-phases.  First, the community of users was
invited to submit Revision Requests, secondly, these were sorted and
analyzed in order to determine what was really implied by the
requests, and finally, a coherent set of requirements was written.
   Establishing the level of the requirements needed care.  Quite
naturally an individual user would often perceive a need in a manner
which reflected a symptom of an underlying problem rather than the
problem itself.  It was very important that the requirements
reflected the essence of the problem rather than what might in
effect be simply one user's suggested solution to a part of a
problem.  One reason for this concern was to ensure that better,
perhaps deeper and simpler, changes were not excluded by shallow
requirements.
   In some cases a complete understanding of a requirement could not
be established and this led to the introduction of Study Topics.  As
its name implies a Study Topic describes an area where something
ought to be done but for some reason the feasibility of a solution
was in doubt; perhaps the needs are changing rapidly or there are
conflicting needs or implementing technology is unstable or it is
simply that we have an incomplete understanding of some basic
principles.
   The general goal of the revision was thus to satisfy all of the
Requirements and to satisfy as many and as much of the Study Topics
as possible.  Any unsatisfied Study Topics would be set aside for
further consideration for Ada0X (that is the next revision due
around 2003).
   The requirements document describes 41 Requirements and 22 Study
Topics.  These are divided into a number of chapters which
themselves form two broad groups.  The first group covers topics of
widespread applicability, whereas the second group addresses more
specialized topics.
   The first group consists of the need to support International
Character Sets (originally identified by several nations in the 1987
ISO standardization process), support for Programming Paradigms
(Object Orientation is included in this category), Real-Time
requirements, requirements for System Programming (such as Unsigned
Integers), and General requirements.  This last topic includes
specific matters such as error detection and general considerations
of efficiency, simplicity and consistency; examples of a number of
individually minor but irritating aspects of Ada 83 which fall into
this category are given in an appendix.
   The second, specialized, group consists of requirements for
Parallel Processing, Distributed Processing, Safety-Critical
Applications, Information Systems, and Scientific and Mathematical
Applications.
   The breadth of these specialized requirements raised the specter
of a language embracing so many application areas that it would
become too costly to implement in its entirety for every
architecture.  On the other hand, one of the strengths of Ada is its
uniformity and the last thing desired was a plethora of uncontrolled
subsets.  Accordingly, the Requirements document recommended the
concept of a Core language plus a small number of specialized
Annexes as a sensible way forward (with emphasis on keeping the
number of such annexes very small).  All validated compilers would
have to implement the Core language and vendors could choose to
implement zero, one or more annexes according to the needs of their
selected market places.
   The Requirements document also included general guidance on the
approach to be taken to avoid unnecessary disruption to the Ada
community.  This covers vital matters such as the ease of
implementation, object code efficiency, keeping a balance between
change and need, and upward compatibility.  It finally stressed that
support for reliability, safety and long-term maintainability should
continue to take precedence over short-term coding convenience.
   Of all these requirements there was strong emphasis on the
overriding goal of upward compatibility in order to preserve
existing investment by the Ada community as a whole.


1.3  The Main User Needs

The Requirements reflect a number of underlying User Needs which had
become apparent over the years since Ada was first defined.  Apart
from a small number of very specific matters such as the character
set issue, the specialized areas and generally tidying up minor
inconsistencies, four main areas stood out as needing attention:

*    Interfacing.  Ada 83 recognizes the importance of being able to
     interface to external systems by the provision of features such
     as representation clauses and pragmas.  Nevertheless, it is
     sometimes not easy to interface certain Ada 83 programs to
     other language systems.  A general need was felt for a more
     flexible approach allowing, for instance, the secure
     manipulation of references and the passing of procedures as
     parameters.  An example arises when interfacing into GUI's
     where it is often necessary to pass a procedure as a parameter
     for call-back.

*    Programming by Extension.  This is closely allied to
     reusability.  Although Ada's package and generic capability are
     an excellent foundation, nevertheless experience with the OO
     paradigm in other languages had shown the advantages of being
     able to extend a program without any modification to existing
     proven components.  Not only does this save disturbing existing
     software thus eliminating the risk of introducing errors but it
     also reduces recompilation costs.

*    Program Libraries.  The Ada program library brings important
     benefits by extending the strong typing across the boundaries
     between separately compiled units.  However, the flat nature of
     the Ada 83 library gave problems of visibility control; for
     example it prevented two library packages from sharing a full
     view of a private type.  A common consequence of the flat
     structure was that packages become large and monolithic.  This
     hindered understanding and increased the cost of recompilation.
     A more flexible and hierarchical structure was necessary.

*    Tasking.  The Ada rendezvous paradigm is a useful model for the
     abstract description of many tasking problems.  But experience
     had shown that a more static monitor-like approach was also
     desirable for common shared-data access applications.
     Furthermore, the Ada priority model needed revision in order to
     enable users to take advantage of the greater understanding of
     scheduling theory which had emerged since Ada 83 was defined.
   
   The main changes incorporated into Ada 9X reflect the response to
the Requirements in meeting these four key needs while at the same
time meeting an overriding need for upward compatibility in order to
minimize the effort and cost of transition.


1.4  The Approach

In responding to the revision requirements, the Revision team
followed the inspiration of Jean Ichbiah (who led the original
design team), both in remaining faithful to the principles
underlying the original Ada design, and in the approach to the
revision process.  To quote Dr Ichbiah in his introduction to John
Barnes' textbook on Ada [Barnes 82]

     Clearly, further progress can only come by a reappraisal
     of implicit assumptions underlying certain compromises.
     Here is the major contradiction in any design work.  On
     the one hand, one can only reach an harmonious integration
     of several features by immersing oneself into the logic of
     the existing parts; it is only in this way that one can
     achieve a perfect combination.  On the other hand, this
     perception of perfection, and the implied acceptance of
     certain unconscious assumptions, will prevent further
     progress.

   Wherever possible, enhanced functionality in Ada 9X has been
achieved by seeking and eliminating such unnecessary assumptions,
thereby permitting the generalization of features already in Ada,
and the removal of special cases and restrictions.  A careful
analysis was made of Ada 83, of language study notes prepared during
the original design process and of the many Ada Issues and other
comments that have since been received.  Based on this analysis, and
on the Ada community's experience in implementing and using Ada
during the past ten years, the team identified limitations that,
while they were included to simplify implementations and/or to lower
risk when the language was first standardized, are no longer
necessary.  They also drew upon the wealth of practical experience
gained during the 1980's in the use of object-oriented design
methods, object-oriented programming languages, and real-time
programming made possible by Ada.
   The resulting Ada 9X revision is upwardly compatible for
virtually all existing Ada 83 applications.  Most incompatibilities
are restricted to pathological combinations of features that are
rarely used in practice.  Total upward compatibility would not have
allowed the correction of certain errors and certainly would not
have allowed the enhancements needed to satisfy many of the
requirements.  Indeed, as discussed, in Chapter 4 in more detail, no
language revision has ever achieved total upward compatibility.  The
careful attention to this issue in the design of Ada 9X means that
the expected transition costs for existing Ada programs are
anticipated to be very low indeed.
   Following the guidance of the Requirements document, Ada 9X
comprises a Core language, which must be implemented in its
entirety, plus several Annexes which provide extended features for
specific application areas.  These Annexes provide standard
definitions for application-specific packages, pragmas, attributes,
and capacity and performance characteristics of implementations.
The Annexes address the following areas: Systems Programming, Real-
Time Systems, Distributed Systems, Language Interfaces, Information
Systems, Safety and Security, and Numerics.  It should be noted that
much of the annex functionality is already provided by
implementations of Ada 83 but in non-standard ways; the Annexes will
thus increase portability between implementations.


1.5  Using this Document

This document provides a description of the main features of Ada 9X
and the rationale for the changes from Ada 83.  It follows the
inspiration of the rationale for Ada 83 [IBFW 86] by blending
exposition with explanation.
   Chapter 2 highlights the main changes - primarily the four key
areas outlined in Section 1.3.  The intent is to provide a
technically oriented management overview illustrating, with
examples, the prime benefits of Ada 9X with respect to Ada 83.
   By contrast, Chapter 3 provides an overview of the whole language
in a discursive style and introduces new terminology where
appropriate.  For the most part, this overview is equally applicable
to both Ada 83 and to Ada 9X.  Areas of enhanced functionality in
Ada 9X are indicated thus illustrating where change has occurred.
   Finally, Chapter 4 summarizes the incompatibilities thereby
giving guidance to existing Ada 83 programmers in order to smooth
their transition to Ada 9X.
