DECLARE X FIXED, Y ENTRY, Z LABEL;
CHAPTER 10: SPECIAL TOPICS
RELATIONSHIP OF ARGUMENTS AND PARAMETERS When a procedure is invoked, a relation-ship is established between the arguments of the invoking statement and the paramet-ers of the invoked entry point.
A parameter may be a scalar, array, or structure name (including a label variable name, a task name, or an event name) that is unqualified and unsubscripted, or i t may be a file parameter or an entry parameter.
A file parameter may be used within a procedure wherever a file name may be used;
an entry pa.rameter may be used whereve.r an entry name may be used.
A parameter is accessible in the proce-dure only if the parameter is in the parameter list of the entry point at which the procedure is invoked.
Parameters must be declared in the invoked procedure; they cannot be declared in outer containing blocks. If no explicit declaration is given, an implicit or con-textual declaration is assumed, internal to the invoked procedure.
Parameters cannot be declared with the storage class attributes STATIC or AUTOMAT-IC, with scope attributes, or with the DEFINED attribute.
A parameter may have the CONTROLLED storage class attribute. In this case, the associated argument must also have the CONTROLLED attribute.
EVALUATION OF ARGUMENT SUBSCRIPTS
When an argument is a subscripted varia-ble, the subscripts are evaluated before invocation. The specified element is then passed as the argument. Subsequent changes in the subscript during the execution of the invoked procedure have no effect upon the corresponding parameter.
USE OF DUMMY ARGUMENTS
A constructed dummy argument containing the argument value is passed to a procedure if the argument is one of the following:
a constant, an entry name,
an expression other than a single unparenthesized scalar variable, array variable, or structure varia-ble, or
an expression whose data attributes may disagree with the declared data attributes of the parameter.
In all other cases the argument as i t appears is passed. The parameter becomes identical with the passed argument; thus, changes to a dummy will be reflected in the original argument only if a dummy is not passed.
USE OF THE ENTRY ATTRIBUTE
An ENTRY attribute may be specified for the invoked entry name; this ENTRY attri-bute appears in a DECLARE statement whose scope includes the invoking block. If an ENTRY attribute is not specified in the invoking procedure for the invoked entry name, the attributes of the arguments must agree with those of the corresponding par-ameters of the invoked entry.
If an ENTRY attribute without parameter attribute lists is specified for an iden-tifier, i t indicates that the identifier is an entry name. In this case also, the argument and parameter attributes are assumed to agree.
However, if an ENTRY attribute with parameter attribute lists is specified for the invoked entry name, then the attributes of the parameter of the invoked entry are assumed to be the same as those specified for i t in the ENTRY attribute specifi-cation. If an argument has data attributes that differ from the corresponding set of attributes defined in the ENTRY attribute specification (string lengths are consid-ered to match only if they have the same decimal integer constant as length) , then a dummy argument, with the value of the given argument, is constructed by converting the argument to the data attributes defined for the corresponding parameter in the ENTRY attribute specification. If conversion is impossible, then the program is in error (e.g., conversion of file name to bit).
The dummy argument is then passed to the invoked entry. Dummy arguments have CON-TROLLED storage class in the invoking pro-cedure. They are allocated immediately
before invocat~ion of the procedure and freed upon return, unless the invocation has a task option, in which case they are freed upon exi t~ from the invoking block.
The asterisk notation may be used in the ENTRY a1:tribute to specify that for varying length strings, or arrays of adjustable dimensions, the current argument bounds or length are to be assumed for the parameter.
Example:
A: PROCEDURE;
DEC]~ARE B E:NTRY (FIXED, FLOAT), (C,D) FLOAT;
CAL]~ B (C, D)
END A;
B: PROCEDURE (P, Q) ;
DECLARE P F'IXED, Q FLOAT;
END B;
The specification of the ENTRY attribute in procedure A indicates that B has two
paramet~~rs, the first with attribute FIXED and the'second with attribute FLOAT. How-ever, t.he arguments C and D both have the FLOAT a1:tribute. Since C is to be f ixed-point ,ghen it. is passed to procedure B, a.
dummy a]~gument is constructed by converting-C from floating-point to fixed-point. This dummy argument is then passed to B.
CORRESPONDENCE OF PARAMETERS AND ARGUMENTS If a paramet~er of an invoked entry is a scalar, the argument must be a scalar expression. The data attributes of the argumen1: must agree with the corresponding attributes of the parameter.
If a paramet:er of an invoked entry is an array, the argument must be an array expression. The argument may also be a scalar expression so long as an ENTRY attribu1:e is given for the invoked entry, specifying the dimension attribute for the relevant parameter. Asterisks may not be given in the dimension attribute if the argumen1t is a scalar. In this case, a dummy array argument will be constructed where the valuE~ of each element of the a-:ray is the value of the scalar expres-S10n. ~['he data attributes of the argument~
must agJcee with those of the parameter. If
the asterisk notation is not used to speci-fy the dimensions of the parameter in the invoked procedure, the values of the bounds of the array argument must agree with the values of the bounds specified for the parameter in the invoked procedure.
If a parameter is a structure, the argument must be a structure expression.
When a structure description is given for a parameter in an ENTRY attribute specifi-cation, a scalar expression may be speci-fied as the corresponding argument. A dummy structure argument will then be con-structed where the value of each element of the structure is the value of the scalar expression. The data attributes of the elements of the structure argument must match those of the associated parameter as specified in the invoked procedure. The relative structuring of the argument and the parameter must be the same, although the level numbers need not be identical.
If a parameter is a scalar-label Varia-ble, the argument must be a scalar-label variable or constant. If a parameter is an array-label variable, the argument must be an array-label variable. If an ENTRY attribute is given for the invoked entry in the invoking procedure, and if the appropriate parameter attribute list speci-fies that the parameter is a label array, then the argument may be a scalar-label variable or constant; a dummy label array argument will be suitably constructed. A dummy argument is always constructed when the argument is a label constant or label array.
If the argument is a statement label constant, this statement label constant is qualified by an identification of the cur-rent invocation of the block containing the label; this information is passed as a dummy argument to the invoked entry.
If a parameter is an entry parameter, the argument must be an entry name or entry parameter. When a parameter is specified as an entry parameter in the parameter description of an ENTRY attribute and is not given data attributes, no default data attributes are assumed. If i t is necessary that the entry parameter have data attri-butes, they may be specified in the param-eter description and a check will be made to insure that a correct argument is pro-vided.
If a parameter is a file parameter, the argument must be a file name or file parameter.
An argument passed to a parameter that is a fixed-length string variable or an array must be of fixed length. An argument passed to a parameter that is a
varying-length string variable or an array must be of varying length.
Example:
M1: PROCEDURE;
DECLARE A (10), AA (10), AAA (10) , N EXTERNAL;
N=10; CALL Sl (A,AA,AAA) ;
END Ml;
Sl: PROCEDURE (P,PP,PPP);
DECLARE P (10) , PP (*) , PPP (N) ,
N EXTERNAL;
END Sl;
In the above example, P, PP, and PPP are parameters. Procedures M1 and Sl are both external procedures. P is declared with constant bounds; thus, the bounds of any argument associated with P must be 10. PP is declared with the asterisk notation;
thus, anyone-dimensional argument of the same type may be associated with it. PPP is declared with an adjustable bound; thus, the bound of any argument associated with PPP must be equal to the value of N when 51 is activated. Note that a similar effect would result if Sl were internal to Ml and N were an internal variable declared in Ml.
ALLOCATION OF PARAMETERS
A parameter that has no storage class may correspond to an argument of any storage class; if more than one genera"tion of the argument exists, however, the param-eter is synonymous only with the generation existing at the point of invocation. A CONTROLLED parameter, however, always must be presented with a CONTROLLED argument;
the argument must be an unsubscripted name of CCNTROLLED data that is not an element of a structure. The parameter is synonym-ous with the entire allocation stack of the coritrolled variable. l'hus each reference to the parameter is a reference to the current generation of the associated argu-ment. A controlled parameter may be allo-cated and/or freed in the invoked proce-dure, thus manipulating the allocation stack of the associated argument.
Parameters, Bounds and Length
If an argument is a string or an array, the length of the string or the bounds of the array must be declared in the invoked procedure by using the asterisk notation, by giving explicit bounds or length or by declaring the bounds or length as an
express~on that, when evaluated, gives the appropriate value. The expressions speci-fied for the bounds or length must be formulated according to the rules stated in
"Evaluation of Expressions," in Chapter 3.
The number of dimensions and the bounds of the array argument or the length of the string argument must be the same as those of the corresponding parameters. However, the actual bounds or length may not be known at the time the invoked procedure is written; the invoked procedure may assume either that storage has been allocated prior to the invocation or that storage will be allocated explicitly in the proce-dure for those parameters declared CON-TROLLED.
Asterisk Notation for Bounds or Length The correspondence between argument and parameter in the invoked procedure can be achieved by specifying, the length by an asterisk or by specifying each and every bound by an asterisk, thus indicating that the length or bounds are the same as those for the corresponding argument.
If storage has been allocated for an argument, the corresponding parameter in the invoked procedure is assumed to have the same length or bounds as the argument.
If the parameter is controlled, further allocations of the data will use these same bounds or length unless different length or bounds are specified in the ALLOCATE state-ment.
If storage has not been allocated for an argument passed to a parameter declared with the asterisk notation, explicit bounds or length must be declared in an ALLOCATE statement given before another reference to the parameter in the invoked procedure.
Expressions as Bounds or Length
If storage has been allocated for an argument passed to a parameter for which explicit bounds or length are specified, then upon entry to the invoked procedure, any expressions are evaluated and must give values such that the bounds or length of the parameter are the same as the argument.
If the parameter is controlled and is subsequently reallocated, these expressions
are again evaluated to give new bounds or' length for the new allocation, unless they are specified in the ALLOCATE statement.
If storage has not been allocated for the argument, t~hen, at the point of entry, no requirements are made on the value of the expressions specified for the corres-ponding parameter bounds or length. These-expressions are evaluated at a subsequent point of allocation, unless they are speci-fied in the ALI,OCATE statement.
Example:
M2: PROCEDURE;
DEC1~RE A(10), AA(25) CONTROLLED;
CALL S2 (A,AA, 1 O~ ;
END M2;
S2: PROCEDURE (P , PP , N) ;
DECLARE PPC*) CONTROLLED, P(N),
~~ (25), S (5) ;
pp Q;
ALLOCATE PP(5);
PP -- S;
END S2;
PROLOGU:E~S
On entering a block, certain initial actions are performed, e.g., allocation of storage for a,utomatic variables. These initial actions constitute the prologue.
On entry to the prologue, the following items al:e available for computation:
1. variables declared outside the block and known within i t
2. val~iables declared STATIC and known wi 1:hin the block
3. ar9uments passed to the block
4. The most recent generations of con-tr()lled variables known within the block
The prologue makes available for computation all the other variables known within the block as follows:
5. automatic variables declared in the block
6. Defined variables declared within the block
In making these items available, the prologue may need to evaluate expressions defining lengths, bounds, iteration fac-tors, and initial values. Such expressions may depend on items of 1, 2, 3 or 4. They may also be dependent on items 5 and 6 under the following circumstances: If an item is referred to in an expression and the allocation or initialization of a sec-ond item depends on that expression, then that first item must in no way be dependent on the second item for its own allocation and initialization. Further, the first item must in no way be dependent on any other item that so depends on the second item.
Example:
The following is illegal:
DECLARE (A(M) INITIAL (1),
M INITIAL «A (1» ('ABC'»
AUTO;
The evaluations must not invoke abnormal functions. The entry invoked with the INITIAL CALL attribute may be abnormal only in that i t sets the data being initialized.
The sequence in which the evaluations refer to any abnormal data is not defined.
Function calls within the evaluations must not r~fer to items being made availa-ble by the prologue.
DATA ALLOCATION ACROSS TASKS
The scope of an identifier declared in an attaching task may include the attached task. Thus, the WAIT statement should properly be used in the attaching task to avoid freeing storage allocated in the attaching task and used in the attached task.
An attached task has almost the same access to the attaching task's data as i t would have if i t were executed synchronous-ly; however, when i t is attached, only the generations of CONTROLLED variables current at the time of attachment are passed to the attached task. Subsequent allocations in the attached task are known only within the attached task; subsequent allocations in the attaching task are known only within
the attaching task. A task may only :free storage that i t has allocated. All storage allocated within a task is destroyed when that task is completed.
. Allocation of Task and Event Names
Like variables, task names and event names have scope and storage class attri-butes. Storage will be allocated for task and event names in the same manner as for variables (by virtue of either an explicit or contextual declaration). If a given task is active and there is a task or event name associated with the task, then storage must not be released for the name until the task is terminated.
ABNORMALITY
The ABNORMAL, NORMAL, USES, and SETS attributes are provided in PL/I to enable the compiler to generate optimized code.
In the absence of any information, the following assumptions are made:
1. All external function references are normal.
2. All other procedure references are abnormal.
3. All variables are normal.
A variable is said to be abnormal if its value may be altered or otherwise accessed without an explicit indication. Thus, for example, the appearance of a variable name on the left side of an assignment state-ment, in the data list specification of a READ or GET statement, or as an argument to an abnormal function or procedure (see below) indicates a predictable situation where the variable may change its value.
However, when the variable is subject to change by the occurrence of an ON-condition, or if i t is subject to change in a procedure invoked with the TASK option (see -Asynchronous Operations and TasksH) , then there is no way to predict the point at which the change in value will occur or, in fact, if i t will occur.
Such possibilities cannot always be recognized contextually. Furthermore, if a portion of a source program contains sever-al references to such a variable, the order in which the indicated operations are exe-cuted becomes significant. (For example, if B is abnormal, the expression B + B is not necessarily equivalent to the exp.res-sion 2
*
B.)The implication is that the programlner expects the operation to be performed in a particular order. Such variables must therefore be declared ABNORMAL, to inhibit the optimization of such portions of a source program •
A procedure may possess varying degrees of abnormality. A procedure is said to be
"definitively abnormal" if it, or any pro-cedures invoked by it, accesses, modifies, allocates, or frees external data or modi-fies, allocates, or frees arguments. In addition, an internal procedure is abnormal if it, or any procedures invoked by it, accesses, modifies, allocates, or frees any variables known in the invoking block.
Such procedures are only definitively abnormal because the exact nature of their abnormality is described by the USES and SETS attributes, thus inhibiting some, but not all, optimization in the neighborhood of a reference to the procedure (see liThe USES and SETS Attributes·· in Chapter 4) •
However, if a procedure is "completely abnormal," all optimization of successive references must be inhibited. A procedure is completely abnormal if it, or any proce-dures invoked by it, does any of the following:
1. returns inconsistent function values for identical argument values
2. maintains any kind of a history 3. performs input or output operations 4. returns control from the procedure by
means of a GO TO statement
The ABNORMAL attribute (described in Chapter 4) is used to describe such a procedure. It may also, of course, be used to describe a procedure that is
"definitively abnormal."
When abnormality is specified, the order of execution becomes significant. In par-ticular, if an expression contains a ref-erence to an abnormal fUnction that way affect valUES in other parts of the expres-sion, the value of the expression will, in general, depend upon the order in which data is accessed ~ee "Order of Evaluation of Expressions, " in Chapter 3) •
If an ABNORfvlAL procedure, referred to in a statement, allocates or frees controlled data that has been referred to else~lere in the same statement, then the effect of the statement is undefined.
PROGRAMS A program erence for
constitutes a domain of ref-external identifiers and a
domain of persistence for data. A program consists of a set of external procedures, linked -to each other in the following sense. Every external identifier has con-stant meaning across all external proce~
domain of persistence for data. A program consists of a set of external procedures, linked -to each other in the following sense. Every external identifier has con-stant meaning across all external proce~