Skip to main content

7.1 Package Specifications and Declarations

danger

This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue

1

[A package is generally provided in two parts: a package_specification and a package_body. Every package has a package_specification, but not all packages have a package_body.]

Syntax​

2
package_declaration ::= package_specification;
3/3
package_specification ::= 
    package defining_program_unit_name
        [aspect_specification] is
      {basic_declarative_item}
   [private
      {basic_declarative_item}]
    end [[parent_unit_name.]identifier]
4

If an identifier or parent_unit_name.identifier appears at the end of a package_specification, then this sequence of lexical elements shall repeat the defining_program_unit_name.

Legality Rules​

5/2

A package_declaration or generic_package_declaration requires a completion [(a body)] if it contains any basic_declarative_item that requires a completion, but whose completion is not in its package_specification.

5.a/3
note
To be honest: If an implementation supports it, the body of a package or generic package may be imported (using aspect Import, see B.1), in which case no explicit body is allowed.

Static Semantics​

6/2

The first list of basic_declarative_items of a package_specification of a package other than a generic formal package is called the visible part of the package. [ The optional list of basic_declarative_items after the reserved word private (of any package_specification) is called the private part of the package. If the reserved word private does not appear, the package has an implicit empty private part.] Each list of basic_declarative_items of a package_specification forms a declaration list of the package.

6.a
ramification
This definition of visible part does not apply to generic formal packages — 12.7 defines the visible part of a generic formal package.
6.b
note
The implicit empty private part is important because certain implicit declarations occur there if the package is a child package, and it defines types in its visible part that are derived from, or contain as components, private types declared within the parent package. These implicit declarations are visible in children of the child package. See 10.1.1.
7

[An entity declared in the private part of a package is visible only within the declarative region of the package itself (including any child units — see 10.1.1). In contrast, expanded names denoting entities declared in the visible part can be used even outside the package; furthermore, direct visibility of such entities can be achieved by means of use_clauses (see 4.1.3 and 8.4).]

Dynamic Semantics​

8

The elaboration of a package_declaration consists of the elaboration of its basic_declarative_items in the given order.

9
note
NOTE 1 The visible part of a package contains all the information that another program unit is able to know about the package.
10
note
NOTE 2 If a declaration occurs immediately within the specification of a package, and the declaration has a corresponding completion that is a body, then that body has to occur immediately within the body of the package.
10.a
proof
This follows from the fact that the declaration and completion are required to occur immediately within the same declarative region, and the fact that bodies are disallowed (by the Syntax Rules) in package_specifications. This does not apply to instances of generic units, whose bodies can occur in package_specifications.

Examples​

11

Example of a package declaration:

12
package Rational_Numbers is
13type Rational is
      record
         Numerator   : Integer;
         Denominator : Positive;
      end record;
14function "="(X,Y : Rational) return Boolean;
15function "/"  (X,Y : Integer)  return Rational;  --  to construct a rational number
16function "+"  (X,Y : Rational) return Rational;
   function "-"  (X,Y : Rational) return Rational;
   function "*"  (X,Y : Rational) return Rational;
   function "/"  (X,Y : Rational) return Rational;
end Rational_Numbers;
17

There are also many examples of package declarations in the predefined language environment (see Annex A).

Incompatibilities With Ada 83​

17.a/5
note
In Ada 83, a library package is allowed to have a body even if it doesn't need one. In Ada 95, a library package body is either required or forbidden — never optional. The workaround is to add aspect Elaborate_Body, or something else requiring a body, to each library package that has a body that isn't otherwise required.

Wording Changes from Ada 83​

17.b/3
note
We have moved the syntax into this subclause and the next subclause from RM83-7.1, “Package Structure”, which we have removed.
17.c
note
RM83 was unclear on the rules about when a package requires a body. For example, RM83-7.1(4) and RM83-7.1(8) clearly forgot about the case of an incomplete type declared in a package_declaration but completed in the body. In addition, RM83 forgot to make this rule apply to a generic package. We have corrected these rules. Finally, since we now allow a pragma Import for any explicit declaration, the completion rules need to take this into account as well.

Wording Changes from Ada 95​

17.d/2
note
Defined “declaration list” to avoid ambiguity in other rules as to whether packages are included.

Extensions to Ada 2005​

17.e/3
note
An optional aspect_specification can be used in a package_specification. This is described in 13.1.1.