Rationale for Ada 2005
1.3 Overview of changes
It would be tedious
to give a section by section review of the changes as seen by the Reference
Manual language lawyer. Instead, the changes will be presented by areas
as seen by the user. There can be considered to be six areas:
1.
Improvements to the OO model. These include a more traditional notation
for invoking an operation of an object without needing to know precisely
where the operation is declared (the Obj.Op(...)
or prefixed style), Java-like multiple inheritance using the concept
of interfaces, the introduction of null procedures as a category of operation
rather like an abstract operation, and the ability to do type extension
at a more nested level than that of the parent type. There are also explicit
features for overcoming nasty bugs that arise from confusion between
overloading and overriding.
2.
More flexible access types. Ada 95 access types have a hair-shirt flavour
compared with other languages because of the general need for explicit
conversions with named access types. This is alleviated by permitting
anonymous access types in more contexts. It is also possible to indicate
whether an access type is an access to a constant and whether a null
value is permitted. Anonymous access-to-subprogram types are also introduced
thus permitting so-called downward closures.
3.
Enhanced structure and visibility control. The most important change
here is the introduction of limited with clauses which allow types in
two packages to refer to each other (the mutual dependence problem referred
to in the WG9 guidelines). This is done by extending the concept of incomplete
types (and introducing tagged incomplete types). There are also private
with clauses just providing access from a private part. And there are
significant changes to limited types to make them more useful; these
include initialization using limited aggregates and composition using
a new form of return statement.
4.
Tasking and real-time improvements. Almost all of the changes are in
the Real-Time Systems annex. They include the introduction of the Ravenscar
profile (as explicitly mentioned in the WG9 guidelines) and a number
of new scheduling and dispatching policies. There are also new predefined
packages for controlling execution time clocks and execution time budgets
and for the notification of task termination and similar matters. A change
related to the OO model is the introduction of protected and task interfaces
thereby drawing the OO and tasking aspects of the language closer together.
5.
Improvements to exceptions, numerics, generics etc. There are some minor
improvements in the exception area, namely, neater ways of testing for
null occurrence and raising an exception with a message. Two small but
vital numeric changes are a Mod attribute
to solve problems of mixing signed and unsigned integers and a fix to
the fixed-fixed multiplication problem (which has kept some users locked
into Ada 83). There are also a number of new pragmas such as: Unsuppress
to complement the Suppress pragma, Assert
which was already offered by most vendors, Preelaborable_Initialization
which works with the existing pragma Preelaborate,
No_Return which indicates that a procedure
never returns normally, and Unchecked_Union
to ease interfacing to unchecked unions in C. There is also the ability
to have more control of partial parameters of generic formal packages
to improve package composition.
6.
Extensions to the standard library. New packages include a comprehensive
Container library, mechanisms for directory operations and access to
environment variables, further operations on times and dates, the vectors
and matrices material from ISO/IEC 13813 (as directed in the WG9 guidelines)
plus commonly required simple linear algebra algorithms. There are also
wide-wide character types and operations for 32-bit characters, the ability
to use more characters in identifiers, and improvements and extensions
to the existing string packages.
Of course, the areas mentioned above interact greatly
and much of 2 and 3 could be classified as improvements to the OO model.
There are also a number of changes not mentioned which will mostly be
of interest to experts in various areas. These cover topics such as streams,
object factory functions, subtle aspects of the overload resolution rules,
and the categorization of packages with pragmas Pure
and Preelaborate.
The reader might feel that the changes are quite
extensive but each has an important role to play in making Ada more useful.
Indeed many other changes were rejected as really unnecessary. These
include old chestnuts such as in out and out parameters
for functions (ugh), extensible enumeration types (a slippery slope),
defaults for all generic parameters (would lead one astray), and user-defined
operator symbols (a nightmare).
Before looking at the six areas in a little more
detail it is perhaps worth saying a few words about compatibility with
Ada 95. The guidelines gave the ARG freedom to be sensible in this area.
Of course, the worst incompatibilities are those where a valid program
in Ada 95 continues to be valid in Ada 2005 but does something different.
It is believed that serious incompatibilities of this nature will never
arise. There are however, a very few minor and benign such incompatibilities
concerning the raising of exceptions such as that with access parameters
discussed in Section
1.3.2.
However, incompatibilities whereby a valid Ada 95
program fails to compile in Ada 2005 are tolerable provided they are
infrequent. A few such incompatibilities are possible. The most obvious
cause is the introduction of three more reserved words:
interface,
overriding, and
synchronized. Thus if an existing Ada 95
program uses any of these as an identifier then it will need modification.
The introduction of a new category of unreserved keywords was considered
for these so that incompatibilities would not arise. However, it was
felt that this was ugly, confusing, and prone to introducing nasty errors.
In any event the identifiers
Overriding and
Synchronized are likely to be rare and although
Interface is clearly a likely identifier nevertheless
to have it both as an identifier and as a keyword in the same program
would be nasty. Note also that the pragma Interface which many compilers
still support from Ada 83 (although not mentioned by Ada 95 at all) is
being put into
Annex
J for obsolescent features.
© 2005, 2006 John Barnes Informatics.
Sponsored in part by:
