Ada Conformity Assessment Authority      Home Conformity Assessment   Test Suite ARGAda Standard
 
Annotated Ada Reference ManualLegal Information
Contents   Index   References   Search   Previous   Next 

6.4 Subprogram Calls

1
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
3.a/3
To be honest: {AI05-0005-1} For the purpose of non-syntax rules, infix operator calls are considered function_calls. See 6.6
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
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/2
{AI95-00310-01} 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. The name or prefix shall not resolve to denote an abstract subprogram unless it is also a dispatching subprogram. [When there is an actual_parameter_part, the prefix can be an implicit_dereference of an access-to-subprogram value.] 
8.a.1/2
Discussion: {AI95-00310-01} This rule is talking about dispatching operations (which is a static concept) and not about dispatching calls (which is a dynamic concept).
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).]
9.a/3
Proof: {AI05-0240-1} All Name Resolution Rules are overloading rules, see 8.6.

Dynamic Semantics

10/2
 {AI95-00345-01} 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, or a call on an entry or protected subprogram is performed (see 3.9.2). 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.d.1/2
{AI95-00345-01} If the subprogram is implemented by an entry or protected subprogram, it will be treated as a dispatching call to the corresponding entry (see 9.5.3, “Entry Calls”) or protected subprogram (see 9.5.1, “Protected Subprograms and Protected Actions”).
10.e/2
{AI95-00348-01} 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, null procedure, 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. 
10.1/2
   {AI95-00407-01} If the name or prefix of a subprogram call denotes a prefixed view (see 4.1.3), the subprogram call is equivalent to a call on the underlying subprogram, with the first actual parameter being provided by the prefix of the prefixed view (or the Access attribute of this prefix if the first formal parameter is an access parameter), and the remaining actual parameters given by the actual_parameter_part, if any.
11/2
 {AI95-00318-02} 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/2
 {AI95-00231-01} A function_call denotes a constant, as defined in 6.5; the nominal subtype of the constant is given by the nominal subtype of the function result.

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/3
{AI05-0299-1} procedure Pair(Left, Right : in Person_Name := new Person(M));   --  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/3
{AI05-0299-1} Pair;
Pair(Left => new Person(F), Right => new Person(M));
NOTES
24
9  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. 

Extensions to Ada 95

31.d/2
{AI95-00310-01} Nondispatching abstract operations are no longer considered when resolving a subprogram call. That makes it possible to use abstract to “undefine” a predefined operation for an untagged type. That's especially helpful when defining custom arithmetic packages. 

Wording Changes from Ada 95

31.e/2
{AI95-00231-01} Changed the definition of the nominal subtype of a function_call to use the nominal subtype wording of 6.1, to take into account null_exclusions and access result types.
31.f/2
{AI95-00345-01} Added wording to clarify that the meaning of a call on a subprogram “implemented by” an entry or protected operation is defined by 3.9.2.
31.g/2
{AI95-00407-01} Defined the meaning of a call on a prefixed view of a subprogram (see 4.1.3). 

Contents   Index   References   Search   Previous   Next 
Ada-Europe Ada 2005 and 2012 Editions sponsored in part by Ada-Europe