Lady Ada

Ada '83 Language Reference Manual

Copyright 1980, 1982, 1983 owned by the United States Government. Direct reproduction and usage requests to the Ada Information Clearinghouse.

6.4. Subprogram Calls


A subprogram call is either a procedure call statement or a function call; it invokes the execution of the corresponding subprogram body. The call specifies the association of the actual parameters, if any, with formal parameters of the subprogram.

    procedure_call_statement ::=
        procedure_name [actual_parameter_part]; 

    function_call ::=
        function_name [actual_parameter_part] 

    actual_parameter_part ::=
        (parameter_association {, parameter_association}) 

    parameter_association ::=
       [formal_parameter =>] actual_parameter 

    formal_parameter ::= parameter_simple_name 

    actual_parameter ::=
       expression | variable_name | type_mark(variable_name)  

Each parameter association associates an actual parameter with a corresponding formal parameter. A parameter association is said to be named if the formal parameter is named explicitly; it is otherwise said to be positional. For a positional association, the actual parameter corresponds to the formal parameter with the same position in the formal part.

Named associations can be given in any order, but if both positional and named associations are used in the same call, positional associations must occur first, at their normal position. Hence once a named association is used, the rest of the call must use only named associations.

For each formal parameter of a subprogram, a subprogram call must specify exactly one corresponding actual parameter. This actual parameter is specified either explicitly, by a parameter association, or, in the absence of such an association, by a default expression (see 6.4.2).

The parameter associations of a subprogram call are evaluated in some order that is not defined by the language. Similarly, the language rules do not define in which order the values of in out or out parameters are copied back into the corresponding actual parameters (when this is done).

Examples of procedure calls:

  TRAVERSE_TREE;                                               --  see 6.1
  TABLE_MANAGER.INSERT(E);                                     --  see 7.5
  PRINT_HEADER(128, TITLE, TRUE);                              --  see 6.1

  SWITCH(FROM => X, TO => NEXT);                               --  see 6.1
  PRINT_HEADER(128, HEADER => TITLE, CENTER => TRUE            --  see 6.1
  PRINT_HEADER(HEADER => TITLE, CENTER => TRUE, PAGES => 128); --  see 6.1

Examples of function calls:

    DOT_PRODUCT(U, V)   --  see 6.1 and 6.5 
    CLOCK               --  see 9.6                                                   

References: default expression for a formal parameter, erroneous, expression, formal parameter, formal part, name, simple name, subprogram, type mark, variable.

Rationale references: 8.2 Parameter Modes, 8.3 Parameter Passing Notations, 8.4 Function Subprograms

Style Guide references: 2.1.1 Horizontal Spacing, 4.1.3 Functions, 5.2.2 Named Association, 5.6.6 Recursion and Iteration Bounds, 5.9.3 Dependence on Parameter Passing Mechanism


6.4.1. Parameter Associations


Each actual parameter must have the same type as the corresponding formal parameter.

An actual parameter associated with a formal parameter of mode in must be an expression; it is evaluated before the call.

An actual parameter associated with a formal parameter of mode in out or out must be either the name of a variable, or of the form of a type conversion whose argument is the name of a variable. In either case, for the mode in out, the variable must not be a formal parameter of mode out or a subcomponent thereof. For an actual parameter that has the form of a type conversion, the type mark must conform (see 6.3.1) to the type mark of he formal parameter; the allowed operand and target types are the same as for type conversions (see 4.6).

The variable name given for an actual parameter of mode in out or out is evaluated before the call. If the actual parameter has the form of a type conversion, then before the call, for a parameter of mode in out, the variable is converted to the specified type; after (normal) completion of the subprogram body, for a parameter of mode in out or out, the formal parameter is converted back to the type of the variable. (The type specified in the conversion must be that of the formal parameter.)

The following constraint checks are performed for parameters of scalar and access types:

In each of the above cases, the execution of the program is erroneous if the checked value is undefined.

For other types, for all modes, a check is made before the call as for scalar and access types; no check is made upon return.

The exception CONSTRAINT_ERROR is raised at the place of the subprogram call if either of these checks fails.


For array types and for types with discriminants, the check before the call is sufficient (a check upon return would be redundant) if the type mark of the formal parameter denotes a constrained subtype, since neither array bounds nor discriminants can then vary.

If this type mark denotes an unconstrained array type, the formal parameter is constrained with the bounds of the corresponding actual parameter and no check (neither before the call nor upon return) is needed (see 3.6.1). Similarly, no check is needed if the type mark denotes an unconstrained type with discriminants, since the formal parameter is then constrained exactly as the corresponding actual parameter (see 3.7.1).

References: actual parameter, array bound, array type, call of a subprogram, conform, constrained subtype, constraint, constraint_error exception, discriminant, erroneous, evaluation, evaluation of a name, expression, formal parameter, mode, name, parameter association, subtype, type, type conversion, type mark, unconstrained array type, unconstrained type with discriminants, undefined value, variable.

Style Guide references: 5.2.2 Named Association, 5.9.8 Incorrect Order Dependencies

6.4.2. Default Parameters


If a parameter specification includes a default expression for a parameter of mode in, then corresponding subprogram calls need not include a parameter association for the parameter. If a parameter association is thus omitted from a call, then the rest of the call, following any initial positional associations, must use only named associations.

For any omitted parameter association, the default expression is evaluated before the call and the resulting value is used as an implicit actual parameter.

Examples of procedures with default values:

                       AFTER   : in PROCESS_NAME := NO_PROCESS;
                       WAIT    : in DURATION := 0.0;
                       PRIOR   : in BOOLEAN := FALSE); 

    procedure PAIR(LEFT, RIGHT : PERSON_NAME := new PERSON); 

Examples of their calls:

    ACTIVATE(X, WAIT => 60.0, PRIOR => TRUE);
    ACTIVATE(X, Y, 10.0, FALSE); 

    PAIR(LEFT => new PERSON, RIGHT => new PERSON);


If a default expression is used for two or more parameters in a multiple parameter specification, the default expression is evaluated once for each omitted parameter. Hence in the above examples, the two calls of PAIR are equivalent.

References: actual parameter, default expression for a formal parameter, evaluation, formal parameter, mode, named parameter association, parameter association, parameter specification, positional parameter association, subprogram call.

Style Guide references: 5.2.2 Named Association, 5.2.3 Default Parameters


[Ada Information Clearinghouse]

Address any questions or comments to