WORKING DRAFT J3/02-007 January 14, 2002 15:34 This is an internal working document of J3. JAN 2002 WORKING DRAFT J3/02-007 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.3 The END statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3.4 Execution sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4 Data concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4.1 Data type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4.2 Data value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.3 Data entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.4 Scalar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.5 Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.4.6 Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.4.7 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5 Fundamental terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5.1 Name and designator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.2 Keyword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.3 Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.4 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 JAN 2002 WORKING DRAFT i J3/02-007 WORKING DRAFT JAN 2002 2.5.5 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.6 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.7 Intrinsic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.8 Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.9 Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 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 Data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.1 The concept of data type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.1.1 Set of values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.1.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.1.3 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2 Type parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.3 Relationship of types and values to objects . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4 Intrinsic data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4.1 Integer type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.5.3 Extensible types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.5.4 Component order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.5.5 Type parameter order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.5.6 Derived-type values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.5.7 Derived-type specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.5.8 Construction of derived-type values . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.5.9 Derived-type operations and assignment . . . . . . . . . . . . . . . . . . . . . . . . 59 4.5.10 The finalization process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.6 Type aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.7 Enumerations and enumerators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.8 Construction of array values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5 Data object declarations and specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 ii WORKING DRAFT JAN 2002 JAN 2002 WORKING DRAFT J3/02-007 5.1 Type declaration statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.1.1 Type specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.1.2 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.2 Attribute specification statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.2.1 Accessibility statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.2.2 ALLOCATABLE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.2.3 ASYNCHRONOUS statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.2.4 BIND statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.2.5 DATA statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.2.6 DIMENSION statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.2.7 INTENT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.2.8 OPTIONAL statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.2.9 PARAMETER statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.2.10 POINTER statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.2.11 PROTECTED statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2.12 SAVE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2.13 TARGET statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2.14 VALUE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.2.15 VOLATILE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.3 IMPLICIT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.4 NAMELIST statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.5 Storage association of data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.5.1 EQUIVALENCE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.5.2 COMMON statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 6 Use of data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 6.1 Scalars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 6.1.1 Substrings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 6.1.2 Structure components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 6.1.3 Type parameter inquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.2 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.2.1 Whole arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.2.2 Array elements and array sections . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 6.3 Dynamic association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.3.1 ALLOCATE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.3.2 NULLIFY statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 6.3.3 DEALLOCATE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 7 Expressions and assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 7.1 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 7.1.1 Form of an expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 7.1.2 Intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 7.1.3 Defined operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 7.1.4 Data type, type parameters, and shape of an expression . . . . . . . . . . . . . . . 116 7.1.5 Conformability rules for elemental operations . . . . . . . . . . . . . . . . . . . . . 117 7.1.6 Specification expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 7.1.7 Initialization expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 7.1.8 Evaluation of operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 7.2 Interpretation of intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 7.2.1 Numeric intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 7.2.2 Character intrinsic operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 7.2.3 Relational intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 7.2.4 Logical intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 7.3 Interpretation of defined operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 JAN 2002 WORKING DRAFT iii J3/02-007 WORKING DRAFT JAN 2002 7.3.1 Unary defined operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 7.3.2 Binary defined operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 7.4 Precedence of operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 7.5 Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 7.5.1 Assignment statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 7.5.2 Pointer assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 7.5.3 Masked array assignment - WHERE . . . . . . . . . . . . . . . . . . . . . . . . . . 138 7.5.4 FORALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 8 Execution control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 8.1 Executable constructs containing blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 8.1.1 Rules governing blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 8.1.2 IF construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 8.1.3 CASE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 8.1.4 SELECT TYPE and ASSOCIATE constructs . . . . . . . . . . . . . . . . . . . . . 152 8.1.5 DO construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 8.2 Branching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 8.2.1 GO TO statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 8.2.2 Computed GO TO statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 8.2.3 Arithmetic IF statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 8.3 CONTINUE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 8.4 STOP statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 9 Input/output statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 9.1 Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 9.1.1 Formatted record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 9.1.2 Unformatted record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 9.1.3 Endfile record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 9.2 External files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 9.2.1 File existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 9.2.2 File access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 9.2.3 File position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 9.2.4 File storage units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 9.3 Internal files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 9.4 File connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 9.4.1 Connection modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 9.4.2 Unit existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 9.4.3 Connection of a file to a unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 9.4.4 Preconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 9.4.5 The OPEN statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 9.4.6 The CLOSE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 9.5 Data transfer statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 9.5.1 Control information list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 9.5.2 Data transfer input/output list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 9.5.3 Execution of a data transfer input/output statement . . . . . . . . . . . . . . . . . 185 9.5.4 Termination of data transfer statements . . . . . . . . . . . . . . . . . . . . . . . . 195 9.6 Waiting on pending data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 9.6.1 WAIT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 9.6.2 Wait operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 9.7 File positioning statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 9.7.1 BACKSPACE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 9.7.2 ENDFILE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 9.7.3 REWIND statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 9.8 File inquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 iv WORKING DRAFT JAN 2002 JAN 2002 WORKING DRAFT J3/02-007 9.8.1 Inquiry specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 9.8.2 Restrictions on inquiry specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 9.8.3 Inquire by output list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 9.9 Error, end-of-record, and end-of-file conditions . . . . . . . . . . . . . . . . . . . . . . . . 205 9.9.1 Error conditions and the ERR= specifier . . . . . . . . . . . . . . . . . . . . . . . 206 9.9.2 End-of-file conditions and the END= specifier . . . . . . . . . . . . . . . . . . . . . 206 9.9.3 End-of-record conditions and the EOR= specifier . . . . . . . . . . . . . . . . . . . 207 9.9.4 IOSTAT= specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9.9.5 IOMSG= specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 9.10 Restriction on input/output statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 10 Input/output editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 10.1 Explicit format specification methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 10.1.1 FORMAT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 10.1.2 Character format specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 10.2 Form of a format item list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 10.2.1 Edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 10.2.2 Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 10.3 Interaction between input/output list and format . . . . . . . . . . . . . . . . . . . . . . . 212 10.4 Positioning by format control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 10.5 Decimal symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 10.6 Data edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 10.6.1 Numeric editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 10.6.2 Logical editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 10.6.3 Character editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 10.6.4 Generalized editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 10.6.5 User-defined derived-type editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 10.7 Control edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 10.7.1 Position editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 10.7.2 Slash editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 10.7.3 Colon editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 10.7.4 SS, SP, and S editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 10.7.5 P editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 10.7.6 BN and BZ editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 10.7.7 RU, RD, RZ, RN, RC, and RP editing . . . . . . . . . . . . . . . . . . . . . . . . . 225 10.7.8 DC and DP editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 10.8 Character string edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 10.9 List-directed formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 10.9.1 List-directed input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 10.9.2 List-directed output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 10.10Namelist formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 10.10.1 Namelist input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 10.10.2 Namelist output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 11 Program units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 11.1 Main program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 11.2 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 11.2.1 Module reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 11.2.2 The USE statement and use association . . . . . . . . . . . . . . . . . . . . . . . . 237 11.3 Block data program units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 12 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 12.1 Procedure classifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 12.1.1 Procedure classification by reference . . . . . . . . . . . . . . . . . . . . . . . . . . 241 JAN 2002 WORKING DRAFT v J3/02-007 WORKING DRAFT JAN 2002 12.1.2 Procedure classification by means of definition . . . . . . . . . . . . . . . . . . . . 241 12.2 Characteristics of procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 12.2.1 Characteristics of dummy arguments . . . . . . . . . . . . . . . . . . . . . . . . . . 242 12.2.2 Characteristics of function results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 12.3 Procedure interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 12.3.1 Implicit and explicit interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 12.3.2 Specification of the procedure interface . . . . . . . . . . . . . . . . . . . . . . . . . 244 12.4 Procedure reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 12.4.1 Actual arguments, dummy arguments, and argument association . . . . . . . . . . 253 12.4.2 Function reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 12.4.3 Subroutine reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 12.4.4 Resolving procedure references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 12.5 Procedure definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 12.5.1 Intrinsic procedure definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 12.5.2 Procedures defined by subprograms . . . . . . . . . . . . . . . . . . . . . . . . . . 263 12.5.3 Definition and invocation of procedures by means other than Fortran . . . . . . . . 270 12.5.4 Statement function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 12.6 Pure procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 12.7 Elemental procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 12.7.1 Elemental procedure declaration and interface . . . . . . . . . . . . . . . . . . . . . 274 12.7.2 Elemental function actual arguments and results . . . . . . . . . . . . . . . . . . . 274 12.7.3 Elemental subroutine actual arguments . . . . . . . . . . . . . . . . . . . . . . . . 275 13 Intrinsic procedures and modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 13.1 Classes of intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 13.2 Arguments to intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 13.2.1 The shape of array arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 13.2.2 Mask arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 13.3 Bit models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 13.4 Numeric models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 13.5 Standard generic intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 13.5.1 Numeric functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 13.5.2 Mathematical functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 13.5.3 Character functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 13.5.4 Kind functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 13.5.5 Miscellaneous type conversion functions . . . . . . . . . . . . . . . . . . . . . . . . 281 13.5.6 Numeric inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 13.5.7 Array inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 13.5.8 Other inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 13.5.9 Bit manipulation procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 13.5.10 Floating-point manipulation functions . . . . . . . . . . . . . . . . . . . . . . . . . 282 13.5.11 Vector and matrix multiply functions . . . . . . . . . . . . . . . . . . . . . . . . . 283 13.5.12 Array reduction functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 13.5.13 Array construction functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 13.5.14 Array location functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 13.5.15 Null function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 13.5.16 Random number subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 13.5.17 System environment procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 13.6 Specific names for standard intrinsic functions . . . . . . . . . . . . . . . . . . . . . . . . . 284 13.7 Specifications of the standard intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . 285 13.8 Standard intrinsic modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 13.8.1 The ISO C BINDING module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 13.8.2 The IEEE modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 13.8.3 The ISO FORTRAN ENV intrinsic module . . . . . . . . . . . . . . . . . . . . . 343 vi WORKING DRAFT JAN 2002 JAN 2002 WORKING DRAFT J3/02-007 14 Exceptions and IEEE arithmetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 14.1 Derived data types and constants defined in the modules . . . . . . . . . . . . . . . . . . . 346 14.2 The exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 14.3 The rounding modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 14.4 Halting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 14.5 The floating point status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 14.6 Exceptional values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 14.7 IEEE arithmetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 14.8 Tables of the procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 14.8.1 Inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 14.8.2 Elemental functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 14.8.3 Kind function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 14.8.4 Elemental subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 14.8.5 Nonelemental subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 14.9 Specifications of the procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 14.10Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 15 Interoperability with C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 15.1 The ISO C BINDING intrinsic module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 15.2 Interoperation between Fortran and C entities . . . . . . . . . . . . . . . . . . . . . . . . . 372 15.2.1 Fortran scalar intrinsic entities and C entities . . . . . . . . . . . . . . . . . . . . . 373 15.2.2 Interoperation with C pointer types . . . . . . . . . . . . . . . . . . . . . . . . . . 374 15.2.3 Interoperability inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 15.2.4 Interoperation with C struct types . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 15.2.5 Interoperation with C array types . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 15.2.6 Interoperation with C functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 15.2.7 Interoperation with C global variables . . . . . . . . . . . . . . . . . . . . . . . . . 379 16 Scope, association, and definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 16.1 Scope of global entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 16.2 Scope of local entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 16.2.1 Local entities that have the same names as common blocks . . . . . . . . . . . . . 383 16.2.2 Function results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 16.2.3 Restrictions on generic declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 16.2.4 Components, type parameters, and bindings . . . . . . . . . . . . . . . . . . . . . . 384 16.2.5 Argument keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 16.3 Statement and construct entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 16.4 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 16.4.1 Name association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 16.4.2 Pointer association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 16.4.3 Storage association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 16.4.4 Inheritance association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 16.4.5 Establishing associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 16.5 Definition and undefinition of variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 16.5.1 Definition of objects and subobjects . . . . . . . . . . . . . . . . . . . . . . . . . . 394 16.5.2 Variables that are always defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 16.5.3 Variables that are initially defined . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 16.5.4 Variables that are initially undefined . . . . . . . . . . . . . . . . . . . . . . . . . . 395 16.5.5 Events that cause variables to become defined . . . . . . . . . . . . . . . . . . . . . 395 16.5.6 Events that cause variables to become undefined . . . . . . . . . . . . . . . . . . . 397 16.5.7 Variable definition context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 A Glossary of technical terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 B Decremental features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 JAN 2002 WORKING DRAFT vii J3/02-007 WORKING DRAFT JAN 2002 B.1 Deleted features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 B.2 Obsolescent features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 B.2.1 Alternate return . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 B.2.2 Computed GO TO statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 B.2.3 Statement functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 B.2.4 DATA statements among executables . . . . . . . . . . . . . . . . . . . . . . . . . 415 B.2.5 Assumed character length functions . . . . . . . . . . . . . . . . . . . . . . . . . . 415 B.2.6 Fixed form source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 B.2.7 CHARACTER* form of CHARACTER declaration . . . . . . . . . . . . . . . . . 415 C Extended notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 C.1 Section 4 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 C.1.1 Intrinsic and derived data types (4.4, 4.5) . . . . . . . . . . . . . . . . . . . . . . . 417 C.1.2 Selection of the approximation methods (4.4.2) . . . . . . . . . . . . . . . . . . . . 418 C.1.3 Extensible types (4.5.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 C.1.4 Pointers (4.5.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 C.1.5 Structure constructors and generic names . . . . . . . . . . . . . . . . . . . . . . . 420 C.1.6 Final subroutines (4.5.1.7, 4.5.10, 4.5.10.1, 4.5.10.2) . . . . . . . . . . . . . . . . . 422 C.2 Section 5 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 C.2.1 The POINTER attribute (5.1.2.11) . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 C.2.2 The TARGET attribute (5.1.2.14) . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 C.2.3 The VOLATILE attribute (5.1.2.16) . . . . . . . . . . . . . . . . . . . . . . . . . . 425 C.3 Section 6 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 C.3.1 Structure components (6.1.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 C.3.2 Allocation with dynamic type (6.3.1) . . . . . . . . . . . . . . . . . . . . . . . . . . 428 C.3.3 Pointer allocation and association . . . . . . . . . . . . . . . . . . . . . . . . . . . 428 C.4 Section 7 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 C.4.1 Character assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 C.4.2 Evaluation of function references . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 C.4.3 Pointers in expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 C.4.4 Pointers on the left side of an assignment . . . . . . . . . . . . . . . . . . . . . . . 430 C.4.5 An example of a FORALL construct containing a WHERE construct . . . . . . . 430 C.4.6 Examples of FORALL statements . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 C.5 Section 8 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 C.5.1 Loop control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 C.5.2 The CASE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 C.5.3 Examples of DO constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 C.5.4 Examples of invalid DO constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 C.6 Section 9 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 C.6.1 External files (9.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 C.6.2 Nonadvancing input/output (9.2.3.1) . . . . . . . . . . . . . . . . . . . . . . . . . . 437 C.6.3 Asynchronous input/output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 C.6.4 OPEN statement (9.4.5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439 C.6.5 Connection properties (9.4.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440 C.6.6 CLOSE statement (9.4.6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 C.7 Section 10 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 C.7.1 Number of records (10.3, 10.4, 10.7.2) . . . . . . . . . . . . . . . . . . . . . . . . . 441 C.7.2 List-directed input (10.9.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442 C.8 Section 11 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 C.8.1 Main program and block data program unit (11.1, 11.3) . . . . . . . . . . . . . . . 443 C.8.2 Dependent compilation (11.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 C.8.3 Examples of the use of modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 C.9 Section 12 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 C.9.1 Portability problems with external procedures (12.3.2.2) . . . . . . . . . . . . . . . 452 viii WORKING DRAFT JAN 2002 JAN 2002 WORKING DRAFT J3/02-007 C.9.2 Procedures defined by means other than Fortran (12.5.3) . . . . . . . . . . . . . . 452 C.9.3 Procedure interfaces (12.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 C.9.4 Argument association and evaluation (12.4.1.2) . . . . . . . . . . . . . . . . . . . . 453 C.9.5 Pointers and targets as arguments (12.4.1.2) . . . . . . . . . . . . . . . . . . . . . . 454 C.9.6 Polymorphic Argument Association (12.4.1.3) . . . . . . . . . . . . . . . . . . . . . 455 C.10 Section 15 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 C.10.1 Runtime environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 C.10.2 Examples of Interoperation between Fortran and C Functions . . . . . . . . . . . . 456 C.10.3 Example of C calling Fortran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 C.11 Section 16 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 C.11.1 Examples of host association (16.4.1.3) . . . . . . . . . . . . . . . . . . . . . . . . . 459 C.11.2 Generic resolution and dynamic dispatch (12.4.4) . . . . . . . . . . . . . . . . . . . 460 C.12 Array feature notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 C.12.1 Summary of features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 C.12.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462 C.12.3 FORmula TRANslation and array processing . . . . . . . . . . . . . . . . . . . . . 466 C.12.4 Sum of squared residuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 C.12.5 Vector norms: infinity-norm and one-norm . . . . . . . . . . . . . . . . . . . . . . 468 C.12.6 Matrix norms: infinity-norm and one-norm . . . . . . . . . . . . . . . . . . . . . . 468 C.12.7 Logical queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 C.12.8 Parallel computations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469 C.12.9 Example of element-by-element computation . . . . . . . . . . . . . . . . . . . . . 469 C.12.10Bit manipulation and inquiry procedures . . . . . . . . . . . . . . . . . . . . . . . 469 D Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 E Index of syntax terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481 F Index of syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 JAN 2002 WORKING DRAFT ix J3/02-007 WORKING DRAFT JAN 2002 x WORKING DRAFT JAN 2002 JAN 2002 WORKING DRAFT J3/02-007 List of Tables 2.1 Requirements on statement ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 Statements allowed in scoping units . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1 Special characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1 Subscript order value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 7.1 Type of operands and results for intrinsic operators . . . . . . . . . . . . . . . . . 114 7.2 Interpretation of the numeric intrinsic operators . . . . . . . . . . . . . . . . . . . 125 7.3 Interpretation of the character intrinsic operator // . . . . . . . . . . . . . . . . . 126 7.4 Interpretation of the relational intrinsic operators . . . . . . . . . . . . . . . . . . 127 7.5 Interpretation of the logical intrinsic operators . . . . . . . . . . . . . . . . . . . . 128 7.6 The values of operations involving logical intrinsic operators . . . . . . . . . . . . 128 7.7 Categories of operations and relative precedence . . . . . . . . . . . . . . . . . . . 129 7.8 Type conformance for the intrinsic assignment statement . . . . . . . . . . . . . . 132 7.9 Numeric conversion and the assignment statement . . . . . . . . . . . . . . . . . . 133 13.1 Characteristics of the result of NULL ( ) . . . . . . . . . . . . . . . . . . . . . . . . 325 15.1 Correspondence between Fortran and C types . . . . . . . . . . . . . . . . . . . . . 373 JAN 2002 WORKING DRAFT xi J3/02-007 WORKING DRAFT JAN 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 Annexes A to F of this part of ISO/IEC 1539 are for information only. xii WORKING DRAFT JAN 2002 JAN 2002 WORKING DRAFT J3/02-007 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 (allowing the kind, length, or shape of a derived type's components to be chosen when the derived type is used), mixed component accessibility (where different components have different accessibility), public entities of private type, improved structure constructors, and finalizers. (2) Object oriented programming support: enhanced data abstraction (where one type may extend the definition of another type), polymorphism (where the type of a variable may vary at runtime), dynamic type allocation, SELECT TYPE construct (which allows a choice of execution flow depending upon which 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 (where a program can con- tinue to process data while an input/output transfer occurs), stream access (which facilitates access to a file without reference to any record structure), user specified transfer opera- tions 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) Abstract interfaces (which give names for specified interfaces) and pointers to procedures. (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 (allowing portable access to many li- braries and the low-level facilities provided by C and allowing 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 (which allows the program to better process exceptional conditions). JAN 2002 WORKING DRAFT xiii J3/02-007 WORKING DRAFT JAN 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 Annex D Index of syntax terms Annex E Index of syntax rules Annex F xiv WORKING DRAFT JAN 2002 JAN 2002 WORKING DRAFT J3/02-007 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 JAN 2002 WORKING DRAFT 1 J3/02-007 WORKING DRAFT JAN 2002 1 1.5, 2 (5) The size or complexity of a program and its data that will exceed the capacity of any specific 3 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 same 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 JAN 2002 JAN 2002 WORKING DRAFT J3/02-007 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 proce- 6 dures than the previous one. Therefore, a Fortran program conforming to an older standard may have 7 a different interpretation under a newer standard if it invokes an external procedure having the same 8 name as one of the new standard intrinsic procedures, unless that procedure is specified to have the 9 EXTERNAL attribute. 10 1.6.1 Fortran 95 compatibility 11 Except as noted in this section, this standard is an upward compatible extension to the preceding 12 Fortran International Standard, ISO/IEC 1539:1997, informally referred to as Fortran 95. Any standard- 13 conforming Fortran 95 program remains standard-conforming under this standard. 14 Earlier Fortran standards had the concept of printing, meaning that column one of formatted output 15 had special meaning for a processor-dependent (possibly empty) set of logical units. This could be 16 neither detected nor specified by a standard-specified means. The interpretation of the first column is 17 not specified by this standard. 18 The PAD= specifier in the INQUIRE statement in this standard returns the value 'UNDEFINED' if there 19 is no connection or the connection is for unformatted input/output. The previous standard specified 20 'YES'. 21 This standard specifies a different output format than Fortran 95 for real zero values in list-directed and 22 namelist output. 23 1.6.2 Fortran 90 compatibility 24 Except for the deleted features noted in Annex B.1, and except as noted in this section, this standard is an 25 upward compatible extension to ISO/IEC 1539:1991 (Fortran 90). Any standard-conforming Fortran 90 26 program that does not use one of the deleted features remains standard-conforming under this standard. J3 internal note Unresolved issue 340 If the relevant interpretations pass the Corrigendum, we need to move the PAD= paragraph from above to here and add a similar paragraph for the MOD function. JAN 2002 WORKING DRAFT 3 J3/02-007 WORKING DRAFT JAN 2002 1 1.6.3 FORTRAN 77 compatibility 2 Except for the deleted features noted in Annex B.1, and except as noted in this section, this standard is 3 an upward compatible extension to ISO 1539:1980 (Fortran 77). Any standard-conforming Fortran 4 77 program that does not use one of the deleted features noted in Annex B.1 remains standard con- 5 forming under this standard. This standard restricts the behavior for some features that were processor 6 dependent in Fortran 77. Therefore, a standard-conforming Fortran 77 program that uses one of 7 these processor-dependent features may have a different interpretation under this standard, yet remain 8 a standard-conforming program. The following Fortran 77 features may have different interpretations 9 in this standard: 10 (1) Fortran 77 permitted a processor to supply more precision derived from a real constant 11 than can be represented in a real datum when the constant is used to initialize a data 12 object of type double precision real in a DATA statement. This standard does not permit 13 a processor this option. 14 (2) If a named variable that was not in a common block was initialized in a DATA statement and 15 did not have the SAVE attribute specified, Fortran 77 left its SAVE attribute processor 16 dependent. This standard specifies (5.2.5) that this named variable has the SAVE attribute. 17 (3) Fortran 77 required that the number of characters required by the input list was to be 18 less than or equal to the number of characters in the record during formatted input. This 19 standard specifies (9.5.3.4.2) that the input record is logically padded with blanks if there 20 are not enough characters in the record, unless the PAD= specifier with the value 'NO' is 21 specified in an appropriate OPEN or READ statement. 22 (4) A value of 0 for a list item in a formatted output statement will be formatted in a differ- 23 ent form for some G edit descriptors. In addition, this standard specifies how rounding of 24 values will affect the output field form, but Fortran 77 did not address this issue. There- 25 fore, some Fortran 77 processors may produce an output form different from the output 26 form produced by Fortran 2000 processors for certain combinations of values and G edit 27 descriptors. 28 (5) If the processor can distinguish between positive and negative real zero, the behavior of the 29 SIGN intrinsic function when the second argument is negative real zero is changed by this 30 standard. 31 1.7 Notation used in this standard 32 In this standard, "shall" is to be interpreted as a requirement; conversely, "shall not" is to be interpreted 33 as a prohibition. Except where stated otherwise, such requirements and prohibitions apply to programs 34 rather than processors. 35 1.7.1 Informative notes 36 Informative notes of explanation, rationale, examples, and other material are interspersed with the nor- 37 mative body of this publication. The informative material is identified by shading and is nonnormative. 38 1.7.2 Syntax rules 39 Syntax rules are used to help describe the forms that Fortran lexical tokens, statements, and constructs 40 may take. These syntax rules are expressed in a variation of Backus-Naur form (BNF) in which: 41 (1) Characters from the Fortran character set (3.1) are interpreted literally as shown, except 42 where otherwise noted. 43 (2) Lower-case italicized letters and words (often hyphenated and abbreviated) represent general 44 syntactic classes for which specific syntactic entities shall be substituted in actual statements. 4 WORKING DRAFT JAN 2002 JAN 2002 WORKING DRAFT J3/02-007 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 which 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 the 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 When specific entities are substituted for digit, actual digit strings might be: 4671999 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 18 where the syntax term appears. 19 Some constraints are not associated with particular syntax rules. The effect of such a constraint is similar 20 to that of a restriction stated in the text, except that a processor is required to have the capability to JAN 2002 WORKING DRAFT 5 J3/02-007 WORKING DRAFT JAN 2002 1 detect and report violations of constraints (1.5). In some cases, a broad requirement is stated in text 2 and a subset of the same requirement is also stated as a constraint. This indicates that a standard- 3 conforming program is required to adhere to the broad requirement, but that a standard-conforming 4 processor is required only to have the capability of diagnosing violations of the constraint. 5 1.7.4 Assumed syntax rules 6 In order to minimize the number of additional syntax rules and convey appropriate constraint informa- 7 tion, the following rules are assumed; an explicit syntax rule for a term overrides an assumed rule. The 8 letters "xyz" stand for any syntactic class phrase: 9 R101 xyz-list is xyz [ , xyz ] ... 10 R102 xyz-name is name 11 R103 scalar-xyz is xyz 12 C101 (R103) scalar-xyz shall be scalar. 13 1.7.5 Syntax conventions and characteristics 14 (1) Any syntactic class name ending in "-stmt" follows the source form statement rules: it shall 15 be delimited by end-of-line or semicolon, and may be labeled unless it forms part of another 16 statement (such as an IF or WHERE statement). Conversely, everything considered to be 17 a source form statement is given a "-stmt" ending in the syntax rules. 18 (2) The rules on statement ordering are described rigorously in the definition of program-unit 19 (R202). Expression hierarchy is described rigorously in the definition of expr (R722). 20 (3) The suffix "-spec" is used consistently for specifiers, such as input/output statement speci- 21 fiers. It also is used for type declaration attribute specifications (for example, "array-spec" 22 in R514), and in a few other cases. 23 (4) When reference is made to a type parameter, including the surrounding parentheses, the 24 suffix "-selector" is used. See, for example, "kind-selector" (R508) and "length-selector" 25 (R510). 26 (5) The term "subscript" (for example, R618, R619, and R620) is used consistently in array 27 definitions. 28 1.7.6 Text conventions 29 In the descriptive text, an equivalent English word is frequently used in place of a syntactic term. Specific 30 statements and attributes are identified in the text by an upper-case keyword, e.g., "END statement". 31 Boldface words are used in the text where they are first defined with a specialized meaning. Obsolescent 32 features (1.8) are shown in a distinguishing type size. NOTE 1.3 This sentence is an example of the type size used for obsolescent features. 33 1.8 Deleted and obsolescent features 34 This standard protects the users' investment in existing software by including all but five of the language 35 elements of Fortran 90 that are not processor dependent. This standard identifies two categories of 36 outmoded features. There are five in the first category, deleted features, which consists of features 37 considered to have been redundant in Fortran 77 and largely unused in Fortran 90. Those in the second 38 category, obsolescent features, are considered to have been redundant in Fortran 90 and Fortran 95, 39 but are still frequently used. 6 WORKING DRAFT JAN 2002 JAN 2002 WORKING DRAFT J3/02-007 1 1.8.1 Nature of deleted features 2 (1) Better methods existed in Fortran 77. 3 (2) These features are not included in Fortran 95 or this revision of Fortran. 4 1.8.2 Nature of obsolescent features 5 (1) Better methods existed in Fortran 90 and Fortran 95. 6 (2) It is recommended that programmers should use these better methods in new programs and 7 convert existing code to these methods. 8 (3) These features are identified in the text of this document by a distinguishing type font 9 (1.7.6). 10 (4) If the use of these features has become insignificant in Fortran programs, future Fortran 11 standards committees should consider deleting them from the next revision. 12 (5) The next Fortran standards committee should consider for deletion only those language 13 features that appear in the list of obsolescent features. 14 (6) Processors supporting the Fortran language should support these features as long as they 15 continue to be used widely in Fortran programs. 16 1.9 Normative references 17 The following standards contain provisions which, through reference in this standard, constitute provi- 18 sions of this standard. At the time of publication, the editions indicated were valid. All standards are 19 subject to revision, and parties to agreements based on this standard are encouraged to investigate the 20 possibility of applying the most recent editions of the standards indicated below. Members of IEC and 21 ISO maintain registers of currently valid International Standards. 22 ISO/IEC 646:1991, Information technology-ISO 7-bit coded character set for information interchange. 23 ISO/IEC 646:1991 (International Reference Version) is the international equivalent of ANSI X3.4-1986, 24 commonly known as ASCII. This standard refers to it as the ASCII standard. 25 ISO 8601:1988, Data elements and interchange formats-Information interchange- 26 Representation of dates and times. 27 ISO/IEC 9989:1999, Information technology-Programming languages-C. 28 This standard refers to ISO/IEC 9899:1999 as the C standard. 29 ISO/IEC 10646-1:2000, Information technology-Universal multiple-octet coded character set (UCS)- 30 Part 1: Architecture and basic multilingual plane. 31 IEC 60559 (1989-01), Binary floating-point arithmetic for microprocessor systems. 32 Since IEC 60559 (1989-01) was originally IEEE 754-1985, Standard for binary floating-point arithmetic, 33 and is widely known by this name, this standard refers to it as the IEEE standard. JAN 2002 WORKING DRAFT 7 J3/02-007 WORKING DRAFT JAN 2002 8 WORKING DRAFT JAN 2002 JAN 2002 WORKING DRAFT J3/02-007 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 R1114 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 ] ... JAN 2002 WORKING DRAFT 9 J3/02-007 WORKING DRAFT JAN 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 R212 module-subprogram-part is contains-stmt 30 module-subprogram 31 [ module-subprogram ] ... 32 R213 module-subprogram is function-subprogram 33 or subroutine-subprogram 34 R214 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 R215 executable-construct is action-stmt 54 or associate-construct 10 WORKING DRAFT JAN 2002 JAN 2002 WORKING DRAFT J3/02-007 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 R216 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 forall-stmt 21 or goto-stmt 22 or if-stmt 23 or inquire-stmt 24 or nullify-stmt 25 or open-stmt 26 or pointer-assignment-stmt 27 or print-stmt 28 or read-stmt 29 or return-stmt 30 or rewind-stmt 31 or stop-stmt 32 or wait-stmt 33 or where-stmt 34 or write-stmt 35 or arithmetic-if-stmt 36 or computed-goto-stmt 37 C201 (R208) An execution-part shall not contain an end-function-stmt, end-program-stmt, or end- 38 subroutine-stmt. 39 2.2 Program unit concepts 40 Program units are the fundamental components of a Fortran program. A program unit may be 41 a main program, an external subprogram, a module, or a block data program unit. A subprogram 42 may be a function subprogram or a subroutine subprogram. A module contains definitions that are 43 to be made accessible to other program units. A block data program unit is used to specify initial 44 values for data objects in named common blocks. Each type of program unit is described in Sections 45 11 or 12. An external subprogram is a subprogram that is not in a main program, a module, or 46 another subprogram. An internal subprogram is a subprogram that is in a main program or another 47 subprogram. A module subprogram is a subprogram that is in a module but is not an internal 48 subprogram. 49 A program unit consists of a set of nonoverlapping scoping units. A scoping unit is JAN 2002 WORKING DRAFT 11 J3/02-007 WORKING DRAFT JAN 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. The set of program units may include any combination of the different kinds of program 10 units in a processor-dependent order as long as there is only one main program unit. J3 internal note Unresolved issue 349 Paper 01-373r2 added the above "processor-dependent order" replacing the prior "any order". However, this makes no sense as written. The processor doesn't determine the order of the program units. The processor might place requirements on what the order has to be (namely that modules must be processed before they are used), but that's not what this says. Even if we grant that reading of these words, this apparently innocuous wording change introduces a major incompatability and portability problem relative to all prior standards. The note below, which prompted this change, refers only to requiring modules to be processed first. The change to the normative text, however, is *FAR* broader. It implies that a processor might, for example, require that the program units be in alphabetical order. Do we really want to explicitly give processors permission to invent such spurious incompatibilities, with not even a hint as to what constitutes a reasonable expectation? NOTE 2.2 There is a restriction that there shall be no more than one unnamed block data program unit (11.3). 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 specific order of processing of the program units. 11 2.2.2 Main program 12 The Fortran main program is described in 11.1. 13 2.2.3 Procedure 14 A procedure encapsulates an arbitrary sequence of actions that may be invoked directly during program 15 execution. Procedures are either functions or subroutines. A function is a procedure that is invoked 16 in an expression; its invocation causes a value to be computed which is then used in evaluating the 17 expression. The variable that returns the value of a function is called the result variable. A subroutine 18 is a procedure that is invoked in a CALL statement, by a defined assignment statement, or by some 19 operations on derived-type entities. Unless it is a pure procedure, a subroutine may be used to change 20 the program state by changing the values of any of the data objects accessible to the subroutine; unless 21 it is a pure procedure, a function may do this in addition to computing the function value. 22 Procedures are described further in Section 12. 12 WORKING DRAFT JAN 2002 JAN 2002 WORKING DRAFT J3/02-007 1 2.2.3.1 External procedure 2 An external procedure is a procedure that is defined by an external subprogram or by means other 3 than Fortran. An external procedure may be invoked by the main program or by any procedure of a 4 program. 5 2.2.3.2 Module procedure 6 A module procedure is a procedure that is defined by a module subprogram (R213). A module 7 procedure may be invoked by another module subprogram in the module or by any scoping unit that 8 accesses the module procedure by use association (11.2.2). The module containing the subprogram is 9 the host scoping unit of the module procedure. 10 2.2.3.3 Internal procedure 11 An internal procedure is a procedure that is defined by an internal subprogram (R211). The containing 12 main program or subprogram is the host scoping unit of the internal procedure. An internal procedure 13 is local to its host in the sense that the internal procedure is accessible within the host scoping unit and 14 all its other internal procedures but is not accessible elsewhere. 15 2.2.3.4 Interface block 16 The purpose of an interface block is to describe the interfaces (12.3) to a set of procedures, and 17 the forms of reference by which the procedures may be invoked (12.4). It may be used to specify the 18 interfaces of external, type-bound, or dummy procedures or of procedure pointers. It may also be used 19 to specify that procedures may be invoked 20 (1) By using a generic name, 21 (2) By using a defined operator, 22 (3) By using a defined assignment, or 23 (4) For derived-type input/output. 24 2.2.4 Module 25 A module contains (or accesses from other modules) definitions that are to be made accessible to other 26 program units. These definitions include data object declarations, type definitions, procedure definitions, 27 and interface blocks. A scoping unit in another program unit may access the definitions in a module. 28 Modules are further described in Section 11. 29 2.3 Execution concepts 30 Each Fortran statement is classified as either an executable statement or a nonexecutable statement. 31 There are restrictions on the order in which statements may appear in a program unit, and not all 32 executable statements may appear in all contexts. 33 2.3.1 Executable/nonexecutable statements 34 Program execution is a sequence, in time, of actions. An executable statement is an instruction to 35 perform or control one or more of these actions. Thus, the executable statements of a program unit 36 determine the behavior of the program unit. The executable statements are all of those that make up 37 the syntactic class executable-construct. 38 Nonexecutable statements do not specify actions; they are used to configure the program environment 39 in which actions take place. The nonexecutable statements are all those not classified as executable. JAN 2002 WORKING DRAFT 13 J3/02-007 WORKING DRAFT JAN 2002 1 2.3.2 Statement order 2 The syntax rules of subclause 2.1 specify the statement order within program units and subprograms. 3 These rules are illustrated in Table 2.1 and Table 2.2. Table 2.1 shows the ordering rules for state- 4 ments and applies to all program units and subprograms. Vertical lines delineate varieties of statements 5 that may be interspersed and horizontal lines delineate varieties of statements that shall not be in- 6 terspersed. Internal or module subprograms shall follow a CONTAINS statement. Between USE and 7 CONTAINS statements in a subprogram, nonexecutable statements generally precede executable state- 8 ments, although the ENTRY statement, FORMAT statement, and DATA statement may appear among 9 the executable statements. Table 2.2 shows which statements are allowed in a scoping unit. 14 WORKING DRAFT JAN 2002 JAN 2002 WORKING DRAFT J3/02-007 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. Executing an end-program-stmt causes JAN 2002 WORKING DRAFT 15 J3/02-007 WORKING DRAFT JAN 2002 1 normal termination of execution of the program. Executing an end-function-stmt or end-subroutine- 2 stmt is equivalent to executing a return-stmt. 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, and IF constructs contain an internal statement structure 15 and execution of these constructs involves implicit internal branching. See Section 8 for the 16 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 data types. 30 2.4.1 Data type 31 A data type is a named category of data that is characterized by a set of values, together with a syntax 32 for denoting these values and a set of operations that interpret and manipulate the values. This central 33 concept is 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 data 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. 16 WORKING DRAFT JAN 2002 JAN 2002 WORKING DRAFT J3/02-007 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 intrinsi- 9 cally (7.5.1.5), but there are no intrinsic operations for struvtures. 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 data type and type parameters; 22 it may have a data value (an exception is an undefined variable). Every data entity has a rank and is 23 thus 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) JAN 2002 WORKING DRAFT 17 J3/02-007 WORKING DRAFT JAN 2002 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, and 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. 18 WORKING DRAFT JAN 2002 JAN 2002 WORKING DRAFT J3/02-007 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, and its number of elements, which is equal to the 7 product of the extents. An array may have zero size. The shape of an array is determined by its rank 8 and its extent in each dimension, and may be represented as a rank-one array whose elements are the 9 extents. All named arrays shall be declared, and the rank of a named array is specified in its declaration. 10 The rank of a named array, once declared, is constant; the extents may be constant or may vary during 11 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-like" operation to produce the corresponding element in the result array, and all such element 17 operations may be performed in any order or simultaneously. Such an operation is described as ele- 18 mental. 19 A rank-one array may be constructed from scalars and other arrays and may be reshaped into any 20 allowable array shape (4.8). 21 Arrays may be of any intrinsic type or derived type and are described further in 6.2. 22 2.4.6 Pointer 23 A data pointer is a data entity that has the POINTER attribute. A procedure pointer is a procedure 24 entity that has the POINTER attribute. A pointer is either a data pointer or a procedure pointer. 25 A pointer is associated with a target by pointer assignment (7.5.2). A data pointer may also be 26 associated with a target by allocation (6.3.1). A pointer is disassociated following execution of a 27 NULLIFY statement, following pointer assignment with a disassociated pointer, by default initialization, 28 or by explicit initialization. A data pointer may also be disassociated by execution of a DEALLOCATE 29 statement. A disassociated pointer is not currently associated with a target (16.4.2). 30 A pointer that is not currently associated shall not be referenced or defined. 31 If a data pointer is an array, the rank is declared, but the extents are determined when the pointer is 32 associated with a target. 33 2.4.7 Storage 34 Many of the facilities of this standard make no assumptions about the physical storage characteristics of 35 data objects. However, program units that include storage association dependent features shall observe 36 certain storage constraints (16.4.3). 37 2.5 Fundamental terms 38 The following terms are defined here and used throughout this standard. JAN 2002 WORKING DRAFT 19 J3/02-007 WORKING DRAFT JAN 2002 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 in this standard. 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 argument lists, type parameter 14 lists, and structure constructors, items may be identified by a preceding keyword= rather 15 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 R217 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 Declaration 21 The term declaration refers to the specification of attributes for various program entities. Often this 22 involves specifying the data type of a named data object or specifying the shape of a named array object. 23 2.5.4 Definition 24 The term definition is used in two ways. First, when a data object is given a valid value during program 25 execution, it is said to become defined. This is often accomplished by execution of an assignment 26 statement or input statement. Under certain circumstances, a variable does not have a predictable value 27 and is said to be undefined. Section 16 describes the ways in which variables may become defined 28 and undefined. The second use of the term definition refers to the specification of derived types and 29 procedures. 30 2.5.5 Reference 31 A data object reference is the appearance of the data object designator in a context requiring its 32 value at that point during execution. 33 A procedure reference is the appearance of the procedure designator, operator symbol, or assignment 20 WORKING DRAFT JAN 2002 JAN 2002 WORKING DRAFT J3/02-007 1 symbol in a context requiring execution of the procedure at that point. An occurance of user-defined 2 derived-type input/output (10.6.5) or derived-type finalization (4.5.10) is also a procedure reference. 3 The appearance of a data object designator or procedure name in an actual argument list does not 4 constitute a reference to that data object or procedure unless such a reference is necessary to complete 5 the specification of the actual argument. 6 A module reference is the appearance of a module name in a USE statement (11.2.1). 7 2.5.6 Association 8 Association may be name association (16.4.1), pointer association (16.4.2), or storage association 9 (16.4.3). Name association may be argument association, host association, use association, or construct 10 association. 11 Storage association causes different entities to use the same storage. Any association permits an entity 12 to be identified by different names in the same scoping unit or by the same name or different names in 13 different scoping units. 14 2.5.7 Intrinsic 15 The qualifier intrinsic has two meanings. The first signifies that the term to which it is applied is 16 defined in this standard. Intrinsic applies to data types, procedures, modules, assignment statements, 17 and operators. All intrinsic data types, procedures, and operators may be used in any scoping unit 18 without further definition or specification. Intrinsic modules may be accessed by use association. Intrinsic 19 procedures and modules defined in this standard are called standard intrinsic procedures and standard 20 intrinsic modules, respectively. 21 The second use of the qualifier applies to procedures or modules that are provided by a processor but 22 are not defined in this standard (13, 14, 15.1). Such procedures and modules are called nonstandard 23 intrinsic procedures and nonstandard intrinsic modules, respectively. 24 2.5.8 Operator 25 An operator specifies a computation involving one (unary operator) or two (binary operator) data values 26 (operands). This standard specifies a number of intrinsic operators (e.g., the arithmetic operators +, ­, 27 *, /, and ** with numeric operands and the logical operators .AND., .OR., etc. with logical operands). 28 Additional operators may be defined within a program (7.1.3). 29 2.5.9 Sequence 30 A sequence is a set ordered by a one-to-one correspondence with the numbers 1, 2, through n The 31 number of elements in the sequence is n. A sequence may be empty, in which case it contains no 32 elements. 33 The elements of a nonempty sequence are referred to as the first element, second element, etc. The 34 nth element, where n is the number of elements in the sequence, is called the last element. An empty 35 sequence has no first or last element. 36 2.5.10 Companion processors 37 A processor has one or more companion processors. A companion processor is a processor-dependent 38 mechanism by which global data and procedures may be referenced or defined. A companion processor 39 may be a mechanism that references and defines such entities by a means other than Fortran (12.5.3), 40 it may be the Fortran processor itself, or it may be another Fortran processor. If there is more than JAN 2002 WORKING DRAFT 21 J3/02-007 WORKING DRAFT JAN 2002 1 one companion processor, the means by which the Fortran processor selects among them are processor 2 dependent. 3 If a procedure is defined by means of a companion processor that is not the Fortran processor itself, 4 this standard refers to the C function that defines the procedure, although the procedure need not be 5 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. 22 WORKING DRAFT JAN 2002 JAN 2002 WORKING DRAFT J3/02-007 1 Section 3: Characters, lexical tokens, and source form 2 This section describes the Fortran character set and the various lexical tokens such as names and oper- 3 ators. This section also describes the rules for the forms that Fortran programs may take. 4 3.1 Processor character set 5 The processor character set is processor dependent. The structure of a processor character set is: 6 (1) Control characters ("newline", for example) 7 (2) Graphic characters 8 (a) Letters (3.1.1) 9 (b) Digits (3.1.2) 10 (c) Underscore (3.1.3) 11 (d) Special characters (3.1.4) 12 (e) Other characters (3.1.5) 13 The letters, digits, underscore, and special characters make up the Fortran character set. 14 R301 character is alphanumeric-character 15 or special-character 16 R302 alphanumeric-character is letter 17 or digit 18 or underscore 19 Except for the currency symbol, the graphics used for the characters shall be as given in 3.1.1, 3.1.2, 20 3.1.3, and 3.1.4. However, the style of any graphic is not specified. 21 3.1.1 Letters 22 The twenty-six letters are: 23 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 24 The set of letters defines the syntactic class letter. The processor character set shall include lower- 25 case and upper-case letters. A lower-case letter is equivalent to the corresponding upper-case letter in 26 program units except in a character context (3.3). NOTE 3.1 The following statements are equivalent: CALL BIG COMPLEX OPERATION (NDATE) call big complex operation (ndate) Call Big Complex Operation (NDate) 27 3.1.2 Digits 28 The ten digits are: JAN 2002 WORKING DRAFT 23 J3/02-007 WORKING DRAFT JAN 2002 1 0 1 2 3 4 5 6 7 8 9 2 The ten digits define the syntactic class digit. 3 3.1.3 Underscore 4 R303