7.   PROCEDURES, FUNCTIONS, AND PARAMETERS

Procedures and functions are major language features for modularizing programs. Procedures and functions are defined by deferred declarations. Since procedures and functions are deferred units, they are elaborated when they are invoked, rather than when their declaration is encountered.

A procedure is elaborated when a procedure invocation statement occurs. A function is elaborated when a function invocation occurs in an expression.

Procedures and functions may be parameterized; when they are, actual parameters are bound to corresponding formal parameters of the procedure or function declaration at the time of invocation. This correspondence is based on the positions of the parameters in the formal and actual parameter lists.

Procedure and function declarations, like all deferred declarations, are closed scopes. Any variables from the enclosing scope used by a procedure or function must be explicitly imported.

7.1  PROCEDURE DECLARATION AND INVOCATION

C - identifier   2 - body   9 - imports   52 - formal parameters   53 - actual parameters
66 - formal translation time properties   67 - actual translation time properties   81 - definable symbol

A procedure is invoked by a procedure invocation statement to perform some action.

RULES

Identifier or definable symbol 1 is defined to be a procedure in the scope in which the procedure declaration appears. Identifier or definable symbol 2 must be identical to identifier or definable symbol 1.

Elaboration of a procedure invocation statement proceeds in the following order:

1. Actual parameters are elaborated;

2. actual parameters are bound to the formal parameters of the named procedure (see Section 7.3); and

3. the body of the named procedure is elaborated

NOTES

    A procedure declaration is a closed scope (see Section 3.5); the formal parameter names are defined in this scope.

    Procedures may be overloaded and may be generic. Overloading, generics, and use of the translation time property list are discussed in Section 11. Use of definable symbol names is discussed in Section 13.2.

    The order in which actual parameters are elaborated and bound is unspecified.

EXAMPLES

7.2  FUNCTION DECLARATION AND INVOCATION

C - identifier   2 - body   9 - imports   10 - type   12 - subtype   52 - formal parameters   53 - actual parameters
66 - formal trans properties   67 - actual trans properties   81 - definable symbol

A function differs from a procedure in that a function produces a result, a temporary data item (see Section 5.1). This result is obtained during elaboration of the body by elaborating a return statement which specifies the value of the result to be produced. A function is elaborated when a function invocation occurs as an operand in an expression.

RULES

Identifier or definable symbol 1 is defined to be a function in the scope in which the function declaration appears. Identifier or definable symbol 2 must be the same as identifier or definable symbol 1.

The type or subtype following => is known as the result type or subtype. The result type or the type of the result subtype must be assignable.

Elaboration of a function invocation primary proceeds in the following order:

1. Actual parameters are elaborated;
2. actual parameters are bound to the formal parameters of the named function (see Section 7.3);
3. the body of the function is elaborated until a return statement is encountered;
4. a result temporary data item is created, whose subtype is the result subtype (if specified) or the subtype of the expression in the return statement (if a result type is specified); and
5. the result of the function is produced by assigning (via :=) the value of the expression in the return statement to a result temporary data item. The := definition used is the one known in the scope where the function is defined.

There must be no way to reach the point immediately after the last statement in the body of the function, i.e., elaboration must always complete by the use of a return statement.

Additional rules for the return statement are given in Section 6.7, and (for side-effects and normality of functions) in Section 7.2.1.

NOTES

    A function declaration is a closed scope (see Section 3.5); the formal parameter names and the result variable are defined in this scope.

    The result subtype may depend on the subtypes and values of the actual parameters.

    Functions may be overloaded and may be generic. Overloading, generics, and use of the translation time property list are discussed in Section 11. Use of definable symbol names is discussed in 13.2.

    The order in which actual parameters are elaborated and bound is unspecified.

EXAMPLES

7.2.1  DECLARING AND USING A NEW TYPE

There are two kinds of functions: normal and abnormal functions. The result of the invocation of a normal function depends only upon the values of the actual parameters. Several invocations of a normal function with the same actual parameter values may be replaced by the translator with a single invocation (this is called common subexpression elimination). The result of the invocation of an abnormal function can depend upon the values of variables other than those in the actual parameters. All abnormal functions should be preceded by the reserved word ABNORMAL. Both abbreviations and types are assumed to be normal; the result of invoking an abbreviation or type should depend only upon the values of the actual parameters.

A function is said to have a side-effect if the function modifies any data whose lifetime is longer than the function invocation. Programs are more understandable, reliable, and verifiable when functions have no side-effects. However, there are cases where having side-effects is useful. The language allows normal functions to have side-effects providing these side-effects are restricted to modifications of data items that are local to the body of a capsule in which the function is also local. For normal functions with side-effects, the user must ensure that any common subexpression elimination will not have an undesired effect upon program behavior.

RULES

The order of elaboration within expressions is not defined. This means that the order in which slde-effects occur within expressions is not guaranteed.

If more than one exception could be raised while elaborating an expression, which of these exceptions is actually raised is not defined.

If there are several invocations anywhere in a program of a normal function, a type, or an abbreviation whose corresponding actual parameters have the same value, these invocations may be replaced (by a translator) by a single invocation which occurs at the point of the first of these invocations.

A normal function may have only CONST and READONLY formal parameters.

If a normal function has an imports list, then:

1. the function must be local to a capsule body;
2. variables imported by the function must be defined locally in the capsule body in which the function is local;
3. no invocations of the function may appear anywhere within the capsule in which the function ls defined; and
4. no variables imported by a normal function may be exported from the capsule.

NOTES

    Failure to mark an abnormal function, or the presence of an abnormal abbreviation or type, means that common subexpression elimination may produce undesired results.

    The only normal functions which have no parameters are functions which always produce the same constant value.

EXAMPLES

1. a normal function with no side-effects.

   
   
   

2. A normal function, fact, with a restricted side-effect which records the number of times it is called. This count is returned by an abnormal fuction, factcnt.

   
   
   

3. A normal function with a restricted side-effect -- a memo function.

   
   
   

4. An abnormal random number generator function.

   
   
   

5. A symbol table.

   
   
   

7.3  FORMAL AND ACTUAL PARAMETERS

C - identifier   10 - type   12 - subtype   26 - expression

Parameters are used to pass information between a specific invocation of a deferred unit (i.e., a procedure, function, task, capsule, type, or abbreviation) and the deferred unit.

When a deferred declaration specifies a list of formal parameters, each invocation of the deferred unit defined by the declaration must then supply an actual parameter for each formal parameter. When the deferred unit is invoked, each formal parameter is bound to its associated actual parameter. The kind of binding is specified for each formal parameter by means of a binding class.

There are four binding classes: two for passing information into a deferred unit (CONST and READONLY); one for passing information out (OUT); and one for passing information both In and out (VAR).

RED RATIONALE Steelman requires only a single input binding class, but RED has chosen to use two: CONST and READONLY. The reasons can be summarized as: "Don't care" semantics is unacceptable because of implementation dependencies which result. "Copy" semantics is necessary for safety, and also for efficiency with respect to avoiding unnecessary indirect referencing. However, "copy" semantics is not sufficient, in the light of the need for an efficient means of passing large objects as input parameters, for an input binding class which may be applied in user-defined assignment routines, and for allowing values of nonassignable types to be passed as input parameters. 4. Therefore, both "copy" and "ref" input binding classes should be provided. In RED, the CONST binding class has "copy" semantics, and READONLY has "ref" semantics.

RULES

Association of Actual and Formal Parameters

The number of actual parameters in an invocation must be equal to the number of formal parameters of the invoked deferred unit. Actual parameters are associated with formal parameters positionally.

Type Checking

Each actual parameter must have the same type as that specified for the corresponding formal parameter (or the type of the subtype specified).

Binding of Actual Parameters to Formal Parameters

If a formal parameter specifies a type, it acquires the subtype of the actual parameter with which it is bound.

If a formal parameter specifies a subtype, the formal parameter has that subtype; if the binding class is VAR or READONLY the actual parameter must have an equal subtype (otherwise the X_SUBTYPE exception is raised).

The binding class is CONST when no binding class is explicitly specified. The actual parameters associated with VAR and OUT formal parameters must be variables. For CONST and OUT, the parameter must have a type for which assignment is defined. Rules for each binding class are given here.

CONST

The formal parameter ls a local constant to which the value of the actual parameter is assigned (via :=).

VAR

The formal parameter is a local name for the actual parameter variable.

OUT

The formal parameter is a local variable which is assigned (via :=) to the actual parameter variable upon normal completion (i.e., completion other than as the result of an unhandled exception) of the invocation.

READONLY

The formal parameter is a local name for the actual parameter. The formal parameter is treated as a readonly data item.

For CONST and OUT formal parameters, the definition of assignment used is one known in the scope where the formal parameter definition appears.

RED RATIONALE INPUT-OUTPUT BINDING RED provides a single binding class for input-output parameters, the VAR class, with "ref" semantics. OUTPUT BINDING RED provides a single output binding class, the RESULT class, with "copy out" semantics. SIDE EFFECTS Side effects of a restricted nature are permitted within normal functions, and the translator ensures that these restrictions are met. The allowed side effects include the ability to modify an own variable of an encapsulation. Unrestricted side effects are permitted within abnormal functions, distinguished syntactically from normal ones by the presence of the keyword ABNORMAL. The semantic distinction between the two kinds of functions is that the translator guarantees the elaboration of each invocation of an abnormal function, whereas it is free to reuse the result of an invocation of a normal function if the values of the actual parameters have not changed. There is no guaranteed order of evaluation in expressions (and hence no guaranteed evaluation order for actual parameters to routines), other than for the "short circuited" AND and OR operations. ALIASING Sharing exists when two referencing forms designate the same data item, or one designates a component of the other, at the same time. Aliasing is a special case of sharing where the two referencing forms are simply identifiers. In contrast with general referencing forms, over its lifetime an identifier always designates the same data item. Aliasing rarely serves to increase the semantic power of a program. This makes aliasing considerably less useful than general sharing. Furthermore, aliasing tends to obfuscate the meaning of a program, and is often the result of a programming error. This has led some languages (e.g., Euclid) to place restrictions on programs in the interest of minimizing or eliminating the possibility for aliasing.

Order of Binding

The order in which actual parameters are bound to formal parameters ls undefined. A subtype specified for a formal parameter may not depend upon the value or subtype of other formal parameters.

NOTES

    Since there are two input binding classes, CONST and READONLY, there are some guidelines on when each should be used.

CONST	The formal parameter is a copy of the actual parameter. In most cases, this is the correct binding to use, since it prevents the occurrence of aliasing and unintended sharing.
READONLY	The formal parameter is a local name for the actual parameter. This binding class must be used when the parameter type is a type for which assignment is not defined; or sharing is desired (see Section 10.6).

    When large objects are to be passed as input, the CONST binding may be less efficient (since copying is involved) then the READONLY binding. However, in many cases, a translator can optimize CONST bindings so that no copy is required.