- (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.
(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)
- 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.
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.
- (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)
- 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).
- (11)
- The exception Program_Error is raised at the point of a function_call if
the function completes normally without executing a return_statement.
- (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.
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);
-
- (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
Subclauses
- Parameter Associations
-- Email comments, additions, corrections, gripes, kudos, etc. to:
Magnus Kempe -- Magnus.Kempe@di.epfl.ch
Copyright statement
Page last generated: 95-03-12