Reference number of working document: ISO/IEC JTC1/SC22/WG5 N1578 Date: 2003-10-8 Reference number of document: ISO/IEC FCD 1539-1:2004(E) Committee identification: ISO/IEC JTC1/SC22 Secretariat: ANSI Information technology - Programming languages - Fortran - Part 1: Base Language Technologies de l'information - Langages de programmation - Fortran - Partie 1: Langage de base OCT 2003 Final Committee Draft J3/03-007R2 Contents 1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Inclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.4 Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.5 Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.6 Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6.1 Fortran 95 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6.2 Fortran 90 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6.3 FORTRAN 77 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.8.1 Nature of deleted features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.8.2 Nature of obsolescent features . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.9 Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 Fortran terms and concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1 High level syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 Program unit concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.1 Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.2 Main program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.3 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.4 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3 Execution concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.1 Executable/nonexecutable statements . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.2 Statement order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.3 The END statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.4 Execution sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4 Data concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.2 Data value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4.3 Data entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4.4 Scalar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.5 Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.6 Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.7 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.5 Fundamental terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.5.1 Name and designator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5.2 Keyword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5.3 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5.4 Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 OCT 2003 Final Committee Draft i J3/03-007R2 Final Committee Draft OCT 2003 2.5.5 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5.6 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.7 Intrinsic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.8 Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.9 Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.10 Companion processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3 Characters, lexical tokens, and source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1 Processor character set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1.1 Letters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1.2 Digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.1.3 Underscore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.1.4 Special characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.1.5 Other characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2 Low-level syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.1 Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.3 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.4 Statement labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.5 Delimiters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3 Source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3.1 Free source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3.2 Fixed source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.4 Including source text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1 The concept of type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1.1 Set of values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1.3 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2 Type parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.3 Relationship of types and values to objects . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.4 Intrinsic types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.4.1 Integer type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.4.2 Real type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.4.3 Complex type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.4.4 Character type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.4.5 Logical type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.5 Derived types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.5.1 Derived-type definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.5.2 Derived-type parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.5.3 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.5.4 Type-bound procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.5.5 Final subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.5.6 Type extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.5.7 Derived-type values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.5.8 Derived-type specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.5.9 Construction of derived-type values . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.5.10 Derived-type operations and assignment . . . . . . . . . . . . . . . . . . . . . . 65 4.6 Enumerations and enumerators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.7 Construction of array values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5 Data object declarations and specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.1 Type declaration statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 ii Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 5.1.1 Declaration type specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.1.2 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.2 Attribute specification statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.2.1 Accessibility statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.2.2 ALLOCATABLE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.2.3 ASYNCHRONOUS statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.2.4 BIND statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2.5 DATA statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2.6 DIMENSION statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.2.7 INTENT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.2.8 OPTIONAL statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.2.9 PARAMETER statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.2.10 POINTER statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.2.11 PROTECTED statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.2.12 SAVE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.2.13 TARGET statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.2.14 VALUE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.2.15 VOLATILE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.3 IMPLICIT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.4 NAMELIST statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.5 Storage association of data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.5.1 EQUIVALENCE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.5.2 COMMON statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 6 Use of data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 6.1 Scalars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.1.1 Substrings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.1.2 Structure components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.1.3 Type parameter inquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 6.2 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 6.2.1 Whole arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 6.2.2 Array elements and array sections . . . . . . . . . . . . . . . . . . . . . . . . . . 107 6.3 Dynamic association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 6.3.1 ALLOCATE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 6.3.2 NULLIFY statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 6.3.3 DEALLOCATE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 7 Expressions and assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.1 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.1.1 Form of an expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.1.2 Intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 7.1.3 Defined operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 7.1.4 Type, type parameters, and shape of an expression . . . . . . . . . . . . . . . . 123 7.1.5 Conformability rules for elemental operations . . . . . . . . . . . . . . . . . . . 125 7.1.6 Specification expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 7.1.7 Initialization expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 7.1.8 Evaluation of operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 7.2 Interpretation of operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 7.2.1 Numeric intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.2.2 Character intrinsic operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 7.2.3 Relational intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 7.2.4 Logical intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 7.3 Precedence of operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 7.4 Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 OCT 2003 Final Committee Draft iii J3/03-007R2 Final Committee Draft OCT 2003 7.4.1 Assignment statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 7.4.2 Pointer assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 7.4.3 Masked array assignment ­ WHERE . . . . . . . . . . . . . . . . . . . . . . . . 145 7.4.4 FORALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 8 Execution control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 8.1 Executable constructs containing blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 8.1.1 Rules governing blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 8.1.2 IF construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 8.1.3 CASE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 8.1.4 ASSOCIATE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 8.1.5 SELECT TYPE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 8.1.6 DO construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 8.2 Branching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 8.2.1 GO TO statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 8.2.2 Computed GO TO statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 8.2.3 Arithmetic IF statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 8.3 CONTINUE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 8.4 STOP statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 9 Input/output statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 9.1 Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 9.1.1 Formatted record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 9.1.2 Unformatted record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 9.1.3 Endfile record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 9.2 External files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 9.2.1 File existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 9.2.2 File access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 9.2.3 File position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 9.2.4 File storage units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 9.3 Internal files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 9.4 File connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 9.4.1 Connection modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 9.4.2 Unit existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 9.4.3 Connection of a file to a unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 9.4.4 Preconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 9.4.5 The OPEN statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 9.4.6 The CLOSE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 9.5 Data transfer statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 9.5.1 Control information list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 9.5.2 Data transfer input/output list . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 9.5.3 Execution of a data transfer input/output statement . . . . . . . . . . . . . . . 194 9.5.4 Termination of data transfer statements . . . . . . . . . . . . . . . . . . . . . . 205 9.6 Waiting on pending data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 9.6.1 WAIT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 9.6.2 Wait operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 9.7 File positioning statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9.7.1 BACKSPACE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9.7.2 ENDFILE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 9.7.3 REWIND statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 9.8 FLUSH statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 9.9 File inquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 9.9.1 Inquiry specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 9.9.2 Restrictions on inquiry specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 iv Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 9.9.3 Inquire by output list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 9.10 Error, end-of-record, and end-of-file conditions . . . . . . . . . . . . . . . . . . . . . . . . 216 9.10.1 Error conditions and the ERR= specifier . . . . . . . . . . . . . . . . . . . . . . 217 9.10.2 End-of-file condition and the END= specifier . . . . . . . . . . . . . . . . . . . . 217 9.10.3 End-of-record condition and the EOR= specifier . . . . . . . . . . . . . . . . . . 218 9.10.4 IOSTAT= specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 9.10.5 IOMSG= specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 9.11 Restrictions on input/output statements . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 10 Input/output editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 10.1 Explicit format specification methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 10.1.1 FORMAT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 10.1.2 Character format specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 10.2 Form of a format item list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 10.2.1 Edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 10.2.2 Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 10.3 Interaction between input/output list and format . . . . . . . . . . . . . . . . . . . . . . 224 10.4 Positioning by format control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 10.5 Decimal symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 10.6 Data edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 10.6.1 Numeric editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 10.6.2 Logical editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 10.6.3 Character editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 10.6.4 Generalized editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 10.6.5 User-defined derived-type editing . . . . . . . . . . . . . . . . . . . . . . . . . . 235 10.7 Control edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 10.7.1 Position editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 10.7.2 Slash editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 10.7.3 Colon editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 10.7.4 SS, SP, and S editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 10.7.5 P editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 10.7.6 BN and BZ editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 10.7.7 RU, RD, RZ, RN, RC, and RP editing . . . . . . . . . . . . . . . . . . . . . . . 238 10.7.8 DC and DP editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 10.8 Character string edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 10.9 List-directed formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 10.9.1 List-directed input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 10.9.2 List-directed output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 10.10 Namelist formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 10.10.1 Namelist input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 10.10.2 Namelist output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 11 Program units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 11.1 Main program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 11.2 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 11.2.1 The USE statement and use association . . . . . . . . . . . . . . . . . . . . . . . 251 11.3 Block data program units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 12 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 12.1 Procedure classifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 12.1.1 Procedure classification by reference . . . . . . . . . . . . . . . . . . . . . . . . . 255 12.1.2 Procedure classification by means of definition . . . . . . . . . . . . . . . . . . . 255 12.2 Characteristics of procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 12.2.1 Characteristics of dummy arguments . . . . . . . . . . . . . . . . . . . . . . . . 256 OCT 2003 Final Committee Draft v J3/03-007R2 Final Committee Draft OCT 2003 12.2.2 Characteristics of function results . . . . . . . . . . . . . . . . . . . . . . . . . . 257 12.3 Procedure interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 12.3.1 Implicit and explicit interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 12.3.2 Specification of the procedure interface . . . . . . . . . . . . . . . . . . . . . . . 258 12.4 Procedure reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 12.4.1 Actual arguments, dummy arguments, and argument association . . . . . . . . . 268 12.4.2 Function reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 12.4.3 Subroutine reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 12.4.4 Resolving named procedure references . . . . . . . . . . . . . . . . . . . . . . . . 276 12.4.5 Resolving type-bound procedure references . . . . . . . . . . . . . . . . . . . . . 278 12.5 Procedure definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 12.5.1 Intrinsic procedure definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 12.5.2 Procedures defined by subprograms . . . . . . . . . . . . . . . . . . . . . . . . . 279 12.5.3 Definition and invocation of procedures by means other than Fortran . . . . . . 285 12.5.4 Statement function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 12.6 Pure procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 12.7 Elemental procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 12.7.1 Elemental procedure declaration and interface . . . . . . . . . . . . . . . . . . . 287 12.7.2 Elemental function actual arguments and results . . . . . . . . . . . . . . . . . . 288 12.7.3 Elemental subroutine actual arguments . . . . . . . . . . . . . . . . . . . . . . . 289 13 Intrinsic procedures and modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 13.1 Classes of intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 13.2 Arguments to intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 13.2.1 The shape of array arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 13.2.2 Mask arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 13.3 Bit model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 13.4 Numeric models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 13.5 Standard generic intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 13.5.1 Numeric functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 13.5.2 Mathematical functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 13.5.3 Character functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 13.5.4 Kind functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 13.5.5 Miscellaneous type conversion functions . . . . . . . . . . . . . . . . . . . . . . . 295 13.5.6 Numeric inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 13.5.7 Array inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 13.5.8 Other inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 13.5.9 Bit manipulation procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 13.5.10 Floating-point manipulation functions . . . . . . . . . . . . . . . . . . . . . . . . 296 13.5.11 Vector and matrix multiply functions . . . . . . . . . . . . . . . . . . . . . . . . 297 13.5.12 Array reduction functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 13.5.13 Array construction functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 13.5.14 Array location functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 13.5.15 Null function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 13.5.16 Allocation transfer procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 13.5.17 Random number subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 13.5.18 System environment procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 13.6 Specific names for standard intrinsic functions . . . . . . . . . . . . . . . . . . . . . . . . 298 13.7 Specifications of the standard intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . 300 13.8 Standard intrinsic modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 13.8.1 The IEEE modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 13.8.2 The ISO FORTRAN ENV intrinsic module . . . . . . . . . . . . . . . . . . . . 360 13.8.3 The ISO C BINDING module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 vi Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 14 Exceptions and IEEE arithmetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 14.1 Derived types and constants defined in the modules . . . . . . . . . . . . . . . . . . . . . 364 14.2 The exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 14.3 The rounding modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 14.4 Underflow mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 14.5 Halting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 14.6 The floating point status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 14.7 Exceptional values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 14.8 IEEE arithmetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 14.9 Tables of the procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 14.9.1 Inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 14.9.2 Elemental functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 14.9.3 Kind function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 14.9.4 Elemental subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 14.9.5 Nonelemental subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 14.10 Specifications of the procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 14.11 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 15 Interoperability with C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 15.1 The ISO C BINDING intrinsic module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 15.1.1 Named constants and derived types in the module . . . . . . . . . . . . . . . . . 391 15.1.2 Procedures in the module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 15.2 Interoperability between Fortran and C entities . . . . . . . . . . . . . . . . . . . . . . . 395 15.2.1 Interoperability of intrinsic types . . . . . . . . . . . . . . . . . . . . . . . . . . 396 15.2.2 Interoperability with C pointer types . . . . . . . . . . . . . . . . . . . . . . . . 397 15.2.3 Interoperability of derived types and C struct types . . . . . . . . . . . . . . . . 398 15.2.4 Interoperability of scalar variables . . . . . . . . . . . . . . . . . . . . . . . . . . 399 15.2.5 Interoperability of array variables . . . . . . . . . . . . . . . . . . . . . . . . . . 399 15.2.6 Interoperability of procedures and procedure interfaces . . . . . . . . . . . . . . 400 15.3 Interoperation with C global variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 15.3.1 Binding labels for common blocks and variables . . . . . . . . . . . . . . . . . . 403 15.4 Interoperation with C functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 15.4.1 Binding labels for procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 15.4.2 Exceptions and IEEE arithmetic procedures . . . . . . . . . . . . . . . . . . . . 404 16 Scope, association, and definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 16.1 Scope of global identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 16.2 Scope of local identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 16.2.1 Local identifiers that are the same as common block names . . . . . . . . . . . . 407 16.2.2 Function results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 16.2.3 Restrictions on generic declarations . . . . . . . . . . . . . . . . . . . . . . . . . 407 16.2.4 Components, type parameters, and bindings . . . . . . . . . . . . . . . . . . . . 408 16.2.5 Argument keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 16.3 Statement and construct entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 16.4 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 16.4.1 Name association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 16.4.2 Pointer association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 16.4.3 Storage association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 16.4.4 Inheritance association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 16.4.5 Establishing associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 16.5 Definition and undefinition of variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 16.5.1 Definition of objects and subobjects . . . . . . . . . . . . . . . . . . . . . . . . . 419 16.5.2 Variables that are always defined . . . . . . . . . . . . . . . . . . . . . . . . . . 419 16.5.3 Variables that are initially defined . . . . . . . . . . . . . . . . . . . . . . . . . . 419 OCT 2003 Final Committee Draft vii J3/03-007R2 Final Committee Draft OCT 2003 16.5.4 Variables that are initially undefined . . . . . . . . . . . . . . . . . . . . . . . . 420 16.5.5 Events that cause variables to become defined . . . . . . . . . . . . . . . . . . . 420 16.5.6 Events that cause variables to become undefined . . . . . . . . . . . . . . . . . . 421 16.5.7 Variable definition context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 A Glossary of technical terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 B Decremental features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 B.1 Deleted features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 B.2 Obsolescent features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 B.2.1 Alternate return . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 B.2.2 Computed GO TO statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 B.2.3 Statement functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 B.2.4 DATA statements among executables . . . . . . . . . . . . . . . . . . . . . . . . 439 B.2.5 Assumed character length functions . . . . . . . . . . . . . . . . . . . . . . . . . 439 B.2.6 Fixed form source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439 B.2.7 CHARACTER* form of CHARACTER declaration . . . . . . . . . . . . . . . . 439 C Extended notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 C.1 Section 4 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 C.1.1 Intrinsic and derived types (4.4, 4.5) . . . . . . . . . . . . . . . . . . . . . . . . 441 C.1.2 Selection of the approximation methods (4.4.2) . . . . . . . . . . . . . . . . . . 442 C.1.3 Type extension and component accessibility (4.5.1.1, 4.5.3) . . . . . . . . . . . . 442 C.1.4 Abstract types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 C.1.5 Pointers (4.5.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 C.1.6 Structure constructors and generic names . . . . . . . . . . . . . . . . . . . . . . 445 C.1.7 Generic type-bound procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 C.1.8 Final subroutines (4.5.5, 4.5.5.1, 4.5.5.2, 4.5.5.3) . . . . . . . . . . . . . . . . . . 448 C.2 Section 5 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 C.2.1 The POINTER attribute (5.1.2.11) . . . . . . . . . . . . . . . . . . . . . . . . . 450 C.2.2 The TARGET attribute (5.1.2.14) . . . . . . . . . . . . . . . . . . . . . . . . . . 451 C.2.3 The VOLATILE attribute (5.1.2.16) . . . . . . . . . . . . . . . . . . . . . . . . . 451 C.3 Section 6 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 C.3.1 Structure components (6.1.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 C.3.2 Allocation with dynamic type (6.3.1) . . . . . . . . . . . . . . . . . . . . . . . . 453 C.3.3 Pointer allocation and association . . . . . . . . . . . . . . . . . . . . . . . . . . 454 C.4 Section 7 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 C.4.1 Character assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 C.4.2 Evaluation of function references . . . . . . . . . . . . . . . . . . . . . . . . . . 455 C.4.3 Pointers in expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 C.4.4 Pointers on the left side of an assignment . . . . . . . . . . . . . . . . . . . . . . 455 C.4.5 An example of a FORALL construct containing a WHERE construct . . . . . . 456 C.4.6 Examples of FORALL statements . . . . . . . . . . . . . . . . . . . . . . . . . . 457 C.5 Section 8 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 C.5.1 Loop control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 C.5.2 The CASE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 C.5.3 Examples of DO constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458 C.5.4 Examples of invalid DO constructs . . . . . . . . . . . . . . . . . . . . . . . . . 460 C.6 Section 9 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 C.6.1 External files (9.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 C.6.2 Nonadvancing input/output (9.2.3.1) . . . . . . . . . . . . . . . . . . . . . . . . 463 C.6.3 Asynchronous input/output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 C.6.4 OPEN statement (9.4.5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 C.6.5 Connection properties (9.4.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 viii Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 C.6.6 CLOSE statement (9.4.6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 C.7 Section 10 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 C.7.1 Number of records (10.3, 10.4, 10.7.2) . . . . . . . . . . . . . . . . . . . . . . . . 467 C.7.2 List-directed input (10.9.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 C.8 Section 11 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 C.8.1 Main program and block data program unit (11.1, 11.3) . . . . . . . . . . . . . 468 C.8.2 Dependent compilation (11.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469 C.8.3 Examples of the use of modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 C.9 Section 12 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 C.9.1 Portability problems with external procedures (12.3.2.2) . . . . . . . . . . . . . 477 C.9.2 Procedures defined by means other than Fortran (12.5.3) . . . . . . . . . . . . . 478 C.9.3 Procedure interfaces (12.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 C.9.4 Abstract interfaces (12.3) and procedure pointer components (4.5) . . . . . . . . 478 C.9.5 Argument association and evaluation (12.4.1.2) . . . . . . . . . . . . . . . . . . 480 C.9.6 Pointers and targets as arguments (12.4.1.2) . . . . . . . . . . . . . . . . . . . . 481 C.9.7 Polymorphic Argument Association (12.4.1.3) . . . . . . . . . . . . . . . . . . . 482 C.10 Section 15 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 C.10.1 Runtime environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 C.10.2 Examples of Interoperation between Fortran and C Functions . . . . . . . . . . 484 C.11 Section 16 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 C.11.1 Examples of host association (16.4.1.3) . . . . . . . . . . . . . . . . . . . . . . . 489 C.11.2 Rules ensuring unambiguous generics (16.2.3) . . . . . . . . . . . . . . . . . . . 490 C.12 Array feature notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 C.12.1 Summary of features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 C.12.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 C.12.3 FORmula TRANslation and array processing . . . . . . . . . . . . . . . . . . . 501 C.12.4 Sum of squared residuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502 C.12.5 Vector norms: infinity-norm and one-norm . . . . . . . . . . . . . . . . . . . . . 502 C.12.6 Matrix norms: infinity-norm and one-norm . . . . . . . . . . . . . . . . . . . . . 502 C.12.7 Logical queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 C.12.8 Parallel computations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 C.12.9 Example of element-by-element computation . . . . . . . . . . . . . . . . . . . . 504 C.12.10 Bit manipulation and inquiry procedures . . . . . . . . . . . . . . . . . . . . . . 504 D Syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505 D.1 Extract of all syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505 D.2 Syntax rule cross-reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 E Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555 OCT 2003 Final Committee Draft ix J3/03-007R2 Final Committee Draft OCT 2003 x Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 List of Tables 2.1 Requirements on statement ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2 Statements allowed in scoping units . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1 Special characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1 Subscript order value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 7.1 Type of operands and results for intrinsic operators . . . . . . . . . . . . . . . . . 121 7.2 Interpretation of the numeric intrinsic operators . . . . . . . . . . . . . . . . . . . 133 7.3 Interpretation of the character intrinsic operator // . . . . . . . . . . . . . . . . . 134 7.4 Interpretation of the relational intrinsic operators . . . . . . . . . . . . . . . . . . 134 7.5 Interpretation of the logical intrinsic operators . . . . . . . . . . . . . . . . . . . . 135 7.6 The values of operations involving logical intrinsic operators . . . . . . . . . . . . 136 7.7 Categories of operations and relative precedence . . . . . . . . . . . . . . . . . . . 136 7.8 Type conformance for the intrinsic assignment statement . . . . . . . . . . . . . . 139 7.9 Numeric conversion and the assignment statement . . . . . . . . . . . . . . . . . . 141 13.1 Characteristics of the result of NULL ( ) . . . . . . . . . . . . . . . . . . . . . . . . 341 15.1 Names of C characters with special semantics . . . . . . . . . . . . . . . . . . . . . 392 15.2 Interoperability between Fortran and C types . . . . . . . . . . . . . . . . . . . . . 396 OCT 2003 Final Committee Draft xi J3/03-007R2 Final Committee Draft OCT 2003 Foreword ISO (the International Organization for Standardization) and IEC (the International Electrotechni- cal Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activ- ity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and nongovernmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft International Standards adopted by the joint technical committee are circu- lated to national bodies for voting. Publication of an International Standard requires approval by at least 75% of the national bodies casting a vote. International Standard ISO/IEC 1539-1 was prepared by Joint Technical Committee ISO/IEC/JTC1, Information technology, Subcommittee SC22, Programming languages, their environments and system software interfaces. This fourth edition cancels and replaces the third edition (ISO/IEC 1539-1:1997), which has been tech- nically revised. ISO/IEC 1539 consists of the following parts, under the general title Information technology -- Pro- gramming languages -- Fortran: -- Part 1: Base language -- Part 2: Varying length character strings -- Part 3: Conditional Compilation The annexes of this part of ISO/IEC 1539 are for information only. xii Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 Introduction Standard programming language Fortran This part of the international standard comprises the specification of the base Fortran language, infor- mally known as Fortran 2003. With the limitations noted in 1.6.2, the syntax and semantics of Fortran 95 are contained entirely within Fortran 2003. Therefore, any standard-conforming Fortran 95 program not affected by such limitations is a standard conforming Fortran 2003 program. New features of Fortran 2003 can be compatibly incorporated into such Fortran 95 programs, with any exceptions indicated in the text of this part of the standard. Fortran 2003 contains several extensions to Fortran 95; among them are: (1) Derived-type enhancements: parameterized derived types (allows the kind, length, or shape of a derived type's components to be chosen when the derived type is used), mixed compo- nent accessibility (allows different components to have different accessibility), public entities of private type, improved structure constructors, and finalizers. (2) Object oriented programming support: enhanced data abstraction (allows one type to ex- tend the definition of another type), polymorphism (allows the type of a variable to vary at runtime), dynamic type allocation, SELECT TYPE construct (allows a choice of execu- tion flow depending upon the type a polymorphic object currently has), and type-bound procedures. (3) The ASSOCIATE construct (allows a complex expression or object to be denoted by a simple symbol). (4) Data manipulation enhancements: allocatable components, deferred type parameters, VOL- ATILE attribute, explicit type specification in array constructors, INTENT specification of pointer arguments, specified lower bounds of pointer assignment and pointer rank remap- ping, extended initialization expressions, MAX and MIN intrinsics for character type, and enhanced complex constants. (5) Input/output enhancements: asynchronous transfer operations (allows a program to con- tinue to process data while an input/output transfer occurs), stream access (allows access to a file without reference to any record structure), user specified transfer operations for derived types, user specified control of rounding during format conversions, the FLUSH statement, named constants for preconnected units, regularization of input/output keywords, and ac- cess to input/output error messages. (6) Procedure pointers. (7) Scoping enhancements: the ability to rename defined operators (supports greater data ab- straction) and control of host association into interface bodies. (8) Support for IEC 60559 (IEEE 754) exceptions and arithmetic (to the extent a processor's arithmetic supports the IEC standard). (9) Interoperability with the C programming language (allows portable access to many libraries and the low-level facilities provided by C and allows the portable use of Fortran libraries by programs written in C). (10) Support for international usage: (ISO 10646) and choice of decimal or comma in numeric formatted input/output. (11) Enhanced integration with the host operating system: access to command line arguments, environment variables, and the processor's error messages. OCT 2003 Final Committee Draft xiii J3/03-007R2 Final Committee Draft OCT 2003 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 A Decremental features B Extended notes C Syntax rules D Index E xiv Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 1Information technology -- Programming languages -- 2Fortran -- 3Part 1: 4Base Language 5Section 1: Overview 61.1 Scope 7ISO/IEC 1539 is a multipart International Standard; the parts are published separately. This publi- 8cation, ISO/IEC 1539-1, which is the first part, specifies the form and establishes the interpretation 9of programs expressed in the base Fortran language. The purpose of this part of ISO/IEC 1539 is to 10promote portability, reliability, maintainability, and efficient execution of Fortran programs for use on 11a variety of computing systems. The second part, ISO/IEC 1539-2, defines additional facilities for the 12manipulation of character strings of variable length. The third part, ISO/IEC 1539-3, defines a stan- 13dard conditional compilation facility for Fortran. A processor conforming to part 1 need not conform to 14ISO/IEC 1539-2 or ISO/IEC 1539-3; however, conformance to either assumes conformance to this part. 15Throughout this publication, the term "this standard" refers to ISO/IEC 1539-1. 161.2 Processor 17The combination of a computing system and the mechanism by which programs are transformed for use 18on that computing system is called a processor in this standard. 191.3 Inclusions 20This 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. 251.4 Exclusions 26This 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 OCT 2003 Final Committee Draft 1 J3/03-007R2 Final Committee Draft OCT 2003 1 1.5, 2 (5) The size or complexity of a program and its data that will exceed the capacity of any 3 particular computing system or the capability of a particular processor, 4 (6) The physical properties of the representation of quantities and the method of rounding, 5 approximating, or computing numeric values on a particular processor, 6 (7) The physical properties of input/output records, files, and units, or 7 (8) The physical properties and implementation of storage. 81.5 Conformance 9A program (2.2.1) is a standard-conforming program if it uses only those forms and relationships 10described 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 12to be standard conforming. 13A 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 an intrinsic type with a kind type parameter value not supported by the processor (4.4); 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. 33However, in a format specification that is not part of a FORMAT statement (10.1.1), a processor need not 34detect or report the use of deleted or obsolescent features, or the use of additional forms or relationships. 35A standard-conforming processor may allow additional forms and relationships provided that such ad- 36ditions do not conflict with the standard forms and relationships. However, a standard-conforming 37processor may allow additional intrinsic procedures even though this could cause a conflict with the 38name of a procedure in a standard-conforming program. If such a conflict occurs and involves the name 39of an external procedure, the processor is permitted to use the intrinsic procedure unless the name is 40given the EXTERNAL attribute (5.1.2.6) in the scoping unit (16). A standard-conforming program 41shall not use nonstandard intrinsic procedures or modules that have been added by the processor. 42Because a standard-conforming program may place demands on a processor that are not within the 43scope of this standard or may include standard items that are not portable, such as external procedures 44defined by means other than Fortran, conformance to this standard does not ensure that a program will 45execute consistently on all or any standard-conforming processors. 2 Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 1In some cases, this standard allows the provision of facilities that are not completely specified in the 2standard. These facilities are identified as processor dependent. They shall be provided, with methods 3or 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. 41.6 Compatibility 5Each standard since ISO 1539:1980 (informally referred to as Fortran 77), defines more intrinsic 6procedures than the previous one. Therefore, a Fortran program conforming to an older standard may 7have a different interpretation under a newer standard if it invokes an external procedure having the 8same name as one of the new standard intrinsic procedures, unless that procedure is specified to have 9the EXTERNAL attribute. 101.6.1 Fortran 95 compatibility 11Except as identified in this section, this standard is an upward compatible extension to the preceding 12Fortran International Standard, ISO/IEC 1539-1:1997 (Fortran 95). Any standard-conforming Fortran 1395 program remains standard-conforming under this standard. The following Fortran 95 features may 14have different interpretations in this standard: 15 (1) Earlier Fortran standards had the concept of printing, meaning that column one of format- 16 ted output had special meaning for a processor-dependent (possibly empty) set of logical 17 units. This could be neither detected nor specified by a standard-specified means. The 18 interpretation of the first column is not specified by this standard. 19 (2) This standard specifies a different output format for real zero values in list-directed and 20 namelist output. 21 (3) If the processor can distinguish between positive and negative real zero, this standard re- 22 quires different returned values for ATAN2(Y,X) when X < 0 and Y is negative real zero 23 and for LOG(X) and SQRT(X) when X is complex with REAL(X) < 0 and negative zero 24 imaginary part. 251.6.2 Fortran 90 compatibility 26Except for the deleted features noted in Annex B.1, and except as identified in this section, this stan- 27dard is an upward compatible extension to ISO/IEC 1539:1991 (Fortran 90). Any standard-conforming 28Fortran 90 program that does not use one of the deleted features remains standard-conforming under 29this standard. 30The PAD= specifier in the INQUIRE statement in this standard returns the value UNDEFINED if there 31is no connection or the connection is for unformatted input/output. Fortran 90 specified YES. 32Fortran 90 specified that if the second argument to MOD or MODULO was zero, the result was processor 33dependent. This standard specifies that the second argument shall not be zero. OCT 2003 Final Committee Draft 3 J3/03-007R2 Final Committee Draft OCT 2003 11.6.3 FORTRAN 77 compatibility 2Except for the deleted features noted in Annex B.1, and except as identified in this section, this standard 3is an upward compatible extension to ISO 1539:1980 (Fortran 77). Any standard-conforming For- 4tran 77 program that does not use one of the deleted features noted in Annex B.1 and that does not 5depend on the differences specified here remains standard conforming under this standard. This stan- 6dard restricts the behavior for some features that were processor dependent in Fortran 77. Therefore, 7a standard-conforming Fortran 77 program that uses one of these processor-dependent features may 8have a different interpretation under this standard, yet remain a standard-conforming program. The 9following Fortran 77 features may have different interpretations 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 specified 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 2003 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. 311.7 Notation used in this standard 32In this standard, "shall" is to be interpreted as a requirement; conversely, "shall not" is to be interpreted 33as a prohibition. Except where stated otherwise, such requirements and prohibitions apply to programs 34rather than processors. 351.7.1 Informative notes 36Informative notes of explanation, rationale, examples, and other material are interspersed with the 37normative body of this publication. The informative material is nonnormative; it is identified by being 38in shaded, framed boxes that have numbered headings beginning with "NOTE." 391.7.2 Syntax rules 40Syntax rules describe the forms that Fortran lexical tokens, statements, and constructs may take. These 41syntax rules are expressed in a variation of Backus-Naur form (BNF) in which: 42 (1) Characters from the Fortran character set (3.1) are interpreted literally as shown, except 43 where otherwise noted. 4 Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 1 (2) Lower-case italicized letters and words (often hyphenated and abbreviated) represent gen- 2 eral syntactic classes for which particular syntactic entities shall be substituted in actual 3 statements. 4 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 5 (3) The syntactic metasymbols used are: is introduces a syntactic class definition or introduces a syntactic class alternative [ ] encloses an optional item [ ] ... encloses an optionally repeated item that may occur zero or more times continues a syntax rule 6 (4) Each syntax rule is given a unique identifying number of the form Rsnn, where s is a one- 7 or two-digit section number and nn is a two-digit sequence number within that section. 8 The syntax rules are distributed as appropriate throughout the text, and are referenced by 9 number as needed. Some rules in Sections 2 and 3 are more fully described in later sections; 10 in such cases, the section number s is the number of the later section where the rule is 11 repeated. 12 (5) The syntax rules are not a complete and accurate syntax description of Fortran, and cannot 13 be used to generate a Fortran parser automatically; where a syntax rule is incomplete, it is 14 restricted by corresponding constraints and text. NOTE 1.2 An example of the use of the syntax rules is: digit-string is digit [ digit ] ... The following are examples of forms for a digit string allowed by the above rule: digit digit digit digit digit digit digit digit digit digit digit digit digit digit digit If particular entities are substituted for digit, actual digit strings might be: 4 67 1999 10243852 151.7.3 Constraints 16Each constraint is given a unique identifying number of the form Csnn, where s is a one- or two-digit 17section number and nn is a two-digit sequence number within that section. OCT 2003 Final Committee Draft 5 J3/03-007R2 Final Committee Draft OCT 2003 1Often a constraint is associated with a particular syntax rule. Where that is the case, the constraint is 2annotated with the syntax rule number in parentheses. A constraint that is associated with a syntax 3rule constitutes part of the definition of the syntax term defined by the rule. It thus applies in all places 4where the syntax term appears. 5Some constraints are not associated with particular syntax rules. The effect of such a constraint is similar 6to that of a restriction stated in the text, except that a processor is required to have the capability to 7detect and report violations of constraints (1.5). In some cases, a broad requirement is stated in text 8and a subset of the same requirement is also stated as a constraint. This indicates that a standard- 9conforming program is required to adhere to the broad requirement, but that a standard-conforming 10processor is required only to have the capability of diagnosing violations of the constraint. 111.7.4 Assumed syntax rules 12In order to minimize the number of additional syntax rules and convey appropriate constraint informa- 13tion, the following rules are assumed; an explicit syntax rule for a term overrides an assumed rule. The 14letters "xyz" stand for any syntactic class phrase: 15R101 xyz-list is xyz [ , xyz ] ... 16R102 xyz-name is name 17R103 scalar-xyz is xyz 18C101 (R103) scalar-xyz shall be scalar. 191.7.5 Syntax conventions and characteristics 20 (1) Any syntactic class name ending in "-stmt" follows the source form statement rules: it shall 21 be delimited by end-of-line or semicolon, and may be labeled unless it forms part of another 22 statement (such as an IF or WHERE statement). Conversely, everything considered to be 23 a source form statement is given a "-stmt" ending in the syntax rules. 24 (2) The rules on statement ordering are described rigorously in the definition of program-unit 25 (R202). Expression hierarchy is described rigorously in the definition of expr (R722). 26 (3) The suffix "-spec" is used consistently for specifiers, such as input/output statement speci- 27 fiers. It also is used for type declaration attribute specifications (for example, "array-spec" 28 in R510), and in a few other cases. 29 (4) Where reference is made to a type parameter, including the surrounding parentheses, the 30 suffix "-selector" is used. See, for example, "kind-selector" (R404) and "length-selector" 31 (R425). 32 (5) The term "subscript" (for example, R618, R619, and R620) is used consistently in array 33 definitions. 341.7.6 Text conventions 35In the descriptive text, an equivalent English word is frequently used in place of a syntactic term. 36Particular statements and attributes are identified in the text by an upper-case keyword, e.g., "END 37statement". Boldface words are used in the text where they are first defined with a specialized meaning. 38The descriptions of obsolescent features appear in a smaller type size. NOTE 1.3 This sentence is an example of the type size used for obsolescent features. 6 Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 11.8 Deleted and obsolescent features 2This standard protects the users' investment in existing software by including all but five of the language 3elements of Fortran 90 that are not processor dependent. This standard identifies two categories of 4outmoded features. There are five in the first category, deleted features, which consists of features 5considered to have been redundant in Fortran 77 and largely unused in Fortran 90. Those in the second 6category, obsolescent features, are considered to have been redundant in Fortran 90 and Fortran 95, 7but are still frequently used. 81.8.1 Nature of deleted features 9 (1) Better methods existed in Fortran 77. 10 (2) These features are not included in Fortran 95 or this revision of Fortran. 111.8.2 Nature of obsolescent features 12 (1) Better methods existed in Fortran 90 and Fortran 95. 13 (2) It is recommended that programmers use these better methods in new programs and convert 14 existing code to these methods. 15 (3) These features are identified in the text of this document by a distinguishing type font 16 (1.7.6). 17 (4) If the use of these features becomes insignificant, future Fortran standards committees should 18 consider deleting them. 19 (5) The next Fortran standards committee should consider for deletion only those language 20 features that appear in the list of obsolescent features. 21 (6) Processors supporting the Fortran language should support these features as long as they 22 continue to be used widely in Fortran programs. 231.9 Normative references 24The following standards contain provisions which, through reference in this standard, constitute provi- 25sions of this standard. At the time of publication, the editions indicated were valid. All standards are 26subject to revision, and parties to agreements based on this standard are encouraged to investigate the 27possibility of applying the most recent editions of the standards indicated below. Members of IEC and 28ISO maintain registers of currently valid International Standards. 29ISO/IEC 646:1991, Information technology--ISO 7-bit coded character set for information interchange. 30ISO/IEC 646:1991 (International Reference Version) is the international equivalent of ANSI X3.4-1986, 31commonly known as ASCII. 32ISO 8601:1988, Data elements and interchange formats--Information interchange-- 33Representation of dates and times. 34ISO/IEC 9899:1999, Information technology--Programming languages--C. 35This standard refers to ISO/IEC 9899:1999 as the C standard. 36ISO/IEC 10646-1:2000, Information technology--Universal multiple-octet coded character set (UCS)-- 37Part 1: Architecture and basic multilingual plane. 38IEC 60559 (1989-01), Binary floating-point arithmetic for microprocessor systems. 39Because IEC 60559 (1989-01) was originally IEEE 754-1985, Standard for binary floating-point arith- 40metic, and is widely known by this name, this standard refers to it as the IEEE standard. OCT 2003 Final Committee Draft 7 J3/03-007R2 Final Committee Draft OCT 2003 8 Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 1Section 2: Fortran terms and concepts 22.1 High level syntax 3This section introduces the terms associated with program units and other Fortran concepts above the 4construct, statement, and expression levels and illustrates their relationships. The notation used in this 5standard 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. 6R201 program is program-unit 7 [ program-unit ] ... 8A program shall contain exactly one main-program program-unit or a main program defined by means 9other than Fortran, but not both. 10R202 program-unit is main-program 11 or external-subprogram 12 or module 13 or block-data 14R1101 main-program is [ program-stmt ] 15 [ specification-part ] 16 [ execution-part ] 17 [ internal-subprogram-part ] 18 end-program-stmt 19R203 external-subprogram is function-subprogram 20 or subroutine-subprogram 21R1223 function-subprogram is function-stmt 22 [ specification-part ] 23 [ execution-part ] 24 [ internal-subprogram-part ] 25 end-function-stmt 26R1231 subroutine-subprogram is subroutine-stmt 27 [ specification-part ] 28 [ execution-part ] 29 [ internal-subprogram-part ] 30 end-subroutine-stmt 31R1104 module is module-stmt 32 [ specification-part ] 33 [ module-subprogram-part ] 34 end-module-stmt 35R1116 block-data is block-data-stmt 36 [ specification-part ] 37 end-block-data-stmt 38R204 specification-part is [ use-stmt ] ... 39 [ import-stmt ] ... 40 [ implicit-part ] 41 [ declaration-construct ] ... OCT 2003 Final Committee Draft 9 J3/03-007R2 Final Committee Draft OCT 2003 1R205 implicit-part is [ implicit-part-stmt ] ... 2 implicit-stmt 3R206 implicit-part-stmt is implicit-stmt 4 or parameter-stmt 5 or format-stmt 6 or entry-stmt 7R207 declaration-construct is derived-type-def 8 or entry-stmt 9 or enum-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-declaration-stmt 16 or stmt-function-stmt 17R208 execution-part is executable-construct 18 [ execution-part-construct ] ... 19R209 execution-part-construct is executable-construct 20 or format-stmt 21 or entry-stmt 22 or data-stmt 23R210 internal-subprogram-part is contains-stmt 24 internal-subprogram 25 [ internal-subprogram ] ... 26R211 internal-subprogram is function-subprogram 27 or subroutine-subprogram 28R1107 module-subprogram-part is contains-stmt 29 module-subprogram 30 [ module-subprogram ] ... 31R1108 module-subprogram is function-subprogram 32 or subroutine-subprogram 33R212 specification-stmt is access-stmt 34 or allocatable-stmt 35 or asynchronous-stmt 36 or bind-stmt 37 or common-stmt 38 or data-stmt 39 or dimension-stmt 40 or equivalence-stmt 41 or external-stmt 42 or intent-stmt 43 or intrinsic-stmt 44 or namelist-stmt 45 or optional-stmt 46 or pointer-stmt 47 or protected-stmt 48 or save-stmt 49 or target-stmt 50 or volatile-stmt 51 or value-stmt 52R213 executable-construct is action-stmt 53 or associate-construct 54 or case-construct 10 Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 1 or do-construct 2 or forall-construct 3 or if-construct 4 or select-type-construct 5 or where-construct 6R214 action-stmt is allocate-stmt 7 or assignment-stmt 8 or backspace-stmt 9 or call-stmt 10 or close-stmt 11 or continue-stmt 12 or cycle-stmt 13 or deallocate-stmt 14 or endfile-stmt 15 or end-function-stmt 16 or end-program-stmt 17 or end-subroutine-stmt 18 or exit-stmt 19 or flush-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 37C201 (R208) An execution-part shall not contain an end-function-stmt, end-program-stmt, or end- 38 subroutine-stmt. 392.2 Program unit concepts 40Program units are the fundamental components of a Fortran program. A program unit may be 41a main program, an external subprogram, a module, or a block data program unit. A subprogram 42may be a function subprogram or a subroutine subprogram. A module contains definitions that are 43to be made accessible to other program units. A block data program unit is used to specify initial 44values for data objects in named common blocks. Each type of program unit is described in Section 4511 or 12. An external subprogram is a subprogram that is not in a main program, a module, or 46another subprogram. An internal subprogram is a subprogram that is in a main program or another 47subprogram. A module subprogram is a subprogram that is in a module but is not an internal 48subprogram. 49A program unit consists of a set of nonoverlapping scoping units. A scoping unit is OCT 2003 Final Committee Draft 11 J3/03-007R2 Final Committee Draft OCT 2003 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. 4A scoping unit that immediately surrounds another scoping unit is called the host scoping unit (often 5abbreviated to host). 62.2.1 Program 7A program consists of exactly one main program, any number (including zero) of other kinds of program 8units, and any number (including zero) of external procedures and other entities defined by means other 9than Fortran. NOTE 2.2 There is a restriction that there shall be no more than one unnamed block data program unit (11.3). This standard places no ordering requirement on the program units that constitute a program, but because the public portions of a module are required to be available by the time a module reference (11.2.1) is processed, a processor may require a particular order of processing of the program units. 102.2.2 Main program 11The Fortran main program is described in 11.1. 122.2.3 Procedure 13A procedure encapsulates an arbitrary sequence of actions that may be invoked directly during program 14execution. Procedures are either functions or subroutines. A function is a procedure that is invoked 15in an expression; its invocation causes a value to be computed which is then used in evaluating the 16expression. The variable that returns the value of a function is called the result variable. A subroutine 17is a procedure that is invoked in a CALL statement, by a defined assignment statement, or by some 18operations on derived-type entities. Unless it is a pure procedure, a subroutine may be used to change 19the program state by changing the values of any of the data objects accessible to the subroutine; unless 20it is a pure procedure, a function may do this in addition to computing the function value. 21Procedures are described further in Section 12. 222.2.3.1 External procedure 23An external procedure is a procedure that is defined by an external subprogram or by means other 24than Fortran. An external procedure may be invoked by the main program or by any procedure of a 25program. 262.2.3.2 Module procedure 27A module procedure is a procedure that is defined by a module subprogram (R1108). The module 28containing the subprogram is the host scoping unit of the module procedure. 292.2.3.3 Internal procedure 30An internal procedure is a procedure that is defined by an internal subprogram (R211). The containing 31main program or subprogram is the host scoping unit of the internal procedure. An internal procedure 12 Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 1is local to its host in the sense that the internal procedure is accessible within the host scoping unit and 2all its other internal procedures but is not accessible elsewhere. 32.2.3.4 Interface block 4An interface body describes an abstract interface or the interface of a dummy procedure, external 5procedure, procedure pointer, or type-bound procedure. 6An interface block is a specific interface block, an abstract interface block, or a generic interface block. 7A specific interface block is a collection of interface bodies. A generic interface block may also be used 8to specify that procedures may be invoked 9 (1) By using a generic name, 10 (2) By using a defined operator, 11 (3) By using a defined assignment, or 12 (4) For derived-type input/output. 132.2.4 Module 14A module contains (or accesses from other modules) definitions that are to be made accessible to other 15program units. These definitions include data object declarations, type definitions, procedure definitions, 16and interface blocks. A scoping unit in another program unit may access the definitions in a module. 17Modules are further described in Section 11. 182.3 Execution concepts 19Each Fortran statement is classified as either an executable statement or a nonexecutable statement. 20There are restrictions on the order in which statements may appear in a program unit, and not all 21executable statements may appear in all contexts. 222.3.1 Executable/nonexecutable statements 23Program execution is a sequence, in time, of actions. An executable statement is an instruction to 24perform or control one or more of these actions. Thus, the executable statements of a program unit 25determine the behavior of the program unit. The executable statements are all of those that make up 26the syntactic class executable-construct. 27Nonexecutable statements do not specify actions; they are used to configure the program environment 28in which actions take place. The nonexecutable statements are all those not classified as executable. 292.3.2 Statement order 30The syntax rules of subclause 2.1 specify the statement order within program units and subprograms. 31These rules are illustrated in Table 2.1 and Table 2.2. Table 2.1 shows the ordering rules for statements 32and applies to all program units, subprograms, and interface bodies. Vertical lines delineate varieties of 33statements that may be interspersed and horizontal lines delineate varieties of statements that shall not 34be interspersed. Internal or module subprograms shall follow a CONTAINS statement. Between USE 35and CONTAINS statements in a subprogram, nonexecutable statements generally precede executable 36statements, although the ENTRY statement, FORMAT statement, and DATA statement may appear 37among the executable statements. Table 2.2 shows which statements are allowed in a scoping unit. OCT 2003 Final Committee Draft 13 J3/03-007R2 Final Committee Draft OCT 2003 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 enumeration declarations, statements statements 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, enum statements, procedure declaration statements, and specification statements. 2) The scoping unit of a module does not include any module subprograms that the module contains. 12.3.3 The END statement 2An end-program-stmt, end-function-stmt, end-subroutine-stmt, end-module-stmt, or end-block-data-stmt 3is an END statement. Each program unit, module subprogram, and internal subprogram shall have 4exactly one END statement. The end-program-stmt, end-function-stmt, and end-subroutine-stmt state- 5ments are executable, and may be branch target statements (8.2). Executing an end-program-stmt causes 6normal termination of execution of the program. Executing an end-function-stmt or end-subroutine-stmt 14 Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 1is equivalent to executing a return-stmt with no scalar-int-expr. 2The end-module-stmt and end-block-data-stmt statements are nonexecutable. 32.3.4 Execution sequence 4If a program contains a Fortran main program, execution of the program begins with the first executable 5construct of the main program. The execution of a main program or subprogram involves execution of 6the executable constructs within its scoping unit. When a procedure is invoked, execution begins with 7the first executable construct appearing after the invoked entry point. With the following exceptions, 8the effect of execution is as if the executable constructs are executed in the order in which they appear 9in the main program or subprogram until a STOP, RETURN, or END statement is executed. The 10exceptions are the following: 11 (1) Execution of a branching statement (8.2) changes the execution sequence. These statements 12 explicitly specify a new starting place for the execution sequence. 13 (2) CASE constructs, DO constructs, IF constructs, and SELECT TYPE constructs contain 14 an internal statement structure and execution of these constructs involves implicit internal 15 branching. See Section 8 for the detailed semantics of each of these constructs. 16 (3) END=, ERR=, and EOR= specifiers may result in a branch. 17 (4) Alternate returns may result in a branch. 18Internal subprograms may precede the END statement of a main program or a subprogram. The 19execution sequence excludes all such definitions. 20Normal termination of execution of the program occurs if a STOP statement or end-program-stmt is 21executed. Normal termination of execution of a program also may occur during execution of a procedure 22defined by a companion processor (C standard 5.1.2.2.3 and 7.20.4.3). If normal termination of execution 23occurs within a Fortran program unit and the program incorporates procedures defined by a companion 24processor, the process of execution termination shall include the effect of executing the C exit() function 25(C standard 7.20.4.3). 262.4 Data concepts 27Nonexecutable statements are used to specify the characteristics of the data environment. This includes 28typing variables, declaring arrays, and defining new types. 292.4.1 Type 30A type is a named category of data that is characterized by a set of values, a syntax for denoting 31these values, and a set of operations that interpret and manipulate the values. This central concept is 32described in 4.1. 33A type may be parameterized, in which case the set of data values, the syntax for denoting them, and 34the set of operations depend on the values of one or more parameters. Such a parameter is called a type 35parameter (4.2). 36There are two categories of types: intrinsic types and derived types. 372.4.1.1 Intrinsic type 38An intrinsic type is a type that is defined by the language, along with operations, and is always 39accessible. The intrinsic types are integer, real, complex, character, and logical. The properties of 40intrinsic types are described in 4.4. The intrinsic type parameters are KIND and LEN. OCT 2003 Final Committee Draft 15 J3/03-007R2 Final Committee Draft OCT 2003 1The kind type parameter indicates the decimal exponent range for the integer type (4.4.1), the 2decimal precision and exponent range for the real and complex types (4.4.2, 4.4.3), and the representation 3methods for the character and logical types (4.4.4, 4.4.5). The character length parameter specifies 4the number of characters for the character type. 52.4.1.2 Derived type 6A derived type is a type that is not defined by the language but requires a type definition to declare its 7components. A scalar object of such a derived type is called a structure (5.1.1.1). Derived types may 8be parameterized. Assignment of structures is defined intrinsically (7.4.1.3), but there are no intrinsic 9operations for structures. For each derived type, a structure constructor is available to provide values 10(4.5.9). In addition, data objects of derived type may be used as procedure arguments and function 11results, and may appear in input/output lists. If additional operations are needed for a derived type, 12they shall be supplied as procedure definitions. 13Derived types are described further in 4.5. 142.4.2 Data value 15Each intrinsic type has associated with it a set of values that a datum of that type may take, depending 16on the values of the type parameters. The values for each intrinsic type are described in 4.4. The values 17that objects of a derived type may assume are determined by the type definition, type parameter values, 18and the sets of values of its components. 192.4.3 Data entity 20A data entity is a data object, the result of the evaluation of an expression, or the result of the execution 21of a function reference (called the function result). A data entity has a type and type parameters; it 22may have a data value (an exception is an undefined variable). Every data entity has a rank and is thus 23either a scalar or an array. 242.4.3.1 Data object 25A data object (often abbreviated to object) is a constant (4.1.2), a variable (6), or a subobject of a 26constant. The type and type parameters of a named data object may be specified explicitly (5.1) or 27implicitly (5.3). 28Subobjects are portions of certain objects that may be referenced and defined (variables only) inde- 29pendently of the other portions. These include portions of arrays (array elements and array sections), 30portions of character strings (substrings), portions of complex objects (real and imaginary parts), and 31portions of structures (components). Subobjects are themselves data objects, but subobjects are refer- 32enced only by object designators or intrinsic functions. A subobject of a variable is a variable. Subobjects 33are described in Section 6. 34Objects referenced by a name are: a named scalar (a scalar object) 35 a named array (an array object) 36Subobjects referenced by an object designator are: an array element (a scalar subobject) an array section (an array subobject) a structure component (a scalar or an array subobject) 37 a substring (a scalar subobject) 16 Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 1Subobjects of complex objects may also be referenced by intrinsic functions. 22.4.3.1.1 Variable 3A variable may have a value and may be defined and redefined during execution of a program. 4A named local variable of the scoping unit of a module, main program, or subprogram, is a named 5variable that is a local entity of the scoping unit, is not a dummy argument, is not in COMMON, does 6not have the BIND attribute, and is not accessed by use or host association. A subobject of a named 7local variable is also a local variable. 82.4.3.1.2 Constant 9A constant has a value and cannot become defined, redefined, or undefined during execution of a 10program. 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). 122.4.3.1.3 Subobject of a constant 13A subobject of a constant is a portion of a constant. The portion referenced may depend on the 14value 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. 152.4.3.2 Expression 16An expression (7.1) produces a data entity when evaluated. An expression represents either a data 17reference or a computation; it is formed from operands, operators, and parentheses. The type, type 18parameters, value, and rank of an expression result are determined by the rules in Section 7. 192.4.3.3 Function reference 20A function reference (12.4.2) produces a data entity when the function is executed during expression 21evaluation. The type, type parameters, and rank of a function result are determined by the interface of 22the function (12.2.2). The value of a function result is determined by execution of the function. 232.4.4 Scalar 24A 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. 25The rank of a scalar is zero. The shape of a scalar is represented by a rank-one array of size zero. OCT 2003 Final Committee Draft 17 J3/03-007R2 Final Committee Draft OCT 2003 12.4.5 Array 2An array is a set of scalar data, all of the same type and type parameters, whose individual elements 3are arranged in a rectangular pattern. An array element is one of the individual elements in the array 4and is a scalar. An array section is a subset of the elements of an array and is itself an array. 5An array may have up to seven dimensions, and any extent (number of elements) in any dimension. 6The rank of the array is the number of dimensions; its size is the total number of elements, which is 7equal to the product of the extents. An array may have zero size. The shape of an array is determined 8by its rank and its extent in each dimension, and may be represented as a rank-one array whose elements 9are the extents. All named arrays shall be declared, and the rank of a named array is specified in its 10declaration. The rank of a named array, once declared, is constant; the extents may be constant or may 11vary during execution. 12Two arrays are conformable if they have the same shape. A scalar is conformable with any array. Any 13intrinsic operation defined for scalar objects may be applied to conformable objects. Such operations 14are performed element-by-element to produce a resultant array conformable with the array operands. 15Element-by-element operation means corresponding elements of the operand arrays are involved in a 16scalar operation to produce the corresponding element in the result array, and all such element operations 17may be performed in any order or simultaneously. Such an operation is described as elemental. 18A rank-one array may be constructed from scalars and other arrays and may be reshaped into any 19allowable array shape (4.7). 20Arrays may be of any intrinsic type or derived type and are described further in 6.2. 212.4.6 Pointer 22A data pointer is a data entity that has the POINTER attribute. A procedure pointer is a procedure 23entity that has the POINTER attribute. A pointer is either a data pointer or a procedure pointer. 24A pointer is associated with a target by pointer assignment (7.4.2). A data pointer may also be 25associated with a target by allocation (6.3.1). A pointer is disassociated following execution of a 26NULLIFY statement, following pointer assignment with a disassociated pointer, by default initialization, 27or by explicit initialization. A data pointer may also be disassociated by execution of a DEALLOCATE 28statement. A disassociated pointer is not associated with a target (16.4.2). 29A pointer that is not associated shall not be referenced or defined. 30If a data pointer is an array, the rank is declared, but the extents are determined when the pointer is 31associated with a target. 322.4.7 Storage 33Many of the facilities of this standard make no assumptions about the physical storage characteristics of 34data objects. However, program units that include storage association dependent features shall observe 35the storage restrictions described in 16.4.3. 362.5 Fundamental terms 37The following terms are defined here and used throughout this standard. 18 Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 12.5.1 Name and designator 2A name is used to identify a program constituent, such as a program unit, named variable, named 3constant, dummy argument, or derived type. The rules governing the construction of names are given 4in 3.2.1. A designator is a name followed by zero or more component selectors, array section selectors, 5array element selectors, and substring selectors. 6An object designator is a designator for a data object. A procedure designator is a designator for 7a procedure. NOTE 2.5 An object name is a special case of an object designator. 82.5.2 Keyword 9The term keyword is used in two ways. 10 (1) It is used to describe a word that is part of the syntax of a statement. These keywords are 11 not reserved words; that is, names with the same spellings are allowed. In the syntax rules, 12 such keywords appear literally. In descriptive text, this meaning is denoted by the term 13 "keyword" without any modifier. Examples of statement keywords are: IF, READ, UNIT, 14 KIND, and INTEGER. 15 (2) It is used to denote names that identify items in a list. In actual argument lists, type 16 parameter lists, and structure constructors, items may be identified by a preceding keyword= 17 rather than their position within the list. An argument keyword is the name of a dummy 18 argument in the interface for the procedure being referenced, a type parameter keyword 19 is the name of a type parameter in the type being specified, and a component keyword 20 is the name of a component in a structure constructor. 21R215 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. 222.5.3 Association 23Association is name association (16.4.1), pointer association (16.4.2), storage association (16.4.3), 24or inheritance association (16.4.4). Name association is argument association, host association, use 25association, linkage association, or construct association. 26Storage association causes different entities to use the same storage. Any association permits an entity 27to be identified by different names in the same scoping unit or by the same name or different names in 28different scoping units. 292.5.4 Declaration 30The term declaration refers to the specification of attributes for various program entities. Often this 31involves specifying the type of a named data object or specifying the shape of a named array object. 322.5.5 Definition 33The term definition is used in two ways. OCT 2003 Final Committee Draft 19 J3/03-007R2 Final Committee Draft OCT 2003 1 (1) It refers to the specification of derived types and procedures. 2 (2) When an object is given a valid value during program execution, it is said to become 3 defined. This is often accomplished by execution of an assignment or input statement. 4 When a variable does not have a predictable value, it is said to be undefined. Similarly, 5 when a pointer is associated with a target or nullified, its pointer association status is said 6 to become defined. When the association status of a pointer is not predictable, its pointer 7 association status is said to be undefined. 8Section 16 describes the ways in which variables may become defined and undefined. 92.5.6 Reference 10A data object reference is the appearance of the data object designator in a context requiring its 11value at that point during execution. 12A procedure reference is the appearance of the procedure designator, operator symbol, or assignment 13symbol in a context requiring execution of the procedure at that point. An occurrence of user-defined 14derived-type input/output (10.6.5) or derived-type finalization (4.5.5.1) is also a procedure reference. 15The appearance of a data object designator or procedure designator in an actual argument list does not 16constitute a reference to that data object or procedure unless such a reference is necessary to complete 17the specification of the actual argument. 18A module reference is the appearance of a module name in a USE statement (11.2.1). 192.5.7 Intrinsic 20The qualifier intrinsic has two meanings. 21 (1) The qualifier signifies that the term to which it is applied is defined in this standard. In- 22 trinsic applies to types, procedures, modules, assignment statements, and operators. All 23 intrinsic types, procedures, assignments, and operators may be used in any scoping unit 24 without further definition or specification. Intrinsic modules may be accessed by use as- 25 sociation. Intrinsic procedures and modules defined in this standard are called standard 26 intrinsic procedures and standard intrinsic modules, respectively. 27 (2) The qualifier applies to procedures or modules that are provided by a processor but are not 28 defined in this standard (13, 14, 15.1). Such procedures and modules are called nonstandard 29 intrinsic procedures and nonstandard intrinsic modules, respectively. 302.5.8 Operator 31An operator specifies a computation involving one (unary operator) or two (binary operator) data values 32(operands). This standard specifies a number of intrinsic operators (e.g., the arithmetic operators +, ­, 33*, /, and ** with numeric operands and the logical operators .AND., .OR., etc. with logical operands). 34Additional operators may be defined within a program (7.1.3). 352.5.9 Sequence 36A sequence is a set ordered by a one-to-one correspondence with the numbers 1, 2, through n. The 37number of elements in the sequence is n. A sequence may be empty, in which case it contains no elements. 38The elements of a nonempty sequence are referred to as the first element, second element, etc. The 39nth element, where n is the number of elements in the sequence, is called the last element. An empty 40sequence has no first or last element. 20 Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 12.5.10 Companion processors 2A processor has one or more companion processors. A companion processor is a processor-dependent 3mechanism by which global data and procedures may be referenced or defined. A companion processor 4may be a mechanism that references and defines such entities by a means other than Fortran (12.5.3), 5it may be the Fortran processor itself, or it may be another Fortran processor. If there is more than 6one companion processor, the means by which the Fortran processor selects among them are processor 7dependent. 8If a procedure is defined by means of a companion processor that is not the Fortran processor itself, 9this standard refers to the C function that defines the procedure, although the procedure need not be 10defined 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. OCT 2003 Final Committee Draft 21 J3/03-007R2 Final Committee Draft OCT 2003 22 Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 1Section 3: Characters, lexical tokens, and source form 2This section describes the Fortran character set and the various lexical tokens such as names and oper- 3ators. This section also describes the rules for the forms that Fortran programs may take. 43.1 Processor character set 5The processor character set is processor dependent. The structure of a processor character set is: 6 (1) Control characters 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) 13The letters, digits, underscore, and special characters make up the Fortran character set. 14R301 character is alphanumeric-character 15 or special-character 16R302 alphanumeric-character is letter 17 or digit 18 or underscore 19Except for the currency symbol, the graphics used for the characters shall be as given in 3.1.1, 3.1.2, 203.1.3, and 3.1.4. However, the style of any graphic is not specified. 21The default character type shall support a character set that includes the Fortran character set. By sup- 22plying nondefault character types, the processor may support additional character sets. The characters 23available in the ASCII and ISO 10646 character sets are specified by ISO/IEC 646:1991 (International 24Reference Version) and ISO/IEC 10646-1:2000 UCS-4, respectively; the characters available in other non- 25default character types are not specified by this standard, except that one character in each nondefault 26character type shall be designated as a blank character to be used as a padding character. 273.1.1 Letters 28The twenty-six letters are: 29 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 30The set of letters defines the syntactic class letter. The processor character set shall include lower- 31case and upper-case letters. A lower-case letter is equivalent to the corresponding upper-case letter in 32program 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) OCT 2003 Final Committee Draft 23 J3/03-007R2 Final Committee Draft OCT 2003 NOTE 3.1 (cont.) Call Big_Complex_Operation (NDate) 13.1.2 Digits 2The ten digits are: 3 0 1 2 3 4 5 6 7 8 9 4The ten digits define the syntactic class digit. 53.1.3 Underscore 6R303 underscore is 7The underscore may be used as a significant character in a name. 83.1.4 Special characters 9The special characters are shown in Table 3.1. Table 3.1: Special characters Character Name of character Character Name of character Blank ; Semicolon = Equals ! Exclamation point + Plus " Quotation mark or quote - Minus % Percent * Asterisk & Ampersand / Slash ~ Tilde \ Backslash < Less than ( Left parenthesis > Greater than ) Right parenthesis ? Question mark [ Left square bracket ' Apostrophe ] Right square bracket ` Grave accent { Left curly bracket ^ Circumflex accent } Right curly bracket | Vertical line , Comma $ Currency symbol . Decimal point or period # Number sign : Colon @ Commercial at 10The special characters define the syntactic class special-character. Some of the special characters are 11used for operator symbols, bracketing, and various forms of separating and delimiting other lexical 12tokens. 133.1.5 Other characters 14Additional characters may be representable in the processor, but may appear only in comments (3.3.1.1, 153.3.2.1), character constants (4.4.4), input/output records (9.1.1), and character string edit descriptors 16(10.2.1). 24 Final Committee Draft OCT 2003 OCT 2003 Final Committee Draft J3/03-007R2 13.2 Low-level syntax 2The low-level syntax describes the fundamental lexical tokens of a program unit. Lexical tokens are 3sequences of characters that constitute the building blocks of a program. They are keywords, names, 4literal constants other than complex literal constants, operators, labels, delimiters, comma, =, =>, :, ::, 5;, and %. 63.2.1 Names 7Names are used for various entities such as variables, program units, dummy arguments, named con- 8stants, and derived types. 9R304 name is letter [ alphanumeric-character ] ... 10C301 (R304) The maximum length of a name is 63 characters. NOTE 3.2 Examples of names: A1 NAME LENGTH (single underscore) S P R E A D O U T (two consecutive underscores) TRAILER (trailing underscore) NOTE 3.3 The word "name" always denotes this particular syntactic form. The word "identifier" is used where entities may be identified by other syntactic forms or by values; its particular meaning depends on the context in which it is used. 113.2.2 Constants 12R305 constant is literal-constant 13 or named-constant 14R306 literal-constant is int-literal-constant 15 or real-literal-constant 16 or complex-literal-constant 17 or logical-literal-constant 18 or char-literal-constant 19 or boz-literal-constant 20R307 named-constant is name 21R308 int-constant is constant 22C302 (R308)int-constant shall be of type integer. 23R309 char-constant is constant 24C303