STRUCTURE statement (STRUCT)
The STRUCTURE statement, like the ORDINAL statement, may create a special form of user-defined type.
A typical STRUCTURE statement may look like this:
STRUCTURE /AC_ENTRY/ (CHARACTER*40) NAME, (FIXED.2) SALARY; LVT, TRZ(30)
and creates the type AC_ENTRY, as well as declaring LVT to be a variable of that type, and TRZ to be an array with 30 elements of that type. Operations can be performed on entities of type STRUCTURE by specifying their elements with the variable name and the element name linked by a period. Thus, LVT.NAME has the type CHARACTER*40, and TRZ.SALARY(23) has the type FIXED.2. The syntax TRZ(23).SALARY is also allowed in FALCON, as it creates no ambiguity, but array subscripts can freely be migrated to the end of a structure element name.
The clause giving a name to the type can be omitted if all desired structures of that type are declared in the one statement. As AC_ENTRY is the name of a user-defined type, the syntax &"AC_ENTRY" is normally required to invoke it.
Elements of a structure may be arrays, and they may have type STRUCTURE. Thus, another possible STRUCTURE statement is
STRUCTURE /BIG/ (CHARACTER*40) NAME,
(INTEGER) IDENT,
(STRUCTURE /ACEN/ ((INTEGER) ACNO,
(FIXED.2) BAL)) AEN(3)
since the semicolon is omitted, no variables are here declared to be of type BIG. Note that the named structure type ACEN can be created within a parenthesized type descriptor.
Note the extra level of parentheses for the elements of the structure AEN of type &"ACEN"; this is required to allow multiple type or attribute names in parentheses as are allowed in FALCON.
This statement implies that if we then encounter
&"BIG" BVAR
in the program, BVAR is a structure having the elements:
BVAR.NAME CHARACTER*40
BVAR.IDENT INTEGER
BVAR.AEN.ACNO(n) INTEGER
BVAR.AEN.BAL(n) FIXED.2
note that AEN comes before ACNO and BAL, just as LVT came before NAME and SALARY in the previous example.
Variables of the category STRUCTURE may be placed in COMMON, EQUIVALENCE, and INTERLEAVE statements, but structure elements cannot.
Type names are always local to the program in which they appear, except that they are available within subprograms which are defined within the text of a program that follow the type definition. Thus, a user-defined type must be defined the same way in a calling program and in an externally compiled subprogram if passing it as an argument is to produce valid results.
When a structure is assigned to a variable of type MUTABLE, the usual syntax suffices to extract its elements in the program in which the structure was established. If such a variable is passed as an argument to an external subprogram, it has the appearance of an array of type MUTABLE which is flagged as a structure; its elements can again be accessed by the usual syntax if the structure is identically defined within the subprogram. Also, the functions _AMS(struct) and _SAM(muar) convert structures to arrays of MUTABLE and vice versa.
Other statements can be used to specify how variables are to be stored in the computer's memory. The EQUIVALENCE, INTERLEAVE, FOLLOW, and LOCATE statements should not be used with variables of the types MUTABLE, STRING, SET, GROUP, PATH, LIST, VLIST and TVAL; these statements, as well as the COMMON statement, will operate only on that part of such variables that has a fixed position in storage. This part contains the address of the data in the variable, which, due to its variable length, will normally be in some form of storage pool, and may also contain some additional information, such as the type of the value of a MUTABLE variable, or the length of a string. (Thus, the use of such variables renders a program subject to unpredictable delays from garbage collection; they are provided to be used when necessary, not as a matter of course, except of course where rapid writing of a program is more important than efficient execution, as, for example, if a program is only to be used a few times.) In the case of the COMMON statement, a useful result is still achieved; the address of the item being shared in the common block, access to the item is also shared. (This may not be true, however, in implementations that do not use full-width machine addresses routinely; this practice on the part of implementors is, however, strongly discouraged; it is permissible to store addresses in segment:offset form rather than linear numerical form for efficiency.)
The COMMON statement, in addition to affecting the order in which values are stored, changes which programs can have access to variables. The EXTERNAL, GLOBAL, and AVAILABLE statements, which do this more directly, are also described in this area.