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, the article "The Ada 2005 Language Design Process",
written shortly after the conclusion of the Ada 2005 process, which appeared
in the “CrossTalk” magazine (page 20),
focused on the shared design principles of the ARG.
- 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.
|