6.3. Subprogram Bodies

A subprogram body specifies the execution of a subprogram.

    subprogram_body ::=
        subprogram_specification is
           [declarative_part]
        begin
            sequence_of_statements
       [exception
            exception_handler
           {exception_handler}]  
        end [designator]; 

The declaration of a subprogram is optional. In the absence of such a declaration, the subprogram specification of the subprogram body (or body stub) acts as the declaration. For each subprogram declaration, there must be a corresponding body (except for a subprogram written in another language, as explained in section 13.9). If both a declaration and a body are given, the subprogram specification of the body must conform to the subprogram specification of the declaration (see section 6.3.1 for conformance rules).

If a designator appears at the end of a subprogram body, it must repeat the designator of the subprogram specification.

The elaboration of a subprogram body has no other effect than to establish that the body can from then on be used for the execution of calls of the subprogram.

The execution of a subprogram body is invoked by a subprogram call (see 6.4). For this execution, after establishing the association between formal parameters and actual parameters, the declarative part of the body is elaborated, and the sequence of statements of the body is then executed. Upon completion of the body, return is made to the caller (and any necessary copying back of formal to actual parameters occurs (see 6.2)). The optional exception handlers at the end of a subprogram body handle exceptions raised during the execution of the sequence of statements of the subprogram body (see 11.4).

Note:

It follows from the visibility rules that if a subprogram declared in a package is to be visible outside the package, a subprogram specification must be given in the visible part of the package. The same rules dictate that a subprogram declaration must be given if a call of the subprogram occurs textually before the subprogram body (the declaration must then occur earlier than the call in the program text). The rules given in sections 3.9 and 7.1 imply that a subprogram declaration and the corresponding body must both occur immediately within the same declarative region.

Example of subprogram body:

    procedure PUSH(E : in ELEMENT_TYPE; S : in out STACK) is
    begin
       if S.INDEX = S.SIZE then
          raise STACK_OVERFLOW;
       else
          S.INDEX := S.INDEX + 1;
          S.SPACE(S.INDEX) := E;
       end if;
    end PUSH;  

References: actual parameter, body stub, conform, declaration, declarative part, declarative region, designator, elaboration, elaboration has no other effect, exception, exception handler, formal parameter, occur immediately within, package, sequence of statements, subprogram, subprogram call, subprogram declaration, subprogram specification, visibility, visible part.

Sub-topics:

• 6.3.1 Conformance Rules
• 6.3.2 Inline Expansion of Subprograms

6.3.1. Conformance Rules

Whenever the language rules require or allow the specification of a given subprogram to be provided in more than one place, the following variations are allowed at each place:

• A numeric literal can be replaced by a different numeric literal if and only if both have the same value.

• A simple name can be replaced by an expanded name in which this simple name is the selector, if and only if at both places the meaning of the simple name is given by the same declaration.

• A string literal given as an operator symbol can be replaced by a different string literal if and only if both represent the same operator.

Two subprogram specifications are said to conform if, apart from comments and the above allowed variations, both specifications are formed by the same sequence of lexical elements, and corresponding lexical elements are given the same meaning by the visibility and overloading rules.

Conformance is likewise defined for formal parts, discriminant parts, and type marks (for deferred constants and for actual parameters that have the form of a type conversion (see 6.4.1)).

Notes:

A simple name can be replaced by an expanded name even if the simple name is itself the prefix of a selected component. For example, Q.R can be replaced by P.Q.R if Q is declared immediately within P.

The following specifications do not conform since they are not formed by the same sequence of lexical elements:

    procedure P(X,Y : INTEGER)
    procedure P(X : INTEGER; Y : INTEGER)
    procedure P(X,Y : in INTEGER)  

References: actual parameter, and 6.4.1, allow, comment, declaration, deferred constant, direct visibility, discriminant part, expanded name, formal part, lexical element, name, numeric literal, operator symbol, overloading, and 8.7, prefix, selected component, selector, simple name, subprogram specification, type conversion, visibility.

6.3.2. Inline Expansion of Subprograms

The pragma INLINE is used to indicate that inline expansion of the subprogram body is desired for every call of each of the named subprograms. The form of this pragma is as follows:

    pragma INLINE (name {, name}); 

Each name is either the name of a subprogram or the name of a generic subprogram. The pragma INLINE is only allowed at the place of a declarative item in a declarative part or package specification, or after a library unit in a compilation, but before any subsequent compilation unit.

If the pragma appears at the place of a declarative item, each name must denote a subprogram or a generic subprogram declared by an earlier declarative item of the same declarative part or package specification. If several (overloaded) subprograms satisfy this requirement, the pragma applies to all of them. If the pragma appears after a given library unit, the only name allowed is the name of this unit. If the name of a generic subprogram is mentioned in the pragma, this indicates that inline expansion is desired for calls of all subprograms obtained by instantiation of the named generic unit.

The meaning of a subprogram is not changed by the pragma INLINE. For each call of the named subprograms, an implementation is free to follow or to ignore the recommendation expressed by the pragma. (Note, in particular, that the recommendation cannot generally be followed for a recursive subprogram.)

References: allow, compilation, compilation unit, declarative item, declarative part, generic subprogram, generic unit, and 12.1, instantiation, library unit, name, overloading, and 8.7, package specification, pragma, subprogram, subprogram body, subprogram call.