English for Ada Developers

Ada is used where a wrong word in a design review can be as costly as a wrong word in the code — safety-critical systems in aerospace, defense, and rail. Precise vocabulary isn’t a nicety here; it’s part of how these teams demonstrate to auditors and certifiers that a system was actually reasoned about correctly.

Key Vocabulary

Strong typing / subtype — Ada’s approach of treating even numerically compatible types (like two different integer ranges) as distinct types the compiler won’t silently convert between, with subtypes adding range constraints on top of a base type. “Don’t just cast this to Integer — declare a subtype with the actual valid range, like Altitude_Feet range 0 .. 60000, so the compiler rejects any value outside that range at the assignment, not three functions downstream.”

Package specification / package body — Ada’s separation of a unit’s public interface (the specification) from its implementation (the body), enforced by the compiler as two separate files, similar in spirit to a header/implementation split but stricter. “The package specification only exposes the operations client code actually needs — the internal state representation lives entirely in the package body, and callers genuinely cannot reach it.”

Contract (precondition / postcondition) — formal Pre and Post aspects attached to a subprogram declaration, checked at runtime in most build configurations and provable statically with tools like SPARK, documenting exactly what a function requires and guarantees. “Add a Pre aspect requiring the input array be non-empty, and a Post aspect guaranteeing the result is sorted — now the contract states what a comment used to just claim, and it’s actually checked.”

Task (Ada tasking) — Ada’s built-in, language-level concurrency unit, roughly analogous to a thread but defined and synchronized through language constructs like rendezvous and protected objects rather than a library. “This isn’t a library-based thread — it’s an Ada task, and the two tasks synchronize through a rendezvous, which is a language-level construct, not something bolted on with a mutex library.”

SPARK subset — a formally analyzable subset of Ada used to mathematically prove the absence of certain classes of runtime errors (like buffer overflows or integer overflow) before the code ever runs, common in the highest-assurance safety-critical work. “This module is written in the SPARK subset specifically so we can run formal proof tools against it — that’s a stronger guarantee than testing, since it verifies the property for all possible inputs, not just the ones we tested.”

Common Phrases

• “Is this a raw Integer, or should it be a properly constrained subtype?”
• “Is that operation exposed in the package specification, or does it only exist in the body?”
• “Does this subprogram have a Pre and Post contract, or is the requirement just documented in a comment?”
• “Is this concurrency handled with Ada tasking, or are we mixing in something else?”
• “Is this module written in the SPARK subset, or full Ada that can’t be formally proven?”

Example Sentences

Explaining a type design decision in review: “We used a subtype with an explicit range instead of a bare Integer here, specifically so an out-of-range altitude value gets caught by the compiler or a runtime check, not three modules later when it causes an actual failure.”

Justifying a contract: “I added a Pre and Post contract to this subprogram because the requirement — that the buffer must already be initialized before this runs — was previously only stated in a comment, which nobody was enforcing.”

Describing a concurrency design: “These two components communicate through Ada tasking with a rendezvous, not a shared mutable variable behind a mutex — that’s a deliberate choice, since the rendezvous makes the synchronization point explicit in the code itself.”

Professional Tips

• Default to a constrained subtype over a bare base type whenever a value has a known valid range — this is one of the main reasons teams choose Ada for safety-critical work, so use it consistently, not just where it’s convenient.
• Keep the package specification minimal and treat it as the actual contract under review — reviewers should be able to understand a package’s public behavior from the specification alone, without reading the body.
• Write Pre and Post contracts for any subprogram whose requirements matter for correctness — a contract is checked and auditable, where a comment claiming the same thing is neither.
• Use Ada tasking constructs rather than reaching for external concurrency libraries when working in Ada — tasking is part of the language specification and is what reviewers and certifiers expect to see.
• Reserve the SPARK subset for the highest-assurance modules where formal proof is worth the added discipline — it’s a stronger guarantee than testing, but it’s not free, so apply it where the assurance case actually needs it.

Practice Exercise

1. Explain why a constrained subtype is safer than a bare Integer type in Ada.
2. Describe the difference between a package specification and a package body.
3. Write a sentence justifying the use of Pre and Post contracts on a safety-critical subprogram.