Rationale for Ada 2005
1.2 Scope of revision
The changes from Ada
83 to Ada 95 were large. They included several major new items such as
- polymorphism through tagged types,
class-wide types and dispatching,
- the hierarchical library system including
public and private child packages,
- protected objects for better real-time
control,
- more comprehensive predefined library,
especially for character and string handling,
- specialized annexes such as those
for system programming, real-time, and numerics.
By contrast the changes from Ada 95 to Ada 2005 are
relatively modest. Ada 95 was almost a new language which happened to
be compatible with Ada 83. However, a new language always brings surprises
and despite very careful design things do not always turn out quite as
expected when used in earnest.
Indeed, a number of errors in the Ada 95 standard
were corrected in the Corrigendum issued in 2001
[2]
and then incorporated into the Consolidated Ada Reference Manual
[3].
But it was still essentially the same language and further improvement
needed to be done.
Technically, Ada 2005 is defined as an Amendment
to rather than a Revision of the Ada 95 standard and this captures the
flavour of the changes as not being very extensive.
In a sense we can think of Ada 2005 as rounding out
the rough edges in Ada 95 rather than making major leaps forward. This
is perhaps not quite true of the Real-Time Systems annex which includes
much new material of an optional nature. Nevertheless I am sure that
the changes will bring big benefits to users at hopefully not too much
cost to implementors.
The scope of the Amendment was guided by a document
issued by WG9 to the ARG in September 2002
[1].
The key paragraph is:
"The main purpose of the Amendment is to address
identified problems in Ada that are interfering with Ada's usage or adoption,
especially in its major application areas (such as high-reliability,
long-lived real-time and/or embedded applications and very large complex
systems). The resulting changes may range from relatively minor, to more
substantial."
Note that by saying "identified problems"
it implicitly rejects a major redesign such as occurred with Ada 95.
The phrase in parentheses draws attention to the areas where Ada has
a major market presence. Ada has carved an important niche in the safety-critical
areas which almost inevitably are of a real-time and/or embedded nature.
But Ada is also in successful use in very large systems where the inherent
reliability and composition features are extremely valuable. So changes
should aim to help in those areas. And the final sentence is really an
exhortation to steer a middle course between too much change and not
enough.
The document then identifies two specific worthwhile
changes, namely, inclusion of the Ravenscar profile
[4]
(for predictable real-time) and a solution to the problem of mutually
dependent types across two packages (see Section
1.3.3
below).
The ARG is then requested
to pay particular attention to
A
Improvements that will maintain or improve Ada's advantages, especially
in those user domains where safety and criticality are prime concerns.
Within this area it cites as high priority, improvements in the real-time
features and improvements in the high integrity features. Of lesser priority
are features that increase static error checking. Improvements in interfacing
to other languages are also mentioned.
B
Improvements that will remedy shortcomings in Ada. It cites in particular
improvements in OO features, specifically, adding a Java-like interface
feature and improved interfacing to other OO languages.
So the ARG is asked to improve both OO and real-time
with a strong emphasis on real-time and high integrity features. It is
interesting that WG9 rejected the thought that "design by contract"
features should be added to the above general categories on the grounds
that they would not be static.
The ARG is also asked
to consider the following factors in selecting features for inclusion:
- Implementability. Can the feature
be implemented at reasonable cost?
- Need. Do users actually need it? [A
good one!]
- Language stability. Would it appear
disturbing to current users?
- Competition and popularity. Does it
help to improve the perception of Ada and make it more competitive?
- Interoperability. Does it ease problems
of interfacing with other languages and systems? [That's the third mention
of interfacing.]
- Language consistency. Is it syntactically
and semantically consistent with the language's current structure and
design philosophy?
An important further statement is that "In order
to produce a technically superior result, it is permitted to compromise
backwards compatibility when the impact on users is judged to be acceptable."
In other words don't be paranoid about compatibility.
Finally, there is a warning about secondary standards.
Its essence is don't use secondary standards if you can get the material
into the RM itself. And please put the stuff on vectors and matrices
from ISO/IEC 13813
[5] into the language
itself. The reason for this exhortation is that secondary standards have
proved themselves to be almost invisible and hence virtually useless.
The guidelines conclude with the target schedule.
This includes WG9 approval of the scope of the amendment in June 2004
which was achieved and submission to ISO/IEC JTC1 in late 2005.
© 2005, 2006 John Barnes Informatics.
Sponsored in part by:
