Contents   Index   Previous   Next


6.4 Subprogram Calls

1
   {subprogram call} A subprogram call is either a procedure_call_statement or a function_call; [it invokes the execution of the subprogram_body. The call specifies the association of the actual parameters, if any, with formal parameters of the subprogram.]

Syntax

2
procedure_call_statement ::=
    procedure_name;
  | procedure_prefix actual_parameter_part;
3
function_call ::=
    function_name
  | function_prefix actual_parameter_part
4
actual_parameter_part ::=
    (parameter_association {, parameter_association})
5
parameter_association ::=
   [formal_parameter_selector_name =>] explicit_actual_parameter
6
explicit_actual_parameter ::= expression | variable_name
7
{named association} {positional association} A parameter_association is named or positional according to whether or not the formal_parameter_selector_name is specified. Any positional associations shall precede any named associations. Named associations are not allowed if the prefix in a subprogram call is an attribute_reference.
7.a
Ramification: This means that the formal parameter names used in describing predefined attributes are to aid presentation of their semantics, but are not intended for use in actual calls.

Name Resolution Rules

8
   The name or prefix given in a procedure_call_statement shall resolve to denote a callable entity that is a procedure, or an entry renamed as (viewed as) a procedure. The name or prefix given in a function_call shall resolve to denote a callable entity that is a function. [When there is an actual_parameter_part, the prefix can be an implicit_dereference of an access-to-subprogram value.]
8.a
Ramification: The function can be an operator, enumeration literal, attribute that is a function, etc.
9
   A subprogram call shall contain at most one association for each formal parameter. Each formal parameter without an association shall have a default_expression (in the profile of the view denoted by the name or prefix). This rule is an overloading rule (see 8.6).

Dynamic Semantics

10
    {execution (subprogram call) [partial]} For the execution of a subprogram call, the name or prefix of the call is evaluated, and each parameter_association is evaluated (see 6.4.1). If a default_expression is used, an implicit parameter_association is assumed for this rule. These evaluations are done in an arbitrary order. The subprogram_body is then executed. Finally, if the subprogram completes normally, then after it is left, any necessary assigning back of formal to actual parameters occurs (see 6.4.1).
10.a
Discussion: The implicit association for a default is only for this run-time rule. At compile time, the visibility rules are applied to the default at the place where it occurs, not at the place of a call.
10.b
To be honest: If the subprogram is inherited, see 3.4, ``Derived Types and Classes''.
10.c
If the subprogram is protected, see 9.5.1, ``Protected Subprograms and Protected Actions''.
10.d
If the subprogram is really a renaming of an entry, see 9.5.3, ``Entry Calls''.
10.e
Normally, the subprogram_body that is executed by the above rule is the one for the subprogram being called. For an enumeration literal, implicitly declared (but noninherited) subprogram, or an attribute that is a subprogram, an implicit body is assumed. For a dispatching call, 3.9.2, ``Dispatching Operations of Tagged Types'' defines which subprogram_body is executed.
11
    {Program_Error (raised by failure of run-time check)} The exception Program_Error is raised at the point of a function_call if the function completes normally without executing a return_statement.
11.a
Discussion: We are committing to raising the exception at the point of call, for uniformity -- see AI83-00152. This happens after the function is left, of course.
11.b
Note that there is no name for suppressing this check, since the check imposes no time overhead and minimal space overhead (since it can usually be statically eliminated as dead code).
12
    A function_call denotes a constant, as defined in 6.5; the nominal subtype of the constant is given by the result subtype of the function. {nominal subtype (of the result of a function_call) [partial]} {constant (result of a function_call) [partial]}

Examples

13
    Examples of procedure calls:
14
Traverse_Tree;                                               --  see 6.1
Print_Header(128, Title, True);                              --  see 6.1
15
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
16
    Examples of function calls:
17
Dot_Product(U, V)   --  see 6.1 and 6.3
Clock               --  see 9.6
F.all               --  presuming F is of an access-to-subprogram type -- see 3.10
18
    Examples of procedures with default expressions:
19
procedure Activate(Process : in Process_Name;
                   After   : in Process_Name := No_Process;
                   Wait    : in Duration := 0.0;
                   Prior   : in Boolean := False);
20
procedure Pair(Left, Right : in Person_Name := new Person);   --  see 3.10.1
21
    Examples of their calls:
22
Activate(X);
Activate(X, After => Y);
Activate(X, Wait => 60.0, Prior => True);
Activate(X, Y, 10.0, False);
23
Pair;
Pair(Left => new Person, Right => new Person);
NOTES
24
7  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.

Examples

25
    Examples of overloaded subprograms:
26
procedure Put(X : in Integer);
procedure Put(X : in String);
27
procedure Set(Tint   : in Color);
procedure Set(Signal : in Light);
28
    Examples of their calls:
29
Put(28);
Put("no possible ambiguity here");
30
Set(Tint   => Red);
Set(Signal => Red);
Set(Color'(Red));
31
--  Set(Red) would be ambiguous since Red may
--  denote a value either of type Color or of type Light

Wording Changes from Ada 83

31.a
We have gotten rid of parameters ``of the form of a type conversion'' (see RM83-6.4.1(3)). The new view semantics of type_conversions allows us to use normal type_conversions instead.
31.b
We have moved wording about run-time semantics of parameter associations to 6.4.1.
31.c
We have moved wording about raising Program_Error for a function that falls off the end to here from RM83-6.5.

Contents   Index   Previous   Next   Legal