6.4 Subprogram Calls
Syntax
{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.
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
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).
Ramification: The function can be an
operator, enumeration literal, attribute that is a function, etc.
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
{
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).
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.
{
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.
{
AI95-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.
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.
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).
{
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.
{nominal subtype (of
the result of a function_call) [partial]} {constant
(result of a function_call) [partial]} Examples
Examples of procedure
calls:
Traverse_Tree; --
see 6.1
Print_Header(128, Title, True); --
see 6.1Switch(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.1Examples of function
calls:
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.10Examples of procedures
with default expressions:
procedure Activate(Process : in Process_Name;
After : in Process_Name := No_Process;
Wait : in Duration := 0.0;
Prior : in Boolean := False);
procedure Pair(Left, Right :
in Person_Name :=
new Person); --
see 3.10.1
Examples of their
calls:
Activate(X);
Activate(X, After => Y);
Activate(X, Wait => 60.0, Prior => True);
Activate(X, Y, 10.0, False);
Pair;
Pair(Left => new Person, Right => new Person);
Examples
Examples of overloaded
subprograms:
procedure Put(X : in Integer);
procedure Put(X : in String);
procedure Set(Tint : in Color);
procedure Set(Signal : in Light);
Examples of their
calls:
Put(28);
Put("no possible ambiguity here");
Set(Tint => Red);
Set(Signal => Red);
Set(Color'(Red));
-- Set(Red) would be ambiguous since Red may
-- denote a value either of type Color or of type Light
Wording Changes from Ada 83
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.
We have moved wording about run-time semantics
of parameter associations to
6.4.1.
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
{
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
{
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.
{
AI95-00407-01}
Defined the meaning of a call on a prefixed view of a subprogram (see
4.1.3).
Sponsored by Ada-Europe