Any object can be passed to a procedure by means of a parameter, whether it be an object of data, a place in the program, or a process to be executed. For data there are two distinct levels of communication, numerical values (for input to the procedure) and data references (for input or output). lists all the types of object which can be passed, the syntactic form of specification, and the corresponding form of the actual parameter which must be supplied in the call. The equivalent syntax rules are:
Parameterspec ::=
Specifier
Idlist
Tablespec
Procedurespec
Specifier ::=
VALUE
Numbertype
LOCATION
Numbertype
Numbertype
ARRAY
LABEL
SWITCH
Table 8-1. Parameters of Procedures
| Notes: a. Composite specification of similar parameters has Idlist in place of Id b. see c. see |
The formal parameter is treated as though declared in the procedure body; upon entry to the procedure, the actual expression is evaluated to the type specified (including scaling if the numeric type is FIXED), and the value is forthwith assigned to the formal parameter. The formal parameter may subsequently be used for working space in the body; if the actual parameter is a variable, its value will be unaffected by assignments to the formal parameter.
Location, array and table parameters are all examples of data references. Upon entry to the procedure, these formals are made to refer to the same computer locations as those to which the actual parameters already refer. Operations upon such formal parameters within the procedure body are therefore operations on actual parameters. For example, the values of the actual parameters may be altered by assignments within the procedure.
The actual parameter must be a word reference, i.e. a simple data reference, an array element, an index table identifier, a whole-word table-element or an anonymous reference. Index expressions are evaluated on entry to the procedure as part of the process of obtaining the location of the actual parameter. The numeric type of the actual parameter must agree exactly with the formal specification. Part-word references, such as table elements are not allowed as word location parameters. An example of a procedure heading and a possible call of the same procedure is
As in an array declaration, the specified numeric type applies to all the elements of the array named. The numeric type of the actual array name must agree with this formal specification. By indexing within the body, the procedure can refer to any element of the actual array.
The specification of a table parameter is identical in form to a table declaration except that presetting is not allowed. The syntax rule is
Tablespec ::=
TABLE
Id [ Width, Length ] [ Elementdeclist ]
The element declaration list need include only such fields as are used in the procedure body.
The actual parameter must be a destination, i.e. a label or a switch element. In the latter case, the index is evaluated once upon entry to the procedure. The actual parameter must be in scope at the call, even if it is out of scope where the formal parameter is used in the procedure body.
The actual parameter is a switch identifier. By indexing within the procedure body, the procedure can refer to any of the individual labels which form the elements of the switch.
Within the body of a procedure, it may be necessary to execute an unknown procedure, i.e. a procedure whose name is to be supplied as an actual parameter. The features of the unknown procedure must be formally specified in the heading of the procedure within which it is called. As an example, suppose that a procedure g has been declared as
and further suppose that a procedure q has a formal parameter f for which it may be required to substitute g. A declaration of q, illustrating the necessary specification (italicized for clarity) might be
PROCEDURE q (LABEL b; FIXED(24,1) PROCEDURE f(VALUE INTEGER, VALUE INTEGER, INTEGER ARRAY) ); Statement
A typical call of q would be q (lab, g). At the inner level of parameter specification, no formal identifiers are required, no composite specifications are allowed (as for i and j in g) and the specifications are separated by commas. To pursue the example to a deeper level of nesting, suppose that a procedure c66 has a parameter p for which it may be required to substitute q. A declaration of c66 might then be
A typical call of c66 would be c66 (q, sw). At the level of specification shown in italics in the latter example, no further parameter specifications are required. The syntax rules for a procedure specification are
Procedurespec ::=
Answerspec
PROCEDURE
Procparamlist
Procparamlist ::=
Procparameter
Procparameter , Procparamlist
Procparameter ::=
Id
Id ( Typelist )
Typelist ::=
Type
Type , Typelist
Type ::=
Specifier
TABLE
Answerspec
PROCEDURE
The need to specify numeric type for formal value and location
parameters places an undesirable constraint on the designer of input and
output procedures. For such procedures it is desirable that the procedure
should adapt itself to the numeric type and scale of the actual parameters.
The following extension of the syntax for Parameterspec
(see ) is regarded as an
acceptable device in Coral 66 implementations:
Parameterspec ::=
VALUE
Formalpairlist
LOCATION
Formalpairlist
Specifier
Idlist
etc
Formalpairlist ::=
Formalpair
Formalpair , Formalpairlist
Formalpair ::=
Id : Id
At the call of the procedure, each formal pair corresponds to a single actual parameter. The first identifier is used within the procedure body, with numeric type integer, as a reference to the value of, or as the location of, the actual parameter. The compiler arranges that the second identifier passes the numeric type and scale of the actual parameter, represented in the form of an integer by some implementation-dependent convention. For example, the declaration of an output procedure might begin
If x is a variable of numeric type FIXED(24,12), the procedure statement out(x) would take account of this known scale.