6.4 Subprogram Calls
1
Syntax
2
3
3.a/3
4
5
6
7
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
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
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
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
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.
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
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
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).
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
