[Home] [Prev] [Next] [Index]

6.4 Subprogram Calls

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

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
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.]

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
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).

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.e
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, 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.

11
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 AI-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
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);

NOTES

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.

6.4.1 Parameter Associations

1
[A parameter association defines the association between an actual parameter and a formal parameter.]

Language Design Principles

1.a
The parameter passing rules for out parameters are designed to ensure that the parts of a type that have implicit initial values (see 3.3.1) don't become "de-initialized" by being passed as an out parameter.

Name Resolution Rules

2
The formal_parameter_selector_name of a parameter_association shall resolve to denote a parameter_specification of the view being called.

3
The actual parameter is either the explicit_actual_parameter given in a parameter_association for a given formal parameter, or the corresponding default_expression if no parameter_association is given for the formal parameter. The expected type for an actual parameter is the type of the corresponding formal parameter.

3.a
To be honest: The corresponding default_expression is the one of the corresponding formal parameter in the profile of the view denoted by the name or prefix of the call.

4
If the mode is in, the actual is interpreted as an expression; otherwise, the actual is interpreted only as a name, if possible.

4.a
Ramification: This formally resolves the ambiguity present in the syntax rule for explicit_actual_parameter.  Note that we don't actually require that the actual be a name if the mode is not in; we do that below.

Legality Rules

5
If the mode is in out or out, the actual shall be a name that denotes a variable.

5.a
Discussion:  We no longer need "or a type_conversion whose argument is the name of a variable," because a type_conversion is now a name, and a type_conversion of a variable is a variable.

5.b
Reason: The requirement that the actual be a (variable) name is not an overload resolution rule, since we don't want the difference between expression and name to be used to resolve overloading. For example:

5.c
procedure Print(X : in Integer; Y : in Boolean := True);
procedure Print(Z : in out Integer);
. . .
Print(3); --Ambiguous!

5.d
The above call to Print is ambiguous even though the call is not compatible with the second Print which requires an actual that is a (variable) name ("3" is an expression, not a name).  This requirement is a legality rule, so overload resolution fails before it is considered, meaning that the call is ambiguous.

6
The type of the actual parameter associated with an access parameter shall be convertible (see 4.6) to its anonymous access type.

Dynamic Semantics

7
For the evaluation of a parameter_association:

8 ·
The actual parameter is first evaluated.

9 ·
For an access parameter, the access_definition is elaborated, which creates the anonymous access type.

10 ·
For a parameter [(of any mode)] that is passed by reference (see 6.2), a view conversion of the actual parameter to the nominal subtype of the formal parameter is evaluated, and the formal parameter denotes that conversion.

10.a
Discussion:  We are always allowing sliding, even for [in] out by-reference parameters.

11 ·
For an in or in out parameter that is passed by copy (see 6.2), the formal parameter object is created, and the value of the actual parameter is converted to the nominal subtype of the formal parameter and assigned to the formal.

11.a
Ramification: The conversion mentioned here is a value conversion.

12 ·
For an out parameter that is passed by copy, the formal parameter object is created, and:

13 ·   
For an access type, the formal parameter is initialized from the value of the actual, without a constraint check;
13.a
Reason: This preserves the Language Design Principle that an object of an access type is always initialized with a "reasonable" value.

14 ·   
For a composite type with discriminants or that has implicit initial values for any subcomponents (see 3.3.1), the behavior is as for an in out parameter passed by copy.
14.a
Reason: This ensures that no part of an object of such a type can become "de-initialized" by being part of an out parameter.

14.b
Ramification: This includes an array type whose component type is an access type, and a record type with a component that has a default_expression, among other things.

15 ·   
For any other type, the formal parameter is uninitialized. If composite, a view conversion of the actual parameter to the nominal subtype of the formal is evaluated [(which might raise Constraint_Error)], and the actual subtype of the formal is that of the view conversion.  If elementary, the actual subtype of the formal is given by its nominal subtype.
15.a
Ramification: This case covers scalar types, and composite types whose subcomponent's subtypes do not have any implicit initial values. The view conversion for composite types ensures that if the lengths don't match between an actual and a formal array parameter, the Constraint_Error is raised before the call, rather than after.

16
A formal parameter of mode in out or out with discriminants is constrained if either its nominal subtype or the actual parameter is constrained.

17
After normal completion and leaving of a subprogram, for each in out or out parameter that is passed by copy, the value of the formal parameter is converted to the subtype of the variable given as the actual parameter and assigned to it. These conversions and assignments occur in an arbitrary order.

17.a
Ramification: The conversions mentioned above during parameter passing might raise Constraint_Error - (see 4.6).

17.b
Ramification: If any conversion or assignment as part of parameter passing propagates an exception, the exception is raised at the place of the subprogram call; that is, it cannot be handled inside the subprogram_body.

17.c
Proof: Since these checks happen before or after executing the subprogram_body, the execution of the subprogram_body does not dynamically enclose them, so it can't handle the exceptions.

17.d
Discussion:  The variable we're talking about is the one denoted by the variable_name given as the explicit_actual_parameter. If this variable_name is a type_conversion, then the rules in for assigning to a view conversion apply. That is, if X is of subtype S1, and the actual is S2(X), the above-mentioned conversion will convert to S2, and the one mentioned in will convert to S1.

Extensions to Ada 83

17.e
In Ada 9X, a program can rely on the fact that passing an object as an out parameter does not "de-initialize" any parts of the object whose subtypes have implicit initial values. (This generalizes the RM83 rule that required copy-in for parts that were discriminants or of an access type.)

Wording Changes From Ada 83

17.f
We have eliminated the subclause on Default Parameters, as it is subsumed by earlier clauses and subclauses.



[Home] [Prev] [Next] [Index]

documentation@rational.com
Copyright © 1993-1998, Rational Software Corporation.   All rights reserved.