Ada 83(ID:2503/ada005)

Renaming of Original Ada 


Related languages
Ada => Ada 83   Renaming
Ada 83 => Ada'   Subset
Ada 83 => Ada 9X   Evolution of
Ada 83 => Ada/Ed   Subset
Ada 83 => Ada++   Extension of
Ada 83 => ADAM   Extension of
Ada 83 => Adaplex   Extension of
Ada 83 => AdLog   Extension of
Ada 83 => ANNA   Extension of
Ada 83 => ASIS   Extension of
Ada 83 => DRAGOON   Extension of
Ada 83 => InnovAda   Extension of
Ada 83 => PAnnDA-S   Influence
Ada 83 => SETL/E   Influence
Ada 83 => SPARK   Subset
Ada 83 => SR   Influence
References:
  • Ichbiah, Jean D.; Barnes, John G.P.; Firth, Robert J.; Woodger, Mike "Ada 83 Rationale" HONEYWELL, Systems and Research Center, Minneapolis, and ALSYS La Celle Saint Cloud, France January 31, 1984 view details Extract: Separate compilation
    Separate compilation of program units is a practical necessity. Its basic goals are to permit the separation of large programs into simpler, more manageable parts, and to create libraries of program units. Separate compilation helps to reduce compilation costs and to simplify the development and management of program corrections and modifications.
    For large projects involving several programmers, separate compilation permits program texts to be separated physically in a way that reflects the division of work and responsibilities. Once the common interface between two parts has been agreed upon and recorded, the two parts can be developed and compiled separately. The fact that the common interface is a physically separate text guarantees that separate recompilation of either part does not invalidate the common interface.

    The physical separation of program texts may be viewed as a support facility for the structured programming concept of refinement. It may also be used to conceal the text of a subprogram body from users who are only allowed to call the subprogram. Such concealment may be justified either for reasons of confidentiality or in order to prevent the user from inferring implicit properties or making assumptions regarding the functioning of the subprogram. Finally this physical separation facilitates the construction of libraries and reusable software components.

    It is appropriate at this stage to introduce the distinction between independent and separate compilation (following J.J. Horning). Independent compilation has been achieved by most assembly languages and also by languages such as Fortran and PL/1. Compilation of individual modules is performed independently in the sense that the modules have no way of sharing knowledge of properties defined in other modules.

    Independent compilation is usually achieved with a lower level of compile-time checking of consistency between units than is possible within a single compilation unit. In consequence, independent compilation came into disrepute and was rejected by safety-minded early typed language definitions such as Algol 68 and Pascal. Fast compilation of the complete program was often advocated by promoters of these languages as a safe alternative to independent compilation. However, fast compilation has its limits, and it fails to answer the needs of confidentiality and libraries.

    Separate compilation, on the other hand, reconciles type-checking safety and the pragmatic reasons for compiling in parts. It is based on the use of a program library which contains a record of previous compilations of the units that form a program. It has been developed in the language Sue and in later languages such as Lis, Jossle, Mesa and later extensions of Pascal and Algol 68. We next discuss its properties in terms of what is provided in Ada.

    When a program unit is submitted to the compiler, the compiler also has access to the program library and is therefore able to perform the same level of checking (in particular type checking) whether a program is compiled in many parts or as a whole. It is the existence of the program library that makes the compilation separate but not independent.

    Using the general information available in the program library, the compiler will be able to assist the user in organizing recompilations. In particular, it will be able to display information about the current state of the compilation of a program that is divided into several compilation units: which separate program units have been compiled, and which need to be recompiled because of prior recompilations.

    It is thus for reasons of safety and utility that Ada offers a powerful facility for separate compilation. Two additional criteria have been followed in this design, namely simplicity of use and simplicity of implementation.

    Separate compilation being a user-oriented facility, it should be simple to understand and use. Consequently it should not introduce other concepts than those required by the nature of separate compilation. Scope rules and the general form of separately compiled program units should be similar to those of other program units.

    In addition, separate compilation should be implementable simply and efficiently. The additional work required for separate compilation should stay within reasonable limits, since one of the goals is to save overall compilation and recompilation time.
  • Baker, Henry G. "Object-Oriented Programming in Ada83 - Genericity Rehabilitated" Nimble Computer Corporation, 1991 view details