US DoD general purpose language 

(named for Ada Lovelace (1811-1852), arguably the world's first computer programmer.)
Jean Ichbiah's team at CII Honeywell, for the U.S. Department of Defense, 1979.
Ada is a large, complex block-structured language aimed primarily at embedded computer applications. It has facilities for real-time response, concurrency, hardware access, and reliable run-time error handling. In support of large-scale software engineering, it emphasizes strong typing, data abstraction and encapsulation. The type system uses name equivalence and includes both subtypes and derived types. Both fixed and floating point numerical types are supported. Control flow is fully bracketed: if-then-elsif-end if, case-is-when-end case, loop-exit-end loop, goto. Subprogram parameters are in, out, or inout. Variables imported from other packages may be hidden or directly visible. Operators may be overloaded, and so may enumeration literals. There are user-defined exceptions and exception handlers.
An Ada program consists of a set of packages encapsulating data objects and their related operations. A package has a separately compilable body and interface. Ada permits generic packages and subroutines, possibly parametrized. Ada programming places a heavy emphasis on multitasking. Tasks are synchronized by the rendezvous, in which a task waits for one of its subroutines to be executed by another. The conditional entry makes it possible for a task to test whether an entry is ready. The selective wait waits for either of two entries or waits for a limited time.

Related languages
DoD-1 => Ada   Renaming
LIS => Ada   Evolution of
Ada => 2-step   Target language for
Ada => ABSDL   Implementation
Ada => Ada 83   Renaming
Ada => Ada with maps   Extension to
Ada => ADA/TL   Extension of
Ada => Ada1   Subset
Ada => ADADL   Adaptation of
Ada => Ada-O   Subset
Ada => AdaTran   Subset
Ada => AIDA   Implementation
Ada => ALSP   Extension of
Ada => APPL/A   Extension of
Ada => AVA   Formally defined Subset
Ada => Charrette Ada   Implementation
Ada => DAda   Extension of
Ada => ForceOne   Targetting
Ada => LIL   Interface for
Ada => Pascal*   Influence
Ada => PLEASE   Extension of
Ada => Ruby   Influence
Ada => TSL   Extension of
Ada => VHDL   Adaptation of

  • Ichbiah, Jean D., et al. "Rationale for the Design of the Ada Programming Language - A Language Designed in Accordance with the Steelman Requirements" view details Abstract: This document, the Rationale for the Design of the Ada Programming Language, is a companion to the Ada Reference Manual; as a set, they are the defining documents for the Green language. The Rationale is meant to provide, for the Reference Manual, an infusion of motivational information, information describing the reasons behind major design decisions and an insertion of larger examples that are essential to understanding the language and for the interaction among its features. Most chapters of the Rationale correspond to chapters of the Reference Manual, with a few exceptions. Most chapters also have a common structure: an introduction to the topic, followed by an introduction to the language feature in terms of examples, and then a discussion of the technical issues such as major design decisions, their justification, and the interactions with other aspects of the language.

          in SIGPLAN Notices 14(06) June 1979 view details
  • J.D. Ichbiah, J.C. Heliard, O. Roubine, J.G.P. Barnes, B. Krieg-Brueckner, B.A. Wichmann, "Reference manual for the Ada programming language" view details
          in SIGPLAN Notices 14(06) June 1979 view details
  • "Reference Manual for the Ada Programming Language - Proposed Standard Document", U.S. Department of Defense, July 1980. view details
          in SIGPLAN Notices 14(06) June 1979 view details
  • Berning, Paul T. "Formal SEMANOL Specification of Ada" TRW Report RADC-TR-89-293 Rome Air Development Center 9/80 view details Abstract: This report summarizes the performance and results of a contractual effort to develop a formal operational specification of the DoD programming language Ada. The formalism used was that of the Semantics Oriented Language, SEMANOL. The design produced essentially covers the entire Ada language, ignoring only the low-level semantics of implementation dependencies.
          in SIGPLAN Notices 14(06) June 1979 view details
  • Bishop, J. M. "Effective machine descriptors for Ada." view details
          in SIGPLAN Notices 15(11) November 1980 view details
  • Fritz, R. E. review of ADA Rationale view details Abstract: When a new language arises from the academic ranks it is usually accompanied by a paper or flurry of papers which describe in quite formal and abstract terms what a marvelous breakthrough the language is and how the brilliant new feature should be used. The ADA Rationale is not one of these; it is a unique blend of language tutorial, informal justification, and ruminations on language design. The authors, who are the design team for ADA, have provided students of language design and of ADA an opportunity to See what the design was supposed to do, why the language was designed so, and how to use the language as it was intended to be used.

    The organization of the Rationale parallels that of the Reference Manual; each chapter has an introduction to the topic, followed by an informal explanation using examples of the features used to implement the topic. As an adjunct to the Reference Manual it is invaluable, but it is also interesting to compiler writers for its insights on implementation considerations. As one might expect, the most significant feature of ADA, tasking, is treated with the most lengthy discussion. ADA tasks are structurally similar to ADA packages, which are units of related data and procedures, but tasks are used for parallel processing applications. Because of the critical nature of parallel processing to the embedded software systems for which ADA is designed, careful and complete understanding of tasking and of the approach taken by the designers is necessary. During the test and evaluation phase for ADA, the tasking feature received the most attention, and the interested reader is referred to the ADA Language Issue Reports for details. Detailed treatment is given for the use of the rendezvous for intertask communication, the interrupt structure, scheduling, and task activation, all of which drew comment during the test and evaluation phase.

    The ADA Rationale will become somewhat obsolescent with the expected revisions in the language, but will not lose any of its importance as a chronicle of the design decisions made in the ADA project. As a tool for learning the language it is as least as important as the Reference Manual and twice as long.

          in ACM Computing Reviews 21(06) June 1980 view details
  • Fritz, R. E. review of Preliminary ADA reference manual view details Abstract: The Department of Defense has developed a high-order language for embedded computer systems (avionics, missile guidance, for example), in cooperation with the academic, industrial, and government communities in the US and in the NATO countries. The language design resulting from the competition in many respects represents state-of-the-art technology for high-order procedural languages. Though there is very little in ADA which had not been tried before in other languages, the integration of these features into the system of the language is unique, and some think the breakthrough to the next generation of high-level procedural languages. Some of the more interesting features include strong typing and runtime type checking, a rigid formulation of visibility rules, a language construct for parallel processing, separate procedure headers and procedure bodies, and strong emphasis on separate compilation. ADA is closely related to PASCAL in structure and appearance, and is designed to be machine-independent and portable.

    Since the selection of the design by Cii Honeywell-Bull of Paris in mid-1979, the language has undergone an intensive review, revision, and education process, both in the defense industry and in the US and European academic and government communities. Criticisms and suggestions for improvement have been accepted from all sources, with language revision to continue until the design is frozen in mid-1980. The criticisms and suggestions number in the hundreds, and are available on MULTICS as ADA Language Issue Reports (ada-lir). Few major changes are expected in this, and the general tone has been one of acceptance and acclaim. Compiler contracts have already been let, and the first compilers are expected by late 1981 projects using ADA by 1983 or 1984, and ADA dominance of embedded software by 1990.

    As a reference manual, the present volume is informal tutorial, and occasionally spotty. For a book of this type, it is extremely readable and worth reading. In many areas, complete description of the feature is given and several examples of its use are offered, but in some cases, particularly where the effect of the procedure is implementation-dependent, the description is short and ambiguous, with no examples. Several of the individuals involved in the ADA Test and Evaluation have enumerated the shortcomings of the manual in Language Issue Reports, and the serious reader is invited to review these. However, the Preliminary ADA Reference Manual is what it should be at this stage of development of the language, informal, descriptive, tutorial; a volume which gives the reader an intuition for the approach and intent of the language design, rather than a listing of syntax and compiler error messages which would be more useful when the language is more widely used. Study of ADA should not be limited to those with an academic interest in languages, since if ADA achieves the success of the last DoD language effort COBOL, it will be a powerful and widespread influence on the next generation of languages and programmers.

          in ACM Computing Reviews 21(06) June 1980 view details
  • Groves, L. J. and W. J. Rogers . "The design of a virtual machine for Ada." view details
          in SIGPLAN Notices 15(11) November 1980 view details
  • William E. Carlson , Larry E. Druffel , David A. Fisher , William A. Whitaker "Introducing Ada" view details Abstract: The Ada programming language was finalized in July 1980 with the publication of the proposed standard Ada Language Reference Manual [A1]. That standard document is being reviewed for clarity and internal consistency under American National Standards Institute (ANSI) canvas procedures in preparation for the issuance of an ANSI Standard for Ada. Ada is also on the agenda of the International Standards Organization (ISO). The United States Department of Defense (DoD) has sponsored the development of Ada to provide a standard machine independent high order language (HOL) for software which is embedded in or procured as part of major defense systems. Examples of the intended applications include communications, avionics, air traffic control, missile guidance, and battlefield or shipboard decision support. Computers are usually dedicated to these applications. Frequently, they must operate in unfriendly environments, and are specially hardened to withstand shocks, vibrations, temperature fluctuations and other environmental stresses. DoD's annual investment for software to run on these embedded computers far exceeds that for data processing applications such as payroll, inventory and financial management [C3].
          in Proceedings of the ACM 1980 annual conference January view details
  • Davis, John S. "Ada -- A Suitable Replacement for Cobol?" US Army Institute for Research in Management Feb 1981 view details Abstract: The new Department of Defense standard programming language for embedded computer systems, Ada, is evaluated as a replacement for COBOL. Ada appears superior to COBOL in facilitating good software development and maintenance practices. Yet Ada is more difficult to learn and does not provide as many convenient built-in features for data formatting and input/output. Adopting Ada may reduce total life cycle cost, but in this document converting from COBOL to Ada is not recommended for the near future.

          in Proceedings of the ACM 1980 annual conference January view details
  • Morris, A. H. Jr. "Can Ada replace FORTRAN for numerical computation?" view details
          in SIGPLAN Notices 16(12) December 1981 view details
  • Waugh, D.W. "PDL/Ada - PDL Equivalencies: A Side-By-Side Comparison of PDL/Ada and PDL" IBM Tech Report 1981 view details Abstract: The purpose of this document is to present the PDL/Ada equivalents for the various PDL constructs. The presentation is in the form of a side-by-side comparison of features in the two languages and assumes a prior knowledge of PDL.. In all cases, the major criterion has been to make PDL/Ada conform to Ada so that design syntax can be checked by a standard Ada translator.
          in SIGPLAN Notices 16(12) December 1981 view details
  • Spector, David "Ambiguities and insecurities in Modula-2" pp43-51 view details Extract: Introduction
    While it is not yet clear whether Ada, BLISS, Mary/2, Modula-2, Mesa, C, CLU, Edison, Concurrent Euclid, Icon, Newton, PLAIN, PLUS, Praxis, Smalltalk, SQURL, Y, or some other language is "best" for systems programming, each language represents an advance towards the goal of supporting an understandable and efficient organization of the many details and relationships inherent in systems programming.
    Unfortunately, no one language has yet achieved the delicate balance between simplicity and power that would distinguish it as ideal, but it appears that Modula-2 comes quite close. Modula-2 represents a step forward in language design, both because it incorporates existing features instead of inventing its own, and because of its evident concern for simplicity.
    Modula-2 offers the following valuable language features:
    Few primitive datatypes are defined, few control constructs are supported (there is no "go to"), and input-output operations are not provided as part of the language (they can be provided via extensions written in Modula-2). This simplicity allows for easier standardization and better portability than can be achieved with most other languages.
    A module is a named collection of variables and procedures, similar to an Ada package. It controls the interfacing and encapsulation of the conceptual parts making up large software systems. Modules provide a more flexible solution to the problem of partitioning the name space of a large program than does the more familiar hierarchical nesting of procedures. They are so valuable they are even being force-fitted onto existing languages.
    Separate Compilation.
    Modules may be compiled separately, providing good management for large programsr and definition modules allow for specifying interfaces without giving implementation details.
    Flexible Datatypes.
    Strong datatypes are enforced, but this can be relaxed when necessary in systems programming to just declaring a parameter to be a word, an address, or an array of words.
    Machine Access.
    Access to specific memory addresses and other characteristics of the underlying machine is supported.
    Flexible and efficient tasking is provided by coroutine management routines.
          in SIGPLAN Notices 17(08) August 1982 view details
  • Wichmann, BA "A comparison of Pascal and Ada" pp248-252 view details Abstract:
    This paper compares the two programming languages, Pascal and Ada. While Ada is based upon Pascal, its design objectives are very different. Pascal was designed for teaching whereas Ada was designed for major military software systems. The simplicity of Pascal is advantageous only if it restrictions does not jeopardize the programming of an application. The improved modularity of Ada, as provided by packages, should be an important aspect for commercial development.
          in The Computer Journal 25(2) May 1982 view details
  • "Reference Manual for the Ada Programming Language", ANSI/MIL STD 1815A, U.S. DoD (Jan 1983). view details
          in The Computer Journal 25(2) May 1982 view details
  • R.P. Cook and T.J. LeBlanc "A Symbol Table Abstraction to Implement Languages with Explicit Scope Control" from IEEE Transactions on Software Engineering, January 1983 view details
          in The Computer Journal 25(2) May 1982 view details
  • daCosta, Robert "The History of Ada" Airforce Reference Number: H03-0285 1984 view details Abstract: This article briefly describes the first 10 years of effort to achieve a common higher-order language. The article starts with the conception of the idea in 1974, describes various personnel involved, discusses the various stages of Design and Requirements criteria. Mention is made of the Cornell workshop (1976), the DoD design competition (1979), and the conception of the AJPO. The article concludes with the mention of the Ada Compiler Validation Capability (ACVC) tests and a discussion of Ada for supercomputers.

          in The Computer Journal 25(2) May 1982 view details
  • Dencker, Peter; Dürre, Karl; Heuft, Johannes "Optimization of parser tables for portable compilers" pp546-572 view details
          in TOPLAS 6(4) October 1984 Lecture Notes in computer science Vol. 174 view details
  • Bielak, R. "Ada vs. Modula-2: a view from the trenches." view details
          in SIGPLAN Notices 20(12) December 1985 view details
  • Gries, D. and J. Prins (1985). "A new notion of encapsulation." view details Abstract: Generally speaking, a `module' is used as an `encapsulation mechanism' to tie together a set of declarations of variables and operations upon them. Although there is no standard way to instantiate or use a module, the general idea is that a module describes the implementation of all the values of a given type. We believe that this is too inflexible to provide enough control: one should be able to use different implementations (given by different modules) for variables (and values) of the same type. When incorporated properly into the notation, this finer grain of control allows one to program at a high level of abstraction and then to indicate how various pieces of the program should be implemented. It provides simple, effective access to earlier-written modules, so that they are usable in a more flexible manner than is possible in current notations. Existing languages such as SETL, Smalltalk, ML, CLU, and Ada already provide some of the capabilities listed above, but our new notion may provide more flexibility and ease of use. The paper is organized as follows. Section 2 gives some basic ground rules for our programming notation and outlines our idea for encapsulation. Section 3 discusses some of the issues involved. Section 4 outlines proofs of correctness. Section 5 discusses a `real' example in detail. This is a report of ongoing work, and not a finished product.     
          in SIGPLAN Notices 20(07) July 1985 (Proceedings of the ACM SIGPLAN 85 symposium on Language issues in programming environments) view details
  • Feldman, M. B. "Ada vs. Modula-2: A response from the ivory tower" view details
          in SIGPLAN Notices 21(05) May 1986 view details
  • Greenwood, J. R. "Comments on 'A View from the Trenches'. Ada vs. Modula-2 vs. Praxis." view details
          in SIGPLAN Notices 21(05) May 1986 view details
  • Seidewitz, Ed "Object-oriented programming in Smalltalk and ADA" pp202-213 view details Abstract: Though Ada and Modula-2 are not object-oriented languages, an object-oriented viewpoint is crucial for effective use of their module facilities. It is therefore instructive to compare the capabilities of a modular language such as Ada with an archetypal object-oriented language such as Smalltalk. The comparison in this paper is in terms of the basic properties of encapsulation, inheritance and binding, with examples given in both languages. This comparison highlights the strengths and weaknesses of both types of languages from an object-oriented perspective. It also provides a basis for the application of experience from Smalltalk and other object-oriented languages to increasingly widely used modular languages such as Ada and Modula-2. DOI
          in SIGPLAN Notices 22(12) December 1987 (OOPSLA '87) view details
  • Seidewitz, Ed "Object-Oriented Programming in Smalltalk and Ada" presented at the 1987 Conference on Object-Oriented Programming Systems, Languages and Applications NASA Goddard Space Flight Center, Greenbelt MD 20771 1987 view details
          in SIGPLAN Notices 22(12) December 1987 (OOPSLA '87) view details
  • Donaho, J. "A comparison of extended Pascal and Ada." view details
          in SIGPLAN Notices 24(05) May 1989 view details
  • Liu, L. Y. H. and Shyamasundar, R. K. "An operational semantics of real time design language RT-CDL" Proceedings of the 5th International Workshop on Software Specifications & Design Pittsburgh, Pennsylvania, United States 1989 pp75-82 view details Extract: Motivation and Related Work
    Motivation and Related Work
    One of the primary objectives of Ada has been the programmability of real-time embedded systems. However, the definition of Ada [3] allows a high-priority task to wait for a low-priority task for an unpredictable delay. Furthermore. Ada lacks the power of harnessing the parallelism inherent in real-time systems. For instance, in Ada, we cannot even interleave some of the operations that am possible in the monitor-based languages--which is a disadvantage at many times. The rendezvous mechanism places a lot of restriction with reference to realizing multiform clocks and harnessing parallelism. Another notable point is that even though the traditional description tools of industrial process control systems arc intrinsically parallel, it is paradoxical that the computerization of these systems results in the progressive replacement of these parallel tools by programming languages involving a great amount of sequentiality. There has been quite a substantial effort in looking for specification/programming languages for real-time distributed systems. However, if we look at requirements for real-time languages [41, we can come to the conclusion that most of these languages fall short of expectations. For example, many languages do not provide any explicit means of correctly specifying timing constraints, or are limited to either delay or timeout statement [lo].

    This limitation not only reduces the expressive power of languages (and hence cannot be used in certain applications such as switching and digital systems) but also makes it difficult to reason about the timing constraints of a given program text. RT-Euclid is essentially a monitor-based language with features for expressing time-bounded loops; however, achieving data integrity through mutual exclusion, again, is not desirable even in non-real-time languages.

    Let us take a look at some of the major efforts towards a desirable specification/programming language for real-time systems. A first systematic study of considering the reasons for the lack of suitable specification/programming languages resulted in the language Esterel. Esterel was designed for programming responsive systems assuming a strong synchrony hypothesis (i.e., control transfer and transmission of events am instantaneous) and thus overcame several of the deficiencies. In Esterel, there is no internal notion of time; the argument is that the local clock can be simulated through an external clock signal. Although such an assumption leads to efficient and nice structures, the assumption is questionable from a realistic point of view and may result in the causality problem (something like a short circuit). One important feature of reactive systems is that they are primarily event-based rather than transformational (state-based). With this view point, the efforts by Harel, Pnueli et al. started looking for pragmatic formalism (perhaps mixed specification and programming) that would aid in the design of reactive systems. Their study resulted in the formalisms referred to as Statecharts. This formalism is based on state diagrams (thus providing graphic design aid) overcoming some of the drawbacks of state diagrams such as flatness, sequentiality, etc. Statecharts cater for hierarchical specification and multi-level concurrency via the broadcast communication mechanism. Although the language has great expressive power, the semantic of some features, e.g., micro-steps, is not very well understood. Furthermore, Statecharts lack data abstraction in the current form. Also, even though the current technology looks for systems which am not necessarily text-based (perhaps one could consider graphic objects as primitive objects), we feel that a graphic based system may provide only an aid rather than a complete basis in the development of large systems.

    The issues of safety and reliability are particularly important events (it is essentially the same as broadcasting a message over a for real-time embedded systems because of the catastrophic consequences. This addresses the need of a sound methodology for the verification of logical correctness as well as responsiveness of real-time programs. Unfortunately, typical real-time embedded systems are large and complex; hence, it is difficult-if not impossible for a programmer or a team to mentally comprehend. Thus, it is essential that we use a compositional methodology and realistic models. One important characteristic of real-time programs is to respond to external stimuli within a controllable delay. However, one cannot interpret this statement to mean an arbitrary delay. Thus, whenever we use interleaving models, we may not be able to satisfy the timing constraints as required.

    RT-CDL (Real Time Common Design Language), inspired by Esterel, has been proposed for the design of real-time reactive systems. The primary goal of the RT-CDL project is to provide a tool to bridge the gap between specification and realization of programs. The language is based on the event-action model and is capable of (i) expressing various timing constraints in a natural way; (ii) responding to various mat-time exceptions in a timely fashion; and (iii) specifying, reasoning, verifying about programs in a compositional manner. In this paper, as a first step, we discuss the primary mat-time features of RT-CDL through an operational semantics. We employed labeled transition systems on the lines of Plotkin's work to provide an operational semantics of RT-CDL using the maximal parallelism model of Salwicki and Milner. The maximal parallelism model is realistic in the sense that the number of actions which can be executed in parallel without violating synchronization constraints is maximized, and that no unnecessary waiting is modeled. Thus, it provides a realistic model-as opposed to the interleaving model-for real-time concurrency. We show how to model the behavior of non-buffered broadcasts, durational events, priority, interrupts, and preemptive commands through the semantics using discrete integer time domain. One nice feature of our approach is that it is compositional and thus provides a firm basis for compositional specification and verification of programs. From the semantics, we are able to show that the practical problems and the causality problems-due to the strong synchrony assumption associated with Esterel are no longer them. It must be noted that one of the distinctive advantages of Esterel is the compilability of the programs; however, that the simplicity of Esterel would be lost if one has to specify timing constraints in a distributed program with reference to the local clock.

          in SIGPLAN Notices 24(05) May 1989 view details
  • Watt, J. M. "A compact syntax chart for Ada" pp61-65 view details DOI
          in SIGPLAN Notices 27(03) March 1992 view details
  • Graham, R.M.; "Ada ? The Billion Dollar Language," Abacus, Winter 1994. view details
          in SIGPLAN Notices 27(03) March 1992 view details
  • Skillicorn, David B. and Talia, Domenico "Models and languages for parallel computation" pp123-169 view details
          in [ACM] ACM Computing Surveys (CSUR) 30(2) June 1998 view details
  • Library of Congress Subject Headings A35 view details
          in [ACM] ACM Computing Surveys (CSUR) 30(2) June 1998 view details
    • info
    • ftp repository

    • ftp info

    • SunOS interpreters

    • AdaEd compiler/interpreter for Amiga

    • AdaEd compiler/interpreter for MS-DOS