WORKING DRAFT J3/02-007R2 May 31, 2002 13:24 This is an internal working document of J3. MAY 2002 WORKING DRAFT J3/02-007R2 Contents 1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Inclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.4 Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.5 Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.6 Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6.1 Fortran 95 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6.2 Fortran 90 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6.3 FORTRAN 77 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.7 Notation used in this standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.7.1 Informative notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.7.2 Syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.7.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.7.4 Assumed syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.7.5 Syntax conventions and characteristics . . . . . . . . . . . . . . . . . . . . . . . 6 1.7.6 Text conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.8 Deleted and obsolescent features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.8.1 Nature of deleted features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.8.2 Nature of obsolescent features . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.9 Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 Fortran terms and concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1 High level syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 Program unit concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.1 Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.2 Main program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.3 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.4 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3 Execution concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.1 Executable/nonexecutable statements . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.2 Statement order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.3 The END statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.4 Execution sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4 Data concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.2 Data value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4.3 Data entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4.4 Scalar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.5 Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.6 Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.7 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.5 Fundamental terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.5.1 Name and designator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5.2 Keyword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5.3 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5.4 Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 MAY 2002 WORKING DRAFT i J3/02-007R2 WORKING DRAFT MAY 2002 2.5.5 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5.6 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.7 Intrinsic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.8 Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.9 Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.10 Companion processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3 Characters, lexical tokens, and source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1 Processor character set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1.1 Letters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1.2 Digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1.3 Underscore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.1.4 Special characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.1.5 Other characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2 Low-level syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.1 Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.3 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.4 Statement labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.5 Delimiters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3 Source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3.1 Free source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3.2 Fixed source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.4 Including source text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.1 The concept of type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.1.1 Set of values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.1.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.1.3 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2 Type parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.3 Relationship of types and values to objects . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4 Intrinsic types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4.1 Integer type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4.2 Real type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.4.3 Complex type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.4.4 Character type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.4.5 Logical type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.5 Derived types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.5.1 Derived-type definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.5.2 Determination of derived types . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.5.3 Extensible types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.5.4 Component order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.5.5 Type parameter order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.5.6 Derived-type values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.5.7 Derived-type specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.5.8 Construction of derived-type values . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.5.9 Derived-type operations and assignment . . . . . . . . . . . . . . . . . . . . . . 61 4.5.10 The finalization process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.6 Type aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.7 Enumerations and enumerators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.8 Construction of array values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5 Data object declarations and specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 ii WORKING DRAFT MAY 2002 MAY 2002 WORKING DRAFT J3/02-007R2 5.1 Type declaration statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.1.1 Type specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.1.2 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.2 Attribute specification statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2.1 Accessibility statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2.2 ALLOCATABLE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2.3 ASYNCHRONOUS statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.2.4 BIND statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.2.5 DATA statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.2.6 DIMENSION statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.2.7 INTENT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.2.8 OPTIONAL statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.2.9 PARAMETER statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.2.10 POINTER statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.2.11 PROTECTED statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.2.12 SAVE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.2.13 TARGET statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.2.14 VALUE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.2.15 VOLATILE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.3 IMPLICIT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.4 NAMELIST statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.5 Storage association of data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.5.1 EQUIVALENCE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.5.2 COMMON statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6 Use of data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 6.1 Scalars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.1.1 Substrings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.1.2 Structure components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.1.3 Type parameter inquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 6.2 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 6.2.1 Whole arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 6.2.2 Array elements and array sections . . . . . . . . . . . . . . . . . . . . . . . . . . 107 6.3 Dynamic association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 6.3.1 ALLOCATE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 6.3.2 NULLIFY statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 6.3.3 DEALLOCATE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 7 Expressions and assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 7.1 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 7.1.1 Form of an expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 7.1.2 Intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 7.1.3 Defined operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 7.1.4 Type, type parameters, and shape of an expression . . . . . . . . . . . . . . . . 125 7.1.5 Conformability rules for elemental operations . . . . . . . . . . . . . . . . . . . 127 7.1.6 Specification expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 7.1.7 Initialization expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 7.1.8 Evaluation of operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 7.2 Interpretation of operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 7.2.1 Numeric intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 7.2.2 Character intrinsic operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 7.2.3 Relational intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 7.2.4 Logical intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 7.3 Precedence of operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 MAY 2002 WORKING DRAFT iii J3/02-007R2 WORKING DRAFT MAY 2002 7.4 Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 7.4.1 Assignment statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 7.4.2 Pointer assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 7.4.3 Masked array assignment ­ WHERE . . . . . . . . . . . . . . . . . . . . . . . . 147 7.4.4 FORALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 8 Execution control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 8.1 Executable constructs containing blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 8.1.1 Rules governing blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 8.1.2 IF construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 8.1.3 CASE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 8.1.4 ASSOCIATE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 8.1.5 SELECT TYPE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 8.1.6 DO construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 8.2 Branching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 8.2.1 GO TO statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 8.2.2 Computed GO TO statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 8.2.3 Arithmetic IF statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 8.3 CONTINUE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 8.4 STOP statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 9 Input/output statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 9.1 Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 9.1.1 Formatted record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 9.1.2 Unformatted record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 9.1.3 Endfile record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 9.2 External files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 9.2.1 File existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 9.2.2 File access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 9.2.3 File position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 9.2.4 File storage units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 9.3 Internal files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 9.4 File connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 9.4.1 Connection modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 9.4.2 Unit existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 9.4.3 Connection of a file to a unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 9.4.4 Preconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 9.4.5 The OPEN statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 9.4.6 The CLOSE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 9.5 Data transfer statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 9.5.1 Control information list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 9.5.2 Data transfer input/output list . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 9.5.3 Execution of a data transfer input/output statement . . . . . . . . . . . . . . . 195 9.5.4 Termination of data transfer statements . . . . . . . . . . . . . . . . . . . . . . 205 9.6 Waiting on pending data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 9.6.1 WAIT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 9.6.2 Wait operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 9.7 File positioning statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9.7.1 BACKSPACE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9.7.2 ENDFILE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 9.7.3 REWIND statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 9.8 FLUSH statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 9.9 File inquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 9.9.1 Inquiry specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 iv WORKING DRAFT MAY 2002 MAY 2002 WORKING DRAFT J3/02-007R2 9.9.2 Restrictions on inquiry specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 9.9.3 Inquire by output list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 9.10 Error, end-of-record, and end-of-file conditions . . . . . . . . . . . . . . . . . . . . . . . . 216 9.10.1 Error conditions and the ERR= specifier . . . . . . . . . . . . . . . . . . . . . . 216 9.10.2 End-of-file conditions and the END= specifier . . . . . . . . . . . . . . . . . . . 217 9.10.3 End-of-record conditions and the EOR= specifier . . . . . . . . . . . . . . . . . 217 9.10.4 IOSTAT= specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 9.10.5 IOMSG= specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 9.10.6 Restrictions on function references in input/output statements . . . . . . . . . . 218 9.11 Restriction on input/output statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 10 Input/output editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 10.1 Explicit format specification methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 10.1.1 FORMAT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 10.1.2 Character format specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 10.2 Form of a format item list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 10.2.1 Edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 10.2.2 Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 10.3 Interaction between input/output list and format . . . . . . . . . . . . . . . . . . . . . . 224 10.4 Positioning by format control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 10.5 Decimal symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 10.6 Data edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 10.6.1 Numeric editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 10.6.2 Logical editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 10.6.3 Character editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 10.6.4 Generalized editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 10.6.5 User-defined derived-type editing . . . . . . . . . . . . . . . . . . . . . . . . . . 233 10.7 Control edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 10.7.1 Position editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 10.7.2 Slash editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 10.7.3 Colon editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 10.7.4 SS, SP, and S editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 10.7.5 P editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 10.7.6 BN and BZ editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 10.7.7 RU, RD, RZ, RN, RC, and RP editing . . . . . . . . . . . . . . . . . . . . . . . 236 10.7.8 DC and DP editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 10.8 Character string edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 10.9 List-directed formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 10.9.1 List-directed input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 10.9.2 List-directed output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 10.10 Namelist formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 10.10.1 Namelist input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 10.10.2 Namelist output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 11 Program units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 11.1 Main program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 11.2 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 11.2.1 Module reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 11.2.2 The USE statement and use association . . . . . . . . . . . . . . . . . . . . . . . 249 11.3 Block data program units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 12 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 12.1 Procedure classifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 12.1.1 Procedure classification by reference . . . . . . . . . . . . . . . . . . . . . . . . . 253 MAY 2002 WORKING DRAFT v J3/02-007R2 WORKING DRAFT MAY 2002 12.1.2 Procedure classification by means of definition . . . . . . . . . . . . . . . . . . . 253 12.2 Characteristics of procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 12.2.1 Characteristics of dummy arguments . . . . . . . . . . . . . . . . . . . . . . . . 254 12.2.2 Characteristics of function results . . . . . . . . . . . . . . . . . . . . . . . . . . 254 12.3 Procedure interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 12.3.1 Implicit and explicit interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 12.3.2 Specification of the procedure interface . . . . . . . . . . . . . . . . . . . . . . . 256 12.4 Procedure reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 12.4.1 Actual arguments, dummy arguments, and argument association . . . . . . . . . 265 12.4.2 Function reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 12.4.3 Subroutine reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 12.4.4 Resolving procedure references . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 12.5 Procedure definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 12.5.1 Intrinsic procedure definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 12.5.2 Procedures defined by subprograms . . . . . . . . . . . . . . . . . . . . . . . . . 276 12.5.3 Definition and invocation of procedures by means other than Fortran . . . . . . 282 12.5.4 Statement function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 12.6 Pure procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 12.7 Elemental procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 12.7.1 Elemental procedure declaration and interface . . . . . . . . . . . . . . . . . . . 285 12.7.2 Elemental function actual arguments and results . . . . . . . . . . . . . . . . . . 286 12.7.3 Elemental subroutine actual arguments . . . . . . . . . . . . . . . . . . . . . . . 286 13 Intrinsic procedures and modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 13.1 Classes of intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 13.2 Arguments to intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 13.2.1 The shape of array arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 13.2.2 Mask arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 13.3 Bit model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 13.4 Numeric models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 13.5 Standard generic intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 13.5.1 Numeric functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 13.5.2 Mathematical functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 13.5.3 Character functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 13.5.4 Kind functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 13.5.5 Miscellaneous type conversion functions . . . . . . . . . . . . . . . . . . . . . . . 291 13.5.6 Numeric inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 13.5.7 Array inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 13.5.8 Other inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 13.5.9 Bit manipulation procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 13.5.10 Floating-point manipulation functions . . . . . . . . . . . . . . . . . . . . . . . . 292 13.5.11 Vector and matrix multiply functions . . . . . . . . . . . . . . . . . . . . . . . . 293 13.5.12 Array reduction functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 13.5.13 Array construction functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 13.5.14 Array location functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 13.5.15 Null function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 13.5.16 Random number subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 13.5.17 System environment procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 13.6 Specific names for standard intrinsic functions . . . . . . . . . . . . . . . . . . . . . . . . 294 13.7 Specifications of the standard intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . 296 13.8 Standard intrinsic modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 13.8.1 The ISO C BINDING module . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 13.8.2 The IEEE modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 13.8.3 The ISO FORTRAN ENV intrinsic module . . . . . . . . . . . . . . . . . . . . 353 vi WORKING DRAFT MAY 2002 MAY 2002 WORKING DRAFT J3/02-007R2 14 Exceptions and IEEE arithmetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 14.1 Derived types and constants defined in the modules . . . . . . . . . . . . . . . . . . . . . 356 14.2 The exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 14.3 The rounding modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 14.4 Halting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 14.5 The floating point status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 14.6 Exceptional values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 14.7 IEEE arithmetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 14.8 Tables of the procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 14.8.1 Inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 14.8.2 Elemental functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 14.8.3 Kind function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 14.8.4 Elemental subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 14.8.5 Nonelemental subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 14.9 Specifications of the procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 14.10 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 15 Interoperability with C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 15.1 The ISO C BINDING intrinsic module . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 15.1.1 Named constants and derived types in the module . . . . . . . . . . . . . . . . . 381 15.1.2 Procedures in the module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 15.2 Interoperability between Fortran and C entities . . . . . . . . . . . . . . . . . . . . . . . 384 15.2.1 Interoperability of intrinsic types . . . . . . . . . . . . . . . . . . . . . . . . . . 384 15.2.2 Interoperability with C pointer types . . . . . . . . . . . . . . . . . . . . . . . . 385 15.2.3 Interoperability of derived types and C struct types . . . . . . . . . . . . . . . . 386 15.2.4 Interoperability of scalar variables . . . . . . . . . . . . . . . . . . . . . . . . . . 387 15.2.5 Interoperability of array variables . . . . . . . . . . . . . . . . . . . . . . . . . . 387 15.2.6 Interoperability of procedures and procedure interfaces . . . . . . . . . . . . . . 388 15.3 Interoperation with C global variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 15.3.1 Binding labels for common blocks and variables . . . . . . . . . . . . . . . . . . 391 15.4 Interoperation with C functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 15.4.1 Binding labels for procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 16 Scope, association, and definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 16.1 Scope of global entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 16.2 Scope of local entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 16.2.1 Local entities that have the same names as common blocks . . . . . . . . . . . . 395 16.2.2 Function results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 16.2.3 Restrictions on generic declarations . . . . . . . . . . . . . . . . . . . . . . . . . 395 16.2.4 Components, type parameters, and bindings . . . . . . . . . . . . . . . . . . . . 397 16.2.5 Argument keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 16.3 Statement and construct entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 16.4 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 16.4.1 Name association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 16.4.2 Pointer association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 16.4.3 Storage association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 16.4.4 Inheritance association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 16.4.5 Establishing associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 16.5 Definition and undefinition of variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 16.5.1 Definition of objects and subobjects . . . . . . . . . . . . . . . . . . . . . . . . . 407 16.5.2 Variables that are always defined . . . . . . . . . . . . . . . . . . . . . . . . . . 407 16.5.3 Variables that are initially defined . . . . . . . . . . . . . . . . . . . . . . . . . . 407 16.5.4 Variables that are initially undefined . . . . . . . . . . . . . . . . . . . . . . . . 408 16.5.5 Events that cause variables to become defined . . . . . . . . . . . . . . . . . . . 408 MAY 2002 WORKING DRAFT vii J3/02-007R2 WORKING DRAFT MAY 2002 16.5.6 Events that cause variables to become undefined . . . . . . . . . . . . . . . . . . 409 16.5.7 Variable definition context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 A Glossary of technical terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 B Decremental features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 B.1 Deleted features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 B.2 Obsolescent features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 B.2.1 Alternate return . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 B.2.2 Computed GO TO statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 B.2.3 Statement functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 B.2.4 DATA statements among executables . . . . . . . . . . . . . . . . . . . . . . . . 427 B.2.5 Assumed character length functions . . . . . . . . . . . . . . . . . . . . . . . . . 427 B.2.6 Fixed form source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 B.2.7 CHARACTER* form of CHARACTER declaration . . . . . . . . . . . . . . . . 427 C Extended notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 C.1 Section 4 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 C.1.1 Intrinsic and derived types (4.4, 4.5) . . . . . . . . . . . . . . . . . . . . . . . . 429 C.1.2 Selection of the approximation methods (4.4.2) . . . . . . . . . . . . . . . . . . 430 C.1.3 Extensible types (4.5.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430 C.1.4 Pointers (4.5.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 C.1.5 Structure constructors and generic names . . . . . . . . . . . . . . . . . . . . . . 432 C.1.6 Final subroutines (4.5.1.7, 4.5.10, 4.5.10.1, 4.5.10.2) . . . . . . . . . . . . . . . . 434 C.2 Section 5 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 C.2.1 The POINTER attribute (5.1.2.11) . . . . . . . . . . . . . . . . . . . . . . . . . 436 C.2.2 The TARGET attribute (5.1.2.14) . . . . . . . . . . . . . . . . . . . . . . . . . . 437 C.2.3 The VOLATILE attribute (5.1.2.16) . . . . . . . . . . . . . . . . . . . . . . . . . 437 C.3 Section 6 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 C.3.1 Structure components (6.1.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 C.3.2 Allocation with dynamic type (6.3.1) . . . . . . . . . . . . . . . . . . . . . . . . 440 C.3.3 Pointer allocation and association . . . . . . . . . . . . . . . . . . . . . . . . . . 440 C.4 Section 7 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 C.4.1 Character assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 C.4.2 Evaluation of function references . . . . . . . . . . . . . . . . . . . . . . . . . . 441 C.4.3 Pointers in expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 C.4.4 Pointers on the left side of an assignment . . . . . . . . . . . . . . . . . . . . . . 442 C.4.5 An example of a FORALL construct containing a WHERE construct . . . . . . 442 C.4.6 Examples of FORALL statements . . . . . . . . . . . . . . . . . . . . . . . . . . 443 C.5 Section 8 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 C.5.1 Loop control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 C.5.2 The CASE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 C.5.3 Examples of DO constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 C.5.4 Examples of invalid DO constructs . . . . . . . . . . . . . . . . . . . . . . . . . 447 C.6 Section 9 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448 C.6.1 External files (9.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448 C.6.2 Nonadvancing input/output (9.2.3.1) . . . . . . . . . . . . . . . . . . . . . . . . 449 C.6.3 Asynchronous input/output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 C.6.4 OPEN statement (9.4.5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 C.6.5 Connection properties (9.4.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 C.6.6 CLOSE statement (9.4.6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 C.7 Section 10 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 C.7.1 Number of records (10.3, 10.4, 10.7.2) . . . . . . . . . . . . . . . . . . . . . . . . 453 C.7.2 List-directed input (10.9.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454 viii WORKING DRAFT MAY 2002 MAY 2002 WORKING DRAFT J3/02-007R2 C.8 Section 11 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 C.8.1 Main program and block data program unit (11.1, 11.3) . . . . . . . . . . . . . 455 C.8.2 Dependent compilation (11.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 C.8.3 Examples of the use of modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 C.9 Section 12 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 C.9.1 Portability problems with external procedures (12.3.2.2) . . . . . . . . . . . . . 463 C.9.2 Procedures defined by means other than Fortran (12.5.3) . . . . . . . . . . . . . 464 C.9.3 Procedure interfaces (12.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 C.9.4 Argument association and evaluation (12.4.1.2) . . . . . . . . . . . . . . . . . . 464 C.9.5 Pointers and targets as arguments (12.4.1.2) . . . . . . . . . . . . . . . . . . . . 465 C.9.6 Polymorphic Argument Association (12.4.1.3) . . . . . . . . . . . . . . . . . . . 467 C.10 Section 15 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 C.10.1 Runtime environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 C.10.2 Examples of Interoperation between Fortran and C Functions . . . . . . . . . . 468 C.11 Section 16 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 C.11.1 Examples of host association (16.4.1.3) . . . . . . . . . . . . . . . . . . . . . . . 471 C.11.2 Generic resolution and dynamic dispatch (12.4.4) . . . . . . . . . . . . . . . . . 472 C.12 Array feature notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 C.12.1 Summary of features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 C.12.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474 C.12.3 FORmula TRANslation and array processing . . . . . . . . . . . . . . . . . . . 479 C.12.4 Sum of squared residuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480 C.12.5 Vector norms: infinity-norm and one-norm . . . . . . . . . . . . . . . . . . . . . 480 C.12.6 Matrix norms: infinity-norm and one-norm . . . . . . . . . . . . . . . . . . . . . 480 C.12.7 Logical queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480 C.12.8 Parallel computations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481 C.12.9 Example of element-by-element computation . . . . . . . . . . . . . . . . . . . . 481 C.12.10 Bit manipulation and inquiry procedures . . . . . . . . . . . . . . . . . . . . . . 481 D Index of syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 E Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523 MAY 2002 WORKING DRAFT ix J3/02-007R2 WORKING DRAFT MAY 2002 x WORKING DRAFT MAY 2002 MAY 2002 WORKING DRAFT J3/02-007R2 List of Tables 2.1 Requirements on statement ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2 Statements allowed in scoping units . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1 Special characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1 Subscript order value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 7.1 Type of operands and results for intrinsic operators . . . . . . . . . . . . . . . . . 123 7.2 Interpretation of the numeric intrinsic operators . . . . . . . . . . . . . . . . . . . 135 7.3 Interpretation of the character intrinsic operator // . . . . . . . . . . . . . . . . . 136 7.4 Interpretation of the relational intrinsic operators . . . . . . . . . . . . . . . . . . 137 7.5 Interpretation of the logical intrinsic operators . . . . . . . . . . . . . . . . . . . . 138 7.6 The values of operations involving logical intrinsic operators . . . . . . . . . . . . 138 7.7 Categories of operations and relative precedence . . . . . . . . . . . . . . . . . . . 139 7.8 Type conformance for the intrinsic assignment statement . . . . . . . . . . . . . . 141 7.9 Numeric conversion and the assignment statement . . . . . . . . . . . . . . . . . . 143 13.1 Characteristics of the result of NULL ( ) . . . . . . . . . . . . . . . . . . . . . . . . 335 15.1 Names of C characters with special semantics . . . . . . . . . . . . . . . . . . . . . 382 15.2 Interoperability between Fortran and C types . . . . . . . . . . . . . . . . . . . . . 384 MAY 2002 WORKING DRAFT xi J3/02-007R2 WORKING DRAFT MAY 2002 Foreword ISO (the International Organization for Standardization) and IEC (the International Electrotechni- cal Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activ- ity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and nongovernmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft International Standards adopted by the joint technical committee are circu- lated to national bodies for voting. Publication of an International Standard requires approval by at least 75% of the national bodies casting a vote. International Standard ISO/IEC 1539-1 was prepared by Joint Technical Committee ISO/IEC/JTC1, Information technology, Subcommittee SC22, Programming languages, their environments and system software interfaces. This fourth edition cancels and replaces the third edition (ISO/IEC 1539-1:1997), which has been tech- nically revised. ISO/IEC 1539 consists of the following parts, under the general title Information technology -- Pro- gramming languages -- Fortran: -- Part 1: Base language -- Part 2: Varying length character strings -- Part 3: Conditional Compilation The annexes of this part of ISO/IEC 1539 are for information only. xii WORKING DRAFT MAY 2002 MAY 2002 WORKING DRAFT J3/02-007R2 Introduction Standard programming language Fortran This part of the international standard comprises the specification of the base Fortran language, infor- mally known as Fortran 2000. With the limitations noted in 1.6.2, the syntax and semantics of Fortran 95 are contained entirely within Fortran 2000. Therefore, any standard-conforming Fortran 95 program not affected by such limitations is a standard conforming Fortran 2000 program. New features of Fortran 2000 can be compatibly incorporated into such Fortran 95 programs, with any exceptions indicated in the text of this part of the standard. Fortran 2000 contains several extensions to Fortran 95; among them are: (1) Derived type enhancements: parameterized derived types (allows the kind, length, or shape of a derived type's components to be chosen when the derived type is used), mixed compo- nent accessibility (allows different components to have different accessibility), public entities of private type, improved structure constructors, and finalizers. (2) Object oriented programming support: enhanced data abstraction (allows one type to ex- tend the definition of another type), polymorphism (allows the type of a variable to vary at runtime), dynamic type allocation, SELECT TYPE construct (allows a choice of execu- tion flow depending upon the type a polymorphic object currently has), and type-bound procedures. (3) The ASSOCIATE construct (which allows a complex expression or object to be denoted by a simple symbol). (4) Data manipulation enhancements: allocatable components, deferred type parameters, VOL- ATILE attribute, explicit type specification in array constructors, INTENT specification of pointer arguments, specified lower bounds of pointer assignment and pointer rank remap- ping, extended initialization expressions, MAX and MIN intrinsics for character type, and enhanced complex constants. (5) Input/output enhancements: asynchronous transfer operations (allows a program to con- tinue to process data while an input/output transfer occurs), stream access (allows access to a file without reference to any record structure), user specified transfer operations for derived types, user specified control of rounding during format conversions, named constants for preconnected units, regularization of input/output keywords, and access to input/output error messages. (6) Procedure pointers. (7) Scoping enhancements: the ability to rename defined operators (which supports greater data abstraction) and control of host association into interface bodies. (8) Support for IEC 60559 (IEEE 754) exceptions and arithmetic (to the extent a processor's arithmetic supports the IEC standard). (9) Interoperability with the C programming language (allows portable access to many libraries and the low-level facilities provided by C and allows the portable use of Fortran libraries by programs written in C). (10) Support for international usage: (ISO 10646) and choice of decimal or comma in numeric formatted input/output. (11) Enhanced integration with the host operating system: access to command line arguments and environment variables, and access to the processor's error messages (improves the ability to handle exceptional conditions). MAY 2002 WORKING DRAFT xiii J3/02-007R2 WORKING DRAFT MAY 2002 Organization of this part of ISO/IEC 1539 This part of ISO/IEC 1539 is organized in 16 sections, dealing with 8 conceptual areas. These 8 areas, and the sections in which they are treated, are: High/low level concepts Sections 1, 2, 3 Data concepts Sections 4, 5, 6 Computations Sections 7, 13, 14 Execution control Section 8 Input/output Sections 9, 10 Program units Sections 11, 12 Interoperability with C Section 15 Scoping and association rules Section 16 It also contains the following nonnormative material: Glossary Annex A Decremental features Annex B Extended notes Annex C Index of syntax rules Annex D Index Annex E xiv WORKING DRAFT MAY 2002 MAY 2002 WORKING DRAFT J3/02-007R2 1 Information technology -- Programming languages -- 2 Fortran -- 3 Part 1: 4 Base Language 5 Section 1: Overview 6 1.1 Scope 7 ISO/IEC 1539 is a multipart International Standard; the parts are published separately. This publi- 8 cation, ISO/IEC 1539-1, which is the first part, specifies the form and establishes the interpretation 9 of programs expressed in the base Fortran language. The purpose of this part of ISO/IEC 1539 is to 10 promote portability, reliability, maintainability, and efficient execution of Fortran programs for use on 11 a variety of computing systems. The second part, ISO/IEC 1539-2, defines additional facilities for the 12 manipulation of character strings of variable length. The third part, ISO/IEC 1539-3, defines a stan- 13 dard conditional compilation facility for Fortran. A processor conforming to part 1 need not conform to 14 ISO/IEC 1539-2 or ISO/IEC 1539-3; however, conformance to either assumes conformance to this part. 15 Throughout this publication, the term "this standard" refers to ISO/IEC 1539-1. 16 1.2 Processor 17 The combination of a computing system and the mechanism by which programs are transformed for use 18 on that computing system is called a processor in this standard. 19 1.3 Inclusions 20 This standard specifies 21 (1) The forms that a program written in the Fortran language may take, 22 (2) The rules for interpreting the meaning of a program and its data, 23 (3) The form of the input data to be processed by such a program, and 24 (4) The form of the output data resulting from the use of such a program. 25 1.4 Exclusions 26 This standard does not specify 27 (1) The mechanism by which programs are transformed for use on computing systems, 28 (2) The operations required for setup and control of the use of programs on computing systems, 29 (3) The method of transcription of programs or their input or output data to or from a storage 30 medium, 31 (4) The program and processor behavior when this standard fails to establish an interpretation 32 except for the processor detection and reporting requirements in items (2) through (8) of MAY 2002 WORKING DRAFT 1 J3/02-007R2 WORKING DRAFT MAY 2002 1 1.5, 2 (5) The size or complexity of a program and its data that will exceed the capacity of any 3 particular computing system or the capability of a particular processor, 4 (6) The physical properties of the representation of quantities and the method of rounding, 5 approximating, or computing numeric values on a particular processor, 6 (7) The physical properties of input/output records, files, and units, or 7 (8) The physical properties and implementation of storage. 8 1.5 Conformance 9 A program (2.2.1) is a standard-conforming program if it uses only those forms and relationships 10 described herein and if the program has an interpretation according to this standard. A program unit 11 (2.2) conforms to this standard if it can be included in a program in a manner that allows the program 12 to be standard conforming. 13 A processor conforms to this standard if 14 (1) It executes any standard-conforming program in a manner that fulfills the interpretations 15 herein, subject to any limits that the processor may impose on the size and complexity of 16 the program; 17 (2) It contains the capability to detect and report the use within a submitted program unit of 18 a form designated herein as obsolescent, insofar as such use can be detected by reference to 19 the numbered syntax rules and constraints; 20 (3) It contains the capability to detect and report the use within a submitted program unit of 21 an additional form or relationship that is not permitted by the numbered syntax rules or 22 constraints, including the deleted features described in Annex B; 23 (4) It contains the capability to detect and report the use within a submitted program unit of 24 kind type parameter values (4.4) not supported by the processor; 25 (5) It contains the capability to detect and report the use within a submitted program unit of 26 source form or characters not permitted by Section 3; 27 (6) It contains the capability to detect and report the use within a submitted program of name 28 usage not consistent with the scope rules for names, labels, operators, and assignment 29 symbols in Section 16; 30 (7) It contains the capability to detect and report the use within a submitted program unit of 31 intrinsic procedures whose names are not defined in Section 13; and 32 (8) It contains the capability to detect and report the reason for rejecting a submitted program. 33 However, in a format specification that is not part of a FORMAT statement (10.1.1), a processor need not 34 detect or report the use of deleted or obsolescent features, or the use of additional forms or relationships. 35 A standard-conforming processor may allow additional forms and relationships provided that such ad- 36 ditions do not conflict with the standard forms and relationships. However, a standard-conforming 37 processor may allow additional intrinsic procedures even though this could cause a conflict with the 38 name of a procedure in a standard-conforming program. If such a conflict occurs and involves the name 39 of an external procedure, the processor is permitted to use the intrinsic procedure unless the name is 40 given the EXTERNAL attribute (5.1.2.6) in the scoping unit (16). A standard-conforming program 41 shall not use nonstandard intrinsic procedures or modules that have been added by the processor. 42 Because a standard-conforming program may place demands on a processor that are not within the 43 scope of this standard or may include standard items that are not portable, such as external procedures 44 defined by means other than Fortran, conformance to this standard does not ensure that a program will 45 execute consistently on all or any standard-conforming processors. 2 WORKING DRAFT MAY 2002 MAY 2002 WORKING DRAFT J3/02-007R2 1 In some cases, this standard allows the provision of facilities that are not completely specified in the 2 standard. These facilities are identified as processor dependent. They shall be provided, with methods 3 or semantics determined by the processor. NOTE 1.1 The processor should be accompanied by documentation that specifies the limits it imposes on the size and complexity of a program and the means of reporting when these limits are exceeded, that defines the additional forms and relationships it allows, and that defines the means of reporting the use of additional forms and relationships and the use of deleted or obsolescent forms. In this context, the use of a deleted form is the use of an additional form. The processor should be accompanied by documentation that specifies the methods or semantics of processor-dependent facilities. 4 1.6 Compatibility 5 Each standard since ISO 1539:1980 (informally referred to as Fortran 77), defines more intrinsic 6 procedures than the previous one. Therefore, a Fortran program conforming to an older standard may 7 have a different interpretation under a newer standard if it invokes an external procedure having the 8 same name as one of the new standard intrinsic procedures, unless that procedure is specified to have 9 the EXTERNAL attribute. 10 1.6.1 Fortran 95 compatibility 11 Except as identified in this section, this standard is an upward compatible extension to the preceding 12 Fortran International Standard, ISO/IEC 1539:1997 (Fortran 95). Any standard-conforming Fortran 95 13 program remains standard-conforming under this standard. The following Fortran 95 features may have 14 different interpretations in this standard: 15 (1) Earlier Fortran standards had the concept of printing, meaning that column one of format- 16 ted output had special meaning for a processor-dependent (possibly empty) set of logical 17 units. This could be neither detected nor specified by a standard-specified means. The 18 interpretation of the first column is not specified by this standard. 19 (2) This standard specifies a different output format for real zero values in list-directed and 20 namelist output. 21 1.6.2 Fortran 90 compatibility 22 Except for the deleted features noted in Annex B.1, and except as identified in this section, this stan- 23 dard is an upward compatible extension to ISO/IEC 1539:1991 (Fortran 90). Any standard-conforming 24 Fortran 90 program that does not use one of the deleted features remains standard-conforming under 25 this standard. 26 The PAD= specifier in the INQUIRE statement in this standard returns the value UNDEFINED if there 27 is no connection or the connection is for unformatted input/output. Fortran 90 specified YES. 28 Fortran 90 specified that if the second argument to MOD or MODULO was zero, the result was processor 29 dependent. This standard specifies that the second argument shall not be zero. 30 1.6.3 FORTRAN 77 compatibility 31 Except for the deleted features noted in Annex B.1, and except as identified in this section, this standard 32 is an upward compatible extension to ISO 1539:1980 (Fortran 77). Any standard-conforming For- 33 tran 77 program that does not use one of the deleted features noted in Annex B.1 and that does not MAY 2002 WORKING DRAFT 3 J3/02-007R2 WORKING DRAFT MAY 2002 1 depend on the differences specified here remains standard conforming under this standard. This stan- 2 dard restricts the behavior for some features that were processor dependent in Fortran 77. Therefore, 3 a standard-conforming Fortran 77 program that uses one of these processor-dependent features may 4 have a different interpretation under this standard, yet remain a standard-conforming program. The 5 following Fortran 77 features may have different interpretations in this standard: 6 (1) Fortran 77 permitted a processor to supply more precision derived from a real constant 7 than can be represented in a real datum when the constant is used to initialize a data 8 object of type double precision real in a DATA statement. This standard does not permit 9 a processor this option. 10 (2) If a named variable that was not in a common block was initialized in a DATA statement and 11 did not have the SAVE attribute specified, Fortran 77 left its SAVE attribute processor 12 dependent. This standard specifies (5.2.5) that this named variable has the SAVE attribute. 13 (3) Fortran 77 specified that the number of characters required by the input list was to be 14 less than or equal to the number of characters in the record during formatted input. This 15 standard specifies (9.5.3.4.2) that the input record is logically padded with blanks if there 16 are not enough characters in the record, unless the PAD= specifier with the value 'NO' is 17 specified in an appropriate OPEN or READ statement. 18 (4) A value of 0 for a list item in a formatted output statement will be formatted in a differ- 19 ent form for some G edit descriptors. In addition, this standard specifies how rounding of 20 values will affect the output field form, but Fortran 77 did not address this issue. There- 21 fore, some Fortran 77 processors may produce an output form different from the output 22 form produced by Fortran 2000 processors for certain combinations of values and G edit 23 descriptors. 24 (5) If the processor can distinguish between positive and negative real zero, the behavior of the 25 SIGN intrinsic function when the second argument is negative real zero is changed by this 26 standard. 27 1.7 Notation used in this standard 28 In this standard, "shall" is to be interpreted as a requirement; conversely, "shall not" is to be interpreted 29 as a prohibition. Except where stated otherwise, such requirements and prohibitions apply to programs 30 rather than processors. 31 1.7.1 Informative notes 32 Informative notes of explanation, rationale, examples, and other material are interspersed with the 33 normative body of this publication. The informative material is nonnormative; it is identified by being 34 in shaded, framed boxes that have numbered headings beginning with "NOTE." 35 1.7.2 Syntax rules 36 Syntax rules describe the forms that Fortran lexical tokens, statements, and constructs may take. These 37 syntax rules are expressed in a variation of Backus-Naur form (BNF) in which: 38 (1) Characters from the Fortran character set (3.1) are interpreted literally as shown, except 39 where otherwise noted. 40 (2) Lower-case italicized letters and words (often hyphenated and abbreviated) represent gen- 41 eral syntactic classes for which particular syntactic entities shall be substituted in actual 42 statements. 4 WORKING DRAFT MAY 2002 MAY 2002 WORKING DRAFT J3/02-007R2 1 Common abbreviations used in syntactic terms are: arg for argument attr for attribute decl for declaration def for definition desc for descriptor expr for expression int for integer op for operator spec for specifier stmt for statement 2 (3) The syntactic metasymbols used are: is introduces a syntactic class definition or introduces a syntactic class alternative [ ] encloses an optional item [ ] ... encloses an optionally repeated item that may occur zero or more times continues a syntax rule 3 (4) Each syntax rule is given a unique identifying number of the form Rsnn, where s is a one- 4 or two-digit section number and nn is a two-digit sequence number within that section. 5 The syntax rules are distributed as appropriate throughout the text, and are referenced by 6 number as needed. Some rules in Sections 2 and 3 are more fully described in later sections; 7 in such cases, the section number s is the number of the later section where the rule is 8 repeated. 9 (5) The syntax rules are not a complete and accurate syntax description of Fortran, and cannot 10 be used to generate a Fortran parser automatically; where a syntax rule is incomplete, it is 11 restricted by corresponding constraints and text. NOTE 1.2 An example of the use of the syntax rules is: digit-string is digit [ digit ] ... The following are examples of forms for a digit string allowed by the above rule: digit digit digit digit digit digit digit digit digit digit digit digit digit digit digit If particular entities are substituted for digit , actual digit strings might be: 4 67 1999 10243852 12 1.7.3 Constraints 13 Each constraint is given a unique identifying number of the form Csnn, where s is a one- or two-digit 14 section number and nn is a two-digit sequence number within that section. 15 Often a constraint is associated with a particular syntax rule. Where that is the case, the constraint is 16 annotated with the syntax rule number in parentheses. A constraint that is associated with a syntax 17 rule constitutes part of the definition of the syntax term defined by the rule. It thus applies in all places MAY 2002 WORKING DRAFT 5 J3/02-007R2 WORKING DRAFT MAY 2002 1 where the syntax term appears. 2 Some constraints are not associated with particular syntax rules. The effect of such a constraint is similar 3 to that of a restriction stated in the text, except that a processor is required to have the capability to 4 detect and report violations of constraints (1.5). In some cases, a broad requirement is stated in text 5 and a subset of the same requirement is also stated as a constraint. This indicates that a standard- 6 conforming program is required to adhere to the broad requirement, but that a standard-conforming 7 processor is required only to have the capability of diagnosing violations of the constraint. 8 1.7.4 Assumed syntax rules 9 In order to minimize the number of additional syntax rules and convey appropriate constraint informa- 10 tion, the following rules are assumed; an explicit syntax rule for a term overrides an assumed rule. The 11 letters "xyz " stand for any syntactic class phrase: 12 R101 xyz-list is xyz [ , xyz ] ... 13 R102 xyz-name is name 14 R103 scalar-xyz is xyz 15 C101 (R103) scalar-xyz shall be scalar. 16 1.7.5 Syntax conventions and characteristics 17 (1) Any syntactic class name ending in "-stmt " follows the source form statement rules: it shall 18 be delimited by end-of-line or semicolon, and may be labeled unless it forms part of another 19 statement (such as an IF or WHERE statement). Conversely, everything considered to be 20 a source form statement is given a "-stmt " ending in the syntax rules. 21 (2) The rules on statement ordering are described rigorously in the definition of program-unit 22 (R202). Expression hierarchy is described rigorously in the definition of expr (R722). 23 (3) The suffix "-spec" is used consistently for specifiers, such as input/output statement speci- 24 fiers. It also is used for type declaration attribute specifications (for example, "array-spec" 25 in R515), and in a few other cases. 26 (4) Where reference is made to a type parameter, including the surrounding parentheses, the 27 suffix "-selector " is used. See, for example, "kind-selector " (R507) and "length-selector " 28 (R511). 29 (5) The term "subscript " (for example, R618, R619, and R620) is used consistently in array 30 definitions. 31 1.7.6 Text conventions 32 In the descriptive text, an equivalent English word is frequently used in place of a syntactic term. 33 Particular statements and attributes are identified in the text by an upper-case keyword, e.g., "END 34 statement". Boldface words are used in the text where they are first defined with a specialized meaning. 35 The descriptions of obsolescent features appear in a smaller type size. NOTE 1.3 This sentence is an example of the type size used for obsolescent features. 36 1.8 Deleted and obsolescent features 37 This standard protects the users' investment in existing software by including all but five of the language 38 elements of Fortran 90 that are not processor dependent. This standard identifies two categories of 39 outmoded features. There are five in the first category, deleted features, which consists of features 40 considered to have been redundant in Fortran 77 and largely unused in Fortran 90. Those in the second 6 WORKING DRAFT MAY 2002 MAY 2002 WORKING DRAFT J3/02-007R2 1 category, obsolescent features, are considered to have been redundant in Fortran 90 and Fortran 95, 2 but are still frequently used. 3 1.8.1 Nature of deleted features 4 (1) Better methods existed in Fortran 77. 5 (2) These features are not included in Fortran 95 or this revision of Fortran. 6 1.8.2 Nature of obsolescent features 7 (1) Better methods existed in Fortran 90 and Fortran 95. 8 (2) It is recommended that programmers use these better methods in new programs and convert 9 existing code to these methods. 10 (3) These features are identified in the text of this document by a distinguishing type font 11 (1.7.6). 12 (4) If the use of these features becomes insignificant, future Fortran standards committees should 13 consider deleting them. 14 (5) The next Fortran standards committee should consider for deletion only those language 15 features that appear in the list of obsolescent features. 16 (6) Processors supporting the Fortran language should support these features as long as they 17 continue to be used widely in Fortran programs. 18 1.9 Normative references 19 The following standards contain provisions which, through reference in this standard, constitute provi- 20 sions of this standard. At the time of publication, the editions indicated were valid. All standards are 21 subject to revision, and parties to agreements based on this standard are encouraged to investigate the 22 possibility of applying the most recent editions of the standards indicated below. Members of IEC and 23 ISO maintain registers of currently valid International Standards. 24 ISO/IEC 646:1991, Information technology--ISO 7-bit coded character set for information interchange. 25 ISO/IEC 646:1991 (International Reference Version) is the international equivalent of ANSI X3.4-1986, 26 commonly known as ASCII. This standard refers to it as the ASCII standard. 27 ISO 8601:1988, Data elements and interchange formats--Information interchange-- 28 Representation of dates and times. 29 ISO/IEC 9989:1999, Information technology--Programming languages--C. 30 This standard refers to ISO/IEC 9899:1999 as the C standard. 31 ISO/IEC 10646-1:2000, Information technology--Universal multiple-octet coded character set (UCS)-- 32 Part 1: Architecture and basic multilingual plane. 33 IEC 60559 (1989-01), Binary floating-point arithmetic for microprocessor systems. 34 Since IEC 60559 (1989-01) was originally IEEE 754-1985, Standard for binary floating-point arithmetic, 35 and is widely known by this name, this standard refers to it as the IEEE standard. MAY 2002 WORKING DRAFT 7 J3/02-007R2 WORKING DRAFT MAY 2002 8 WORKING DRAFT MAY 2002 MAY 2002 WORKING DRAFT J3/02-007R2 1 Section 2: Fortran terms and concepts 2 2.1 High level syntax 3 This section introduces the terms associated with program units and other Fortran concepts above the 4 construct, statement, and expression levels and illustrates their relationships. The notation used in this 5 standard is described in 1.7. NOTE 2.1 Constraints and other information related to the rules that do not begin with R2 appear in the appropriate section. 6 R201 program is program-unit 7 [ program-unit ] ... 8 A program shall contain exactly one main-program program-unit or a main program defined by means 9 other than Fortran, but not both. 10 R202 program-unit is main-program 11 or external-subprogram 12 or module 13 or block-data 14 R1101 main-program is [ program-stmt ] 15 [ specification-part ] 16 [ execution-part ] 17 [ internal-subprogram-part ] 18 end-program-stmt 19 R203 external-subprogram is function-subprogram 20 or subroutine-subprogram 21 R1223 function-subprogram is function-stmt 22 [ specification-part ] 23 [ execution-part ] 24 [ internal-subprogram-part ] 25 end-function-stmt 26 R1230 subroutine-subprogram is subroutine-stmt 27 [ specification-part ] 28 [ execution-part ] 29 [ internal-subprogram-part ] 30 end-subroutine-stmt 31 R1104 module is module-stmt 32 [ specification-part ] 33 [ module-subprogram-part ] 34 end-module-stmt 35 R1116 block-data is block-data-stmt 36 [ specification-part ] 37 end-block-data-stmt 38 R204 specification-part is [ use-stmt ] ... 39 [ import-stmt ] ... 40 [ implicit-part ] 41 [ declaration-construct ] ... MAY 2002 WORKING DRAFT 9 J3/02-007R2 WORKING DRAFT MAY 2002 1 R205 implicit-part is [ implicit-part-stmt ] ... 2 implicit-stmt 3 R206 implicit-part-stmt is implicit-stmt 4 or parameter-stmt 5 or format-stmt 6 or entry-stmt 7 R207 declaration-construct is derived-type-def 8 or entry-stmt 9 or enum-alias-def 10 or format-stmt 11 or interface-block 12 or parameter-stmt 13 or procedure-declaration-stmt 14 or specification-stmt 15 or type-alias-stmt 16 or type-declaration-stmt 17 or stmt-function-stmt 18 R208 execution-part is executable-construct 19 [ execution-part-construct ] ... 20 R209 execution-part-construct is executable-construct 21 or format-stmt 22 or entry-stmt 23 or data-stmt 24 R210 internal-subprogram-part is contains-stmt 25 internal-subprogram 26 [ internal-subprogram ] ... 27 R211 internal-subprogram is function-subprogram 28 or subroutine-subprogram 29 R1107 module-subprogram-part is contains-stmt 30 module-subprogram 31 [ module-subprogram ] ... 32 R1108 module-subprogram is function-subprogram 33 or subroutine-subprogram 34 R212 specification-stmt is access-stmt 35 or allocatable-stmt 36 or asynchronous-stmt 37 or bind-stmt 38 or common-stmt 39 or data-stmt 40 or dimension-stmt 41 or equivalence-stmt 42 or external-stmt 43 or intent-stmt 44 or intrinsic-stmt 45 or namelist-stmt 46 or optional-stmt 47 or pointer-stmt 48 or protected-stmt 49 or save-stmt 50 or target-stmt 51 or volatile-stmt 52 or value-stmt 53 R213 executable-construct is action-stmt 54 or associate-construct 10 WORKING DRAFT MAY 2002 MAY 2002 WORKING DRAFT J3/02-007R2 1 or case-construct 2 or do-construct 3 or forall-construct 4 or if-construct 5 or select-type-construct 6 or where-construct 7 R214 action-stmt is allocate-stmt 8 or assignment-stmt 9 or backspace-stmt 10 or call-stmt 11 or close-stmt 12 or continue-stmt 13 or cycle-stmt 14 or deallocate-stmt 15 or endfile-stmt 16 or end-function-stmt 17 or end-program-stmt 18 or end-subroutine-stmt 19 or exit-stmt 20 or flush-stmt 21 or forall-stmt 22 or goto-stmt 23 or if-stmt 24 or inquire-stmt 25 or nullify-stmt 26 or open-stmt 27 or pointer-assignment-stmt 28 or print-stmt 29 or read-stmt 30 or return-stmt 31 or rewind-stmt 32 or stop-stmt 33 or wait-stmt 34 or where-stmt 35 or write-stmt 36 or arithmetic-if-stmt 37 or computed-goto-stmt 38 C201 (R208) An execution-part shall not contain an end-function-stmt , end-program-stmt , or end- 39 subroutine-stmt . 40 2.2 Program unit concepts 41 Program units are the fundamental components of a Fortran program. A program unit may be 42 a main program, an external subprogram, a module, or a block data program unit. A subprogram 43 may be a function subprogram or a subroutine subprogram. A module contains definitions that are 44 to be made accessible to other program units. A block data program unit is used to specify initial 45 values for data objects in named common blocks. Each type of program unit is described in Section 46 11 or 12. An external subprogram is a subprogram that is not in a main program, a module, or 47 another subprogram. An internal subprogram is a subprogram that is in a main program or another 48 subprogram. A module subprogram is a subprogram that is in a module but is not an internal 49 subprogram. 50 A program unit consists of a set of nonoverlapping scoping units. A scoping unit is MAY 2002 WORKING DRAFT 11 J3/02-007R2 WORKING DRAFT MAY 2002 1 (1) A program unit or subprogram, excluding any scoping units in it, 2 (2) A derived-type definition (4.5.1), or 3 (3) An interface body, excluding any scoping units in it. 4 A scoping unit that immediately surrounds another scoping unit is called the host scoping unit (often 5 abbreviated to host). 6 2.2.1 Program 7 A program consists of exactly one main program, any number (including zero) of other kinds of program 8 units, and any number (including zero) of external procedures and other entities defined by means other 9 than Fortran. NOTE 2.2 There is a restriction that there shall be no more than one unnamed block data program unit (11.3). This standard places no ordering requirement on the program units that constitute a program, but since the public portions of a module are required to be available by the time a module reference (11.2.1) is processed, a processor may require a particular order of processing of the program units. 10 2.2.2 Main program 11 The Fortran main program is described in 11.1. 12 2.2.3 Procedure 13 A procedure encapsulates an arbitrary sequence of actions that may be invoked directly during program 14 execution. Procedures are either functions or subroutines. A function is a procedure that is invoked 15 in an expression; its invocation causes a value to be computed which is then used in evaluating the 16 expression. The variable that returns the value of a function is called the result variable. A subroutine 17 is a procedure that is invoked in a CALL statement, by a defined assignment statement, or by some 18 operations on derived-type entities. Unless it is a pure procedure, a subroutine may be used to change 19 the program state by changing the values of any of the data objects accessible to the subroutine; unless 20 it is a pure procedure, a function may do this in addition to computing the function value. 21 Procedures are described further in Section 12. 22 2.2.3.1 External procedure 23 An external procedure is a procedure that is defined by an external subprogram or by means other 24 than Fortran. An external procedure may be invoked by the main program or by any procedure of a 25 program. 26 2.2.3.2 Module procedure 27 A module procedure is a procedure that is defined by a module subprogram (R1108). A module 28 procedure may be invoked by another module subprogram in the module or by any scoping unit that 29 accesses the module procedure by use association (11.2.2). The module containing the subprogram is 30 the host scoping unit of the module procedure. 31 2.2.3.3 Internal procedure 32 An internal procedure is a procedure that is defined by an internal subprogram (R211). The containing 33 main program or subprogram is the host scoping unit of the internal procedure. An internal procedure 12 WORKING DRAFT MAY 2002 MAY 2002 WORKING DRAFT J3/02-007R2 1 is local to its host in the sense that the internal procedure is accessible within the host scoping unit and 2 all its other internal procedures but is not accessible elsewhere. 3 2.2.3.4 Interface bodies and interface blocks 4 An interface body describes a procedure interface. The name of an interface body may be used 5 to specify the interface of a dummy procedure, external procedure, procedure pointer, or type-bound 6 procedure. 7 An interface block is either a specific interface block or a generic interface block. A specific interface 8 block is simply a collection of interface bodies. A generic interface block may also be used to specify 9 that procedures may be invoked 10 (1) By using a generic name, 11 (2) By using a defined operator, 12 (3) By using a defined assignment, or 13 (4) For derived-type input/output. 14 2.2.4 Module 15 A module contains (or accesses from other modules) definitions that are to be made accessible to other 16 program units. These definitions include data object declarations, type definitions, procedure definitions, 17 and interface blocks. A scoping unit in another program unit may access the definitions in a module. 18 Modules are further described in Section 11. 19 2.3 Execution concepts 20 Each Fortran statement is classified as either an executable statement or a nonexecutable statement. 21 There are restrictions on the order in which statements may appear in a program unit, and not all 22 executable statements may appear in all contexts. 23 2.3.1 Executable/nonexecutable statements 24 Program execution is a sequence, in time, of actions. An executable statement is an instruction to 25 perform or control one or more of these actions. Thus, the executable statements of a program unit 26 determine the behavior of the program unit. The executable statements are all of those that make up 27 the syntactic class executable-construct . 28 Nonexecutable statements do not specify actions; they are used to configure the program environment 29 in which actions take place. The nonexecutable statements are all those not classified as executable. 30 2.3.2 Statement order 31 The syntax rules of subclause 2.1 specify the statement order within program units and subprograms. 32 These rules are illustrated in Table 2.1 and Table 2.2. Table 2.1 shows the ordering rules for state- 33 ments and applies to all program units and subprograms. Vertical lines delineate varieties of statements 34 that may be interspersed and horizontal lines delineate varieties of statements that shall not be in- 35 terspersed. Internal or module subprograms shall follow a CONTAINS statement. Between USE and 36 CONTAINS statements in a subprogram, nonexecutable statements generally precede executable state- 37 ments, although the ENTRY statement, FORMAT statement, and DATA statement may appear among 38 the executable statements. Table 2.2 shows which statements are allowed in a scoping unit. MAY 2002 WORKING DRAFT 13 J3/02-007R2 WORKING DRAFT MAY 2002 Table 2.1: Requirements on statement ordering PROGRAM, FUNCTION, SUBROUTINE, MODULE, or BLOCK DATA statement USE statements IMPORT statements IMPLICIT NONE PARAMETER IMPLICIT statements statements Derived-type definitions, FORMAT interface blocks, and PARAMETER type declaration statements, ENTRY and DATA type alias definitions, statements statements enumeration declarations, procedure declarations, specification statements, and statement function statements DATA Executable statements constructs CONTAINS statement Internal subprograms or module subprograms END statement Table 2.2: Statements allowed in scoping units Kind of scoping unit: Main Module Block External Module Internal Interface program data subprog subprog subprog body USE statement Yes Yes Yes Yes Yes Yes Yes IMPORT statement No No No No No No Yes ENTRY statement No No No Yes Yes No No FORMAT statement Yes No No Yes Yes Yes No Misc. decls (see note) Yes Yes Yes Yes Yes Yes Yes DATA statement Yes Yes Yes Yes Yes Yes No Derived-type definition Yes Yes Yes Yes Yes Yes Yes Interface block Yes Yes No Yes Yes Yes Yes Executable statement Yes No No Yes Yes Yes No CONTAINS statement Yes Yes No Yes Yes No No Statement function statement Yes No No Yes Yes Yes No Notes for Table 2.2: 1) Misc. declarations are PARAMETER statements, IMPLICIT statements, type declaration statements, type alias statements, enum statements, procedure declara- tion statements, and specification statements. 2) The scoping unit of a module does not include any module subprograms that the module contains. 1 2.3.3 The END statement 2 An end-program-stmt , end-function-stmt , end-subroutine-stmt , end-module-stmt , or end-block-data-stmt 3 is an END statement. Each program unit, module subprogram, and internal subprogram shall have 4 exactly one END statement. The end-program-stmt , end-function-stmt , and end-subroutine-stmt state- 5 ments are executable, and may be branch target statements (8.2). Executing an end-program-stmt causes 14 WORKING DRAFT MAY 2002 MAY 2002 WORKING DRAFT J3/02-007R2 1 normal termination of execution of the program. Executing an end-function-stmt or end-subroutine-stmt 2 is equivalent to executing a return-stmt with no scalar-int-expr. 3 The end-module-stmt and end-block-data-stmt statements are nonexecutable. 4 2.3.4 Execution sequence 5 If a program contains a Fortran main program, execution of the program begins with the first executable 6 construct of the main program. The execution of a main program or subprogram involves execution of 7 the executable constructs within its scoping unit. When a procedure is invoked, execution begins with 8 the first executable construct appearing after the invoked entry point. With the following exceptions, 9 the effect of execution is as if the executable constructs are executed in the order in which they appear 10 in the main program or subprogram until a STOP, RETURN, or END statement is executed. The 11 exceptions are the following: 12 (1) Execution of a branching statement (8.2) changes the execution sequence. These statements 13 explicitly specify a new starting place for the execution sequence. 14 (2) CASE constructs, DO constructs, IF constructs, and SELECT TYPE constructs contain 15 an internal statement structure and execution of these constructs involves implicit internal 16 branching. See Section 8 for the detailed semantics of each of these constructs. 17 (3) END=, ERR=, and EOR= specifiers may result in a branch. 18 (4) Alternate returns may result in a branch. 19 Internal subprograms may precede the END statement of a main program or a subprogram. The 20 execution sequence excludes all such definitions. 21 Normal termination of execution of the program occurs if a STOP statement or end-program-stmt is 22 executed. Normal termination of execution of a program also may occur during execution of a procedure 23 defined by a companion processor (C standard 5.1.2.2.3 and 7.20.4.3). If normal termination of execution 24 occurs within a Fortran program unit and the program incorporates procedures defined by a companion 25 processor, the process of execution termination shall include the effect of executing the C exit() function 26 (C standard 7.20.4.3). 27 2.4 Data concepts 28 Nonexecutable statements are used to specify the characteristics of the data environment. This includes 29 typing variables, declaring arrays, and defining new types. 30 2.4.1 Type 31 A type is a named category of data that is characterized by a set of values, a syntax for denoting 32 these values, and a set of operations that interpret and manipulate the values. This central concept is 33 described in 4.1. 34 A type may be parameterized, in which case the set of data values, the syntax for denoting them, and 35 the set of operations depend on the values of one or more parameters. Such a parameter is called a type 36 parameter (4.2). 37 There are two categories of types: intrinsic types and derived types. 38 2.4.1.1 Intrinsic type 39 An intrinsic type is a type that is defined by the language, along with operations, and is always 40 accessible. The intrinsic types are integer, real, complex, character, and logical. The properties of 41 intrinsic types are described in 4.4. The intrinsic type parameters are KIND and LEN. MAY 2002 WORKING DRAFT 15 J3/02-007R2 WORKING DRAFT MAY 2002 1 The kind type parameter indicates the decimal exponent range for the integer type (4.4.1), the 2 decimal precision and exponent range for the real and complex types (4.4.2, 4.4.3), and the representation 3 methods for the character and logical types (4.4.4, 4.4.5). The character length parameter specifies 4 the number of characters for the character type. 5 2.4.1.2 Derived type 6 A derived type is a type that is not defined by the language but requires a type definition to declare 7 components of intrinsic or of other derived types. A scalar object of such a derived type is called a 8 structure (5.1.1.7). Derived types may be parameterized. Assignment of structures is defined intrin- 9 sically (7.4.1.3), but there are no intrinsic operations for structures. For each derived type, a structure 10 constructor is available to provide values (4.5.8). In addition, data objects of derived type may be 11 used as procedure arguments and function results, and may appear in input/output lists. If additional 12 operations are needed for a derived type, they shall be supplied as procedure definitions. 13 Derived types are described further in 4.5. 14 2.4.2 Data value 15 Each intrinsic type has associated with it a set of values that a datum of that type may take, depending 16 on the values of the type parameters. The values for each intrinsic type are described in 4.4. The values 17 that objects of a derived type may assume are determined by the type definition, type parameter values, 18 and the sets of values of its components. 19 2.4.3 Data entity 20 A data entity is a data object, the result of the evaluation of an expression, or the result of the execution 21 of a function reference (called the function result). A data entity has a type and type parameters; it 22 may have a data value (an exception is an undefined variable). Every data entity has a rank and is thus 23 either a scalar or an array. 24 2.4.3.1 Data object 25 A data object (often abbreviated to object) is a constant (4.1.2), a variable (6), or a subobject of a 26 constant. The type and type parameters of a named data object may be specified explicitly (5.1) or 27 implicitly (5.3). 28 Subobjects are portions of certain objects that may be referenced and defined (variables only) inde- 29 pendently of the other portions. These include portions of arrays (array elements and array sections), 30 portions of character strings (substrings), portions of complex objects (real and imaginary parts), and 31 portions of structures (components). Subobjects are themselves data objects, but subobjects are refer- 32 enced only by object designators or intrinsic functions. A subobject of a variable is a variable. Subobjects 33 are described in Section 6. 34 Objects referenced by a name are: a named scalar (a scalar object) 35 a named array (an array object) 36 Subobjects referenced by an object designator are: an array element (a scalar subobject) an array section (an array subobject) a structure component (a scalar or an array subobject) 37 a substring (a scalar subobject) 16 WORKING DRAFT MAY 2002 MAY 2002 WORKING DRAFT J3/02-007R2 1 Subobjects of complex objects may also be referenced by intrinsic functions. 2 2.4.3.1.1 Variable 3 A variable may have a value and may be defined and redefined during execution of a program. 4 A named local variable of the scoping unit of a module, main program, or subprogram, is a variable 5 that is a local entity of the scoping unit, is not a dummy argument, is not in COMMON, does not 6 have the BIND attribute, and is not accessed by use or host association. A subobject of a named local 7 variable is also a local variable. 8 2.4.3.1.2 Constant 9 A constant has a value and cannot become defined, redefined, or undefined during execution of a 10 program. A constant with a name is called a named constant and has the PARAMETER attribute 11 (5.1.2.10). A constant without a name is called a literal constant (4.4). 12 2.4.3.1.3 Subobject of a constant 13 A subobject of a constant is a portion of a constant. The portion referenced may depend on the 14 value of a variable. NOTE 2.3 For example, given: CHARACTER (LEN = 10), PARAMETER :: DIGITS = '0123456789' CHARACTER (LEN = 1) :: DIGIT INTEGER :: I ... DIGIT = DIGITS (I:I) DIGITS is a named constant and DIGITS (I:I) designates a subobject of the constant DIGITS. 15 2.4.3.2 Expression 16 An expression (7.1) produces a data entity when evaluated. An expression represents either a data 17 reference or a computation; it is formed from operands, operators, and parentheses. The type, type 18 parameters, value, and rank of an expression result are determined by the rules in Section 7. 19 2.4.3.3 Function reference 20 A function reference (12.4.2) produces a data entity when the function is executed during expression 21 evaluation. The type, type parameters, and rank of a function result are determined by the interface of 22 the function (12.2.2). The value of a function result is determined by execution of the function. 23 2.4.4 Scalar 24 A scalar is a datum that is not an array. Scalars may be of any intrinsic type or derived type. NOTE 2.4 A structure is scalar even if it has arrays as components. 25 The rank of a scalar is zero. The shape of a scalar is represented by a rank-one array of size zero. MAY 2002 WORKING DRAFT 17 J3/02-007R2 WORKING DRAFT MAY 2002 1 2.4.5 Array 2 An array is a set of scalar data, all of the same type and type parameters, whose individual elements 3 are arranged in a rectangular pattern. An array element is one of the individual elements in the array 4 and is a scalar. An array section is a subset of the elements of an array and is itself an array. 5 An array may have up to seven dimensions, and any extent (number of elements) in any dimension. 6 The rank of the array is the number of dimensions; its size is the total number of elements, which is 7 equal to the product of the extents. An array may have zero size. The shape of an array is determined 8 by its rank and its extent in each dimension, and may be represented as a rank-one array whose elements 9 are the extents. All named arrays shall be declared, and the rank of a named array is specified in its 10 declaration. The rank of a named array, once declared, is constant; the extents may be constant or may 11 vary during execution. 12 Two arrays are conformable if they have the same shape. A scalar is conformable with any array. Any 13 intrinsic operation defined for scalar objects may be applied to conformable objects. Such operations 14 are performed element-by-element to produce a resultant array conformable with the array operands. 15 Element-by-element operation means corresponding elements of the operand arrays are involved in a 16 scalar operation to produce the corresponding element in the result array, and all such element operations 17 may be performed in any order or simultaneously. Such an operation is described as elemental. 18 A rank-one array may be constructed from scalars and other arrays and may be reshaped into any 19 allowable array shape (4.8). 20 Arrays may be of any intrinsic type or derived type and are described further in 6.2. 21 2.4.6 Pointer 22 A data pointer is a data entity that has the POINTER attribute. A procedure pointer is a procedure 23 entity that has the POINTER attribute. A pointer is either a data pointer or a procedure pointer. 24 A pointer is associated with a target by pointer assignment (7.4.2). A data pointer may also be 25 associated with a target by allocation (6.3.1). A pointer is disassociated following execution of a 26 NULLIFY statement, following pointer assignment with a disassociated pointer, by default initialization, 27 or by explicit initialization. A data pointer may also be disassociated by execution of a DEALLOCATE 28 statement. A disassociated pointer is not associated with a target (16.4.2). 29 A pointer that is not associated shall not be referenced or defined. 30 If a data pointer is an array, the rank is declared, but the extents are determined when the pointer is 31 associated with a target. 32 2.4.7 Storage 33 Many of the facilities of this standard make no assumptions about the physical storage characteristics of 34 data objects. However, program units that include storage association dependent features shall observe 35 the storage restrictions described in 16.4.3. 36 2.5 Fundamental terms 37 The following terms are defined here and used throughout this standard. 18 WORKING DRAFT MAY 2002 MAY 2002 WORKING DRAFT J3/02-007R2 1 2.5.1 Name and designator 2 A name is used to identify a program constituent, such as a program unit, named variable, named 3 constant, dummy argument, or derived type. The rules governing the construction of names are given 4 in 3.2.1. An object designator is a name followed by zero or more subobject selectors, which are 5 component selectors, array section selectors, array element selectors, and substring selectors. NOTE 2.5 An object name is a special case of an object designator. 6 2.5.2 Keyword 7 The term keyword is used in two ways. 8 (1) It is used to describe a word that is part of the syntax of a statement. These keywords are 9 not reserved words; that is, names with the same spellings are allowed. In the syntax rules, 10 such keywords appear literally. In descriptive text, this meaning is denoted by the term 11 "keyword" without any modifier. Examples of statement keywords are: IF, READ, UNIT, 12 KIND, and INTEGER. 13 (2) It is used to denote names that identify items in a list. In actual argument lists, type 14 parameter lists, and structure constructors, items may be identified by a preceding keyword = 15 rather than their position within the list. An argument keyword is the name of a dummy 16 argument in the interface for the procedure being referenced, a type parameter keyword 17 is the name of a type parameter in the type being specified, and a component keyword 18 is the name of a component in a structure constructor. 19 R215 keyword is name NOTE 2.6 Use of keywords rather than position to identify items in a list can make such lists more readable and allows them to be reordered. This facilitates specification of a list in cases where optional items are omitted. 20 2.5.3 Association 21 Association may be name association (16.4.1), pointer association (16.4.2), or storage association 22 (16.4.3). Name association may be argument association, host association, use association, or construct 23 association. 24 Storage association causes different entities to use the same storage. Any association permits an entity 25 to be identified by different names in the same scoping unit or by the same name or different names in 26 different scoping units. 27 2.5.4 Declaration 28 The term declaration refers to the specification of attributes for various program entities. Often this 29 involves specifying the type of a named data object or specifying the shape of a named array object. 30 2.5.5 Definition 31 The term definition is used in two ways. 32 (1) It refers to the specification of derived types and procedures. 33 (2) When an object is given a valid value during program execution, it is said to become 34 defined. This is often accomplished by execution of an assignment or input statement. MAY 2002 WORKING DRAFT 19 J3/02-007R2 WORKING DRAFT MAY 2002 1 When a variable does not have a predictable value, it is said to be undefined. Similarly, 2 when a pointer is associated with a target or nullified, its pointer association status is said 3 to become defined. When the association status of a pointer is not predictable, its pointer 4 association status is said to be undefined. 5 Section 16 describes the ways in which variables may become defined and undefined. 6 2.5.6 Reference 7 A data object reference is the appearance of the data object designator in a context requiring its 8 value at that point during execution. 9 A procedure reference is the appearance of the procedure designator, operator symbol, or assignment 10 symbol in a context requiring execution of the procedure at that point. An occurrence of user-defined 11 derived-type input/output (10.6.5) or derived-type finalization (4.5.10) is also a procedure reference. 12 The appearance of a data object designator or procedure name in an actual argument list does not 13 constitute a reference to that data object or procedure unless such a reference is necessary to complete 14 the specification of the actual argument. 15 A module reference is the appearance of a module name in a USE statement (11.2.1). 16 2.5.7 Intrinsic 17 The qualifier intrinsic has two meanings. 18 (1) The qualifier signifies that the term to which it is applied is defined in this standard. Intrinsic 19 applies to types, procedures, modules, assignment statements, and operators. All intrinsic 20 types, procedures, and operators may be used in any scoping unit without further definition 21 or specification. Intrinsic modules may be accessed by use association. Intrinsic procedures 22 and modules defined in this standard are called standard intrinsic procedures and standard 23 intrinsic modules, respectively. 24 (2) The qualifier applies to procedures or modules that are provided by a processor but are not 25 defined in this standard (13, 14, 15.1). Such procedures and modules are called nonstandard 26 intrinsic procedures and nonstandard intrinsic modules, respectively. 27 2.5.8 Operator 28 An operator specifies a computation involving one (unary operator) or two (binary operator) data values 29 (operands). This standard specifies a number of intrinsic operators (e.g., the arithmetic operators +, ­, 30 *, /, and ** with numeric operands and the logical operators .AND., .OR., etc. with logical operands). 31 Additional operators may be defined within a program (7.1.3). 32 2.5.9 Sequence 33 A sequence is a set ordered by a one-to-one correspondence with the numbers 1, 2, through n The 34 number of elements in the sequence is n. A sequence may be empty, in which case it contains no 35 elements. 36 The elements of a nonempty sequence are referred to as the first element, second element, etc. The 37 nth element, where n is the number of elements in the sequence, is called the last element. An empty 38 sequence has no first or last element. 20 WORKING DRAFT MAY 2002 MAY 2002 WORKING DRAFT J3/02-007R2 1 2.5.10 Companion processors 2 A processor has one or more companion processors. A companion processor is a processor-dependent 3 mechanism by which global data and procedures may be referenced or defined. A companion processor 4 may be a mechanism that references and defines such entities by a means other than Fortran (12.5.3), 5 it may be the Fortran processor itself, or it may be another Fortran processor. If there is more than 6 one companion processor, the means by which the Fortran processor selects among them are processor 7 dependent. 8 If a procedure is defined by means of a companion processor that is not the Fortran processor itself, 9 this standard refers to the C function that defines the procedure, although the procedure need not be 10 defined by means of the C programming language. NOTE 2.7 A companion processor might or might not be a mechanism that conforms to the requirements of the C standard. For example, a processor may allow a procedure defined by some language other than Fortran or C to be linked (12.5.3) with a Fortran procedure if it can be described by a C prototype as defined in 6.5.5.3 of the C standard. MAY 2002 WORKING DRAFT 21 J3/02-007R2 WORKING DRAFT MAY 2002 22 WORKING DRAFT MAY 2002 MAY 2002 WORKING DRAFT J3/02-007R2 1 Section 3: Characters, lexical tokens, an