ACAA Header

ARG Ada Design Principles

The ARG generally tries to operate under a set of shared design principles. We can't always follow all of our principles, in part because sometimes they conflict with one another. In other cases, there are simply special requirements relating to a particular feature that override the general principles. Nevertheless, by having a set of shared design principles, the ARG can be more productive and provide long-term consistency in its work related to the evolution and maintenance of the Ada standard.
  • For a discussion of this topic in general, it is useful to look at the “Design Goals” included in the Ada Introduction. It is also useful to look at various places in the Annotated Ada Reference Manual where we mention “Language Design Principles”.

  • For another take on this topic, here is a paper written shortly after the conclusion of the Ada 2005 process, which appeared in the “CrossTalk” magazine, focused on the shared design principles of the ARG.

Overall Ada Design Principles

  • Safety is Ada's most important property. We should always be striving to provide a safe solution, but necessarily this has to be balanced with achieving good usability, because poor usability can by itself cause a loss in safety.

  • Consistency and orthogonality in language features are important so programmers can anticipate how features will combine, and use them as “building blocks”.

  • Readability is more important than writability, though economy of expression consistent with readability is also a virtue from a usability point of view.

  • Users should be able to start with a basic set of algorithms and data structures, and then over time tune and refine the program and take more control over the important underlying mechanisms that affect efficient resource utilization.

  • “Programming in the large” is an overarching philosophy of Ada's design.
    • Large programs are constructed incrementally. It is important that Ada programs can have correctness enforced even when part of the program is incomplete or even missing. Splitting a program into multiple units should be possible without compromising safety and correctness.
    • Abstraction is also an important part of programming in the large. Ada's rich type system and explicit structuring target data modeling rather than representation. Structuring of program units provides explicit control of interactions between types. New features should not weaken the control of interaction between units.
    • Conforming implementations should be able to perform required compile-time checks without breaking separate compilation, and without doing control or data flow analysis. Checks on operations on program entities should be performed according to the entities' visibly declared properties, such as their scope, kind, type, constancy, and other named aspects.
            SPARK goes beyond this.

  • Real-time usage is an important application domain for Ada, so operations should have clear, well-defined semantics ideally with clear time and space bounds.

  • All constructs should allow for efficient implementations, both in time and space usage.

  • The language should be factored so that users can productively use a subset of the whole language as appropriate to their problem domain, and if desired, impose restrictions on themselves or their projects that the compiler will help them enforce.

  • Vendors should have some flexibility in supporting certain specialized features (such as a specialized scheduling policy) only in target environments or application domains where they make sense.