Form G104-1092a
9X-GUIDE.HLP

Ada Information Clearinghouse, 1-800-AdaIC-11, 1-703/685-1477

(This has been later published in the November/December 1992 issue of ACM 
SIGAda's Ada Letters.)

                    HOW TO PROGRAM IN Ada 9X, USING Ada 83

                           Erhard Ploedereder, Ph.D.
                                 Tartan, Inc.
                               300 Oxford Drive
                            Monroeville, PA, 15146
                              ploedere@tartan.com

                                   Abstract

Existing software will have to be transitioned from Ada 83 to Ada 9X.  This 
paper explains presently known incompatibilities between the existing Ada 
standard and its proposed revision.  It provides guidelines to users, which 
will make their Ada 83 code upward compatible with Ada 9X.

                                1. Introduction

Ada 9X is approaching rapidly.  Initiation of the formal ANSI and ISO 
standardization processes is expected in late 1993.  Although attracted by the 
added functionality of Ada 9X, many users are concerned about the eventual 
cost of upgrading their Ada applications to the revised standard.  Of 
particular interest are any incompatibilities that might exist between Ada 83 
and Ada 9X.  The detection and analysis of such incompatibilities, and the 
resulting program changes, add risk and cost to the transition to Ada 9X.

Avoiding such incompatibilities has been a central design goal of the Ada 9X 
revision effort.  However, in some cases, they are a necessary consequence of 
changes to the semantics of existing language features, in order to correct 
problems in Ada 83.  In early 1992, the Ada 9X Mapping Team compiled a list of 
incompatibilities [1] for the then existing Mapping Specification [2,3].  
Since that time, refinements of the Mapping Specification have steadily 
reduced the number of incompatibilities.  Still, some incompatibilities will 
remain.

In this article, we provide practical guidelines to Ada 83 programmers, so 
that their Ada 83 code will be upward compatible with the Ada 9X standard.  
The information presented in this paper is based on the current state (July 
'92) of the revision proposal, which is widely regarded as fairly stable.  
Nevertheless, it is work in progress, subject to change and all it implies for 
the accuracy of the presented information.

While it is conceivable that additional incompatibilities will still be 
discovered, it is reassuring to know that, since the time the cited list was 
established, review of the Mapping has not revealed previously unknown 
incompatibilities.  Hence, adherence to the presented guidelines will help 
significantly to reduce the effort of migrating to Ada 9X.

Moreover, we believe that these guidelines do not seriously constrain the use 
of Ada 83; some of them could be regarded as good style guidelines in any 
case.  Even if continued work on Ada 9X eliminates some of the 
incompatibilities, these guidelines will not have a detrimental effect on the 
produced Ada code.

For ease of reference, we first enumerate the guidelines and then explain them 
in more detail.  We do not attempt to provide any comprehensive rationale for 
the underlying language changes; for such information, we refer the reader to 
[1] and its future revisions or replacements.

                        2.  The Guidelines at a Glance

Most of the upward incompatibilities imply that some legal Ada 83 programs are 
no longer legal in Ada 9X.  Any Ada 9X compiler is guaranteed to identify and 
reject all such incompatible situations, safeguarding users against 
unrecognized changes in program behavior.  However, there is also a very small 
number of language changes that alter the meaning of Ada 83 programs while 
retaining their legality when compiled with an Ada 9X compiler.  Unless the 
compiler issues friendly informational messages about such situations, these 
changes could go unnoticed.  They deserve special attention by the users.  
Guidelines 2, 5, 9, and 12 address these particular situations.

The incompatibilities likely to be encountered with some frequency are 
addressed by Guidelines 8, 10, and possibly 1.

For some of the guidelines, we have consciously preferred a simpler, more 
memorable rule to a more precise, but also more complicated one.  Guidelines 3 
and 7 are examples, where a less encompassing rule would also suffice.

The guidelines for Ada 83 programs are:

      1.    Do not use the following Ada 9X keywords as Ada 83 identifiers in 
            your program: aliased, protected, requeue, tagged, until.

      2.    Do not declare the identifiers WIDE_STRING and WIDE_CHARACTER in 
            package specifications.

      3.    Do not apply use-clauses to package SYSTEM.

      4.    Do not declare the identifier APPEND_FILE in a package 
            specification.  Alternatively, do not apply use-clauses to package 
            TEXT_IO and instantiations of SEQUENTIAL_IO.

      5.    For type CHARACTER, be prepared that the enumeration will comprise 
            256, rather than 128, literals.  Similarly, for type FILE_MODE, be 
            prepared for the added literal APPEND_FILE.

      6.    Do not use accuracy constraints in subtype declarations.

      7.    Put representation clauses for real types immediately after the 
            type declaration.

      8.    All library unit packages must have bodies, even if such bodies 
            are empty.

      9.    Do not derive from a type declared in the same package.  Or, if 
            you do, derive the new types before redefining any predefined 
            operations on the parent type.

      10.   Add a distinctive comment to all generic formal private types that 
            can be legally instantiated with unconstrained types.

      11.   Do not assume "too much" about the state of the computation when 
            exceptions are implicitly raised.  Do not cause implicit 
            exceptions knowingly.  Be prepared for the elimination of the 
            exception NUMERIC_ERROR.

      12.   Be prepared for attribute values of real types to more closely 
            reflect the actual hardware.  Be aware that accuracy requirements 
            for operations combining fixed-point types with differently based 
            'SMALL may be lessened.

                         3.  The Guidelines in Detail

Guideline 1:
Do not use the following Ada 9X keywords as Ada 83 identifiers in your 
program: aliased, protected, requeue, tagged, until.

These reserved keywords have been added to Ada 9X.  Clearly, programs 
containing such identifiers will be rejected as syntactically illegal by any 
Ada 9X compiler.  See declaration (1) in Figure 1 for an example.

For existing programs, editor scripts can be easily written to check for the 
absence of such identifiers.  If they are present, consistent replacement with 
a different identifier makes the code upward compatible.  Note, however, that 
the choice of a replacement identifier must not coincide with another name 
already visible in any of the contexts, in which the conflicting identifier 
occurs.  A cross-reference listing of the program may greatly assist in 
finding unique replacement identifiers.

------------------------------------------------------------------------------
|                                                                            |
|                                                                            |
|    package PKG is                                                          |
|        type WIDE_STRING is ....;                                           |
|        APPEND_FILE: INTEGER;                                               |
|    end PKG;                                                                |
|                                                                            |
|    with PKG; use PKG;                                                      |
|    with TEXT_IO; use TEXT_IO;                                              |
|    package NAME_CONFLICTS is                                               |
|                                                                            |
|        PROTECTED: BOOLEAN := true;  -- (1)  -- illegal in Ada 9X           |
|                                             -- 'protected' is now a keyword|
|                                                                            |
|        STR: WIDE_STRING;  -- (2) -- in Ada 83, denotes PKG.WIDE_STRING     |
|                                  -- in Ada 9X, denotes STANDARD.WIDE_STRING|
|                                                                            |
|        X: INTEGER := APPEND_FILE;  -- (3)                                  |
|                   -- illegal in Ada 9X. Due to new presence                |
|                   -- of name APPEND_FILE in TEXT_IO, the                   |
|                   -- name is no longer directly visible                    |
|                                                                            |
|                                                                            |
|    end NAME_CONFLICTS;                                                     |
|                                                                            |
|                                                                            |
|   Figure 1:  Incompatibilities Caused by New Predefined Names and Keywords |
|                                                                            |
------------------------------------------------------------------------------

Guideline 2:
Do not declare the identifiers WIDE_STRING and WIDE_CHARACTER in package 
specifications.

These identifiers have been added to package STANDARD of Ada 9X.  As a 
consequence, user-defined names with the same identifier, when made directly 
visible via use-clauses, will no longer denote the imported definitions but 
those in package STANDARD.  The rules of Ada give precedence to directly 
visible names over names made directly visible by use-clauses.  Theoretically, 
the program will still be legal, but behave differently in execution.  In 
practice, however, it is likely that program illegalities will occur as a 
consequence of the altered binding.  See declaration (2) in Figure 1 for an 
example.

For existing programs, the analysis and correction described for guideline 1 
applies.

A secondary consequence of the appearance of the new types WIDE_CHARACTER and 
WIDE_STRING for the support of international character sets is that operations 
involving only character or string literals may become ambiguous, since the 
operation could be for either the Ada 83 types or the new Ada 9X types.  For 
example, the equalities in

            if 'a' = 'b' then ...
            if "abc" = "def" then ...

are now ambiguous.  The same applies, if the operands are overloaded function 
calls that cannot be disambiguated by their parameters.  Given that no 
competent programmer would compare two string or character literals, this 
situation is not worth a guideline.  However, preprocessors might generate 
such code.  The solution is to type-qualify one of the arguments of the 
expression.  The appearance of a variable anywhere in the expression avoids 
the ambiguity.

Guideline 3:
Do not apply use-clauses to package SYSTEM.

This is generally a good Ada 83 guideline, since implementors are free to add 
additional declarations to package SYSTEM.  Consequently, a new release of a 
compiler may declare new names in the package, causing visibility conflicts or 
ambiguities in code that already makes equally named declarations from other 
packages directly visible via use-clauses.  Ada 9X adds additional predefined 
names in package SYSTEM and, hence, can cause this problem.  Unlike the 
situation discussed in Guideline 2, encountering this incompatibility will 
make the Ada 83 program illegal in Ada 9X, since the Ada visibility rules will 
then make the conflicting, non-overloadable declarations from neither package 
directly visible.  See Guideline 4 for an analogous problem and example.

Guideline 4:
Do not declare the identifier APPEND_FILE in a package specification.  
Alternatively, do not apply use-clauses to package TEXT_IO and instantiations 
of SEQUENTIAL_IO.

Ada 9X adds the enumeration literal APPEND_FILE to the FILE_MODE type in these 
packages.  As an additional name in a predefined package, this can create the 
problems already described under Guideline 3.  See declaration (3) in Figure 1 
for an example.

For existing code, the remedies given under Guideline 1 apply.

Guideline 5:
For type CHARACTER, be prepared that the enumeration will comprise 256, rather 
than 128, literals.  Similarly, for type FILE_MODE, be prepared for the added 
literal APPEND_FILE.

------------------------------------------------------------------------------
|                                                                            |
|                                                                            |
|   if ASCII.DEL = CHARACTER'LAST then               -- (1)                  |
|                -- always true in Ada 83 (until recently -- see explanation)|
|                -- always false in Ada 9X                                   |
|                                                                            |
|   case CHAR is                                     -- (2)                  |
|                -- illegal in Ada 9X, since not all choices are covered     |
|      when CHARACTER'VAL(0) .. CHARACTER'VAL(63) => ...;                    |
|      when CHARACTER'VAL(64) .. CHARACTER'VAL(127) => ...;                  |
|   end case;                                                                |
|                                                                            |
|   subtype ASCII_CHARACTER is CHARACTER                                     |
|           range ASCII.NUL ... ASCII.DEL;           -- (3)                  |
|                                                                            |
|   case ASCII_CHARACTER'(CHAR) is                   -- (4)                  |
|                -- legal in both Ada 83 and Ada 9X                          |
|      when CHARACTER'VAL(0) .. CHARACTER'VAL(63) => ...;                    |
|      when CHARACTER'VAL(64) .. CHARACTER'VAL(127) => ...;                  |
|   end case;                                                                |
|                                                                            |
|   case CHAR is                                     -- (5)                  |
|                -- legal in both Ada 83 and Ada 9X                          |
|      when CHARACTER'VAL(0) .. CHARACTER'VAL(63) => ...;                    |
|      when CHARACTER'VAL(64) .. CHARACTER'VAL(127) => ...;                  |
|      when others => ... ;  -- Ada 9X alternative                           |
|   end case;                                                                |
|                                                                            |
|   type GOOD_CHAR_TABLE is array(CHARACTER) of INTEGER;                     |
|   type BAD_CHAR_TABLE is array(0..127) of INTEGER;                         |
|   GOOD_TT: GOOD_CHAR_TABLE;                                                |
|   BAD_TT: BAD_CHAR_TABLE;                                                  |
|                                                                            |
|   for CHR in GOOD_TT'RANGE loop                                            |
|       GOOD_TT(CHR) := ....;                        -- (6)                  |
|   end loop;                                                                |
|                                                                            |
|   for CHR in CHARACTER'FIRST .. CHARACTER'LAST loop                        |
|       BAD_TT(CHARACTER'POS(CHR)) := ....;          -- (7)                  |
|   end loop;                                                                |
|                                                                            |
|                                                                            |
|           Figure 2:  Examples of Character Set (In)compatibilities         |
|                                                                            |
------------------------------------------------------------------------------

These changes have two major consequences:

      -     The 'LAST attribute applied to type CHARACTER (or any of its 
            derived types) will yield a value with an encoding of 255 rather 
            than 127.  See the example (1) in Figure 2.  Similarly, 
            FILE_MODE'LAST will now yield APPEND_FILE.  Whether this impacts 
            an algorithm, depends entirely on the programmer's assumptions.  
            If the assumption was to obtain truly the last character in the 
            enumeration, regardless of its encoding, the code will still 
            operate as intended.  If the specific value is important, the 
            explicit literal (or a declared constant) should be used in lieu 
            of the attribute.  An analogous reasoning applies to the 'RANGE 
            attribute applied to arrays with such index types or to any 
            implicit assumptions about the magnitude of the enumeration.  
            Examples (6) and (7) in Figure 2 show how Ada 83 code will (not) 
            be upward compatible.  The loop (7) will result in a 
            CONSTRAINT_ERROR in Ada 9X, besides being poor style in Ada 83.

      -     Case statements over expressions of such types need to account for 
            the possible choices added by Ada 9X.  Otherwise the statements 
            will be illegal in Ada 9X.  Since a superfluous others or an empty 
            range choice is legal in Ada, case statements, whose choices do 
            not already cover all values permitted by Ada 9X should be written 
            with such an added choice.  Alternatively, one can also qualify 
            the case expression with a static subtype, reflecting the Ada 83 
            range of types CHARACTER and FILE_MODE, respectively.  Examples 
            (2) through (5) in Figure 2 illustrate the situation.  The choice 
            of solution will depend on the circumstances.  If the algorithm is 
            guaranteed to be applied only to the first 128 characters, 
            qualified expressions should be used, as shown by example (4).  
            Otherwise, the modification of example (5) should be applied after 
            giving thought to programming the Ada 9X branch of the case 
            statement.  An addition of the form

                        when others => null;

            is almost certainly the wrong solution.

ISO/IEC JTC1/SC22 WG9, the group chartered to issue interpretations of the 
existing Ada standard, has recently voted to permit this definitional change 
of type CHARACTER in Ada 83 implementations.  Consequently, this problem could 
already arise with the next release of an Ada 83 compiler, rather than with an 
Ada 9X compiler, when the change becomes mandatory.

For existing programs, the necessary changes are somewhat problematic, since 
they are not easily found by syntactic searches, nor is it easy to determine 
whether or not the intent of the algorithms is affected by the language 
change.

Fortunately, for the large class of programs that are intended and guaranteed 
to deal only with the ASCII character set even after Ada 9X has been adopted, 
there is a very simple guideline that prevents the incompatibility.  Rather 
than using the type CHARACTER, such programs should define a subtype of 
CHARACTER, as shown in example (3) of figure 2, and consistently use this 
subtype in lieu of type CHARACTER.  In Ada 83, this subtype encompasses all 
values of type CHARACTER; in Ada 9X, it will ensure the constraint to the 
ASCII characters.  None of the above compatibility problems arise.  Similarly, 
for existing such programs, a global substitution of CHARACTER by the subtype 
name and the addition of suitable context-clauses to make the subtype name 
visible renders the programs upward compatible with Ada 9X.

For type FILE_MODE, an analogous approach is complicated by the fact that 
multiple instantiations of SEQUENTIAL_IO yield different such types.  It is 
probably easier to correct the few places in the code, where the expansion of 
the enumeration type makes any difference.

Guideline 6:
Do not use accuracy constraints in subtype declarations.

Accuracy constraints in subtype declarations will be removed from the 
language.  It is surmised that all existing Ada implementations simply ignore 
such subtype constraints, computing and storing results in the accuracy of the 
respective type, anyhow.

In existing programs, such accuracy constraints should be removed.  They can 
be found via editor scripts or syntactic searches.  In an example adapted from 
the Ada Reference Manual [4],

            type VOLT is delta 0.125 range 0.0 .. 255.0;
            subtype ROUGH_VOLTAGE is VOLT delta 1.0 range 0.0 .. 100.0;

should be replaced with

            type VOLT is delta 0.125 range 0.0 .. 255.0;
            subtype ROUGH_VOLTAGE is VOLT range 0.0 .. 100.0;

Guideline 7:
Put representation clauses for real types immediately after the type 
declaration.

Ada 9X solves an obscure problem in Ada 83 by mandating that such 
representation clauses be given before any subtypes or derived types of the 
given type are declared.

In existing programs, once the situation is identified, the correction is very 
simple: merely move the representation clause to precede the subtype or 
derived type declarations.

Guideline 8:
All library unit packages must have bodies, even if such bodies are empty.

Ada 83 allows the omission of packages bodies if none is needed to complete 
the specification.  A usage problem results, since library unit bodies that 
are semantically optional, but vital to the functioning of the program, are 
omitted from executables, when they happen to be obsolete.  Ada 9X mandates 
the existence of previously optional bodies for library units to eliminate 
this usage problem.  Users should therefore add such empty bodies, e.g.,

            package body <name> is end <name>;

in the source files after the package specification.

For existing programs, simple Ada library queries provide the necessary 
information to produce these bodies.

Guideline 9:
Do not derive from a type declared in the same package.  Or, if you do, derive 
the new types before redefining any predefined operations on the parent type.

------------------------------------------------------------------------------
|                                                                            |
|                                                                            |
|    package DERIVATIONS is                                                  |
|                                                                            |
|        type BYTE is array (0..7) of BOOLEAN;                               |
|        function "and"(L,R: BYTE) return BYTE;                              |
|              -- redefine "and" for whatever reason                         |
|                                                                            |
|        type CHAR is new BYTE;                                              |
|              -- in Ada 83, this type inherits the predefined "and"         |
|              -- in Ada 9X, this type inherits the redefined "and" of Byte  |
|                                                                            |
|    end DERIVATIONS;                                                        |
|                                                                            |
|                                                                            |
|            Figure 3:  Inheritance of Operations for Derived Types          |
|                                                                            |
|                                                                            |
------------------------------------------------------------------------------

In Ada 83, subprograms become derivable only at the end of the visible part of 
the package in which the type is declared.  In Ada 9X, they are immediately 
derivable.  As shown in Figure 3, a sequence of declarations, interspersing 
redefinitions of pre-defined operations with derived type declarations yields 
different definitions of these operations for the derived type.  The guideline 
avoids this situation, which has surprised many first-time Ada users.  (Note 
that deriving from a derived type in the same package is already illegal in 
Ada 83.  The situation therefore arises only if the parent type is declared by 
means of a type definition.)

In existing programs, these situations can best be identified by searching for 
redefinitions of pre-defined operations, which should be relatively rare, and 
inspecting the context of these redefinitions for subsequent derived type 
declarations.  If such situations are found, a simple reordering of the 
declarations makes the programs upward compatible.

Guideline 10:
Add a distinctive comment to all generic formal private types that can be 
legally instantiated with unconstrained types.

In Ada 83, the instantiation of a generic with an unconstrained type can be 
illegal, depending on the use of the type in the generic unit, e.g., in an 
object declaration.  In Ada 9X, this instantiation will always be illegal, 
unless the formal type is identified as one that can be instantiated with an 
unconstrained type (in which case, the instantiation will always be legal, and 
the generic must not contain conflicting uses of the type).  Ada 9X uses the 
box notation for this purpose.  See Figure 4 for an example.  The legality of 
the instantiation (1) will depend on the use of type X in the body of 
'Ada_83'.

This is the single instance, where Ada 83 code cannot be written to be upward 
compatible with Ada 9X.  Consequently, we recommend the use of a distinctive 
comment convention, as shown at the beginning of the example, so that, upon 
transition to Ada 9X, the necessary source changes are easily located and 
made.

------------------------------------------------------------------------------
|                                                                            |
|                                                                            |
|    generic                                                                 |
|       type X is private;        --Ada 9X: add (<>)                         |
|    procedure Ada_83;                                                       |
|                                                                            |
|    type SHORT_STRING is new STRING(1..8);                                  |
|                                                                            |
|    procedure GOOD_ONE is new Ada_83(SHORT_STRING);                         |
|                                                                            |
|    procedure DUBIOUS_ONE is new Ada_83(STRING);                            |
|           -- may be illegal in Ada 83, depending on generic body in Ada_83 |
|           -- will always be illegal in Ada 9X                              |
|                                                                            |
|    generic                                                                 |
|       type X(<>) is private;         -- Ada 9X notation; illegal in Ada 83 |
|    procedure Ada_9X;                                                       |
|                                                                            |
|    procedure BETTER_ONE is new Ada_9X(STRING);        -- always legal      |
|                                                                            |
|                                                                            |
|              Figure 4:  Instantiations with Unconstrained Types            |
|                                                                            |
|                                                                            |
------------------------------------------------------------------------------

For existing programs, there is a mechanical method of establishing whether or 
not such a comment should be added: Identify all generic units with formal 
private types and instantiate them with unconstrained types.  All such 
instantiations not rejected by the Ada 83 compilation system (possibly at link 
time) are candidates to be commented as indicated.

Guideline 11:
Do not assume "too much" about the state of the computation when exceptions 
are implicitly raised.  Do not cause implicit exceptions knowingly.  Be 
prepared for the elimination of the exception NUMERIC_ERROR.

Software engineers generally agree that knowingly utilizing implicitly raised 
exceptions as a control flow mechanism is a highly dubious practice.  The 
interpretation of Ada 83 regarding the execution order in the presence of 
implicitly raised exceptions is far from clear.  Efficient support of RISC, 
pipe-lined, super-scalar, and massively parallel architectures makes it 
necessary to deviate from a purely sequential execution model.  Ada 9X is 
likely to better codify permission for such support by compilers.

Consequently, users should not rely in their algorithms on the specific point 
in the sequential execution order where an implicit exception may get raised.  
A good, although over-conservative, guideline is to assume that, in any 
exception frame, the raising of implicit exceptions may occur as early as the 
beginning of the frame or as late as the end of the frame, regardless of where 
the exception occurs in the sequential execution order.

This guideline applies already to Ada 83 code, regardless of Ada 9X.  Yet, it 
will avoid additional surprises when upgrading the code to Ada 9X.

In some situations, where Ada 83 mandates the raising of CONSTRAINT_ERROR, the 
semantics of Ada 9X will cause the "expected" result, rather than an 
exception.  Since all these (three) cases are at the fringes of the language 
usage, and since programmers should not cause CONSTRAINT_ERROR intentionally, 
they are not worth a guideline.

Ada 9X is very likely to eliminate the exception NUMERIC_ERROR from the 
language definition.  An official Ada 83 interpretation advises non-bindingly 
that Ada 83 implementations should use CONSTRAINT_ERROR instead of 
NUMERIC_ERROR.  Users whose compilers already adhere to this interpretation, 
should cease to reference NUMERIC_ERROR.  In existing programs, the name 
should be deleted from exception choices or replaced by CONSTRAINT_ERROR, as 
appropriate.  For users, whose Ada 83 compilers do not adhere to this 
non-binding interpretation, the situation is more difficult.  It would be best 
to apply the above source modification at the time of transition to Ada 9X.  
(There is an upward compatible alternative described in [1], involving the 
introduction of a superfluous user-defined NUMERIC_ERROR exception in a 
separate package to be imported into all contexts that reference 
NUMERIC_ERROR.  However, we hesitate to recommend this approach, since it 
certainly is confusing to the reader of the program.)

Guideline 12 (Numerics):
Be prepared for attribute values of real types to more closely reflect the 
actual type representation.  Be aware that accuracy requirements for 
operations combining fixed-point types with differently based 'SMALL may be 
lessened.

For the casual user of real types, these language changes are most unlikely to 
have any impact.  In particular, users of the predefined floating-point types 
should have no problems in upgrading to Ada 9X.  For numeric applications that 
parameterize algorithms by means of real type attributes, however, the changes 
to attribute values may have some effect, albeit a positive one, since such 
applications are presumably interested in more accurate attribute values.  
(For example, it is proposed that the attribute 'SMALL return the actual 
smallest representation increment, rather than the increment between model 
numbers.)  Such code is typically written by numerical analysts, who as a 
group have requested these changes to be made to Ada 83.  The reduced accuracy 
requirements for operations combining fixed-point types with differently based 
scales is unlikely to have any significant impact, because such operations are 
exceedingly rare.  Also, many Ada 83 compilers support only binary and decimal 
'SMALLs, thereby making it rather unlikely that existing code applies such 
operations and rely on the accuracy required in Ada 83.

                                  4.  Summary

Most of the incompatibilities and guidelines arise from language changes 
proposed to correct Ada 83 problems.  Some of the incompatibilities are so 
specialized that the probability of encountering them is minimal.  To many 
users, the primary practical incompatibility will be the mandatory presence of 
library unit bodies.

The given guidelines address virtually all of the known incompatibilities, 
thus providing for Ada 9X compatible Ada 83 code.  Only the incompatibility 
discussed by Guideline 10 (generics instantiated with unconstrained types) 
and, depending on the Ada 83 compiler implementation, the disappearance of the 
exception NUMERIC_ERROR cannot be addressed in today's Ada 83 code.

For most incompatibilities, locating their occurrence can be largely automated 
and the corrections needed are straightforward.  Only the incompatibility 
avoided by Guideline 5 does not fit this description; yet it is a necessary 
consequence of allowing for 8-bit character representations and the capability 
to append to files.  Still, there is a simple guideline to ensure 
compatibility for all those programs that will be exposed only to ASCII 
character input.

Finally we advice that users intending to upgrade to Ada 9X should obtain 
early releases of Ada 9X compilers (e.g., the freely available GNU-Ada 
implementation, to be released in late 1993) to check their Ada 83 code for 
upward compatibility problems.

                               Acknowledgements

The incompatibilities addressed by the presented guidelines were originally 
identified and documented by the Ada 9X Mapping Team at Intermetrics.  Many of 
the guidelines are but an update and repackaging of information contained in 
the original publication [1].  I appreciate the comments from several 
reviewers of an earlier draft of this paper, in particular Bryce Bardin, Bob 
Duff, Art Evans, and Philippe Kruchten, who helped to improve the guidelines 
and the presentation.

                                 Bibliography

[1] Ada 9X Mapping Document, Volume I, Mapping Rationale, Version 4.1., Office 
of the Under Secretary of Defense for Acquisition, US Department of Defense, 
March 1992.

[2] Ada 9X Mapping Document, Volume II, Mapping Specification, Version 4.0., 
Office of the Under Secretary of Defense for Acquisition, US Department of 
Defense, December 1991.

[3] Ada 9X Mapping Document, Volume II, Mapping Specification, Annexes, 
Version 4.0., Office of the Under Secretary of Defense for Acquisition, US 
Department of Defense, March 1992.

[4] Reference Manual for the Ada Programming Language, 
ANSI/MIL-STD-1815A-1983, US Department of Defense, February 17, 1983.

                            **********************

                          Reprinted with permission.

                     Ada Information Clearinghouse (AdaIC)
                                P.O. Box 46593
                          Washington, DC  20050-6593
                 703/685-1477, 800/AdaIC-11, FAX 703/685-7019
                adainfo@ajpo.sei.cmu.edu; CompuServe 70312,3303

The AdaIC is sponsored by the Ada Joint Program Office and operated by IIT 
Research Institute.




