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/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).
Dynamic Semantics
10/2
{
AI95-00345-01}
{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
, 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
10.c
10.d
10.d.1/2
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
{
AI-00318-02}
{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 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 result
subtype of the function
result.
{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.115
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.116
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.1018
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);
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.
Extensions to Ada 95
31.d/2
{
AI95-00310-01}
{extensions to Ada 95} 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).
Sponsored by Ada-Europe