WORKING DRAFT J3/07-007 5th January 2007 18:42 This is an internal working document of J3. 2006/01/05 WORKING DRAFT J3/07-007 Contents 1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Inclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.4 Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.5 Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.6 Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6.1 New intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6.2 New intrinsic data type and operator . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6.3 Fortran 2003 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6.4 Fortran 95 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.6.5 Fortran 90 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.6.6 FORTRAN 77 compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.7 Notation used in this part of ISO/IEC 1539 . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.7.1 Applicability of requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.7.2 Informative notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.7.3 Syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.7.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.7.5 Assumed syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.7.6 Syntax conventions and characteristics . . . . . . . . . . . . . . . . . . . . . . . 7 1.7.7 Text conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.8 Deleted and obsolescent features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.8.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.8.2 Nature of deleted features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.8.3 Nature of obsolescent features . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.9 Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2 Fortran terms and concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1 High level syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 Program unit concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.1 Program units and scoping units . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.2 Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.3 Main program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.4 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.5 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.6 Submodule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3 Execution concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.1 Statement classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.2 Program execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.3 Executable/nonexecutable statements . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3.4 Statement order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3.5 The END statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.6 Execution sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4 Data concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.1 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.2 Data value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.3 Data entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 i J3/07-007 WORKING DRAFT 2006/01/05 2.4.4 Scalar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.4.5 Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.4.6 Co-array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.7 Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.8 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5 Fundamental terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.1 Name and designator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.2 Keyword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.3 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.4 Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.5 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.6 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.7 Intrinsic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.8 Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.9 Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.10 Companion processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3 Lexical tokens, source form, and macro processing . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1 Processor character set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.1 Letters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.2 Digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.3 Underscore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.4 Special characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.5 Other characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2 Low-level syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.1 Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.2.3 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.2.4 Statement labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.5 Delimiters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3 Source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.1 Free source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.2 Fixed source form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.4 Including source text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.5 Macro processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.5.1 Macro definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.5.2 Macro expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.1 The concept of type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.1.1 Set of values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.1.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.1.3 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2 Type parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3 Relationship of types and values to objects . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.3.1 Type specifiers and type compatibility . . . . . . . . . . . . . . . . . . . . . . . 45 4.4 Intrinsic types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.4.1 Classification and specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.4.2 Integer type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.4.3 Real type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.4.4 Complex type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.4.5 Character type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.4.6 Logical type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.4.7 Bits type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 ii 2006/01/05 WORKING DRAFT J3/07-007 4.5 Derived types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.5.1 Derived type concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.5.2 Derived-type definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.5.3 Derived-type parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.5.4 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.5.5 Type-bound procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.5.6 Final subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.5.7 Type extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.5.8 Derived-type values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.5.9 Derived-type specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.5.10 Construction of derived-type values . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.5.11 Derived-type operations and assignment . . . . . . . . . . . . . . . . . . . . . . 80 4.6 Enumerations and enumerators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.7 Construction of array values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5 Attribute declarations and specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.2 Type declaration statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.2.2 Automatic data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.2.3 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2.4 Examples of type declaration statements . . . . . . . . . . . . . . . . . . . . . . 87 5.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.3.1 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.3.2 Accessibility attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.3.3 ALLOCATABLE attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.3.4 ASYNCHRONOUS attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.3.5 BIND attribute for data entities . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.3.6 CONTIGUOUS attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.3.7 DIMENSION attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.3.8 EXTERNAL attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.3.9 INTENT attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.3.10 INTRINSIC attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.3.11 OPTIONAL attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.3.12 PARAMETER attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.3.13 POINTER attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.3.14 PROTECTED attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.3.15 SAVE attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.3.16 TARGET attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.3.17 VALUE attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.3.18 VOLATILE attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.4 Attribute specification statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.4.1 Accessibility statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.4.2 ALLOCATABLE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.4.3 ASYNCHRONOUS statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.4.4 BIND statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.4.5 CONTIGUOUS statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.4.6 DATA statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.4.7 DIMENSION statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.4.8 INTENT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.4.9 OPTIONAL statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.4.10 PARAMETER statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.4.11 POINTER statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.4.12 PROTECTED statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 iii J3/07-007 WORKING DRAFT 2006/01/05 5.4.13 SAVE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.4.14 TARGET statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.4.15 VALUE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.4.16 VOLATILE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.5 IMPLICIT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.6 NAMELIST statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.7 Storage association of data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.7.1 EQUIVALENCE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.7.2 COMMON statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.7.3 Restrictions on common and equivalence . . . . . . . . . . . . . . . . . . . . . . 115 6 Use of data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.1 Scalars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 6.1.1 Substrings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 6.1.2 Structure components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 6.1.3 Complex parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 6.1.4 Type parameter inquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6.2 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6.2.1 Whole arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6.2.2 Array elements and array sections . . . . . . . . . . . . . . . . . . . . . . . . . . 122 6.2.3 Image selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 6.3 Dynamic association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 6.3.1 ALLOCATE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 6.3.2 NULLIFY statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 6.3.3 DEALLOCATE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 6.3.4 STAT= specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 6.3.5 ERRMSG= specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 7 Expressions and assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.1 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.1.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.1.2 Form of an expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.1.3 Precedence of operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 7.1.4 Evaluation of operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 7.1.5 Intrinsic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 7.1.6 Defined operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 7.1.7 Evaluation of operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 7.1.8 Integrity of parentheses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 7.1.9 Type, type parameters, and shape of an expression . . . . . . . . . . . . . . . . 152 7.1.10 Conformability rules for elemental operations . . . . . . . . . . . . . . . . . . . 154 7.1.11 Specification expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 7.1.12 Initialization expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 7.2 Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 7.2.1 Assignment statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 7.2.2 Pointer assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 7.2.3 Masked array assignment ­ WHERE . . . . . . . . . . . . . . . . . . . . . . . . 166 7.2.4 FORALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 8 Execution control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 8.1 Executable constructs containing blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 8.1.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 8.1.2 Rules governing blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 8.1.3 ASSOCIATE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 8.1.4 BLOCK construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 iv 2006/01/05 WORKING DRAFT J3/07-007 8.1.5 CASE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 8.1.6 CRITICAL construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 8.1.7 DO construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 8.1.8 IF construct and statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 8.1.9 SELECT TYPE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 8.1.10 EXIT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 8.2 Branching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 8.2.1 GO TO statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 8.2.2 Computed GO TO statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 8.2.3 Arithmetic IF statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 8.3 CONTINUE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 8.4 STOP statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 8.5 Image execution control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 8.5.1 Image control statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 8.5.2 SYNC ALL statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 8.5.3 SYNC TEAM statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 8.5.4 SYNC IMAGES statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 8.5.5 NOTIFY and QUERY statements . . . . . . . . . . . . . . . . . . . . . . . . . . 203 8.5.6 SYNC MEMORY statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 8.5.7 STAT= and ERRMSG= specifiers in image execution control statements . . . . 206 9 Input/output statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9.1 Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9.1.1 Formatted record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9.1.2 Unformatted record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 9.1.3 Endfile record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 9.2 External files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 9.2.1 File existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 9.2.2 File access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 9.2.3 File position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 9.2.4 File storage units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 9.3 Internal files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 9.4 File connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 9.4.1 Connection modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 9.4.2 Unit existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 9.4.3 Connection of a file to a unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 9.4.4 Preconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 9.4.5 OPEN statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 9.4.6 CLOSE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 9.5 Data transfer statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 9.5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 9.5.2 Control information list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 9.5.3 Data transfer input/output list . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 9.5.4 Execution of a data transfer input/output statement . . . . . . . . . . . . . . . 231 9.5.5 Termination of data transfer statements . . . . . . . . . . . . . . . . . . . . . . 243 9.6 Waiting on pending data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 9.6.1 Wait operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 9.6.2 WAIT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 9.7 File positioning statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 9.7.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 9.7.2 BACKSPACE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 9.7.3 ENDFILE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 9.7.4 REWIND statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 9.8 FLUSH statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 v J3/07-007 WORKING DRAFT 2006/01/05 9.9 File inquiry statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 9.9.1 Forms of the INQUIRE statement . . . . . . . . . . . . . . . . . . . . . . . . . . 247 9.9.2 Inquiry specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 9.9.3 Inquire by output list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 9.10 Error, end-of-record, and end-of-file conditions . . . . . . . . . . . . . . . . . . . . . . . . 254 9.10.1 Error conditions and the ERR= specifier . . . . . . . . . . . . . . . . . . . . . . 255 9.10.2 End-of-file condition and the END= specifier . . . . . . . . . . . . . . . . . . . . 255 9.10.3 End-of-record condition and the EOR= specifier . . . . . . . . . . . . . . . . . . 255 9.10.4 IOSTAT= specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 9.10.5 IOMSG= specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 9.11 Restrictions on input/output statements . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 10 Input/output editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 10.1 Format specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 10.2 Explicit format specification methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 10.2.1 FORMAT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 10.2.2 Character format specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 10.3 Form of a format item list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 10.3.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 10.3.2 Edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 10.3.3 Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 10.4 Interaction between input/output list and format . . . . . . . . . . . . . . . . . . . . . . 262 10.5 Positioning by format control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 10.6 Decimal symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 10.7 Data edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 10.7.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 10.7.2 Numeric and bits editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 10.7.3 Logical editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 10.7.4 Character editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 10.7.5 Generalized editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 10.7.6 User-defined derived-type editing . . . . . . . . . . . . . . . . . . . . . . . . . . 274 10.8 Control edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 10.8.1 Position editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 10.8.2 Slash editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 10.8.3 Colon editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 10.8.4 SS, SP, and S editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 10.8.5 P editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 10.8.6 BN and BZ editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 10.8.7 RU, RD, RZ, RN, RC, and RP editing . . . . . . . . . . . . . . . . . . . . . . . 277 10.8.8 DC and DP editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 10.9 Character string edit descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 10.10 List-directed formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 10.10.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 10.10.2 Values and value separators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 10.10.3 List-directed input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 10.10.4 List-directed output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 10.11 Namelist formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 10.11.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 10.11.2 Name-value subsequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 10.11.3 Namelist input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 10.11.4 Namelist output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 11 Program units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 11.1 Main program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 vi 2006/01/05 WORKING DRAFT J3/07-007 11.2 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 11.2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 11.2.2 The USE statement and use association . . . . . . . . . . . . . . . . . . . . . . . 291 11.2.3 Submodules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 11.3 Block data program units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 12 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 12.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 12.2 Procedure classifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 12.2.1 Procedure classification by reference . . . . . . . . . . . . . . . . . . . . . . . . . 297 12.2.2 Procedure classification by means of definition . . . . . . . . . . . . . . . . . . . 297 12.3 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 12.3.1 Characteristics of procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 12.3.2 Characteristics of dummy arguments . . . . . . . . . . . . . . . . . . . . . . . . 298 12.3.3 Characteristics of function results . . . . . . . . . . . . . . . . . . . . . . . . . . 299 12.4 Procedure interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 12.4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 12.4.2 Implicit and explicit interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 12.4.3 Specification of the procedure interface . . . . . . . . . . . . . . . . . . . . . . . 300 12.5 Procedure reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 12.5.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 12.5.2 Actual arguments, dummy arguments, and argument association . . . . . . . . . 313 12.5.3 Function reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 12.5.4 Subroutine reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 12.5.5 Resolving named procedure references . . . . . . . . . . . . . . . . . . . . . . . . 326 12.5.6 Resolving type-bound procedure references . . . . . . . . . . . . . . . . . . . . . 328 12.6 Procedure definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 12.6.1 Intrinsic procedure definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 12.6.2 Procedures defined by subprograms . . . . . . . . . . . . . . . . . . . . . . . . . 329 12.6.3 Definition and invocation of procedures by means other than Fortran . . . . . . 336 12.6.4 Statement function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 12.7 Pure procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 12.8 Elemental procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 12.8.1 Elemental procedure declaration and interface . . . . . . . . . . . . . . . . . . . 339 12.8.2 Elemental function actual arguments and results . . . . . . . . . . . . . . . . . . 339 12.8.3 Elemental subroutine actual arguments . . . . . . . . . . . . . . . . . . . . . . . 340 13 Intrinsic procedures and modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 13.1 Classes of intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 13.2 Arguments to intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 13.2.1 General rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 13.2.2 The shape of array arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 13.2.3 Mask arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 13.2.4 Arguments to collective subroutines . . . . . . . . . . . . . . . . . . . . . . . . . 342 13.3 Bit model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 13.4 Numeric models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 13.5 Standard generic intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 13.5.1 Numeric functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 13.5.2 Mathematical functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 13.5.3 Character functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 13.5.4 Kind functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 13.5.5 Miscellaneous type conversion functions . . . . . . . . . . . . . . . . . . . . . . . 346 13.5.6 Numeric inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 13.5.7 Array inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 vii J3/07-007 WORKING DRAFT 2006/01/05 13.5.8 Other inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 13.5.9 Bit manipulation procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 13.5.10 Floating-point manipulation functions . . . . . . . . . . . . . . . . . . . . . . . . 347 13.5.11 Vector and matrix multiply functions . . . . . . . . . . . . . . . . . . . . . . . . 348 13.5.12 Array reduction functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 13.5.13 Array construction functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 13.5.14 Array location functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 13.5.15 Collective subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 13.5.16 Null function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 13.5.17 Allocation transfer procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 13.5.18 Random number subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 13.5.19 System environment procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 13.6 Specific names for standard intrinsic functions . . . . . . . . . . . . . . . . . . . . . . . . 350 13.7 Specifications of the standard intrinsic procedures . . . . . . . . . . . . . . . . . . . . . . 351 13.8 Standard intrinsic modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 13.8.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 13.8.2 The ISO FORTRAN ENV intrinsic module . . . . . . . . . . . . . . . . . . . . 435 14 Exceptions and IEEE arithmetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439 14.1 Derived types and constants defined in the modules . . . . . . . . . . . . . . . . . . . . . 440 14.2 The exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 14.3 The rounding modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 14.4 Underflow mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 14.5 Halting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 14.6 The floating-point status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 14.7 Exceptional values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 14.8 IEEE arithmetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 14.9 Tables of the procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 14.9.1 Inquiry functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 14.9.2 Elemental functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 14.9.3 Kind function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 14.9.4 Elemental subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 14.9.5 Nonelemental subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 14.10 Specifications of the procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 14.11 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462 15 Interoperability with C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 15.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 15.2 The ISO C BINDING intrinsic module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 15.2.1 Summary of contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 15.2.2 Named constants and derived types in the module . . . . . . . . . . . . . . . . . 467 15.2.3 Procedures in the module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 15.3 Interoperability between Fortran and C entities . . . . . . . . . . . . . . . . . . . . . . . 472 15.3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 15.3.2 Interoperability of intrinsic types . . . . . . . . . . . . . . . . . . . . . . . . . . 472 15.3.3 Interoperability with C pointer types . . . . . . . . . . . . . . . . . . . . . . . . 474 15.3.4 Interoperability of derived types and C struct types . . . . . . . . . . . . . . . . 475 15.3.5 Interoperability of scalar variables . . . . . . . . . . . . . . . . . . . . . . . . . . 476 15.3.6 Interoperability of array variables . . . . . . . . . . . . . . . . . . . . . . . . . . 476 15.3.7 Interoperability of procedures and procedure interfaces . . . . . . . . . . . . . . 477 15.4 Interoperation with C global variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 15.4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 15.4.2 Binding labels for common blocks and variables . . . . . . . . . . . . . . . . . . 480 15.5 Interoperation with C functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480 viii 2006/01/05 WORKING DRAFT J3/07-007 15.5.1 Definition and reference of interoperable procedures . . . . . . . . . . . . . . . . 480 15.5.2 Binding labels for procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481 15.5.3 Exceptions and IEEE arithmetic procedures . . . . . . . . . . . . . . . . . . . . 481 16 Scope, association, and definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 16.1 Identifiers and entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 16.2 Scope of global identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 16.3 Scope of local identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 16.3.1 Classes of local identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 16.3.2 Local identifiers that are the same as common block names . . . . . . . . . . . . 485 16.3.3 Function results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485 16.3.4 Components, type parameters, and bindings . . . . . . . . . . . . . . . . . . . . 485 16.3.5 Argument keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486 16.4 Statement and construct entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486 16.5 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 16.5.1 Name association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 16.5.2 Pointer association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491 16.5.3 Storage association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 16.5.4 Inheritance association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 16.5.5 Establishing associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 16.6 Definition and undefinition of variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 16.6.1 Definition of objects and subobjects . . . . . . . . . . . . . . . . . . . . . . . . . 497 16.6.2 Variables that are always defined . . . . . . . . . . . . . . . . . . . . . . . . . . 498 16.6.3 Variables that are initially defined . . . . . . . . . . . . . . . . . . . . . . . . . . 498 16.6.4 Variables that are initially undefined . . . . . . . . . . . . . . . . . . . . . . . . 498 16.6.5 Events that cause variables to become defined . . . . . . . . . . . . . . . . . . . 498 16.6.6 Events that cause variables to become undefined . . . . . . . . . . . . . . . . . . 501 16.6.7 Variable definition context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 16.6.8 Pointer association context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 Annex A (informative)Glossary of technical terms . . . . . . . . . . . . . . . . . . . . . . . . . . 505 Annex B (informative)Decremental features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519 B.1 Deleted features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519 B.2 Obsolescent features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 B.2.1 Alternate return . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 B.2.2 Computed GO TO statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 B.2.3 Statement functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 B.2.4 DATA statements among executables . . . . . . . . . . . . . . . . . . . . . . . . 521 B.2.5 Assumed character length functions . . . . . . . . . . . . . . . . . . . . . . . . . 521 B.2.6 Fixed form source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521 B.2.7 CHARACTER* form of CHARACTER declaration . . . . . . . . . . . . . . . . 521 Annex C (informative)Extended notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523 C.1 Clause 4 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523 C.1.1 Selection of the approximation methods (4.4.3) . . . . . . . . . . . . . . . . . . 523 C.1.2 Type extension and component accessibility (4.5.2.2, 4.5.4) . . . . . . . . . . . . 523 C.1.3 Abstract types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524 C.1.4 Pointers (4.5.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 C.1.5 Structure constructors and generic names . . . . . . . . . . . . . . . . . . . . . . 526 C.1.6 Generic type-bound procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 528 C.1.7 Final subroutines (4.5.6, 4.5.6.2, 4.5.6.3, 4.5.6.4) . . . . . . . . . . . . . . . . . . 529 C.2 Clause 5 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531 C.2.1 The POINTER attribute (5.3.13) . . . . . . . . . . . . . . . . . . . . . . . . . . 531 C.2.2 The TARGET attribute (5.3.16) . . . . . . . . . . . . . . . . . . . . . . . . . . . 532 ix J3/07-007 WORKING DRAFT 2006/01/05 C.2.3 The VOLATILE attribute (5.3.18) . . . . . . . . . . . . . . . . . . . . . . . . . . 532 C.3 Clause 6 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533 C.3.1 Structure components (6.1.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533 C.3.2 Allocation with dynamic type (6.3.1) . . . . . . . . . . . . . . . . . . . . . . . . 535 C.3.3 Pointer allocation and association . . . . . . . . . . . . . . . . . . . . . . . . . . 535 C.4 Clause 7 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536 C.4.1 Character assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536 C.4.2 Evaluation of function references . . . . . . . . . . . . . . . . . . . . . . . . . . 536 C.4.3 Pointers in expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536 C.4.4 Pointers on the left side of an assignment . . . . . . . . . . . . . . . . . . . . . . 537 C.4.5 An example of a FORALL construct containing a WHERE construct . . . . . . 537 C.4.6 Examples of FORALL statements . . . . . . . . . . . . . . . . . . . . . . . . . . 538 C.5 Clause 8 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539 C.5.1 Loop control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539 C.5.2 The CASE construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539 C.5.3 Examples of DO constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539 C.5.4 Examples of invalid DO constructs . . . . . . . . . . . . . . . . . . . . . . . . . 542 C.6 Clause 9 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 C.6.1 External files (9.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 C.6.2 Nonadvancing input/output (9.2.3.1) . . . . . . . . . . . . . . . . . . . . . . . . 544 C.6.3 Asynchronous input/output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545 C.6.4 OPEN statement (9.4.5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546 C.6.5 Connection properties (9.4.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 C.6.6 CLOSE statement (9.4.6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 C.7 Clause 10 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 C.7.1 Number of records (10.4, 10.5, 10.8.2) . . . . . . . . . . . . . . . . . . . . . . . . 548 C.7.2 List-directed input (10.10.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549 C.8 Clause 11 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550 C.8.1 Main program and block data program unit (11.1, 11.3) . . . . . . . . . . . . . 550 C.8.2 Dependent compilation (11.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550 C.8.3 Examples of the use of modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 552 C.8.4 Modules with submodules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558 C.9 Clause 12 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563 C.9.1 Portability problems with external procedures (12.4.3.5) . . . . . . . . . . . . . 563 C.9.2 Procedures defined by means other than Fortran (12.6.3) . . . . . . . . . . . . . 563 C.9.3 Procedure interfaces (12.4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564 C.9.4 Abstract interfaces (12.4) and procedure pointer components (4.5) . . . . . . . . 564 C.9.5 Argument association and evaluation (12.5.2) . . . . . . . . . . . . . . . . . . . 566 C.9.6 Pointers and targets as arguments (12.5.2.5, 12.5.2.7, 12.5.2.8) . . . . . . . . . . 567 C.9.7 Polymorphic Argument Association (12.5.2.10) . . . . . . . . . . . . . . . . . . . 568 C.10 Clause 13 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570 C.10.1 Module for THIS IMAGE and IMAGE INDEX . . . . . . . . . . . . . . . . . . 570 C.10.2 Collective co-array subroutine variations . . . . . . . . . . . . . . . . . . . . . . 570 C.11 Clause 15 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571 C.11.1 Runtime environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571 C.11.2 Examples of Interoperation between Fortran and C Functions . . . . . . . . . . 571 C.12 Clause 16 notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577 C.12.1 Examples of host association (16.5.1.4) . . . . . . . . . . . . . . . . . . . . . . . 577 C.12.2 Rules ensuring unambiguous generics (12.4.3.4.5) . . . . . . . . . . . . . . . . . 578 C.13 Array feature notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582 C.13.1 Summary of features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582 C.13.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583 C.13.3 FORmula TRANslation and array processing . . . . . . . . . . . . . . . . . . . 588 C.13.4 Sum of squared residuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589 x 2006/01/05 WORKING DRAFT J3/07-007 C.13.5 Vector norms: infinity-norm and one-norm . . . . . . . . . . . . . . . . . . . . . 589 C.13.6 Matrix norms: infinity-norm and one-norm . . . . . . . . . . . . . . . . . . . . . 589 C.13.7 Logical queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589 C.13.8 Parallel computations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590 C.13.9 Example of element-by-element computation . . . . . . . . . . . . . . . . . . . . 590 C.13.10 Bit manipulation and inquiry procedures . . . . . . . . . . . . . . . . . . . . . . 591 Annex D (informative)Processor Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593 D.1 Unspecified Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593 D.2 Processor Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593 D.3 Unresolved Technical Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596 Annex E (informative)Syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599 E.1 Extract of all syntax rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599 E.2 Syntax rule cross-reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644 Annex F (informative)Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659 xi J3/07-007 WORKING DRAFT 2006/01/05 xii 2006/01/05 WORKING DRAFT J3/07-007 List of Tables 2.1 Requirements on statement ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 Statements allowed in scoping units . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1 Special characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1 Subscript order value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 7.2 Categories of operations and relative precedence . . . . . . . . . . . . . . . . . . . 137 7.3 Type of operands and results for intrinsic operators . . . . . . . . . . . . . . . . . 141 7.4 Interpretation of the numeric intrinsic operators . . . . . . . . . . . . . . . . . . . 143 7.6 Interpretation of the character intrinsic operator // . . . . . . . . . . . . . . . . . 145 7.7 Interpretation of the logical intrinsic operators . . . . . . . . . . . . . . . . . . . . 146 7.8 The values of operations involving logical intrinsic operators . . . . . . . . . . . . 146 7.9 Interpretation of the bits intrinsic operators . . . . . . . . . . . . . . . . . . . . . . 147 7.10 The values of bits intrinsic operations other than // . . . . . . . . . . . . . . . . . 147 7.11 Interpretation of the relational intrinsic operators . . . . . . . . . . . . . . . . . . 148 7.12 Type conformance for the intrinsic assignment statement . . . . . . . . . . . . . . 158 7.13 Numeric conversion and the assignment statement . . . . . . . . . . . . . . . . . . 160 7.14 Bits conversion and the assignment statement . . . . . . . . . . . . . . . . . . . . . 161 10.1 E and D exponent forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 10.2 EN exponent forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 10.3 ES exponent forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 13.1 Characteristics of the result of NULL ( ) . . . . . . . . . . . . . . . . . . . . . . . . 412 15.1 Names of C characters with special semantics . . . . . . . . . . . . . . . . . . . . . 468 15.2 Interoperability between Fortran and C types . . . . . . . . . . . . . . . . . . . . . 472 xiii J3/07-007 WORKING DRAFT 2006/01/05 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 activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organi- zations, 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. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. The main task of the joint technical committee is to prepare International Standards. Draft Interna- tional Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. 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 fifth edition cancels and replaces the fourth edition (ISO/IEC 1539-1:2004), which has been tech- nically revised. It also incorporates the Technical Corrigenda ISO/IEC 1539-1:2004/Cor. 1:2005 and ISO/IEC 15391:2004/Cor. 2:2006. 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 xiv 2006/01/05 WORKING DRAFT J3/07-007 Introduction International Standard programming language Fortran This part of the International Standard comprises the specification of the base Fortran language, infor- mally known as Fortran 2008. With the limitations noted in 1.6.3, the syntax and semantics of Fortran 2003 are contained entirely within Fortran 2008. Therefore, any standard-conforming Fortran 2003 pro- gram not affected by such limitations is a standard-conforming Fortran 2008 program. New features of Fortran 2008 can be compatibly incorporated into such Fortran 2003 programs, with any exceptions indicated in the text of this part of ISO/IEC 1539. Fortran 2008 contains several extensions to Fortran 2003; some of these are listed below. (1) The maximum rank of an array has been increased from seven to fifteen. (2) Performance enhancements: The DO CONCURRENT construct, which allows loop itera- tions to be executed in any order or potentially concurrently. (3) Pointers can be initialized to point to a target. (4) Performance enhancements: CONTIGUOUS attribute. (5) The ATAN intrinsic is extended so that ATAN (Y, X) is ATAN2 (Y,X). (6) Allocatable components of recursive type. (7) The MOLD= specifier has been added to the ALLOCATE statement. (8) OPEN statement enhancements that allow the processor to select a unit number when opening an external unit. Such a unit number is guaranteed not to interfere with any program-managed unit numbers. (9) The BLOCK construct (allows declarations within executable statements). (10) A disassociated or deallocated actual argument can correspond to an optional nonpointer nonallocatable dummy argument. (11) The concept of variable now includes references to pointer functions which return associated pointers. (12) The COMPILER VERSION and COMPILER OPTIONS functions provide information about the translation phase of the execution of a program. (13) The real and imaginary parts of a COMPLEX variable can be selected using a component- like syntax. (14) Scoped macros which can generate whole Fortran statements and subprograms. (15) A FINDLOC intrinsic was added and a BACK= argument was also added to MAXLOC and MINLOC. (16) Parallel programming support: SPMD parallel programming, co-arrays for data exchange between images, image control statements, and collective procedures. (17) A BITS data type for non-numeric programming and enhanced handling of binary, octal, and hexadecimal constants. (18) The G0 edit descriptor. (19) Additional mathematical intrinsic functions for computing Bessel functions, error functions, the Gamma function, and generalized L2 norms. J3 internal note Unresolved Technical Issue 080 The laundry list needs to be redone at a later time. RAH suggests going down the list of things in spread sheet and having a big feature and a little feature list. xv J3/07-007 WORKING DRAFT 2006/01/05 Organization of this part of ISO/IEC 1539 This part of ISO/IEC 1539 is organized in 16 clauses, dealing with 8 conceptual areas. These 8 areas, and the clauses in which they are treated, are: High/low level concepts Clauses 1, 2, 3 Data concepts Clauses 4, 5, 6 Computations Clauses 7, 13, 14 Execution control Clause 8 Input/output Clauses 9, 10 Program units Clauses 11, 12 Interoperability with C Clause 15 Scoping and association rules Clause 16 It also contains the following nonnormative material: Glossary A Decremental features B Extended notes C Syntax rules D Index E xvi 2006/01/05 WORKING DRAFT J3/07-007 Information technology -- Programming languages -- 1 2Fortran -- 3Part 1: Base Language 4 51 Overview 1.1 Scope 6 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; this has been largely subsumed by allocatable char- 13acters with deferred length parameters. The third part, ISO/IEC 1539-3, defines a standard conditional 14compilation facility for Fortran. A processor conforming to part 1 need not conform to ISO/IEC 1539-2 or ISO/IEC 1539-3; however, conformance to either assumes conformance to this part. 15 161.2 Processor 17The combination of a computing system and the mechanism by which programs are transformed for use on that computing system is called a processor in this part of ISO/IEC 1539. 18 191.3 Inclusions This part of ISO/IEC 1539 specifies 20 (1) the forms that a program written in the Fortran language may take, 21 (2) the rules for interpreting the meaning of a program and its data, 22 (3) the form of the input data to be processed by such a program, and 23 (4) the form of the output data resulting from the use of such a program. 24 251.4 Exclusions This part of ISO/IEC 1539 does not specify 26 (1) the mechanism by which programs are transformed for use on computing systems, 27 (2) the operations required for setup and control of the use of programs on computing systems, 28 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 part of ISO/IEC 1539 fails to establish an 32 interpretation except for the processor detection and reporting requirements in items (2) to (8) of 1.5, 1 J3/07-007 WORKING DRAFT 2006/01/05 1 (5) the size or complexity of a program and its data that will exceed the capacity of any 2 particular computing system or the capability of a particular processor, (6) the mechanism for determining the number of images of a program, 3 4 (7) the physical properties of an image or the relationship between images and the computational 5 elements of a computing system, J3 internal note Unresolved Technical Issue 099 Image properties not specified by the standard. According to later notes, we don't specify this kind of stuff. I think it belongs in Exclusions. It definitely does not belong in a note! 6 (8) the physical properties of the representation of quantities and the method of rounding, 7 approximating, or computing numeric values on a particular processor, (9) the physical properties of input/output records, files, and units, or 8 (10) the physical properties and implementation of storage. 9 101.5 Conformance 11A program (2.2.2) is a standard-conforming program if it uses only those forms and relationships 12described herein and if the program has an interpretation according to this part of ISO/IEC 1539. A 13program unit (2.2.1) conforms to this part of ISO/IEC 1539 if it can be included in a program in a 14manner that allows the program to be standard conforming. A processor conforms to this part of ISO/IEC 1539 if: 15 16 (1) it executes any standard-conforming program in a manner that fulfills the interpretations 17 herein, subject to any limits that the processor may impose on the size and complexity of 18 the program; 19 (2) it contains the capability to detect and report the use within a submitted program unit of 20 a form designated herein as obsolescent, insofar as such use can be detected by reference to 21 the numbered syntax rules and constraints; 22 (3) it contains the capability to detect and report the use within a submitted program unit of 23 an additional form or relationship that is not permitted by the numbered syntax rules or 24 constraints, including the deleted features described in Annex B; 25 (4) it contains the capability to detect and report the use within a submitted program unit of an intrinsic type with a kind type parameter value not supported by the processor (4.4); 26 27 (5) it contains the capability to detect and report the use within a submitted program unit of 28 source form or characters not permitted by Clause 3; 29 (6) it contains the capability to detect and report the use within a submitted program of name 30 usage not consistent with the scope rules for names, labels, operators, and assignment 31 symbols in Clause 16; 32 (7) it contains the capability to detect and report the use within a submitted program unit of 33 intrinsic procedures whose names are not defined in Clause 13; and (8) it contains the capability to detect and report the reason for rejecting a submitted program. 34 35However, in a format specification that is not part of a FORMAT statement (10.2.1), a processor need not 36detect or report the use of deleted or obsolescent features, or the use of additional forms or relationships. 37A standard-conforming processor may allow additional forms and relationships provided that such ad- 38ditions do not conflict with the standard forms and relationships. However, a standard-conforming 39processor may allow additional intrinsic procedures even though this could cause a conflict with the 2 2006/01/05 WORKING DRAFT J3/07-007 1name of a procedure in a standard-conforming program. If such a conflict occurs and involves the name 2of an external procedure, the processor is permitted to use the intrinsic procedure unless the name is 3given the EXTERNAL attribute (5.3.8) in the scoping unit (2.2.1). A standard-conforming program 4shall not use nonstandard intrinsic procedures or modules that have been added by the processor. 5Because a standard-conforming program may place demands on a processor that are not within the 6scope of this part of ISO/IEC 1539 or may include standard items that are not portable, such as 7external procedures defined by means other than Fortran, conformance to this part of ISO/IEC 1539 8does not ensure that a program will execute consistently on all or any standard-conforming processors. 9In some cases, the provision of facilities that are not completely specified in thisstandard is allowed. 10These facilities are identified as processor dependent. They shall be provided, with methods or 11semantics 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. 1.6 Compatibility 12 1.6.1 New intrinsic procedures 13 14Each Fortran International Standard since ISO 1539:1980 (informally referred to as Fortran 77), defines 15more intrinsic procedures than the previous one. Therefore, a Fortran program conforming to an older 16standard may have a different interpretation under a newer standard if it invokes an external procedure 17having the same name as one of the new standard intrinsic procedures, unless that procedure is specified 18to have the EXTERNAL attribute. 1.6.2 New intrinsic data type and operator 19 20This part of ISO/IEC 1539 specifies a new intrinsic type, BITS, which will conflict with a derived type 21of the same name. 22This part of ISO/IEC 1539 specifies a new intrinsic operator, .XOR., which might conflict with a user- 23defined operator of the same name, has a different precedence from that of a user-defined operator, and 24a different syntax from that of a user-defined unary operator. 1.6.3 Fortran 2003 compatibility 25 26Except as identified in this subclause, this part of ISO/IEC 1539 is an upward compatible extension 27to the preceding Fortran International Standard, ISO/IEC 1539-1:2004 (Fortran 2003). Any standard- 28conforming Fortran 2003 program that does not use a derived type called BITS, and does not use a user-defined operator called .XOR., remains standard-conforming under this part of ISO/IEC 1539. 29 1.6.4 Fortran 95 compatibility 30 31Except as identified in this subclause, this part of ISO/IEC 1539 is an upward compatible extension to 32ISO/IEC 1539-1:1997 (Fortran 95). Any standard-conforming Fortran 95 program that does not use a 3 J3/07-007 WORKING DRAFT 2006/01/05 1derived type called BITS or a user-defined operator called .XOR. remains standard-conforming under 2this part of ISO/IEC 1539. The following Fortran 95 features may have different interpretations in this part of ISO/IEC 1539. 3 4 (1) Earlier Fortran standards had the concept of printing, meaning that column one of formatted 5 output had special meaning for a processor-dependent (possibly empty) set of external 6 files. This could be neither detected nor specified by a standard-specified means. The interpretation of the first column is not specified by this part of ISO/IEC 1539. 7 8 (2) This part of ISO/IEC 1539 specifies a different output format for real zero values in list- 9 directed and namelist output. 10 (3) If the processor can distinguish between positive and negative real zero, this part of ISO/IEC 11 1539 requires different returned values for ATAN2(Y,X) when X < 0 and Y is negative real 12 zero and for LOG(X) and SQRT(X) when X is complex with REAL(X) < 0 and negative 13 zero imaginary part. 1.6.5 Fortran 90 compatibility 14 15Except for the deleted features noted in Annex B.1, and except as identified in this subclause, this part 16of ISO/IEC 1539 is an upward compatible extension to ISO/IEC 1539:1991 (Fortran 90). Any standard- 17conforming Fortran 90 program that does not use a derived type called BITS, a user-defined operator 18called .XOR., or one of the deleted features remains standard-conforming under this part of ISO/IEC 191539. 20The PAD= specifier in the INQUIRE statement in this part of ISO/IEC 1539 returns the value UNDE- 21FINED if there is no connection or the connection is for unformatted input/output. Fortran 90 specified 22YES. 23Fortran 90 specified that if the second argument to MOD or MODULO was zero, the result was processor dependent. this part of ISO/IEC 1539 specifies that the second argument shall not be zero. 24 1.6.6 FORTRAN 77 compatibility 25 26Except for the deleted features noted in Annex B.1, and except as identified in this subclause, this part 27of ISO/IEC 1539 is an upward compatible extension to ISO 1539:1980 (Fortran 77). Any standard- 28conforming Fortran 77 program that does not use one of the deleted features noted in Annex B.1 and 29that does not depend on the differences specified here remains standard-conforming under this part of 30ISO/IEC 1539. This part of ISO/IEC 1539 restricts the behavior for some features that were processor 31dependent in Fortran 77. Therefore, a standard-conforming Fortran 77 program that uses one of 32these processor-dependent features may have a different interpretation under this part of ISO/IEC 1539, 33yet remain a standard-conforming program. The following Fortran 77 features may have different interpretations in this part of ISO/IEC 1539. 34 35 (1) Fortran 77 permitted a processor to supply more precision derived from a real constant 36 than can be represented in a real datum when the constant is used to initialize a data object 37 of type double precision real in a DATA statement. This part of ISO/IEC 1539 does not 38 permit a processor this option. 39 (2) If a named variable that was not in a common block was initialized in a DATA statement and 40 did not have the SAVE attribute specified, Fortran 77 left its SAVE attribute processor 41 dependent. This part of ISO/IEC 1539 specifies (5.4.6) that this named variable has the 42 SAVE attribute. 43 (3) Fortran 77 specified that the number of characters required by the input list was to be 44 less than or equal to the number of characters in the record during formatted input. This 45 part of ISO/IEC 1539 specifies (9.5.4.4.2) that the input record is logically padded with 46 blanks if there are not enough characters in the record, unless the PAD= specifier with the 47 value 'NO' is specified in an appropriate OPEN or READ statement. 4 2006/01/05 WORKING DRAFT J3/07-007 1 (4) A value of 0 for a list item in a formatted output statement will be formatted in a different 2 form for some G edit descriptors. In addition, this part of ISO/IEC 1539 specifies how 3 rounding of values will affect the output field form, but Fortran 77 did not address this 4 issue. Therefore, some Fortran 77 processors may produce an output form different from 5 the output form produced by Fortran 2003 processors for certain combinations of values and 6 G edit descriptors. 7 (5) If the processor can distinguish between positive and negative real zero, the behavior of the 8 SIGN intrinsic function when the second argument is negative real zero is changed by this part of ISO/IEC 1539. 9 1.7 Notation used in this part of ISO/IEC 1539 10 1.7.1 Applicability of requirements 11 12In this part of ISO/IEC 1539, "shall" is to be interpreted as a requirement; conversely, "shall not" is 13to be interpreted as a prohibition. Except where stated otherwise, such requirements and prohibitions 14apply to programs rather than processors. 151.7.2 Informative notes 16Informative notes of explanation, rationale, examples, and other material are interspersed with the 17normative body of this part of ISO/IEC 1539. The informative material is nonnormative; it is identified 18by being in shaded, framed boxes that have numbered headings beginning with "NOTE." 1.7.3 Syntax rules 19 20Syntax rules describe the forms that Fortran lexical tokens, statements, and constructs may take. These syntax rules are expressed in a variation of Backus-Naur form (BNF) with the following conventions. 21 22 (1) Characters from the Fortran character set (3.1) are interpreted literally as shown, except 23 where otherwise noted. 24 (2) Lower-case italicized letters and words (often hyphenated and abbreviated) represent gen- 25 eral syntactic classes for which particular syntactic entities shall be substituted in actual 26 statements. 27 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 (3) The syntactic metasymbols used are: 28 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 29 (4) Each syntax rule is given a unique identifying number of the form Rsnn, where s is a 30 one- or two-digit clause number and nn is a two-digit sequence number within that clause. 5 J3/07-007 WORKING DRAFT 2006/01/05 1 The syntax rules are distributed as appropriate throughout the text, and are referenced by 2 number as needed. Some rules in Clauses 2 and 3 are more fully described in later clauses; in 3 such cases, the clause number s is the number of the later clause where the rule is repeated. 4 (5) The syntax rules are not a complete and accurate syntax description of Fortran, and cannot 5 be used to generate a Fortran parser automatically; where a syntax rule is incomplete, it is 6 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 71.7.4 Constraints 8Each constraint is given a unique identifying number of the form Csn, where s is a one or two digit clause 9number and nn is a two or three digit sequence number within that clause. 10Often a constraint is associated with a particular syntax rule. Where that is the case, the constraint is 11annotated with the syntax rule number in parentheses. A constraint that is associated with a syntax 12rule constitutes part of the definition of the syntax term defined by the rule. It thus applies in all places 13where the syntax term appears. 14Some constraints are not associated with particular syntax rules. The effect of such a constraint is similar 15to that of a restriction stated in the text, except that a processor is required to have the capability to 16detect and report violations of constraints (1.5). In some cases, a broad requirement is stated in text 17and a subset of the same requirement is also stated as a constraint. This indicates that a standard- 18conforming program is required to adhere to the broad requirement, but that a standard-conforming 19processor is required only to have the capability of diagnosing violations of the constraint. 1.7.5 Assumed syntax rules 20 21In order to minimize the number of additional syntax rules and convey appropriate constraint informa- 22tion, the following rules are assumed. R101 xyz-list is xyz [ , xyz ] ... 23 24R102 xyz-name is name 25R103 scalar-xyz is xyz C101 (R103) scalar-xyz shall be scalar. 26 6 2006/01/05 WORKING DRAFT J3/07-007 1The letters "xyz" stand for any syntactic class phrase. An explicit syntax rule for a term overrides an 2assumed rule. 1.7.6 Syntax conventions and characteristics 3 4 (1) Any syntactic class name ending in "-stmt" follows the source form statement rules: it shall 5 be delimited by end-of-line or semicolon, and may be labeled unless it forms part of another 6 statement (such as an IF or WHERE statement). Conversely, everything considered to be 7 a source form statement is given a "-stmt" ending in the syntax rules. 8 (2) The rules on statement ordering are described rigorously in the definition of program-unit (R202). Expression hierarchy is described rigorously in the definition of expr (R722). 9 10 (3) The suffix "-spec" is used consistently for specifiers, such as input/output statement speci- 11 fiers. It also is used for type declaration attribute specifications (for example, "array-spec" in R510), and in a few other cases. 12 13 (4) Where reference is made to a type parameter, including the surrounding parentheses, the 14 suffix "-selector" is used. See, for example, "kind-selector" (R405) and "length-selector" (R421). 15 16 (5) The term "subscript" (for example, R619, R620, and R621) is used consistently in array 17 definitions. 181.7.7 Text conventions 19In the descriptive text, an equivalent English word is frequently used in place of a syntactic term. 20Particular statements and attributes are identified in the text by an upper-case keyword, e.g., "END 21statement". Boldface words are used in the text where they are first defined with a specialized meaning. 22The 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. 231.8 Deleted and obsolescent features 241.8.1 General 25This part of ISO/IEC 1539 protects the users' investment in existing software by including all but five 26of the language elements of Fortran 90 that are not processor dependent. This part of ISO/IEC 1539 27identifies two categories of outmoded features. There are five in the first category, deleted features, 28which consists of features considered to have been redundant in Fortran 77 and largely unused in 29Fortran 90. Those in the second category, obsolescent features, are considered to have been redundant 30in Fortran 90 and Fortran 95, but are still frequently used. 311.8.2 Nature of deleted features 32Better methods existed in Fortran 77 for each deleted feature. These features were not included in 33Fortran 95 or Fortran 2003, and are not included in this revision of Fortran. 341.8.3 Nature of obsolescent features 35Better methods existed in Fortran 90 and Fortran 95 for each obsolescent feature. It is recommended 36that programmers use these better methods in new programs and convert existing code to these methods. 37The obsolescent features are identified in the text of this part of ISO/IEC 1539 by a distinguishing type font (1.7.7). 38 7 J3/07-007 WORKING DRAFT 2006/01/05 1A future revision of this part of ISO/IEC 1539 might delete an obscolescent feature if its use has become 2insignificant. 31.9 Normative references 4The following referenced standards are indispensable for the application of this part of ISO/IEC 1539. 5For dated references, only the edition cited applies. For undated references, the latest edition of the referenced standard (including any amendments) applies. 6 ISO/IEC 646:1991, Information technology--ISO 7-bit coded character set for information interchange. 7 8ISO 8601:1988, Data elements and interchange formats--Information interchange-- 9Representation of dates and times. ISO/IEC 9899:1999, Information technology--Programming languages--C. 10 11ISO/IEC 10646-1:2000, Information technology--Universal multiple-octet coded character set (UCS)-- 12Part 1: Architecture and basic multilingual plane. IEC 60559 (1989-01), Binary floating-point arithmetic for microprocessor systems. 13 14ISO/IEC 646:1991 (International Reference Version) is the international equivalent of ANSI X3.4-1986, 15commonly known as ASCII. This part of ISO/IEC 1539 refers to ISO/IEC 9899:1999 as the C International Standard. 16 17Because IEC 60559 (1989-01) was originally IEEE 754-1985, Standard for binary floating-point arith- 18metic, and is widely known by this name, this part of ISO/IEC 1539 refers to it as the IEEE International 19Standard. 8 2006/01/05 WORKING DRAFT J3/07-007 2 Fortran terms and concepts 1 2.1 High level syntax 2 3This clause 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 part of ISO/IEC 1539 is described in 1.7. 5 NOTE 2.1 Constraints and other information related to the rules that do not begin with R2 appear in the appropriate clause. 6R201 program is program-unit [ program-unit ] ... 7 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 submodule 14 or block-data 15R1101 main-program is [ program-stmt ] 16 [ specification-part ] 17 [ execution-part ] 18 [ internal-subprogram-part ] 19 end-program-stmt 20R203 external-subprogram is function-subprogram 21 or subroutine-subprogram 22R1227 function-subprogram is function-stmt 23 [ specification-part ] 24 [ execution-part ] 25 [ internal-subprogram-part ] 26 end-function-stmt 27R1233 subroutine-subprogram is subroutine-stmt 28 [ specification-part ] 29 [ execution-part ] 30 [ internal-subprogram-part ] 31 end-subroutine-stmt 32R1104 module is module-stmt 33 [ specification-part ] 34 [ module-subprogram-part ] 35 end-module-stmt 36R1116 submodule is submodule-stmt 9 J3/07-007 WORKING DRAFT 2006/01/05 1 [ specification-part ] 2 [ module-subprogram-part ] 3 end-submodule-stmt 4R1120 block-data is block-data-stmt 5 [ specification-part ] 6 end-block-data-stmt 7R204 specification-part is [ use-stmt ] ... 8 [ import-stmt ] ... 9 [ implicit-part ] [ declaration-construct ] ... 10 11R205 implicit-part is [ implicit-part-stmt ] ... 12 implicit-stmt 13R206 implicit-part-stmt is implicit-stmt 14 or parameter-stmt 15 or format-stmt 16 or entry-stmt 17R207 declaration-construct is derived-type-def 18 or entry-stmt 19 or enum-def 20 or format-stmt 21 or interface-block 22 or macro-definition 23 or parameter-stmt 24 or procedure-declaration-stmt 25 or specification-stmt 26 or type-declaration-stmt 27 or stmt-function-stmt 28R208 execution-part is executable-construct [ execution-part-construct ] ... 29 30R209 execution-part-construct is executable-construct 31 or format-stmt 32 or entry-stmt 33 or data-stmt 34R210 internal-subprogram-part is contains-stmt [ internal-subprogram ] ... 35 36R211 internal-subprogram is function-subprogram 37 or subroutine-subprogram 38R1107 module-subprogram-part is contains-stmt [ module-subprogram ] ... 39 40R1108 module-subprogram is function-subprogram 41 or subroutine-subprogram 42 or separate-module-subprogram 43R1237 separate-module-subprogram is mp-subprogram-stmt 44 [ specification-part ] 45 [ execution-part ] 10 2006/01/05 WORKING DRAFT J3/07-007 1 [ internal-subprogram-part ] 2 end-mp-subprogram-stmt 3R212 specification-stmt is access-stmt 4 or allocatable-stmt 5 or asynchronous-stmt 6 or bind-stmt 7 or common-stmt 8 or data-stmt 9 or dimension-stmt 10 or equivalence-stmt 11 or external-stmt 12 or intent-stmt 13 or intrinsic-stmt 14 or namelist-stmt 15 or optional-stmt 16 or pointer-stmt 17 or protected-stmt 18 or save-stmt 19 or target-stmt 20 or volatile-stmt 21 or value-stmt 22R213 executable-construct is action-stmt 23 or associate-construct 24 or block-construct 25 or case-construct 26 or critical-construct 27 or do-construct 28 or forall-construct 29 or if-construct 30 or select-type-construct 31 or where-construct 32R214 action-stmt is allocate-stmt 33 or assignment-stmt 34 or backspace-stmt 35 or call-stmt 36 or close-stmt 37 or continue-stmt 38 or cycle-stmt 39 or deallocate-stmt 40 or end-function-stmt 41 or end-mp-subprogram-stmt 42 or end-program-stmt 43 or end-subroutine-stmt 44 or endfile-stmt 45 or exit-stmt 46 or flush-stmt 47 or forall-stmt 48 or goto-stmt 49 or if-stmt 50 or inquire-stmt 51 or notify-stmt 52 or nullify-stmt 11 J3/07-007 WORKING DRAFT 2006/01/05 1 or open-stmt 2 or pointer-assignment-stmt 3 or print-stmt 4 or query-stmt 5 or read-stmt 6 or return-stmt 7 or rewind-stmt 8 or stop-stmt 9 or sync-all-stmt 10 or sync-images-stmt 11 or sync-memory-stmt 12 or sync-team-stmt 13 or wait-stmt 14 or where-stmt 15 or write-stmt 16 or arithmetic-if-stmt 17 or computed-goto-stmt 18C201 (R208) An execution-part shall not contain an end-function-stmt, end-mp-subprogram-stmt, end- 19 program-stmt, or end-subroutine-stmt. 20Additionally, an EXPAND statement may occur anywhere that any statement may occur other than 21as the first statement of a program unit. The syntax rules are applied to the program after macro 22expansion, i.e. with each EXPAND statement replaced by the statements it produces. 2.2 Program unit concepts 23 2.2.1 Program units and scoping units 24 25Program units are the fundamental components of a Fortran program. A program unit may be 26a main program, an external subprogram, a module, a submodule, or a block data program unit. A 27subprogram may be a function subprogram or a subroutine subprogram. A module contains definitions 28that are to be made accessible to other program units. A submodule is a extension of a module; it may 29contain the definitions of procedures declared in a module or another submodule. A block data program 30unit is used to specify initial values for data objects in named common blocks. Each type of program 31unit is described in Clause 11 or 12. An external subprogram is a subprogram that is not in a main 32program, a module, a submodule, or another subprogram. An internal subprogram is a subprogram 33that is in a main program or another subprogram. A module subprogram is a subprogram that is in 34a module or submodule but is not an internal subprogram. 35A program unit consists of a set of nonoverlapping scoping units. A scoping unit is (1) a program unit or subprogram, excluding any scoping units in it, 36 (2) a derived-type definition (4.5.2), or 37 (3) an interface body, excluding any scoping units in it. 38 39A scoping unit that immediately surrounds another scoping unit is called the host scoping unit (often abbreviated to host). A module or submodule is also the host scoping unit of its child submodules. 40 2.2.2 Program 41 42A program consists of exactly one main program, any number (including zero) of other kinds of program 43units, any number (including zero) of external procedures, and any number (including zero) of other 44entities defined by means other than Fortran. 12 2006/01/05 WORKING DRAFT J3/07-007 NOTE 2.2 There is a restriction that there shall be no more than one unnamed block data program unit (11.3). This part of ISO/IEC 1539 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.2) is processed, a processor may require a particular order of processing of the program units. 2.2.3 Main program 1 2The Fortran main program is described in 11.1. 32.2.4 Procedure 4A procedure encapsulates an arbitrary sequence of actions that may be invoked directly during program 5execution. Procedures are either functions or subroutines. A function is a procedure that is invoked 6in an expression; its invocation causes a value to be computed which is then used in evaluating the 7expression. The variable that returns the value of a function is called the result variable. A subroutine 8is a procedure that is invoked in a CALL statement, by a defined assignment statement, or by some 9operations on derived-type entities. Unless it is a pure procedure, a subroutine may be used to change 10the program state by changing the values of any of the data objects accessible to the subroutine; unless 11it is a pure procedure, a function may do this in addition to computing the function value. 12Procedures are described further in Clause 12. 132.2.4.1 External procedure 14An external procedure is a procedure that is defined by an external subprogram or by means other 15than Fortran. An external procedure may be invoked by the main program or by any procedure of a 16program. 172.2.4.2 Module procedure 18A module procedure is a procedure that is defined by a module subprogram (R1108). The module or 19submodule containing the subprogram is the host scoping unit of the module procedure. 202.2.4.3 Internal procedure 21An internal procedure is a procedure that is defined by an internal subprogram (R211). The containing 22main program or subprogram is the host scoping unit of the internal procedure. An internal procedure 23is local to its host in the sense that its name is accessible within the host scoping unit and all its other 24internal procedures but is not accessible elsewhere. 252.2.4.4 Interface block 26An interface body describes an abstract interface or the interface of a dummy procedure, external 27procedure, procedure pointer, or separate module procedure. 28An interface block is a specific interface block, an abstract interface block, or a generic interface block. 29A specific interface block is a collection of interface bodies. A generic interface block can also be used 30to specify that a procedure can be invoked (1) by using a generic name, 31 (2) by using a defined operator, 32 13 J3/07-007 WORKING DRAFT 2006/01/05 (3) by using a defined assignment, or 1 (4) for derived-type input/output. 2 32.2.5 Module 4A module contains (or accesses from other modules) definitions that are to be made accessible to other 5program units. These definitions include data object declarations, type definitions, procedure definitions, 6and interface blocks. A scoping unit in another program unit may access the definitions in a module. 7Modules are further described in Clause 11. 82.2.6 Submodule 9A submodule is a program unit that extends a module or another submodule. It may provide definitions 10(12.6) for procedures whose interfaces are declared (12.4.3.2) in an ancestor module or submodule. It 11may also contain declarations and definitions of other entities, which are accessible in its descendants. 12An entity declared in a submodule is not accessible by use association unless it is a module procedure 13whose interface is declared in the ancestor module. Submodules are further described in Clause 11. NOTE 2.3 The scoping unit of a submodule accesses the scoping unit of its parent module or submodule by host association. 2.3 Execution concepts 14 152.3.1 Statement classification 16Each Fortran statement is classified as either an executable statement or a nonexecutable statement. 17There are restrictions on the order in which statements may appear in a program unit, and not all 18executable statements may appear in all contexts. 2.3.2 Program execution 19 20An instance of a Fortran program is an image. Execution of a program consists of the asynchronous 21execution of a fixed number (which may be one) of its images. Each image has its own execution state, 22floating-point status (14.6), and set of data objects and procedure pointers. Whether a file is available 23on any image or only on a specific image is processor dependent. Each image is identified by an image 24index, which is an integer value in the range one to the number of images. NOTE 2.4 The programmer controls the progress of execution in each image through explicit use of Fortran control constructs (8.1, 8.2). Image control statements (8.5.1) affect the relative progress of exe- cution between images. Co-arrays (2.4.6) provide a mechanism for accessing data on one image from another image. NOTE 2.5 A processor might allow the number of images to be chosen at compile time, link time, or run time. It might be the same as the number of CPUs but this is not required. Compiling for a single image might permit the optimizer to eliminate overhead associated with parallel execution. Portable programs should not make assumptions about the exact number of images. The maximum number of images may be limited due to architectural constraints. A team is a set of images identified by a scalar object of type IMAGE TEAM (13.8.2.7). 25 14 2006/01/05 WORKING DRAFT J3/07-007 2.3.3 Executable/nonexecutable statements 1 2Image execution is a sequence, in time, of actions. An executable statement is an instruction to 3perform or control one or more of these actions. Thus, the executable statements of a program unit 4determine the behavior of the program unit. The executable statements are all of those that make up 5the syntactic class executable-construct, excluding those in the specification-part of a BLOCK executable 6construct. 7Nonexecutable statements do not specify actions; they are used to configure the program environment 8in which actions take place. The nonexecutable statements are all those not classified as executable. 92.3.4 Statement order 10The syntax rules of clause 2.1 specify the statement order within program units and subprograms. These 11rules are illustrated in Table 2.1 and Table 2.2. Table 2.1 shows the ordering rules for statements and 12applies to all program units, subprograms, and interface bodies. Vertical lines delineate varieties of 13statements that may be interspersed and horizontal lines delineate varieties of statements that shall not 14be interspersed. Internal or module subprograms shall follow a CONTAINS statement. Between USE 15and CONTAINS statements in a subprogram, nonexecutable statements generally precede executable 16statements, although the ENTRY statement, FORMAT statement, and DATA statement may appear 17among the executable statements. Table 2.2 shows which statements are allowed in a scoping unit. Table 2.1: Requirements on statement ordering PROGRAM, FUNCTION, SUBROUTINE, MODULE, SUBMODULE, 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 definitions, 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 unit1 Main Module or Block External Module Internal Interface Statement type program submodule data subprog subprog subprog body USE Yes Yes Yes Yes Yes Yes Yes IMPORT No No No No No No Yes 15 J3/07-007 WORKING DRAFT 2006/01/05 Statements allowed in scoping units Kind of scoping unit1 Main Module or Block External Module Internal Interface Statement type program submodule data subprog subprog subprog body ENTRY No No No Yes Yes No No FORMAT Yes No No Yes Yes Yes No Misc. decl.s 2 Yes Yes Yes Yes Yes Yes Yes DATA Yes Yes Yes Yes Yes Yes No Derived-type Yes Yes Yes Yes Yes Yes Yes Interface Yes Yes No Yes Yes Yes Yes Executable Yes No No Yes Yes Yes No CONTAINS Yes Yes No Yes Yes No No Statement function Yes No No Yes Yes Yes No (1) The scoping unit of a module or submodule does not include any module subprograms that it contains. (2) Miscellaneous declarations are PARAMETER statements, IMPLICIT statements, type declaration statements, enumeration definitions, procedure declaration statements, and spec- ification statements. 12.3.5 The END statement 2An end-program-stmt, end-function-stmt, end-subroutine-stmt, end-mp-subprogram-stmt, end-module- 3stmt, end-submodule-stmt, or end-block-data-stmt is an END statement. Each program unit, module 4subprogram, and internal subprogram shall have exactly one END statement. The end-program-stmt, 5end-function-stmt, end-subroutine-stmt, and end-mp-subprogram-stmt statements are executable, and 6may be branch target statements (8.2). Executing an end-program-stmt causes normal termination of 7execution of the program. Executing an end-function-stmt, end-subroutine-stmt, or end-mp-subprogram- 8stmt is equivalent to executing a return-stmt with no scalar-int-expr. 9The end-module-stmt, end-submodule-stmt, and end-block-data-stmt statements are nonexecutable. 2.3.6 Execution sequence 10 11If a program contains a Fortran main program, execution of the program begins by creating a fixed 12number of instances of the program; each image begins execution with the first executable construct of 13the main program. The execution of a main program or subprogram involves execution of the executable 14constructs within its scoping unit. When a Fortran procedure is invoked, the specification expressions 15within the specification-part of the invoked procedure, if any, are evaluated in a processor dependent 16order. Thereafter, execution proceeds to the first executable construct appearing within the scoping unit 17of the procedure after the invoked entry point. With the following exceptions, the effect of execution is 18as if the executable constructs are executed in the order in which they appear in the main program or 19subprogram until a STOP, RETURN, or END statement is executed. 20 (1) Execution of a branching statement (8.2) changes the execution sequence. These statements 21 explicitly specify a new starting place for the execution sequence. 22 (2) CASE constructs, DO constructs, IF constructs, and SELECT TYPE constructs contain 23 an internal statement structure and execution of these constructs involves implicit internal 24 branching. See Clause 8 for the detailed semantics of each of these constructs. 25 (3) BLOCK constructs may contain specification expressions; see 8.1.4 for detailed semantics 26 of this construct. 16 2006/01/05 WORKING DRAFT J3/07-007 (4) END=, ERR=, and EOR= specifiers may result in a branch. 1 (5) 2 Alternate returns may result in a branch. 3Internal subprograms may precede the END statement of a main program or a subprogram. The 4execution sequence excludes all such definitions. 5The relative ordering of the exeuction sequences of different images can be affected by image control statements (8.5.1). 6 7Normal termination of execution of an image occurs if a STOP statement is executed on that image. Ex- 8ecution of an end-program-stmt results in a synchronization of all images followed by normal termination 9of execution of all images. Normal termination of execution of an image also may occur during execution 10of a procedure defined by a companion processor (C International Standard 5.1.2.2.3 and 7.20.4.3). If 11normal termination of execution occurs within a Fortran program unit and the program incorporates 12procedures defined by a companion processor, the process of execution termination shall include the effect of executing the C exit() function (C International Standard 7.20.4.3). 13 2.4 Data concepts 14 15Nonexecutable statements are used to specify the characteristics of the data environment. This includes 16typing variables, declaring arrays, and defining new types. 2.4.1 Type 17 18A type is a named category of data that is characterized by a set of values, a syntax for denoting 19these values, and a set of operations that interpret and manipulate the values. This central concept is 20described in 4.1. 21A type may be parameterized, in which case the set of data values, the syntax for denoting them, and 22the set of operations depend on the values of one or more parameters. Such a parameter is called a type parameter (4.2). 23 24There are two categories of types: intrinsic types and derived types. 252.4.1.1 Intrinsic type 26An intrinsic type is a type that is defined by the language, along with operations, and is always 27accessible. The intrinsic types are integer, real, complex, character, logical, and bits. The properties of 28intrinsic types are described in 4.4. The intrinsic type parameters are KIND and LEN. 29The kind type parameter indicates the representation method for the specified type. 302.4.1.2 Derived type 31A derived type is a type that is defined by a type definition or by an intrinsic module. A scalar object of 32derived type is called a structure (4.5). Derived types may be parameterized. Assignment of structures 33is defined intrinsically (7.2.1.3), but there are no intrinsic operations for structures. For each derived 34type, a structure constructor is available to provide values (4.5.10). In addition, data objects of derived 35type may be used as procedure arguments and function results, and may appear in input/output lists. 36If additional operations are needed for a derived type, they shall be supplied as procedure definitions. 37Derived types are described further in 4.5. 382.4.2 Data value 17 J3/07-007 WORKING DRAFT 2006/01/05 1Each intrinsic type has associated with it a set of values that a datum of that type may take, depending 2on the values of the type parameters. The values for each intrinsic type are described in 4.4. The values 3that objects of a derived type may assume are determined by the type definition, type parameter values, 4and the sets of values of its components. 2.4.3 Data entity 5 6A data entity is a data object, the result of the evaluation of an expression, or the result of the execution 7of a function reference (called the function result). A data entity has a type and type parameters; it 8may have a data value (an exception is an undefined variable). Every data entity has a rank and is thus 9either a scalar or an array. 102.4.3.1 Data object 11A data object (often abbreviated to object) is a constant (4.1.2), a variable (6), or a subobject of a 12constant. The type and type parameters of a named data object may be specified explicitly (5.2) or implicitly (5.5). 13 14Subobjects are portions of certain objects that may be referenced and defined (variables only) inde- 15pendently of the other portions. These include portions of arrays (array elements and array sections), 16portions of character strings (substrings), portions of complex objects (real and imaginary parts), and 17portions of structures (components). Subobjects are themselves data objects, but subobjects are refer- 18enced only by object designators or intrinsic functions. A subobject of a variable is a variable. Subobjects 19are described in Clause 6. 20Objects referenced by a name are: a named scalar (a scalar object) a named array (an array object) 21 22Subobjects referenced by an object designator are: an array element (a scalar subobject) an array section (an array subobject) a complex part designator (the real or imaginary part of a complex object) a structure component (a scalar or an array subobject) a substring (a scalar subobject) 23 242.4.3.1.1 Variable 25A variable may have a value and may be defined and redefined during execution of a program. 26A named local variable of the scoping unit of a module, submodule, main program, or subprogram, is a 27named variable that is a local entity of the scoping unit, is not a dummy argument, is not in COMMON, 28does not have the BIND attribute, and is not accessed by use or host association. A named local variable 29of a BLOCK construct is a named variable that is declared in that construct, is not in COMMON, does 30not have the BIND attribute, and is not accessed by use association. A subobject of a named local 31variable is also a local variable. 322.4.3.1.2 Constant 33A constant has a value and cannot become defined, redefined, or undefined during execution of a 34program. A constant with a name is called a named constant and has the PARAMETER attribute (5.3.12). A constant without a name is called a literal constant (4.4). 35 362.4.3.1.3 Subobject of a constant 18 2006/01/05 WORKING DRAFT J3/07-007 1A subobject of a constant is a portion of a constant. The portion referenced may depend on the 2value of a variable. NOTE 2.6 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. 32.4.3.2 Expression 4An expression (7.1) produces a data entity when evaluated. An expression represents either a data 5reference or a computation; it is formed from operands, operators, and parentheses. The type, type 6parameters, value, and rank of an expression result are determined by the rules in Clause 7. 72.4.3.3 Function reference 8A function reference (12.5.3) produces a data entity when the function is executed during expression 9evaluation. The type, type parameters, and rank of a function result are determined by the interface of the function (12.3.3). The value of a function result is determined by execution of the function. 10 112.4.4 Scalar 12A scalar (2.4.4) is a data entity that can be represented by a single value of the type and that is not an array (6.2). Its value, if defined, is a single element from the set of values that characterize its type. 13 NOTE 2.7 A structure is scalar even if it has arrays as components. A scalar object of derived type has a single value that consists of the values of its components (4.5.8). 14The rank of a scalar is zero. The shape of a scalar is represented by a rank-one array of size zero. 2.4.5 Array 15 16An array is a set of scalar data, all of the same type and type parameters, whose individual elements 17are arranged in a rectangular pattern. An array element is one of the individual elements in the array 18and is a scalar. An array section is a subset of the elements of an array and is itself an array. 19An array may have up to fifteen dimensions, and any extent (number of elements) in any dimension. 20The rank of the array is the number of dimensions; its size is the total number of elements, which is 21equal to the product of the extents. An array may have zero size. The shape of an array is determined 22by its rank and its extent in each dimension, and may be represented as a rank-one array whose elements 23are the extents. All named arrays shall be declared, and the rank of a named array is specified in its 24declaration. The rank of a named array, once declared, is constant; the extents may be constant or may 25vary during execution. 26Two arrays are conformable if they have the same shape. A scalar is conformable with any array. Any 19 J3/07-007 WORKING DRAFT 2006/01/05 1intrinsic operation defined for scalar objects may be applied to conformable objects. Such operations 2are performed element-by-element to produce a resultant array conformable with the array operands. 3Element-by-element operation means corresponding elements of the operand arrays are involved in a 4scalar operation to produce the corresponding element in the result array. Such an operation is described 5as elemental. NOTE 2.8 If an elemental operation is intrinsically pure or is implemented by a pure elemental function (12.8), the element operations may be performed simultaneously or in any order. 6A rank-one array may be constructed from scalars and other arrays and may be reshaped into any allowable array shape (4.7). 7 8Arrays may be of any type and are described further in 6.2. 2.4.6 Co-array 9 10A co-array is a data entity that has nonzero co-rank; it can be directly referenced or defined by any 11image. It may be a scalar or an array. 12For each co-array on an image, there is a corresponding co-array with the same type, type parameters, 13and bounds on every other image. If a co-array is scalar, the set of corresponding co-arrays on all the 14images is arranged in a rectangular pattern. If a co-array is an array, the set of corresponding co-array 15elements on all the images is arranged in a rectangular pattern. In both cases, the dimensions of the 16pattern are called co-dimensions. The bounds for each co-dimension are called co-bounds. 17A co-array on another image can be accessed directly by using co-subscripts. On its own image, a 18co-array can be accessed without use of co-subscripts. 19The co-rank of a co-array is the number of co-dimensions. The co-size of a co-array is always equal to 20the number of images. 21An object whose designator includes an image-selector is a co-indexed object. For a co-indexed object, 22its co-subscript list determines the image index in the same way that a subscript list determines the subscript order value for an array element (6.2.2.1). 23 24Intrinsic procedures are provided for mapping between an image index and a list of co-subscripts. NOTE 2.9 The mechanism for an image to reference and define a co-array on another image might vary according to the hardware. On a shared-memory machine, a co-array could be implemented as a section of an array of higher rank. On a distributed-memory machine with separate physical memory for each image, a processor might store a co-array at the same virtual address in each physical memory. 252.4.7 Pointer 26A data pointer is a data entity that has the POINTER attribute. A procedure pointer is a procedure 27entity that has the POINTER attribute. A pointer is either a data pointer or a procedure pointer. 28A pointer is associated with a target by pointer assignment (7.2.2) or pointer initialization (4.5.4.5, 295.2.3). A data pointer may also be associated with a target by allocation (6.3.1) or argument association 30(12.5.2.8). A pointer is disassociated following execution of a NULLIFY statement, following pointer 31assignment with a disassociated pointer, by default initialization, or by explicit initialization. A data 32pointer may also be disassociated by execution of a DEALLOCATE statement. A disassociated pointer 20 2006/01/05 WORKING DRAFT J3/07-007 is not associated with a target (16.5.2). 1 2A pointer that is not associated shall not be referenced or defined. 3If a data pointer is an array, the rank is declared, but the extents are determined when the pointer is 4associated with a target. 2.4.8 Storage 5 6Many of the facilities of this part of ISO/IEC 1539 make no assumptions about the physical storage 7characteristics of data objects. However, program units that include storage association dependent 8features shall observe the storage restrictions described in 16.5.3. 92.5 Fundamental terms 10For the purposes of this document, the terms and definitions in this subclause apply. 2.5.1 Name and designator 11 12A name is used to identify a program constituent, such as a program unit, named variable, named 13constant, dummy argument, or derived type. The rules governing the construction of names are given 14in 3.2.1. A designator is a name followed by zero or more component selectors, complex part selectors, 15array section selectors, array element selectors, image selectors, and substring selectors. 16An object designator is a designator for a data object. A procedure designator is a designator for 17a procedure. NOTE 2.10 An object name is a special case of an object designator. 2.5.2 Keyword 18 19The term keyword is used in two ways. 20 (1) It is used to describe a word that is part of the syntax of a statement. These keywords are 21 not reserved words; that is, names with the same spellings are allowed. In the syntax rules, 22 such keywords appear literally. In descriptive text, this meaning is denoted by the term 23 "keyword" without any modifier. Examples of statement keywords are IF, READ, UNIT, 24 KIND, and INTEGER. 25 (2) It is used to denote names that identify items in a list. In actual argument lists, type 26 parameter lists, and structure constructors, items may be identified by a preceding keyword= 27 rather than their position within the list. An argument keyword is the name of a dummy 28 argument in the interface for the procedure being referenced, a type parameter keyword 29 is the name of a type parameter in the type being specified, and a component keyword 30 is the name of a component in a structure constructor. 31R215 keyword is name NOTE 2.11 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. 21 J3/07-007 WORKING DRAFT 2006/01/05 12.5.3 Association 2Association is name association (16.5.1), pointer association (16.5.2), storage association (16.5.3), 3or inheritance association (16.5.4). Name association is argument association, host association, use 4association, linkage association, or construct association. 5Storage association causes different entities to use the same storage. Any association permits an entity 6to be identified by different names in the same scoping unit or by the same name or different names in 7different scoping units. 82.5.4 Declaration 9The term declaration refers to the specification of attributes for various program entities. Often this 10involves specifying the type of a named data object or specifying the shape of a named array object. 112.5.5 Definition 12The term definition is used in two ways. (1) It refers to the specification of derived types, enumerations, and procedures. 13 14 (2) When an object is given a valid value during program execution, it becomes defined. This 15 is often accomplished by execution of an assignment or input statement. When a variable 16 does not have a predictable value, it is undefined. Similarly, when a pointer is associated 17 with a target or nullified, its pointer association status is said to become defined. When 18 the association status of a pointer is not predictable, its pointer association status is said to 19 be undefined. 20Clause 16 describes the ways in which variables become defined and undefined. 212.5.6 Reference 22A data object reference is the appearance of the data object designator in a context requiring its 23value at that point during execution. 24A procedure reference is the appearance of the procedure designator, operator symbol, or assignment 25symbol in a context requiring execution of the procedure at that point. An occurrence of user-defined derived-type input/output (10.7.6) or derived-type finalization (4.5.6.2) is also a procedure reference. 26 27The appearance of a data object designator or procedure designator in an actual argument list does not 28constitute a reference to that data object or procedure unless such a reference is necessary to complete 29the specification of the actual argument. A module reference is the appearance of a module name in a USE statement (11.2.2). 30 312.5.7 Intrinsic 32The qualifier intrinsic has two meanings. 33 (1) The qualifier signifies that the term to which it is applied is defined in this part of ISO/IEC 34 1539. Intrinsic applies to types, procedures, modules, assignment statements, and operators. 35 All intrinsic types, procedures, assignments, and operators may be used in any scoping 36 unit without further definition or specification. Intrinsic modules may be accessed by use 37 association. Intrinsic procedures and modules defined in this part of ISO/IEC 1539 are 38 called standard intrinsic procedures and standard intrinsic modules, respectively. 22 2006/01/05 WORKING DRAFT J3/07-007 1 (2) The qualifier applies to procedures or modules that are provided by a processor but are not 2 defined in this part of ISO/IEC 1539 (13, 14, 15.2). Such procedures and modules are called 3 nonstandard intrinsic procedures and nonstandard intrinsic modules, respectively. 2.5.8 Operator 4 5An operator specifies a computation involving one (unary operator) or two (binary operator) data 6values (operands). This part of ISO/IEC 1539 specifies a number of intrinsic operators (e.g., the 7arithmetic operators +, ­, *, /, and ** with numeric operands and the logical operators .AND., .OR., etc. with logical operands). Additional operators may be defined within a program (4.5.5, 12.4.3.4). 8 2.5.9 Sequence 9 10A sequence is a set ordered by a one-to-one correspondence with the numbers 1, 2, through n. The 11number of elements in the sequence is n. A sequence may be empty, in which case it contains no elements. 2.5.10 Companion processors 12 13A processor has one or more companion processors. A companion processor is a processor-dependent 14mechanism by which global data and procedures may be referenced or defined. A companion processor 15may be a mechanism that references and defines such entities by a means other than Fortran (12.6.3), 16it may be the Fortran processor itself, or it may be another Fortran processor. If there is more than 17one companion processor, the means by which the Fortran processor selects among them are processor 18dependent. 19If a procedure is defined by means of a companion processor that is not the Fortran processor itself, this 20part of ISO/IEC 1539 refers to the C function that defines the procedure, although the procedure need 21not be defined by means of the C programming language. NOTE 2.12 A companion processor might or might not be a mechanism that conforms to the requirements of the C International Standard. For example, a processor may allow a procedure defined by some language other than Fortran or C to be invoked if it can be described by a C prototype as defined in 6.5.5.3 of the C International Standard. 23 J3/07-007 WORKING DRAFT 2006/01/05 24 2006/01/05 WORKING DRAFT J3/07-007 3 Lexical tokens, source form, and macro processing 1 23.1 Processor character set 3The processor character set is processor dependent. Each character in a processor character set is either 4a control character or a graphic character. The set of graphic characters is further divided into letters (3.1.1), digits (3.1.2), underscore (3.1.3), special characters (3.1.4), and other characters (3.1.5). 5 6The letters, digits, underscore, and special characters make up the Fortran character set. 7R301 character is alphanumeric-character 8 or special-character 9R302 alphanumeric-character is letter 10 or digit 11 or underscore 12Except for the currency symbol, the graphics used for the characters shall be as given in 3.1.1, 3.1.2, 133.1.3, and 3.1.4. However, the style of any graphic is not specified. 143.1.1 Letters 15The twenty-six letters are: 16 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 17The set of letters defines the syntactic class letter. The processor character set shall include lower- 18case and upper-case letters. A lower-case letter is equivalent to the corresponding upper-case letter in program units except in a character context (3.3). 19 NOTE 3.1 The following statements are equivalent: CALL BIG_COMPLEX_OPERATION (NDATE) call big_complex_operation (ndate) Call Big_Complex_Operation (NDate) 3.1.2 Digits 20 21The ten digits are: 22 0 1 2 3 4 5 6 7 8 9 23The ten digits define the syntactic class digit. 243.1.3 Underscore 25R303 underscore is 3.1.4 Special characters 26 25 J3/07-007 WORKING DRAFT 2006/01/05 1The special characters are shown in Table 3.1. 26 2006/01/05 WORKING DRAFT J3/07-007 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 1The special characters define the syntactic class special-character. Some of the special characters are 2used for operator symbols, bracketing, and various forms of separating and delimiting other lexical 3tokens. 43.1.5 Other characters 5Additional characters may be representable in the processor, but may appear only in comments (3.3.1.1, 63.3.2.1), character constants (4.4.5), input/output records (9.1.1), and character string edit descriptors (10.3.2). 7 3.2 Low-level syntax 8 9The low-level syntax describes the fundamental lexical tokens of a program unit. Lexical tokens are 10sequences of characters that constitute the building blocks of a program. They are keywords, names, 11literal constants other than complex literal constants, operators, labels, delimiters, comma, =, =>, :, ::, 12;, and %. 133.2.1 Names 14Names are used for various entities such as variables, program units, dummy arguments, named con- 15stants, and derived types. R304 name is letter [ alphanumeric-character ] ... 16 C301 (R304) The maximum length of a name is 63 characters. 17 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) 27 J3/07-007 WORKING DRAFT 2006/01/05 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. 13.2.2 Constants 2R305 constant is literal-constant 3 or named-constant 4R306 literal-constant is int-literal-constant 5 or real-literal-constant 6 or complex-literal-constant 7 or logical-literal-constant 8 or char-literal-constant 9 or bits-literal-constant 10R307 named-constant is name 11R308 int-constant is constant C302 (R308) int-constant shall be of type integer. 12 13R309 char-constant is constant C303 (R309) char-constant shall be of type character. 14 3.2.3 Operators 15 16R310 intrinsic-operator is power-op 17 or mult-op 18 or add-op 19 or concat-op 20 or rel-op 21 or not-op 22 or and-op 23 or or-op 24 or equiv-op 25R707 power-op is ** 26R708 mult-op is * or / 27 28R709 add-op is + 29 or ­ R711 concat-op is // 30 31R713 rel-op is .EQ. 32 or .NE. 33 or .LT. 34 or .LE. 35 or .GT. 36 or .GE. 37 or == 28 2006/01/05 WORKING DRAFT J3/07-007 1 or /= 2 or < 3 or <= 4 or > 5 or >= 6R718 not-op is .NOT. 7R719 and-op is .AND. 8R720 or-op is .OR. 9R721 equiv-op is .EQV. 10 or .NEQV. 11 or .XOR. 12R311 defined-operator is defined-unary-op 13 or defined-binary-op 14 or extended-intrinsic-op R703 defined-unary-op is . letter [ letter ] ... . 15 R723 defined-binary-op is . letter [ letter ] ... . 16 17R312 extended-intrinsic-op is intrinsic-operator 183.2.4 Statement labels 19A statement label provides a means of referring to an individual statement. R313 label is digit [ digit [ digit [ digit [ digit ] ] ] ] 20 C304 (R313) At least one digit in a label shall be nonzero. 21 22If a statement is labeled, the statement shall contain a nonblank character. The same statement label 23shall not be given to more than one statement in a scoping unit. Leading zeros are not significant in 24distinguishing between statement labels. NOTE 3.4 For example: 99999 10 010 are all statement labels. The last two are equivalent. There are 99999 unique statement labels and a processor shall accept any of them as a statement label. However, a processor may have a limit on the total number of unique statement labels in one program unit. 25Any statement may have a statement label, but the labels are used only in the following ways. 26 (1) The label on a branch target statement (8.2) is used to identify that statement as the 27 possible destination of a branch. 28 (2) The label on a FORMAT statement (10.2.1) is used to identify that statement as the format 29 J3/07-007 WORKING DRAFT 2006/01/05 specification for a data transfer statement (9.5). 1 2 (3) In some forms of the DO construct (8.1.7), the range of the DO construct is identified by 3 the label on the last statement in that range. 43.2.5 Delimiters 5Delimiters are used to enclose syntactic lists. The following pairs are delimiters: 6( ... ) 7/ ... / 8[ ... ] 9(/ ... /) 103.3 Source form 11A Fortran program unit is a sequence of one or more lines, organized as Fortran statements, comments, 12and INCLUDE lines. A line is a sequence of zero or more characters. Lines following a program unit 13END statement are not part of that program unit. A Fortran statement is a sequence of one or more 14complete or partial lines. 15A character context means characters within a character literal constant (4.4.5) or within a character string edit descriptor (10.3.2). 16 17A comment may contain any character that may occur in any character context. 18There are two source forms: free and fixed. Free form and fixed form shall not be mixed in the same program unit. 19 The means for specifying the source form of a program unit are processor dependent. 203.3.1 Free source form 21In free source form there are no restrictions on where a statement (or portion of a statement) may 22appear within a line. A line may contain zero characters. If a line consists entirely of characters of 23default kind (4.4.5), it may contain at most 132 characters. If a line contains any character that is not 24of default kind, the maximum number of characters allowed on the line is processor dependent. 25Blank characters shall not appear within lexical tokens other than in a character context or in a format 26specification. Blanks may be inserted freely between tokens to improve readability; for example, blanks 27may occur between the tokens that form a complex literal constant. A sequence of blank characters 28outside of a character context is equivalent to a single blank character. 29A blank shall be used to separate names, constants, or labels from adjacent keywords, names, constants, 30or labels. NOTE 3.5 For example, the blanks after REAL, READ, 30, and DO are required in the following: REAL X READ 10 30 DO K=1,3 31One or more blanks shall be used to separate adjacent keywords except in the following cases, where blanks are optional: 30 2006/01/05 WORKING DRAFT J3/07-007 1 31 J3/07-007 WORKING DRAFT 2006/01/05 Adjacent keywords where separating blanks are optional BLOCK DATA END MODULE DOUBLE PRECISION END INTERFACE ELSE IF END PROCEDURE ELSE WHERE END PROGRAM END ASSOCIATE END SELECT END BLOCK END SUBMODULE END BLOCK DATA END SUBROUTINE END CRITICAL END TYPE END DO END WHERE END ENUM GO TO END FILE IN OUT END FORALL SELECT CASE END FUNCTION SELECT TYPE END IF 13.3.1.1 Free form commentary 2The character "!" initiates a comment except where it appears within a character context. The 3comment extends to the end of the line. If the first nonblank character on a line is an "!", the line 4is a comment line. Lines containing only blanks or containing no characters are also comment lines. 5Comments may appear anywhere in a program unit and may precede the first statement of a program 6unit or may follow the last statement of a program unit. Comments have no effect on the interpretation 7of the program unit. NOTE 3.6 This part of ISO/IEC 1539 does not restrict the number of consecutive comment lines. 83.3.1.2 Free form statement continuation 9The character "&" is used to indicate that the current statement is continued on the next line that is not 10a comment line. Comment lines cannot be continued; an "&" in a comment has no effect. Comments may 11occur within a continued statement. When used for continuation, the "&" is not part of the statement. 12No line shall contain a single "&" as the only nonblank character or as the only nonblank character 13before an "!" that initiates a comment. 14If a noncharacter context is to be continued, an "&" shall be the last nonblank character on the line, 15or the last nonblank character before an "!". There shall be a later line that is not a comment; the 16statement is continued on the next such line. If the first nonblank character on that line is an "&", the 17statement continues at the next character position following that "&"; otherwise, it continues with the 18first character position of that line. 19If a lexical token is split across the end of a line, the first nonblank character on the first following 20noncomment line shall be an "&" immediately followed by the successive characters of the split token. 21If a character context is to be continued, an "&" shall be the last nonblank character on the line and 22shall not be followed by commentary. There shall be a later line that is not a comment; an "&" shall be 23the first nonblank character on the next such line and the statement continues with the next character 24following that "&". 253.3.1.3 Free form statement termination 26If a statement is not continued, a comment or the end of the line terminates the statement. 32 2006/01/05 WORKING DRAFT J3/07-007 1 A statement may alternatively be terminated by a ";" character that appears other than in a character 2 context or in a comment. The ";" is not part of the statement. After a ";" terminator, another statement 3 may appear on the same line, or begin on that line and be continued. A sequence consisting only of zero 4 or more blanks and one or more ";" terminators, in any order, is equivalent to a single ";" terminator. 5 3.3.1.4 Free form statements 6 A label may precede any statement not forming part of another statement. NOTE 3.7 No Fortran statement begins with a digit. 7 A statement shall not have more than 255 continuation lines. 8 3.3.2 Fixed source form 9 In fixed source form, there are restrictions on where a statement may appear within a line. If a source line contains only 10 default kind characters, it shall contain exactly 72 characters; otherwise, its maximum number of characters is processor 11 dependent. 12 Except in a character context, blanks are insignificant and may be used freely throughout the program. 13 3.3.2.1 Fixed form commentary 14 The character "!" initiates a comment except where it appears within a character context or in character position 6. The 15 comment extends to the end of the line. If the first nonblank character on a line is an "!" in any character position other 16 than character position 6, the line is a comment line. Lines beginning with a "C" or "*" in character position 1 and lines 17 containing only blanks are also comment lines. Comments may appear anywhere in a program unit and may precede the 18 first statement of the program unit or may follow the last statement of a program unit. Comments have no effect on the 19 interpretation of the program unit. NOTE 3.8 This part of ISO/IEC 1539 does not restrict the number of consecutive comment lines. 20 3.3.2.2 Fixed form statement continuation 21 Except within commentary, character position 6 is used to indicate continuation. If character position 6 contains a blank 22 or zero, the line is the initial line of a new statement, which begins in character position 7. If character position 6 contains 23 any character other than blank or zero, character positions 7­72 of the line constitute a continuation of the preceding 24 noncomment line. NOTE 3.9 An "!" or ";" in character position 6 is interpreted as a continuation indicator unless it appears within commentary indicated by a "C" or "*" in character position 1 or by an "!" in character positions 1­5. 25 Comment lines cannot be continued. Comment lines may occur within a continued statement. 263.3.2.3 Fixed form statement termination 27 If a statement is not continued, a comment or the end of the line terminates the statement. 28 A statement may alternatively be terminated by a ";" character that appears other than in a character context, in a 29 comment, or in character position 6. The ";" is not part of the statement. After a ";" terminator, another statement may 30 begin on the same line, or begin on that line and be continued. A ";" shall not appear as the first nonblank character 31 on an initial line. A sequence consisting only of zero or more blanks and one or more ";" terminators, in any order, is 32 equivalent to a single ";" terminator. 33 J3/07-007 WORKING DRAFT 2006/01/05 13.3.2.4 Fixed form statements 2 A label, if present, shall occur in character positions 1 through 5 of the first line of a statement; otherwise, positions 1 3 through 5 shall be blank. Blanks may appear anywhere within a label. A statement following a ";" on the same line shall 4 not be labeled. Character positions 1 through 5 of any continuation lines shall be blank. A statement shall not have more 5 than 255 continuation lines. The program unit END statement shall not be continued. A statement whose initial line 6 appears to be a program unit END statement shall not be continued. 3.4 Including source text 7 8Additional text may be incorporated into the source text of a program unit during processing. This is 9accomplished with the INCLUDE line, which has the form 10 INCLUDE char-literal-constant 11 The char-literal-constant shall not have a kind type parameter value that is a named-constant. 12An INCLUDE line is not a Fortran statement. 13An INCLUDE line shall appear on a single source line where a statement may appear; it shall be the 14only nonblank text on this line other than an optional trailing comment. Thus, a statement label is not 15allowed. 16The effect of the INCLUDE line is as if the referenced source text physically replaced the INCLUDE line 17prior to program processing. Included text may contain any source text, including additional INCLUDE 18lines; such nested INCLUDE lines are similarly replaced with the specified source text. The maximum 19depth of nesting of any nested INCLUDE lines is processor dependent. Inclusion of the source text 20referenced by an INCLUDE line shall not, at any level of nesting, result in inclusion of the same source 21text. 22When an INCLUDE line is resolved, the first included statement line shall not be a continuation line 23and the last included statement line shall not be continued. 24The interpretation of char-literal-constant is processor dependent. An example of a possible valid inter- 25pretation is that char-literal-constant is the name of a file that contains the source text to be included. NOTE 3.10 In some circumstances, for example where source code is maintained in an INCLUDE file for use in programs whose source form might be either fixed or free, observing the following rules allows the code to be used with either source form: (1) Confine statement labels to character positions 1 to 5 and statements to character positions 7 to 72; (2) Treat blanks as being significant; (3) Use only the exclamation mark (!) to indicate a comment, but do not start the comment in character position 6; (4) For continued statements, place an ampersand (&) in both character position 73 of a continued line and character position 6 of a continuing line. 3.5 Macro processing 26 34 2006/01/05 WORKING DRAFT J3/07-007 13.5.1 Macro definition 2A macro definition defines a macro. A defined macro shall only be referenced by a USE statement, 3IMPORT statement, or macro expansion statement. A defined macro shall not be redefined. 4R314 macro-definition is define-macro-stmt 5 [ macro-declaration-stmt ] ... 6 macro-body-block 7 end-macro-stmt 8R315 define-macro-stmt is DEFINE MACRO [ , macro-attr-list ] :: macro-name [ ( [ macro-dummy-arg-name-list ] ) ] 9 10C305 (R315) A macro-dummy-arg-name shall not appear more than once in a macro-dummy-arg- 11 name-list. 12R316 macro-attr is access-spec 13The DEFINE MACRO statement begins the definition of the macro macro-name. Appearance of an 14access-spec in the DEFINE MACRO statement explicitly gives the macro the specified attribute. Each 15macro-dummy-arg-name is a macro dummy argument. A macro dummy argument is a macro local 16variable. 17R317 macro-declaration-stmt is macro-type-declaration-stmt 18 or macro-optional-decl-stmt 19 or macro-variable-decl-stmt 20R318 macro-type-declaration-stmt is MACRO macro-type-spec :: macro-local-variable-name-list 21R319 macro-optional-decl-stmt is MACRO OPTIONAL :: macro-dummy-arg-name-list 22R320 macro-variable-decl-stmt is MACRO VARIABLE :: macro-local-variable-name-list R321 macro-type-spec is INTEGER [ ( [ KIND= ] macro-expr ) ] 23 24C306 (R318, macro-variable-decl-stmt) A macro-local-variable-name shall not be the same as the name 25 of a dummy argument of the macro being defined. 26C307 (R319) A macro-dummy-arg-name shall be the name of a dummy argument of the macro being 27 defined. 28C308 (R321) If macro-expr appears, when the macro is expanded macro-expr shall be of type integer, 29 and have a non-negative value that specifies a representation method that exists on the processor. 30A macro type declaration statement specifies that the named entities are macro local variables of the 31specified type. If the kind is not specified, they are of default kind. A macro variable declaration 32statement declares untyped macro local variables; the value of an untyped macro local variable is a 33token sequence, and its initial value is an empty sequence (no tokens). A macro local variable that is 34not a macro dummy argument shall appear in a macro type declaration statement or in a macro variable 35declaration statement. R322 macro-body-block is [ macro-body-construct ] ... 36 37R323 macro-body-construct is macro-definition 38 or expand-stmt 39 or macro-body-stmt 40 or macro-do-construct 41 or macro-if-construct 35 J3/07-007 WORKING DRAFT 2006/01/05 1 or macro-int-assignment-stmt 2 or macro-tok-assignment-stmt 3C309 A statement in a macro definition that is not a macro-body-construct or macro-definition shall 4 not appear on a line with any other statement. 5R324 macro-do-construct is macro-do-stmt 6 macro-body-block 7 macro-end-do-stmt 8R325 macro-do-stmt is MACRO DO macro-do-variable-name = macro-do-limit , macro-do-limit [ , macro-do-limit ] 9 10C310 (R325) A macro-do-variable-name shall be a local variable of the macro being defined, and shall 11 not be a macro dummy argument. 12R326 macro-do-limit is macro-expr C311 (R326) A macro-do-limit shall expand to an expression of type integer. 13 14R327 macro-end-do-stmt is MACRO END DO 15A macro DO construct iterates the expansion of its enclosed macro body block at macro expansion time. 16The number of iterations is determined by the values of the expanded macro expressions in the MACRO 17DO statement. 18R328 macro-if-construct is macro-if-then-stmt 19 macro-body-block 20 [ macro-else-if-stmt 21 macro-body-block ] ... 22 [ macro-else-stmt 23 macro-body-block ] 24 macro-end-if-stmt R329 macro-if-then-stmt is MACRO IF ( macro-condition ) THEN 25 R330 macro-else-if-stmt is MACRO ELSE IF ( macro-condition ) THEN 26 27R331 macro-else-stmt is MACRO ELSE 28R332 macro-end-if-stmt is MACRO END IF 29R333 macro-condition is macro-expr C312 (R333) A macro condition shall expand to an expression of type logical. 30 31A macro IF construct provides conditional expansion of its enclosed macro body blocks at macro expan- 32sion time. Whether the enclosed macro body blocks contribute to the macro expansion is determined by 33the logical value of the expanded macro expressions in the MACRO IF and MACRO ELSE IF statements. 34R334 macro-int-assignment-stmt is MACRO macro-integer-variable-name = macro-expr C313 (R334) macro-integer-variable-name shall be the name of a macro local variable of type integer. 35 36R335 macro-tok-assignment-stmt is MACRO macro-tok-variable-name = assignment-tok-sequence 37 38C314 (R335) macro-tok-variable-name shall be the name of an untyped macro local variable that is 39 not a macro dummy argument. 36 2006/01/05 WORKING DRAFT J3/07-007 R336 assignment-tok-sequence is result-token [ result-token ] ... [ && ] 1 R337 macro-body-stmt is result-token [ result-token ] ... [ && ] 2 3C315 (R337) If the first result-token is MACRO the second result-token shall not be a keyword or 4 name. C316 (R337) If the first token is DEFINE the second token shall not be MACRO. 5 R338 result-token is token [ %% token ] ... 6 7R339 token is any lexical token including labels, keywords, and semi-colon. 8C317 && shall not appear in the last macro-body-stmt of a macro definition. 9C318 When a macro is expanded, the last macro-body-stmt processed shall not end with &&. R340 end-macro-stmt is END MACRO [ macro-name ] 10 11C319 (R314) The macro-name in the END MACRO statement shall be the same as the macro-name 12 in the DEFINE MACRO statement. 13R341 macro-expr is basic-token-sequence C320 (R341) A macro-expr shall expand to a scalar initialization expression. 14 15Macro expressions are used to control the behavior of the MACRO DO and MACRO IF constructs when 16a macro is being expanded. The type, type parameters, and value of a macro expression are determined 17when that macro expression is expanded. 3.5.2 Macro expansion 18 193.5.2.1 General 20Macro expansion is the conceptual replacement of the EXPAND statement with the Fortran statements 21that it produces. The semantics of an EXPAND statement are those of the Fortran statements that it 22produces. It is recommended that a processor be capable of displaying the results of macro expansion. It 23is processor-dependent whether comments in a macro definition appear in the expansion. It is processor- 24dependent whether continuations and consecutive blanks that are not part of a token are preserved. 25The process of macro expansion produces Fortran statements consisting of tokens. The combined length 26of the tokens for a single statement, plus inter-token spacing, shall not be greater than 33280 characters. 27If a statement contains any character that is not of default kind, the maximum number of characters 28allowed is processor dependent. NOTE 3.11 This length is so that the result of macro expansion can be formed into valid free form Fortran source, consisting of an initial line and 255 continuation lines, times 130 which allows for beginning and ending continuation characters (&) on each line. Also, breaking tokens across continuation lines in macro definitions and in EXPAND statements does not affect macro expansion: it is as if they were joined together before replacement. R342 expand-stmt is EXPAND macro-name [ ( macro-actual-arg-list ) ] 29 30C321 (R342) macro-name shall be the name of a macro that was previously defined or accessed via 31 use or host association. 37 J3/07-007 WORKING DRAFT 2006/01/05 C322 (R342) The macro shall expand to a sequence or zero or more complete Fortran statements. 1 2C323 (R342) The statements produced by a macro expansion shall conform to the syntax rules and 3 constraints as if they replaced the EXPAND statement prior to program processing. 4C324 (R342) The statements produced by a macro expansion shall not include a statement which 5 ends the scoping unit containing the EXPAND statement. 6C325 (R342) If a macro expansion produces a statement which begins a new scoping unit, it shall also 7 produce a statement which ends that scoping unit. 8C326 (R342) If the EXPAND statement appears as the action-stmt of an if-stmt, it shall expand 9 to exactly one action-stmt that is not an end-function-stmt, end-mp-subprogram-stmt, end- 10 program-stmt, end-subroutine-stmt, or if-stmt. 11C327 (R342) If the EXPAND statement appears as a do-term-action-stmt, it shall expand to exactly one action- 12 stmt that is not an arithmetic-if-stmt, continue-stmt, cycle-stmt, end-function-stmt, end-mp-subprogram-stmt, 13 end-program-stmt, end-subroutine-stmt, exit-stmt, goto-stmt, return-stmt, or stop-stmt. 14C328 (R342) If the EXPAND statement has a label, the expansion of the macro shall produce at least 15 one statement, and the first statement produced shall not have a label. 16C329 (R342) A macro-actual-arg shall appear corresponding to each nonoptional macro dummy ar- 17 gument. 18C330 (R342) At most one macro-actual-arg shall appear corresponding to each optional macro dummy 19 argument. 20Expansion of a macro is performed by the EXPAND statement. If the EXPAND statement has a label, 21the label is interpreted after expansion as belonging to the first statement of the expansion. R343 macro-actual-arg is [ macro-dummy-name = ] macro-actual-arg-value 22 23C331 (R343) macro-dummy-name shall be the name of a macro dummy argument of the macro being 24 expanded. 25C332 (R342) The macro-dummy-name= shall not be omitted unless it has been omitted from each 26 preceding macro-actual-arg in the expand-stmt. 27R344 macro-actual-arg-value is basic-token-sequence 28R345 basic-token-sequence is basic-token 29 or [ basic-token-sequence] nested-token-sequence 30 [ basic-token-sequence ] 31 or basic-token basic-token-sequence 32R346 basic-token is any lexical token except comma, parentheses, array 33 constructor delimiters, and semi-colon. 34R347 nested-token-sequence is ( [ arg-token ] ... ) 35 or (/ [ arg-token ] ... /) or lbracket [ arg-token ] ... rbracket 36 37R348 arg-token is basic-token 38 or , 39Macro expansion processes any macro declarations of the macro definition, and then expands its macro 40body block. Any macro expressions in macro-type-specs are evaluated and the kinds of the macro 38 2006/01/05 WORKING DRAFT J3/07-007 1variables thereby declared are determined for that particular expansion. 2Macro expansion of a macro body block processes each macro body construct of the macro body block 3in turn, starting with the first macro body construct and ending with the last macro body construct. 4Expansion of a statement within a macro body construct consists of three steps: (1) token replacement, 5 (2) token concatenation, and 6 (3) statement-dependent processing. 7 83.5.2.2 Token replacement 9Token replacement replaces each token of a macro body statement, assignment token sequence, or macro 10expression that is a macro local variable with the value of that variable. 11In a macro expression, a reference to the PRESENT intrinsic function with a macro dummy argument 12name as its actual argument is replaced by the token .TRUE. if the specified macro dummy argument 13is present, and the token .FALSE. if the specified macro dummy argument is not present. Otherwise, 14the value of a macro dummy argument that is present is the sequence of tokens from the corresponding 15actual argument, and the value of a macro dummy argument that is not present is a zero-length token 16sequence. 17The value of an integer macro variable is its minimal-length decimal representation; if negative this 18produces two tokens, a minus sign and an unsigned integer literal constant. An untyped macro local 19variable expands to the sequence of tokens that was assigned to it, or to zero-length token sequence if it 20has never been assigned to. 213.5.2.3 Token concatenation 22Token concatenation is performed with the %% operator, which is only permitted inside a macro defini- 23tion. After expansion, each sequence of single tokens separated by %% operators is replaced by a single 24token consisting of the concatenated text of the sequence of tokens. The result of a concatenation shall 25be a valid Fortran token, and may be a different kind of token from one or more of the original sequence 26of tokens. C333 (R338) The result of token concatenation shall have the form of a lexical token. 27 NOTE 3.12 For example, the sequence 3 %% .14159 %% E %% + %% 0 forms the single real literal constant 3.14159E+0. 283.5.2.4 Macro body statements 29Processing a macro body statement produces a whole or partial Fortran statement. A macro body 30statement that is either the first macro body statement processed by this macro expansion or the next 31macro body statement processed after a macro body statement that did not end with the continuation 32generation operator &&, is an initial macro body statement. The next macro body statement processed 33after a macro body statement that ends with && is a continuation macro body statement. An initial 34macro body statement that does not end with && produces a whole Fortran statement consisting of its 35token sequence. All other macro body statements produce partial Fortran statements, and the sequence 36of tokens starting with those produced by the initial macro body statement and appending the tokens 39 J3/07-007 WORKING DRAFT 2006/01/05 1produced by each subsequent continuation macro body statement form a Fortran statement. The && 2operators are not included in the token sequence. 33.5.2.5 The MACRO DO construct 4The MACRO DO construct specifies the repeated expansion of a macro body block. Processing the 5MACRO DO statement performs the following steps in sequence. 6 (1) The initial parameter m1, the terminal parameter m2, and the incrementation parameter 7 m3 are of type integer with the same kind type parameter as the macro-do-variable-name. 8 Their values are given by the first macro-expr, the second macro-expr, and the third macro- 9 expr of the macro-do-stmt respectively, including, if necessary, conversion to the kind type 10 parameter of the macro-do-variable-name according to the rules for numeric conversion 11 (Table 7.13). If the third macro-expr does not appear, m3 has the value 1. The value of m3 12 shall not be zero. (2) 13 The MACRO DO variable becomes defined with the value of the initial parameter m1. 14 (3) The iteration count is established and is the value of the expression (m2 - m1 + m3)/m3, 15 unless that value is negative, in which case the iteration count is 0. 16After this, the following steps are performed repeatedly until processing of the MACRO DO construct 17is finished. 18 (1) The iteration count is tested. If it is zero, the loop terminates and processing of the MACRO 19 DO construct is finished. 20 (2) If the iteration count is nonzero, the macro body block of the MACRO DO construct is 21 expanded. 22 (3) The iteration count is decremented by one. The MACRO DO variable is incremented by 23 the value of the incrementation parameter m3. 243.5.2.6 The MACRO IF construct 25The MACRO IF construct provides conditional expansion of macro body blocks. At most one of the 26macro body blocks of the MACRO IF construct is expanded. The macro conditions of the construct 27are evaluated in order until a true value is found or a MACRO ELSE or MACRO END IF statement is 28encountered. If a true value or a MACRO ELSE statement is found, the macro body block immediately 29following is expanded and this completes the processing of the construct. If none of the evaluated 30conditions is true and there is no MACRO ELSE statement, the processing of the construct is completed 31without expanding any of the macro body blocks within the construct. 323.5.2.7 Macro assignment 33Processing a macro integer assignment statement sets the macro local variable value to that of the macro 34expression. 35Processing a macro token assignment statement sets the macro local variable value to be the sequence 36of tokens following the equals sign. If no tokens appear after the equals sign, the macro local variable is 37set to the zero-length token sequence. 383.5.2.8 Macro definitions 39Processing a macro definition defines a new macro. If a macro definition is produced by a macro expan- 40sion, all of the statements of the produced macro definition have token replacement and concatenation 41applied to them before the new macro is defined. 40 2006/01/05 WORKING DRAFT J3/07-007 13.5.2.9 Examples NOTE 3.13 This is a macro which loops over an array of any rank and processes each array element. DEFINE MACRO loop_over(array,rank,traceinfo) MACRO INTEGER :: i BLOCK MACRO DO i=1,rank INTEGER loop_over_temp_%%i MACRO END DO MACRO DO i=1,rank DO loop_over_temp_%%i=1,size(array,i) MACRO END DO CALL impure_scalar_procedure(array(loop_over_temp_%%1 && MACRO DO i=2,rank ,loop_over_temp%i && MACRO END DO ),traceinfo) MACRO DO i=1,rank END DO MACRO END DO END BLOCK END MACRO NOTE 3.14 One can effectively pass macro names as macro arguments, since expansion of arguments occurs before analysis of each macro body statement. For example: DEFINE MACRO :: iterator(count,operation) MACRO DO i=1,count EXPAND operation(i) MACRO END DO END MACRO DEFINE MACRO :: process_element(j) READ *,a(j) result(j) = process(a(j)) IF (j>1) PRINT *,'difference =',result(j)-result(j-1) END MACRO EXPAND iterator(17,process_element) This expands into 17 sets of 3 statements: READ *,a(1) result(1) = process(a(1)) IF (1>1) PRINT *,'difference =',result(1)-result(1-1) READ *,a(2) result(2) = process(a(2)) IF (2>1) PRINT *,'difference =',result(2)-result(2-1) ... 41 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 3.14 (cont.) READ *,a(17) result(17) = process(a(17)) IF (17>1) PRINT *,'difference =',result(17)-result(17-1) NOTE 3.15 Using the ability to evaluate initialization expressions under macro control and test them, one can create interfaces and procedures for all kinds of a type, for example: DEFINE MACRO :: i_square_procs() MACRO INTEGER i MACRO DO i=1,1000 MACRO IF (SELECTED_INT_KIND(i)>=0 .AND. (i==1 .OR. SELECTED_INT_KIND(i)/=SELECTED_INT_KIND(i-1))) THEN FUNCTION i_square_range_%%i(a) RESULT(r) INTEGER(SELECTED_INT_KIND(i)) a,r r = a**2 END FUNCTION MACRO END IF MACRO END DO END MACRO NOTE 3.16 Macros can be used to define other macros on expansion. For example, ! Macro that defines a macro which assigns a value to an array element DEFINE MACRO :: assign_shortcut(rank) DEFINE MACRO assign_%%rank(array,indices,value) MACRO INTEGER :: i array(indices(1)&& MACRO DO i=2,rank ,indices(i)&& MACRO END DO )=value END MACRO assign_%%rank END MACRO assign_shortcut ! Create assignment macros for all ranks MACRO DO i=1,15 EXPAND assign_shortcut(i) MACRO END DO ! Now use the rank-3 assignment macro: REAL :: A(10,10,10) INTEGER :: indices(3)=[1,5,6] EXPAND assign_3(A,indices,5.0) ! Expands to: ! A(indices(1),indices(2),indices(3))=5.0 42 2006/01/05 WORKING DRAFT J3/07-007 4 Types 1 4.1 The concept of type 2 3Fortran provides an abstract means whereby data can be categorized without relying on a particular 4physical representation. This abstract means is the concept of type. 5A type has a name, a set of valid values, a means to denote such values (constants), and a set of 6operations to manipulate the values. 7A type is either an intrinsic type or a derived type. This part of ISO/IEC 1539 defines six intrinsic types: integer, real, complex, character, logical, and bits. 8 9A derived type is one that is defined by a derived-type definition (4.5.2) or by an intrinsic module. It shall be used only where it is accessible (4.5.2.2). An intrinsic type is always accessible. 10 114.1.1 Set of values 12For each type, there is a set of valid values. The sets of valid values for logical and bits are completely 13determined by this part of ISO/IEC 1539. The sets of valid values for integer, character, and real are 14processor dependent. The set of valid values for complex consists of the set of all the combinations of 15the values of the individual components. The set of valid values for a derived type is as defined in 4.5.8. 164.1.2 Constants 17The syntax for literal constants of each intrinsic type is specified in 4.4. 18The syntax for denoting a value indicates the type, type parameters, and the particular value. A constant value can be given a name (5.3.12, 5.4.10). 19 20A structure constructor (4.5.10) can be used to construct a constant value of derived type from an 21appropriate sequence of initialization expressions (7.1.12). Such a constant value is scalar even if it has 22components that are arrays. 4.1.3 Operations 23 24For each of the intrinsic types, a set of operations and corresponding operators is defined intrinsically. 25These are described in Clause 7. The intrinsic set can be augmented with operations and operators 26defined by functions with the OPERATOR interface (12.4.3.2). Operator definitions are described in 27Clauses 7 and 12. 28For derived types, there are no intrinsic operations. Operations on derived types can be defined by the program (4.5.11). 29 4.2 Type parameters 30 31A type might be parameterized. In this case, the set of values, the syntax for denoting the values, and 32the set of operations on the values of the type depend on the values of the parameters. 43 J3/07-007 WORKING DRAFT 2006/01/05 1The intrinsic types are all parameterized. Derived types may be defined to be parameterized. 2A type parameter is either a kind type parameter or a length type parameter. All type parameters are 3of type integer. 4A kind type parameter may be used in initialization and specification expressions within the derived-type 5definition (4.5.2) for the type; it participates in generic resolution (12.5.5.2). Each of the intrinsic types 6has a kind type parameter named KIND, which is used to distinguish multiple representations of the 7intrinsic type. NOTE 4.1 The value of a kind type parameter is always known at compile time. Some parameterizations that involve multiple representation forms need to be distinguished at compile time for practical implementation and performance. Examples include the multiple precisions of the intrinsic real type and the possible multiple character sets of the intrinsic character type. A type parameter of a derived type may be specified to be a kind type parameter in order to allow generic resolution based on the parameter; that is to allow a single generic to include two specific procedures that have interfaces distinguished only by the value of a kind type parameter of a dummy argument. All generic references are resolvable at compile time. 8A length type parameter may be used in specification expressions within the derived-type definition for 9the type, but it shall not be used in initialization expressions. The intrinsic character type has a length 10type parameter named LEN, which is the length of the string. NOTE 4.2 The adjective "length" is used for type parameters other than kind type parameters because they often specify a length, as for intrinsic character type. However, they may be used for other purposes. The important difference from kind type parameters is that their values need not be known at compile time and might change during execution. A type parameter value may be specified with a type specification (4.4, 4.5.9). 11 12R401 type-param-value is scalar-int-expr 13 or * 14 or : C401 (R401) The type-param-value for a kind type parameter shall be an initialization expression. 15 16C402 (R401) A colon shall not be used as a type-param-value except in the declaration of an entity or 17 component that has the POINTER or ALLOCATABLE attribute. 18A deferred type parameter is a length type parameter whose value can change during execution of 19the program. A colon as a type-param-value specifies a deferred type parameter. 20The values of the deferred type parameters of an object are determined by successful execution of an 21ALLOCATE statement (6.3.1), execution of an intrinsic assignment statement (7.2.1.3), execution of a pointer assignment statement (7.2.2), or by argument association (12.5.2). 22 NOTE 4.3 Deferred type parameters of functions, including function procedure pointers, have no values. Instead, they indicate that those type parameters of the function result will be determined by execution of the function, if it returns an allocated allocatable result or an associated pointer result. 44 2006/01/05 WORKING DRAFT J3/07-007 1An assumed type parameter is a length type parameter for a dummy argument that assumes the 2type parameter value from the corresponding actual argument; it is also used for an associate name in a 3SELECT TYPE construct that assumes the type parameter value from the corresponding selector, and 4for a named constant of type character that assumes its length from the initialization-expr. An asterisk 5as a type-param-value specifies an assumed type parameter. 4.3 Relationship of types and values to objects 6 7The name of a type serves as a type specifier and may be used to declare objects of that type. A 8declaration specifies the type of a named object. A data object may be declared explicitly or implicitly. 9Data objects may have attributes in addition to their types. Clause 5 describes the way in which a data 10object is declared and how its type and other attributes are specified. 11Scalar data of any intrinsic or derived type may be shaped in a rectangular pattern to compose an array 12of the same type and type parameters. An array object has a type and type parameters just as a scalar 13object does. 14A variable is a data object. The type and type parameters of a variable determine which values that 15variable may take. Assignment (7.2) provides one means of defining or redefining the value of a variable 16of any type. 17The type of a variable determines the operations that may be used to manipulate the variable. 4.3.1 Type specifiers and type compatibility 18 194.3.1.1 General 20A type is specified by a type specifier. 21R402 type-spec is intrinsic-type-spec 22 or derived-type-spec C403 (R402) The derived-type-spec shall not specify an abstract type (4.5.7). 23 24R403 declaration-type-spec is intrinsic-type-spec 25 or TYPE ( intrinsic-type-spec ) 26 or TYPE ( derived-type-spec ) 27 or CLASS ( derived-type-spec ) or CLASS ( * ) 28 29C404 (R403) In a declaration-type-spec, every type-param-value that is not a colon or an asterisk shall 30 be a specification-expr. 31C405 (R403) In a declaration-type-spec that uses the CLASS keyword, derived-type-spec shall specify an extensible type (4.5.7). 32 C406 (R403) The TYPE(derived-type-spec) shall not specify an abstract type (4.5.7). 33 34C407 An entity declared with the CLASS keyword shall be a dummy argument or have the ALLO- 35 CATABLE or POINTER attribute. It shall not have the VALUE attribute. 36An intrinsic-type-spec specifies the named intrinsic type and its type parameter values. A derived-type- 37spec specifies the named derived type and its type parameter values. 45 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 4.4 A type-spec is used in an array constructor, a SELECT TYPE construct, or an ALLOCATE statement. Elsewhere, a declaration-type-spec is used. 14.3.1.2 TYPE 2A TYPE type specifier is used to declare entities of an intrinsic or derived type. 3Where a data entity is declared explicitly using the TYPE type specifier to be of derived type, the 4specified derived type shall have been defined previously in the scoping unit or be accessible there by 5use or host association. If the data entity is a function result, the derived type may be specified in 6the FUNCTION statement provided the derived type is defined within the body of the function or is 7accessible there by use or host association. If the derived type is specified in the FUNCTION statement 8and is defined within the body of the function, it is as if the function result variable was declared with 9that derived type immediately following the derived-type-def of the specified derived type. 104.3.1.3 CLASS 11A polymorphic entity is a data entity that is able to be of differing types during program execution. 12The type of a data entity at a particular point during execution of a program is its dynamic type. The 13declared type of a data entity is the type that it is declared to have, either explicitly or implicitly. 14A CLASS type specifier is used to declare polymorphic entities. The declared type of a polymorphic 15entity is the specified type if the CLASS type specifier contains a type name. 16An entity declared with the CLASS(*) specifier is an unlimited polymorphic entity. An unlimited 17polymorphic entity is not declared to have a type. It is not considered to have the same declared type 18as any other entity, including another unlimited polymorphic entity. 19A nonpolymorphic entity is type compatible only with entities of the same declared type. A poly- 20morphic entity that is not an unlimited polymorphic entity is type compatible with entities of the same 21declared type or any of its extensions. Even though an unlimited polymorphic entity is not considered 22to have a declared type, it is type compatible with all entities. An entity is type compatible with a type 23if it is type compatible with entities of that type. 24Two entities are type incompatible if neither is type compatible with the other. NOTE 4.5 Given TYPE TROOT ... TYPE,EXTENDS(TROOT) :: TEXTENDED ... CLASS(TROOT) A CLASS(TEXTENDED) B ... A is type compatible with B but B is not type compatible with A. 25A polymorphic allocatable object may be allocated to be of any type with which it is type compatible. 26A polymorphic pointer or dummy argument may, during program execution, be associated with objects 27with which it is type compatible. 28The dynamic type of an allocated allocatable polymorphic object is the type with which it was allocated. 46 2006/01/05 WORKING DRAFT J3/07-007 1The dynamic type of an associated polymorphic pointer is the dynamic type of its target. The dynamic 2type of a nonallocatable nonpointer polymorphic dummy argument is the dynamic type of its associated 3actual argument. The dynamic type of an unallocated allocatable or a disassociated pointer is the same 4as its declared type. The dynamic type of an entity identified by an associate name (8.1.3) is the dynamic 5type of the selector with which it is associated. The dynamic type of an object that is not polymorphic 6is its declared type. NOTE 4.6 Only components of the declared type of a polymorphic object may be designated by component selection (6.1.2). 4.4 Intrinsic types 7 4.4.1 Classification and specification 8 9Each intrinsic type is classified as a numeric type or a nonnumeric type. The numeric types are integer, 10real, and complex. The nonnumeric intrinsic types are character, logical, and bits. 11The numeric types are provided for numerical computation. The normal operations of arithmetic, 12addition (+), subtraction (­), multiplication (*), division (/), exponentiation (**), identity (unary +), and negation (unary ­), are defined intrinsically for the numeric types. 13 14R404 intrinsic-type-spec is INTEGER [ kind-selector ] 15 or REAL [ kind-selector ] 16 or DOUBLE PRECISION 17 or COMPLEX [ kind-selector ] 18 or CHARACTER [ char-selector ] 19 or LOGICAL [ kind-selector ] or BITS [ kind-selector ] 20 R405 kind-selector is ( [ KIND = ] scalar-int-initialization-expr ) 21 22C408 (R405) The value of scalar-int-initialization-expr shall be nonnegative and shall specify a rep- 23 resentation method that exists on the processor. 4.4.2 Integer type 24 25The set of values for the integer type is a subset of the mathematical integers. The processor shall 26provide one or more representation methods that define sets of values for data of type integer. Each 27such method is characterized by a value for a type parameter called the kind type parameter; this kind 28type parameter is of type default integer. The kind type parameter of a representation method is returned 29by the intrinsic inquiry function KIND (13.7.96). The decimal exponent range of a representation method 30is returned by the intrinsic function RANGE (13.7.143). The intrinsic function SELECTED INT KIND 31(13.7.153) returns a kind value based on a specified decimal range requirement. The integer type includes 32a zero value, which is considered to be neither negative nor positive. The value of a signed integer zero 33is the same as the value of an unsigned integer zero. 34The processor shall provide at least one representation method with a decimal exponent range greater 35than or equal to 18. 36The type specifier for the integer type uses the keyword INTEGER. 37If the kind type parameter is not specified, the default kind value is KIND (0) and the type specified is 38default integer. The decimal exponent range of default integer shall be at least 5. 47 J3/07-007 WORKING DRAFT 2006/01/05 1Any integer value may be represented as a signed-int-literal-constant. R406 signed-int-literal-constant is [ sign ] int-literal-constant 2 R407 int-literal-constant is digit-string [ kind-param ] 3 4R408 kind-param is digit-string 5 or scalar-int-constant-name R409 signed-digit-string is [ sign ] digit-string 6 R410 digit-string is digit [ digit ] ... 7 8R411 sign is + 9 or ­ C409 (R408) A scalar-int-constant-name shall be a named constant of type integer. 10 C410 (R408) The value of kind-param shall be nonnegative. 11 12C411 (R407) The value of kind-param shall specify a representation method that exists on the pro- 13 cessor. 14The optional kind type parameter following digit-string specifies the kind type parameter of the integer 15constant; if it is not present, the constant is of type default integer. 16An integer constant is interpreted as a decimal value. NOTE 4.7 Examples of signed integer literal constants are: 473 +56 -101 21_2 21_SHORT 1976354279568241_8 where SHORT is a scalar integer named constant. 4.4.3 Real type 17 18The real type has values that approximate the mathematical real numbers. The processor shall provide 19two or more approximation methods that define sets of values for data of type real. Each such method 20has a representation method and is characterized by a value for a type parameter called the kind 21type parameter; this kind type parameter is of type default integer. The kind type parameter of an approximation method is returned by the intrinsic inquiry function KIND (13.7.96). 22 23The decimal precision, decimal exponent range, and radix of an approximation method are returned by 24the intrinsic functions PRECISION (13.7.137), RANGE (13.7.143), and RADIX (13.7.140). The intrinsic 25function SELECTED REAL KIND (13.7.154) returns a kind value based on specified precision, range, 26and radix requirements. 48 2006/01/05 WORKING DRAFT J3/07-007 NOTE 4.8 See C.1.1 for remarks concerning selection of approximation methods. 1The real type includes a zero value. Processors that distinguish between positive and negative zeros 2shall treat them as mathematically equivalent (1) in all relational operations, 3 4 (2) as actual arguments to intrinsic procedures other than those for which it is explicitly specified 5 that negative zero is distinguished, and (3) 6 as the scalar-numeric-expr in an arithmetic IF. NOTE 4.9 On a processor that can distinguish between 0.0 and -0.0, ( X >= 0.0 ) evaluates to true if X = 0.0 or if X = -0.0, ( X < 0.0 ) evaluates to false for X = -0.0, and IF (X) 1,2,3 causes a transfer of control to the branch target statement with the statement label "2" for both X = 0.0 and X = -0.0. In order to distinguish between 0.0 and -0.0, a program should use the SIGN function. SIGN(1.0,X) will return -1.0 if X < 0.0 or if the processor distinguishes between 0.0 and -0.0 and X has the value -0.0. 7The type specifier for the real type uses the keyword REAL. The keyword DOUBLE PRECISION is an 8alternative specifier for one kind of real type. 9If the type keyword REAL is specified and the kind type parameter is not specified, the default kind 10value is KIND (0.0) and the type specified is default real. If the type keyword DOUBLE PRECISION 11is specified, the kind value is KIND (0.0D0) and the type specified is double precision real. The 12decimal precision of the double precision real approximation method shall be greater than that of the 13default real method. 14The decimal precision of double precision real shall be at least 10, and its decimal exponent range shall 15be at least 37. It is recommended that the decimal precision of default real be at least 6, and that its 16decimal exponent range be at least 37. R412 signed-real-literal-constant is [ sign ] real-literal-constant 17 18R413 real-literal-constant is significand [ exponent-letter exponent ] [ kind-param ] or digit-string exponent-letter exponent [ kind-param ] 19 20R414 significand is digit-string . [ digit-string ] 21 or . digit-string 22R415 exponent-letter is E 23 or D 49 J3/07-007 WORKING DRAFT 2006/01/05 1R416 exponent is signed-digit-string C412 (R413) If both kind-param and exponent-letter are present, exponent-letter shall be E. 2 3C413 (R413) The value of kind-param shall specify an approximation method that exists on the 4 processor. 5A real literal constant without a kind type parameter is a default real constant if it is without an 6exponent part or has exponent letter E, and is a double precision real constant if it has exponent letter 7D. A real literal constant written with a kind type parameter is a real constant with the specified kind 8type parameter. 9The exponent represents the power of ten scaling to be applied to the significand or digit string. The 10meaning of these constants is as in decimal scientific notation. 11The significand may be written with more digits than a processor will use to approximate the value of 12the constant. NOTE 4.10 Examples of signed real literal constants are: -12.78 +1.6E3 2.1 -16.E4_8 0.45D-4 10.93E7_QUAD .123 3E4 where QUAD is a scalar integer named constant. 4.4.4 Complex type 13 14The complex type has values that approximate the mathematical complex numbers. The values of a 15complex type are ordered pairs of real values. The first real value is called the real part, and the second 16real value is called the imaginary part. 17Each approximation method used to represent data entities of type real shall be available for both the 18real and imaginary parts of a data entity of type complex. A kind type parameter may be specified for 19a complex entity and selects for both parts the real approximation method characterized by this kind 20type parameter value; this kind type parameter is of type default integer. The kind type parameter of an approximation method is returned by the intrinsic inquiry function KIND (13.7.96). 21 22The type specifier for the complex type uses the keyword COMPLEX. There is no keyword for double 23precision complex. If the type keyword COMPLEX is specified and the kind type parameter is not 24specified, the default kind value is the same as that for default real, the type of both parts is default 25real, and the type specified is default complex. R417 complex-literal-constant is ( real-part , imag-part ) 26 27R418 real-part is signed-int-literal-constant 28 or signed-real-literal-constant 29 or named-constant 30R419 imag-part is signed-int-literal-constant 50 2006/01/05 WORKING DRAFT J3/07-007 1 or signed-real-literal-constant 2 or named-constant C414 (R417) Each named constant in a complex literal constant shall be of type integer or real. 3 4If the real part and the imaginary part of a complex literal constant are both real, the kind type 5parameter value of the complex literal constant is the kind type parameter value of the part with the 6greater decimal precision; if the precisions are the same, it is the kind type parameter value of one of the 7parts as determined by the processor. If a part has a kind type parameter value different from that of 8the complex literal constant, the part is converted to the approximation method of the complex literal 9constant. 10If both the real and imaginary parts are integer, they are converted to the default real approximation 11method and the constant is of type default complex. If only one of the parts is an integer, it is converted 12to the approximation method selected for the part that is real and the kind type parameter value of the 13complex literal constant is that of the part that is real. NOTE 4.11 Examples of complex literal constants are: (1.0, -1.0) (3, 3.1E6) (4.0_4, 3.6E7_8) ( 0., PI) where PI is a previously declared named real constant. 4.4.5 Character type 14 154.4.5.1 Character sets 16The character type has a set of values composed of character strings. A character string is a sequence 17of characters, numbered from left to right 1, 2, 3, ... up to the number of characters in the string. The 18number of characters in the string is called the length of the string. The length is a type parameter; its 19kind is processor-dependent and its value is greater than or equal to zero. 20The processor shall provide one or more representation methods that define sets of values for data 21of type character. Each such method is characterized by a value for a type parameter called the kind 22type parameter; this kind type parameter is of type default integer. The kind type parameter of a rep- 23resentation method is returned by the intrinsic inquiry function KIND (13.7.96). The intrinsic function 24SELECTED CHAR KIND (13.7.152) returns a kind value based on the name of a character type. Any 25character of a particular representation method representable in the processor may occur in a character 26string of that representation method. 27The character set defined by ISO/IEC 646:1991 (International Reference Version) is referred to as the 28ASCII character set and its corresponding representation method is the ASCII character type. 29The character set defined by ISO/IEC 10646-1:2000 UCS-4 is referred to as the ISO 10646 character 30set and its corresponding representation method is the ISO 10646 character type. 314.4.5.2 Character type specifier 32The type specifier for the character type uses the keyword CHARACTER. 33If the kind type parameter is not specified, the default kind value is KIND ('A') and the type specified 34is default character. 51 J3/07-007 WORKING DRAFT 2006/01/05 1The default character kind shall support a character set that includes the Fortran character set. By 2supplying nondefault character kinds, the processor may support additional character sets. The charac- 3ters available in nondefault character kinds are not specified by this part of ISO/IEC 1539, except that 4one character in each nondefault character set shall be designated as a blank character to be used as a 5padding character. 6R420 char-selector is length-selector 7 or ( LEN = type-param-value , 8 KIND = scalar-int-initialization-expr ) 9 or ( type-param-value , 10 [ KIND = ] scalar-int-initialization-expr ) 11 or ( KIND = scalar-int-initialization-expr [ , LEN =type-param-value ] ) 12 13R421 length-selector is ( [ LEN = ] type-param-value ) 14 or * char-length [ , ] 15R422 char-length is ( type-param-value ) 16 or int-literal-constant 17C415 (R420) The value of scalar-int-initialization-expr shall be nonnegative and shall specify a rep- 18 resentation method that exists on the processor. C416 (R422) The int-literal-constant shall not include a kind-param. 19 C417 (R422) A type-param-value in a char-length shall be a colon, asterisk, or specification-expr. 20 C418 (R420 R421 R422) A type-param-value of * shall be used only 21 (1) to declare a dummy argument, 22 (2) to declare a named constant, 23 24 (3) in the type-spec of an ALLOCATE statement wherein each allocate-object is a dummy 25 argument of type CHARACTER with an assumed character length, (4) in the type-spec or derived-type-spec of a type guard statement (8.1.9), or 26 (5) 27 in an external function, to declare the character length parameter of the function result. 28C419 A function name shall not be declared with an asterisk type-param-value unless it is of type CHAR- 29 ACTER and is the name of the result of an external function or the name of a dummy function. 30C420 A function name declared with an asterisk type-param-value shall not be an array, a pointer, elemental, recursive, 31 or pure. 32C421 (R421) The optional comma in a length-selector is permitted only in a declaration-type-spec in a type-declaration- 33 stmt. 34C422 (R421) The optional comma in a length-selector is permitted only if no double-colon separator appears in the 35 type-declaration-stmt. 36C423 (R420) The length specified for a character statement function or for a statement function dummy argument of 37 type character shall be an initialization expression. 38The char-selector in a CHARACTER intrinsic-type-spec and the * char-length in an entity-decl or in 39a component-decl of a type definition specify character length. The * char-length in an entity-decl or 40a component-decl specifies an individual length and overrides the length specified in the char-selector, 41if any. If a * char-length is not specified in an entity-decl or a component-decl, the length-selector or 42type-param-value specified in the char-selector is the character length. If the length is not specified in a 43char-selector or a * char-length, the length is 1. 52 2006/01/05 WORKING DRAFT J3/07-007 1If the character length parameter value evaluates to a negative value, the length of character entities 2declared is zero. A character length parameter value of : indicates a deferred type parameter (4.2). A 3char-length type parameter value of * has the following meanings. 4 (1) If used to declare a dummy argument of a procedure, the dummy argument assumes the 5 length of the associated actual argument. (2) If used to declare a named constant, the length is that of the constant value. 6 7 (3) If used in the type-spec of an ALLOCATE statement, each allocate-object assumes its length 8 from the associated actual argument. 9 (4) If used in the type-spec of a type guard statement, the associating entity assumes its length 10 from the selector. 11 (5) If used to specify the character length parameter of a function result, any scoping unit invoking the function 12 shall declare the function name with a character length parameter value other than * or access such a 13 definition by host or use association. When the function is invoked, the length of the result variable in the 14 function is assumed from the value of this type parameter. 154.4.5.3 Character literal constant 16A character literal constant is written as a sequence of characters, delimited by either apostrophes 17or quotation marks. 18R423 char-literal-constant is [ kind-param ] ' [ rep-char ] ... ' or [ kind-param 19 ] " [ rep-char ] ... " 20C424 (R423) The value of kind-param shall specify a representation method that exists on the pro- 21 cessor. 22The optional kind type parameter preceding the leading delimiter specifies the kind type parameter of 23the character constant; if it is not present, the constant is of type default character. 24For the type character with kind kind-param, if present, and for type default character otherwise, a 25representable character, rep-char, is defined as follows. (1) In free source form, it is any graphic character in the processor-dependent character set. 26 27 (2) In fixed source form, it is any character in the processor-dependent character set. A processor may restrict 28 the occurrence of some or all of the control characters. NOTE 4.12 Fortran 77 allowed any character to occur in a character context. This part of ISO/IEC 1539 allows a source program to contain characters of more than one kind. Some processors may identify characters of nondefault kinds by control characters (called "escape" or "shift" characters). It is difficult, if not impossible, to process, edit, and print files where some occurences of control char- acters have their intended meaning and some occurrences might not. Almost all control characters have uses or effects that effectively preclude their use in character contexts and this is why free source form allows only graphic characters as representable characters. Nevertheless, for compatibility with Fortran 77, control characters remain permitted in principle in fixed source form. 29The delimiting apostrophes or quotation marks are not part of the value of the character literal constant. 30An apostrophe character within a character constant delimited by apostrophes is represented by two 31consecutive apostrophes (without intervening blanks); in this case, the two apostrophes are counted as 32one character. Similarly, a quotation mark character within a character constant delimited by quotation 33marks is represented by two consecutive quotation marks (without intervening blanks) and the two 34quotation marks are counted as one character. 35A zero-length character literal constant is represented by two consecutive apostrophes (without inter- 53 J3/07-007 WORKING DRAFT 2006/01/05 1vening blanks) or two consecutive quotation marks (without intervening blanks) outside of a character 2context. 3The intrinsic operation concatenation (//) is defined between two data entities of type character (7.1.5.3) with the same kind type parameter. 4 NOTE 4.13 Examples of character literal constants are: "DON'T" 'DON''T' both of which have the value DON'T and '' which has the zero-length character string as its value. NOTE 4.14 An example of a nondefault character literal constant, where the processor supports the corre- sponding character set, is: ¡ ¢ £ ¤ ¢ ¥ ¦ § NIHONGO ' ' where NIHONGO is a named constant whose value is the kind type parameter for Nihongo (Japanese) characters. This means "Without her, nothing is possible". 54.4.5.4 Collating sequence 6The processor defines a collating sequence for the character set of each kind of character. A collating 7sequence is a one-to-one mapping of the characters into the nonnegative integers such that each charac- 8ter corresponds to a different nonnegative integer. The intrinsic functions CHAR (13.7.30) and ICHAR (13.7.84) provide conversions between the characters and the integers according to this mapping. 9 NOTE 4.15 For example: ICHAR ( 'X' ) returns the integer value of the character 'X' according to the collating sequence of the processor. 10The collating sequence of the default character type shall satisfy the following constraints. (1) ICHAR ('A') < ICHAR ('B') < ... < ICHAR ('Z') for the twenty-six upper-case letters. 11 (2) ICHAR ('0') < ICHAR ('1') < ... < ICHAR ('9') for the ten digits. 12 (3) ICHAR (' ') < ICHAR ('0') < ICHAR ('9') < ICHAR ('A') or 13 ICHAR (' ') < ICHAR ('A') < ICHAR ('Z') < ICHAR ('0'). 14 (4) ICHAR ('a') < ICHAR ('b') < ... < ICHAR ('z') for the twenty-six lower-case letters. 15 (5) ICHAR (' ') < ICHAR ('0') < ICHAR ('9') < ICHAR ('a') or 16 ICHAR (' ') < ICHAR ('a') < ICHAR ('z') < ICHAR ('0'). 17 18Except for blank, there are no constraints on the location of the special characters and underscore in 19the collating sequence, nor is there any specified collating sequence relationship between the upper-case 54 2006/01/05 WORKING DRAFT J3/07-007 1and lower-case letters. 2The collating sequence for the ASCII character type is as defined by ISO/IEC 646:1991 (International 3Reference Version); this collating sequence is called the ASCII collating sequence in this part of 4ISO/IEC 1539. The collating sequence for the ISO 10646 character type is as defined by ISO/IEC 510646-1:2000. NOTE 4.16 The intrinsic functions ACHAR (13.7.2) and IACHAR (13.7.77) provide conversion between char- acters and corresponding integer values according to the ASCII collating sequence. 6The intrinsic functions LGT, LGE, LLE, and LLT (13.7.101-13.7.104) provide comparisons between 7strings based on the ASCII collating sequence. International portability is guaranteed if the set of 8characters used is limited to the letters, digits, underscore, and special characters. 4.4.6 Logical type 9 10The logical type has two values, which represent true and false. 11The processor shall provide one or more representation methods for data of type logical. Each such 12method is characterized by a value for a type parameter called the kind type parameter; this kind type 13parameter is of type default integer. The kind type parameter of a representation method is returned by the intrinsic inquiry function KIND (13.7.96). 14 15The type specifier for the logical type uses the keyword LOGICAL. 16If the kind type parameter is not specified, the default kind value is KIND (.FALSE.) and the type 17specified is default logical. 18R424 logical-literal-constant is .TRUE. [ kind-param ] or .FALSE. [ kind-param ] 19 20C425 (R424) The value of kind-param shall specify a representation method that exists on the pro- 21 cessor. 22The optional kind type parameter specifies the kind type parameter of the logical constant; if it is not 23present, the constant is of type default logical. 24The intrinsic operations defined for data entities of logical type are negation (.NOT.), conjunction 25(.AND.), inclusive disjunction (.OR.), logical equivalence (.EQV.), and logical nonequivalence (.NEQV., 26.XOR.) as described in 7.1.5.4. There is also a set of intrinsically defined relational operators that 27compare the values of data entities of other types and yield a value of type default logical. These 28operations are described in 7.1.5.6. 4.4.7 Bits type 29 30The bits type has a set of values composed of ordered sequences of bits. The number of bits in 31the sequence is specified by the kind type parameter, which shall be greater than or equal to zero. 32The processor shall provide representation methods with kind type parameter values equal to every 33nonnegative integer less than or equal to a processor-determined limit. This limit shall be at least as 34large as the storage size, expressed in bits, of every supported kind of type integer, real, complex, and 35logical. Additional representation methods may be provided. 36The type specifier for the bits type uses the keyword BITS. 37If the kind type parameter is not specified for a bits variable, the default kind value is the size of a 55 J3/07-007 WORKING DRAFT 2006/01/05 1numeric storage unit expressed in bits, and the type specified is default bits. 2R425 bits-literal-constant is binary-constant [ kind-param ] 3 or octal-constant [ kind-param ] or hex-constant [ kind-param ] 4 5R426 binary-constant is B ' digit [ digit ] ... ' 6 or B " digit [ digit ] ... " C426 (R426) digit shall have one of the values 0 or 1. 7 8R427 octal-constant is O ' digit [ digit ] ... ' 9 or O " digit [ digit ] ... " C427 (R427) digit shall have one of the values 0 through 7. 10 11R428 hex-constant is Z ' hex-digit [ hex-digit ] ... ' 12 or Z " hex-digit [ hex-digit ] ... " 13R429 hex-digit is digit 14 or A 15 or B 16 or C 17 or D 18 or E 19 or F 20The hex-digits A through F represent the numbers ten through fifteen, respectively; they may be repre- 21sented by their lower-case equivalents. 22If the optional kind type parameter is not specified for a bits literal constant, the kind value is assumed 23from the form of the constant. If the constant is a binary-constant the kind value is the number 24of digit characters. If the constant is an octal-constant the kind value is three times the number of 25digit characters. If the constant is a hex-constant the kind value is four times the number of hex-digit 26characters. NOTE 4.17 Even if a bits value is too large to fit into a single statement as a literal constant, it can be constructed by concatenation of bits named constants. 27Each digit of an octal constant represents three bits, and each hex digit of a hex constant represents 28four bits, according to their numerical representations as binary integers, with leading zero bits where 29needed. 30If a kind-param is specified for a bits literal constant and has a value greater than the number of bits 31specified by its digits, the constant is padded on the left (13.3) with enough zero bits to create a constant 32of kind kind-param. If the kind-param specified has a value smaller the number of bits specified by its 33digits, only the rightmost kind-param bits are used to determine the value of the constant and the 34remaining bits shall be zero. NOTE 4.18 Though the processor is required to provide bit kinds only up to four times the size of a numeric storage unit, or up to the maximum intrinsic type size (whichever is larger), it is expected that the actual size limit will be much larger, based on system capacity constraints. Use of BITS objects with KIND values equal to small integer multiples of NUMERIC STORAGE SIZE should result in more efficient execution. 56 2006/01/05 WORKING DRAFT J3/07-007 4.5 Derived types 1 4.5.1 Derived type concepts 2 3Additional types may be derived from the intrinsic types and other derived types. A type definition is 4required to define the name of the type and the names and attributes of its components and type-bound 5procedures. 6A derived type may be parameterized by multiple type parameters, each of which is defined to be either 7a kind or length type parameter and may have a default value. 8The ultimate components of an object of derived type are the components that are of intrinsic type 9or have the POINTER or ALLOCATABLE attribute, plus the ultimate components of the components 10of the object that are of derived type and have neither the ALLOCATABLE nor POINTER attribute. NOTE 4.19 The ultimate components of objects of the derived type kids defined below are name, age, and other_kids. type :: person character(len=20) :: name integer :: age end type person type :: kids type(person) :: oldest_child type(person), allocatable, dimension(:) :: other_kids end type kids 11The direct components of an object of derived type are the components of that object, plus the direct 12components of the components of the object that are of derived type and have neither the ALLOCAT- 13ABLE nor POINTER attribute. 14By default, no storage sequence is implied by the order of the component definitions. However, a storage 15order is implied for a sequence type (4.5.2.3). If the derived type has the BIND attribute, the storage sequence is that required by the companion processor (2.5.10, 15.3.4). 16 17A scalar entity of derived type is a structure. If a derived type has the SEQUENCE property, a scalar 18entity of the type is a sequence structure. 4.5.2 Derived-type definition 19 204.5.2.1 Syntax 21R430 derived-type-def is derived-type-stmt 22 [ type-param-def-stmt ] ... 23 [ private-or-sequence ] ... 24 [ component-part ] 25 [ type-bound-procedure-part ] 26 end-type-stmt 27R431 derived-type-stmt is TYPE [ [ , type-attr-spec-list ] :: ] type-name [ ( type-param-name-list ) ] 28 29R432 type-attr-spec is ABSTRACT 57 J3/07-007 WORKING DRAFT 2006/01/05 1 or access-spec 2 or BIND (C) or EXTENDS ( parent-type-name ) 3 4C428 (R431) A derived type type-name shall not be DOUBLEPRECISION or the same as the name of any intrinsic type defined in this part of ISO/IEC 1539. 5 C429 (R431) The same type-attr-spec shall not appear more than once in a given derived-type-stmt. 6 C430 (R432) A parent-type-name shall be the name of a previously defined extensible type (4.5.7). 7 8C431 (R430) If the type definition contains or inherits (4.5.7.2) a deferred binding (4.5.5), ABSTRACT 9 shall appear. C432 (R430) If ABSTRACT appears, the type shall be extensible. 10 C433 (R430) If EXTENDS appears, SEQUENCE shall not appear. 11 12C434 (R430) If EXTENDS appears and the type being defined has a co-array ultimate component, 13 its parent type shall have a co-array ultimate component. 14R433 private-or-sequence is private-components-stmt 15 or sequence-stmt 16C435 (R430) The same private-or-sequence shall not appear more than once in a given derived-type- 17 def . R434 end-type-stmt is END TYPE [ type-name ] 18 19C436 (R434) If END TYPE is followed by a type-name, the type-name shall be the same as that in 20 the corresponding derived-type-stmt. 21Derived types with the BIND attribute are subject to additional constraints as specified in 15.3.4. NOTE 4.20 An example of a derived-type definition is: TYPE PERSON INTEGER AGE CHARACTER (LEN = 50) NAME END TYPE PERSON An example of declaring a variable CHAIRMAN of type PERSON is: TYPE (PERSON) :: CHAIRMAN 224.5.2.2 Accessibility 23Types that are defined in a module or accessible in that module by use association have either the 24PUBLIC or PRIVATE attribute. Types for which an access-spec is not explicitly specified in that 25module have the default accessibility attribute for that module. The default accessibility attribute for a 26module is PUBLIC unless it has been changed by a PRIVATE statement (5.4.1). Only types that have 27the PUBLIC attribute in that module are available to be accessed from that module by use association. 28The accessibility of a type does not affect, and is not affected by, the accessibility of its components and 29bindings. 58 2006/01/05 WORKING DRAFT J3/07-007 1If a type definition is private, then the type name, and thus the structure constructor (4.5.10) for the 2type, are accessible only within the module containing the definition, and within its descendants. NOTE 4.21 An example of a type with a private name is: TYPE, PRIVATE :: AUXILIARY LOGICAL :: DIAGNOSTIC CHARACTER (LEN = 20) :: MESSAGE END TYPE AUXILIARY Such a type would be accessible only within the module in which it is defined, and within its descendants. 34.5.2.3 Sequence type 4R435 sequence-stmt is SEQUENCE 5C437 (R439) If SEQUENCE appears, each data component shall be declared to be of an intrinsic type 6 or of a sequence derived type. C438 (R430) If SEQUENCE appears, a type-bound-procedure-part shall not appear. 7 8If the SEQUENCE statement appears, the type is a sequence type. The order of the component 9definitions in a sequence type specifies a storage sequence for objects of that type. The type is a 10numeric sequence type if there are no type parameters, no pointer or allocatable components, and 11each component is of type default integer, default real, double precision real, default complex, default 12logical, default bits, or a numeric sequence type. The type is a character sequence type if there 13are no type parameters, no pointer or allocatable components, and each component is of type default 14character or a character sequence type. NOTE 4.22 An example of a numeric sequence type is: TYPE NUMERIC_SEQ SEQUENCE INTEGER :: INT_VAL REAL :: REAL_VAL LOGICAL :: LOG_VAL END TYPE NUMERIC_SEQ NOTE 4.23 A structure resolves into a sequence of components. Unless the structure includes a SEQUENCE statement, the use of this terminology in no way implies that these components are stored in this, or any other, order. Nor is there any requirement that contiguous storage be used. The sequence merely refers to the fact that in writing the definitions there will necessarily be an order in which the components appear, and this will define a sequence of components. This order is of limited significance because a component of an object of derived type will always be accessed by a component name except in the following contexts: the sequence of expressions in a derived-type value constructor, intrinsic assignment, the data values in namelist input data, and the inclusion of the structure in an input/output list of a formatted data transfer, where it is expanded to this sequence of components. Provided the processor adheres to the defined order in these cases, it is otherwise free to organize the storage of the components for any nonsequence structure in memory 59 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 4.23 (cont.) as best suited to the particular architecture. 14.5.2.4 Determination of derived types 2Derived-type definitions with the same type name may appear in different scoping units, in which case 3they may be independent and describe different derived types or they may describe the same type. 4Two data entities have the same type if they are declared with reference to the same derived-type 5definition. The definition may be accessed from a module or from a host scoping unit. Data entities in 6different scoping units also have the same type if they are declared with reference to different derived-type 7definitions that specify the same type name, all have the SEQUENCE property or all have the BIND 8attribute, have no components with PRIVATE accessibility, and have type parameters and components 9that agree in order, name, and attributes. Otherwise, they are of different derived types. A data entity 10declared using a type with the SEQUENCE property or with the BIND attribute is not of the same type 11as an entity of a type declared to be PRIVATE or that has any components that are PRIVATE. NOTE 4.24 An example of declaring two entities with reference to the same derived-type definition is: TYPE POINT REAL X, Y END TYPE POINT TYPE (POINT) :: X1 CALL SUB (X1) ... CONTAINS SUBROUTINE SUB (A) TYPE (POINT) :: A ... END SUBROUTINE SUB The definition of derived type POINT is known in subroutine SUB by host association. Because the declarations of X1 and A both reference the same derived-type definition, X1 and A have the same type. X1 and A also would have the same type if the derived-type definition were in a module and both SUB and its containing program unit referenced the module. NOTE 4.25 An example of data entities in different scoping units having the same type is: PROGRAM PGM TYPE EMPLOYEE SEQUENCE INTEGER ID_NUMBER CHARACTER (50) NAME END TYPE EMPLOYEE TYPE (EMPLOYEE) PROGRAMMER CALL SUB (PROGRAMMER) ... END PROGRAM PGM SUBROUTINE SUB (POSITION) TYPE EMPLOYEE 60 2006/01/05 WORKING DRAFT J3/07-007 NOTE 4.25 (cont.) SEQUENCE INTEGER ID_NUMBER CHARACTER (50) NAME END TYPE EMPLOYEE TYPE (EMPLOYEE) POSITION ... END SUBROUTINE SUB The actual argument PROGRAMMER and the dummy argument POSITION have the same type because they are declared with reference to a derived-type definition with the same name, the SEQUENCE property, and components that agree in order, name, and attributes. Suppose the component name ID NUMBER was ID NUM in the subroutine. Because all the component names are not identical to the component names in derived type EMPLOYEE in the main program, the actual argument PROGRAMMER would not be of the same type as the dummy argument POSITION. Thus, the program would not be standard-conforming. NOTE 4.26 The requirement that the two types have the same name applies to the type-names of the respective derived-type-stmts, not to local names introduced via renaming in USE statements. 4.5.3 Derived-type parameters 1 24.5.3.1 Type parameter definition statement 3R436 type-param-def-stmt is INTEGER [ kind-selector ] , type-param-attr-spec :: 4 type-param-decl-list R437 type-param-decl is type-param-name [ = scalar-int-initialization-expr ] 5 6C439 (R436) A type-param-name in a type-param-def-stmt in a derived-type-def shall be one of the 7 type-param-names in the derived-type-stmt of that derived-type-def . 8C440 (R436) Each type-param-name in the derived-type-stmt in a derived-type-def shall appear as a 9 type-param-name in a type-param-def-stmt in that derived-type-def . 10R438 type-param-attr-spec is KIND 11 or LEN 12The derived type is parameterized if the derived-type-stmt has any type-param-names. 13Each type parameter is itself of type integer. If its kind selector is omitted, the kind type parameter is 14default integer. 15The type-param-attr-spec explicitly specifies whether a type parameter is a kind parameter or a length 16parameter. 17If a type-param-decl has a scalar-int-initialization-expr, the type parameter has a default value which 18is specified by the expression. If necessary, the value is converted according to the rules of intrinsic assignment (7.2.1.3) to a value of the same kind as the type parameter. 19 20A type parameter may be used as a primary in a specification expression (7.1.11) in the derived-type- 21def . A kind type parameter may also be used as a primary in an initialization expression (7.1.12) in the 22derived-type-def . 61 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 4.27 The following example uses derived-type parameters. TYPE humongous_matrix(k, d) INTEGER, KIND :: k = kind(0.0) INTEGER(selected_int_kind(12)), LEN :: d !-- Specify a nondefault kind for d. REAL(k) :: element(d,d) END TYPE In the following example, dim is declared to be a kind parameter, allowing generic overloading of procedures distinguished only by dim. TYPE general_point(dim) INTEGER, KIND :: dim REAL :: coordinates(dim) END TYPE 14.5.3.2 Type parameter order 2Type parameter order is an ordering of the type parameters of a derived type; it is used for derived- 3type specifiers. 4The type parameter order of a nonextended type is the order of the type parameter list in the derived- 5type definition. The type parameter order of an extended type (4.5.7 consists of the type parameter 6order of its parent type followed by any additional type parameters in the order of the type parameter 7list in the derived-type definition. NOTE 4.28 Given TYPE :: t1(k1,k2) INTEGER,KIND :: k1,k2 REAL(k1) a(k2) END TYPE TYPE,EXTENDS(t1) :: t2(k3) INTEGER,KIND :: k3 LOGICAL(k3) flag END TYPE the type parameter order for type T1 is K1 then K2, and the type parameter order for type T2 is K1 then K2 then K3. 4.5.4 Components 8 94.5.4.1 Component definition statement R439 component-part is [ component-def-stmt ] ... 10 11R440 component-def-stmt is data-component-def-stmt 12 or proc-component-def-stmt 13R441 data-component-def-stmt is declaration-type-spec [ [ , component-attr-spec-list ] :: ] 14 component-decl-list 62 2006/01/05 WORKING DRAFT J3/07-007 1R442 component-attr-spec is access-spec 2 or ALLOCATABLE 3 or DIMENSION ( component-array-spec ) 4 or DIMENSION [ ( deferred-shape-spec-list ) ] 5 lbracket co-array-spec rbracket 6 or CONTIGUOUS 7 or POINTER 8R443 component-decl is component-name [ ( component-array-spec ) ] 9 [ lbracket co-array-spec rbracket ] [ * char-length ] [ component-initialization ] 10 11R444 component-array-spec is explicit-shape-spec-list 12 or deferred-shape-spec-list 13 C441 (R441) No component-attr-spec shall appear more than once in a given component-def-stmt. 14 15C442 (R441) If neither the POINTER nor ALLOCATABLE attribute is specified, the declaration-type- 16 spec in the component-def-stmt shall specify an intrinsic type or a previously defined derived 17 type. 18C443 (R441) If the POINTER or ALLOCATABLE attribute is specified, the declaration-type-spec in 19 the component-def-stmt shall be CLASS(*) or shall specify an intrinsic type or any accessible 20 derived type including the type being defined. 21C444 (R441) If the POINTER or ALLOCATABLE attribute is specified, each component-array-spec 22 shall be a deferred-shape-spec-list. 23C445 (R441) If a co-array-spec appears, it shall be a deferred-co-shape-spec-list and the component 24 shall have the ALLOCATABLE attribute. 25C446 (R441) If a co-array-spec appears, the component shall not be of type IMAGE TEAM (13.8.2.7), C PTR, or C FUNPTR (15.3.3). 26 27C447 A data component whose type has a co-array ultimate component shall be a nonpointer nonal- 28 locatable scalar and shall not be a co-array. 29C448 (R441) If neither the POINTER attribute nor the ALLOCATABLE attribute is specified, each 30 component-array-spec shall be an explicit-shape-spec-list. 31C449 (R444) Each bound in the explicit-shape-spec shall either be an initialization expression or be a 32 specification expression that does not contain references to specification functions or any object 33 designators other than named constants or subobjects thereof. J3 internal note Unresolved Technical Issue 094 This contraint is inconsistent (as is the one 3 below): it allows INTEGER c1(DIGITS(yvariable)) INTEGER c2(len_type_param) but not INTEGER c3(DIGITS(yvariable)+len_type_param) It's not quite trivial to word this correctly... 63 J3/07-007 WORKING DRAFT 2006/01/05 C450 (R441) A component shall not have both the ALLOCATABLE and the POINTER attribute. 1 2C451 (R441) If the CONTIGUOUS attribute is specified, the component shall be an array with the 3 POINTER attribute. C452 (R443) The * char-length option is permitted only if the component is of type character. 4 5C453 (R440) Each type-param-value within a component-def-stmt shall either be a colon, be an ini- 6 tialization expression, or be a specification expression that contains neither references to speci- 7 fication functions nor any object designators other than named constants or subobjects thereof. NOTE 4.29 Because a type parameter is not an object, a type-param-value or a bound in an explicit-shape-spec may contain a type-param-name. 8R445 proc-component-def-stmt is PROCEDURE ( [ proc-interface ] ) , 9 proc-component-attr-spec-list :: proc-decl-list NOTE 4.30 See 12.4.3.6 for definitions of proc-interface and proc-decl. 10R446 proc-component-attr-spec is POINTER 11 or PASS [ (arg-name) ] 12 or NOPASS 13 or access-spec 14C454 (R445) The same proc-component-attr-spec shall not appear more than once in a given proc- 15 component-def-stmt. C455 (R445) POINTER shall appear in each proc-component-attr-spec-list. 16 17C456 (R445) If the procedure pointer component has an implicit interface or has no arguments, 18 NOPASS shall be specified. 19C457 (R445) If PASS (arg-name) appears, the interface shall have a dummy argument named arg- 20 name. C458 (R445) PASS and NOPASS shall not both appear in the same proc-component-attr-spec-list. 21 224.5.4.2 Array components 23A data component is an array if its component-decl contains a component-array-spec or its data-compo- 24nent-def-stmt contains the DIMENSION clause with a component-array-spec. If the component-decl 25contains a component-array-spec, it specifies the array rank, and if the array is explicit shape (5.3.7.2), 26the array bounds; otherwise, the component-array-spec in the DIMENSION clause specifies the array 27rank, and if the array is explicit shape, the array bounds. 28A data component is a co-array if its component-decl contains a co-array-spec or its data-component-def- 29stmt contains a DIMENSION clause with a co-array-spec. If the component-decl contains a co-array-spec 30it specifies the co-rank; otherwise, the co-array-spec in the DIMENSION clause specifies the co-rank. NOTE 4.31 An example of a derived type definition with an array component is: 64 2006/01/05 WORKING DRAFT J3/07-007 NOTE 4.31 (cont.) TYPE LINE REAL, DIMENSION (2, 2) :: COORD ! ! COORD(:,1) has the value of [X1, Y1] ! COORD(:,2) has the value of [X2, Y2] REAL :: WIDTH ! Line width in centimeters INTEGER :: PATTERN ! 1 for solid, 2 for dash, 3 for dot END TYPE LINE An example of declaring a variable LINE SEGMENT to be of the type LINE is: TYPE (LINE) :: LINE_SEGMENT The scalar variable LINE SEGMENT has a component that is an array. In this case, the array is a subobject of a scalar. The double colon in the definition for COORD is required; the double colon in the definition for WIDTH and PATTERN is optional. NOTE 4.32 An example of a derived type definition with an allocatable component is: TYPE STACK INTEGER :: INDEX INTEGER, ALLOCATABLE :: CONTENTS (:) END TYPE STACK For each scalar variable of type STACK, the shape of the component CONTENTS is determined by execution of an ALLOCATE statement or assignment statement, or by argument association. NOTE 4.33 Default initialization of an explicit-shape array component may be specified by an initialization expression consisting of an array constructor (4.7), or of a single scalar that becomes the value of each array element. 14.5.4.3 Pointer components 2A component is a pointer (2.4.7) if its component-attr-spec-list contains the POINTER attribute. A 3pointer component may be a data pointer or a procedure pointer. NOTE 4.34 An example of a derived type definition with a pointer component is: TYPE REFERENCE INTEGER :: VOLUME, YEAR, PAGE CHARACTER (LEN = 50) :: TITLE PROCEDURE (printer_interface), POINTER :: PRINT => NULL() CHARACTER, DIMENSION (:), POINTER :: SYNOPSIS END TYPE REFERENCE Any object of type REFERENCE will have the four nonpointer components VOLUME, YEAR, PAGE, and TITLE, the procedure pointer PRINT, which has an explicit interface the same as printer interface, plus a pointer to an array of characters holding SYNOPSIS. The size of this 65 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 4.34 (cont.) target array will be determined by the length of the abstract. The space for the target may be allocated (6.3.1) or the pointer component may be associated with a target by a pointer assignment statement (7.2.2). 14.5.4.4 The passed-object dummy argument 2A passed-object dummy argument is a distinguished dummy argument of a procedure pointer 3component or type-bound procedure. It affects procedure overriding (4.5.7.3) and argument association (12.5.2.2). 4 5If NOPASS is specified, the procedure pointer component or type-bound procedure has no passed-object 6dummy argument. 7If neither PASS nor NOPASS is specified or PASS is specified without arg-name, the first dummy argu- 8ment of a procedure pointer component or type-bound procedure is its passed-object dummy argument. 9If PASS (arg-name) is specified, the dummy argument named arg-name is the passed-object dummy 10argument of the procedure pointer component or named type-bound procedure. 11C459 The passed-object dummy argument shall be a scalar, nonpointer, nonallocatable dummy data 12 object with the same declared type as the type being defined; all of its length type parameters 13 shall be assumed; it shall be polymorphic (4.3.1.3) if and only if the type being defined is extensible (4.5.7). It shall not have the VALUE attribute. 14 NOTE 4.35 If a procedure is bound to several types as a type-bound procedure, different dummy arguments might be the passed-object dummy argument in different contexts. 154.5.4.5 Default initialization for components 16Default initialization provides a means of automatically initializing pointer components to be disassoci- 17ated or associated with specific targets, and nonpointer nonallocatable components to have a particular 18value. Allocatable components are always initialized to not allocated. 19A pointer variable or component is data-pointer-initialization compatible with a target if the pointer 20is type compatible with the target, they have the same rank, and the values of corresponding nondeferred 21type parameters are specified by initialization expressions that have the same value. 22R447 component-initialization is = initialization-expr 23 or => null-init 24 or => initial-data-target 25R448 initial-data-target is designator 26C460 (R441) If component-initialization appears, a double-colon separator shall appear before the 27 component-decl-list. 28C461 (R441) If component-initialization appears, every type parameter and array bound of the com- 29 ponent shall be a colon or initialization expression. 30C462 (R441) If => appears in component-initialization, POINTER shall appear in the component- 31 attr-spec-list. If = appears in component-initialization, neither POINTER nor ALLOCATABLE 32 shall appear in the component-attr-spec-list. 66 2006/01/05 WORKING DRAFT J3/07-007 1C463 (R447) If initial-data-target appears, component-name shall be data-pointer-initialization com- 2 patible with it. 3C464 (R448) The designator shall designate a variable that is an initialization target. Every subscript, 4 section subscript, substring starting point, and substring ending point in designator shall be an 5 initialization expression. 6If null-init appears for a pointer component, that component in any object of the type has an initial association status of disassociated (16.5.2.2) or becomes disassociated as specified in 16.5.2.2.2. 7 8A variable is an initialization target if it has the TARGET attribute, either has the SAVE attribute 9or is declared in the main program, and does not have the ALLOCATABLE attribute. 10If initial-data-target appears for a data pointer component, that component in any object of the type is 11initially associated with the target or becomes associated with the target as specified in 16.5.2.2.1. 12If initial-proc-target (12.4.3.6) appears in proc-decl for a procedure pointer component, that component 13in any object of the type is initially associated with the target or becomes associated with the target as 14specified in 16.5.2.2.1. 15If initialization-expr appears for a nonpointer component, that component in any object of the type 16is initially defined (16.6.3) or becomes defined as specified in 16.6.5 with the value determined from 17initialization-expr. If necessary, the value is converted according to the rules of intrinsic assignment 18(7.2.1.3) to a value that agrees in type, type parameters, and shape with the component. If the compo- 19nent is of a type for which default initialization is specified for a component, the default initialization 20specified by initialization-expr overrides the default initialization specified for that component. When 21one initialization overrides another it is as if only the overriding initialization were specified (see Note 224.37). Explicit initialization in a type declaration statement (5.2) overrides default initialization (see 23Note 4.36). Unlike explicit initialization, default initialization does not imply that the object has the 24SAVE attribute. 25A subcomponent (6.1.2) is default-initialized if the type of the object of which it is a component 26specifies default initialization for that component, and the subcomponent is not a subobject of an object 27that is default-initialized or explicitly initialized. NOTE 4.36 It is not required that initialization be specified for each component of a derived type. For example: TYPE DATE INTEGER DAY CHARACTER (LEN = 5) MONTH INTEGER :: YEAR = 1994 ! Partial default initialization END TYPE DATE In the following example, the default initial value for the YEAR component of TODAY is overridden by explicit initialization in the type declaration statement: TYPE (DATE), PARAMETER :: TODAY = DATE (21, "Feb.", 1995) NOTE 4.37 The default initial value of a component of derived type may be overridden by default initialization specified in the definition of the type. Continuing the example of Note 4.36: TYPE SINGLE_SCORE 67 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 4.37 (cont.) TYPE(DATE) :: PLAY_DAY = TODAY INTEGER SCORE TYPE(SINGLE_SCORE), POINTER :: NEXT => NULL ( ) END TYPE SINGLE_SCORE TYPE(SINGLE_SCORE) SETUP The PLAY DAY component of SETUP receives its initial value from TODAY, overriding the initialization for the YEAR component. NOTE 4.38 Arrays of structures may be declared with elements that are partially or totally initialized by default. Continuing the example of Note 4.37 : TYPE MEMBER (NAME_LEN) INTEGER, LEN :: NAME_LEN CHARACTER (LEN = NAME_LEN) NAME = '' INTEGER :: TEAM_NO, HANDICAP = 0 TYPE (SINGLE_SCORE), POINTER :: HISTORY => NULL ( ) END TYPE MEMBER TYPE (MEMBER(9)) LEAGUE (36) ! Array of partially initialized elements TYPE (MEMBER(9)) :: ORGANIZER = MEMBER ("I. Manage",1,5,NULL ( )) ORGANIZER is explicitly initialized, overriding the default initialization for an object of type MEMBER. Allocated objects may also be initialized partially or totally. For example: ALLOCATE (ORGANIZER % HISTORY) ! A partially initialized object of type ! SINGLE_SCORE is created. NOTE 4.39 A pointer component of a derived type may have as its target an object of that derived type. The type definition may specify that in objects declared to be of this type, such a pointer is default initialized to disassociated. For example: TYPE NODE INTEGER :: VALUE = 0 TYPE (NODE), POINTER :: NEXT_NODE => NULL ( ) END TYPE A type such as this may be used to construct linked lists of objects of type NODE. See C.1.4 for an example. Linked lists can also be constructed using allocatable components. NOTE 4.40 A pointer component of a derived type may be default-initialized to have an initial target. TYPE NODE INTEGER :: VALUE = 0 TYPE (NODE), POINTER :: NEXT_NODE => SENTINEL END TYPE 68 2006/01/05 WORKING DRAFT J3/07-007 NOTE 4.40 (cont.) TYPE(NODE), SAVE, TARGET :: SENTINEL 14.5.4.6 Component order 2Component order is an ordering of the nonparent components of a derived type; it is used for intrinsic 3formatted input/output and structure constructors (where component keywords are not used). Parent components are excluded from the component order of an extended type (4.5.7). 4 5The component order of a nonextended type is the order of the declarations of the components in the 6derived-type definition. The component order of an extended type consists of the component order of 7its parent type followed by any additional components in the order of their declarations in the extended 8derived-type definition. NOTE 4.41 Given the same type definitions as in Note 4.28, the component order of type T1 is just A (there is only one component), and the component order of type T2 is A then FLAG. The parent component (T1) does not participate in the component order. 94.5.4.7 Component accessibility 10R449 private-components-stmt is PRIVATE 11C465 (R449) A private-components-stmt is permitted only if the type definition is within the specifi- 12 cation part of a module. 13The default accessibility for the components that are declared in a type's component-part is private 14if the type definition contains a private-components-stmt, and public otherwise. The accessibility of a 15component may be explicitly declared by an access-spec; otherwise its accessibility is the default for the 16type definition in which it is declared. 17If a component is private, that component name is accessible only within the module containing the 18definition, and within its descendants. NOTE 4.42 Type parameters are not components. They are effectively always public. NOTE 4.43 The accessibility of the components of a type is independent of the accessibility of the type name. It is possible to have all four combinations: a public type name with a public component, a private type name with a private component, a public type name with a private component, and a private type name with a public component. NOTE 4.44 An example of a type with private components is: TYPE POINT PRIVATE REAL :: X, Y END TYPE POINT 69 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 4.44 (cont.) Such a type definition is accessible in any scoping unit accessing the module via a USE state- ment; however, the components X and Y are accessible only within the module, and within its descendants. NOTE 4.45 The following example illustrates the use of an individual component access-spec to override the default accessibility: TYPE MIXED PRIVATE INTEGER :: I INTEGER, PUBLIC :: J END TYPE MIXED TYPE (MIXED) :: M The component M%J is accessible in any scoping unit where M is accessible; M%I is accessible only within the module containing the TYPE MIXED definition, and within its descendants. 4.5.5 Type-bound procedures 1 2R450 type-bound-procedure-part is contains-stmt 3 [ binding-private-stmt ] [ type-bound-proc-binding ] ... 4 5R451 binding-private-stmt is PRIVATE 6C466 (R450) A binding-private-stmt is permitted only if the type definition is within the specification 7 part of a module. 8R452 type-bound-proc-binding is type-bound-procedure-stmt 9 or type-bound-generic-stmt 10 or final-procedure-stmt 11R453 type-bound-procedure-stmt is PROCEDURE [ [ , binding-attr-list ] :: ] 12 binding-name [ => procedure-name ] 13 or PROCEDURE (interface-name) 14 , binding-attr-list :: binding-name C467 (R453) If => procedure-name appears, the double-colon separator shall appear. 15 16C468 (R453) The procedure-name shall be the name of an accessible module procedure or an external 17 procedure that has an explicit interface. 18If neither => procedure-name nor interface-name appears, it is as though => procedure-name had 19appeared with a procedure name the same as the binding name. 20R454 type-bound-generic-stmt is GENERIC [, access-spec ] :: generic-spec => binding-name-list 21 22C469 (R454) Within the specification-part of a module, each type-bound-generic-stmt shall specify, 23 either implicitly or explicitly, the same accessibility as every other type-bound-generic-stmt with 24 that generic-spec in the same derived type. 70 2006/01/05 WORKING DRAFT J3/07-007 1C470 (R454) Each binding-name in binding-name-list shall be the name of a specific binding of the 2 type. 3C471 (R454) If generic-spec is not generic-name, each of its specific bindings shall have a passed-object dummy argument (4.5.4.4). 4 5C472 (R454) If generic-spec is OPERATOR ( defined-operator ), the interface of each binding shall 6 be as specified in 12.4.3.4.2. 7C473 (R454) If generic-spec is ASSIGNMENT ( = ), the interface of each binding shall be as specified 8 in 12.4.3.4.3. 9C474 (R454) If generic-spec is dtio-generic-spec, the interface of each binding shall be as specified in 10 9.5.4.7. The type of the dtv argument shall be type-name. 11R455 binding-attr is PASS [ (arg-name) ] 12 or NOPASS 13 or NON OVERRIDABLE 14 or DEFERRED 15 or access-spec C475 (R455) The same binding-attr shall not appear more than once in a given binding-attr-list. 16 17C476 (R453) If the interface of the binding has no dummy argument of the type being defined, 18 NOPASS shall appear. 19C477 (R453) If PASS (arg-name) appears, the interface of the binding shall have a dummy argument 20 named arg-name. C478 (R455) PASS and NOPASS shall not both appear in the same binding-attr-list. 21 22C479 (R455) NON OVERRIDABLE and DEFERRED shall not both appear in the same binding- 23 attr-list. C480 (R455) DEFERRED shall appear if and only if interface-name appears. 24 25C481 (R453) An overriding binding (4.5.7.3) shall have the DEFERRED attribute only if the binding 26 it overrides is deferred. 27C482 (R453) A binding shall not override an inherited binding (4.5.7.2) that has the NON OVER- 28 RIDABLE attribute. 29A type-bound procedure statement declares a specific type-bound procedure. A specific type- 30bound procedure may have a passed-object dummy argument (4.5.4.4). A binding that specifies the 31DEFERRED attribute is a deferred binding. A deferred binding shall appear only in the definition 32of an abstract type. 33A GENERIC statement declares a type-bound generic interface for its specific type-bound procedures. 34A binding of a type is a specific type-bound procedure, a generic type-bound interface, or a final 35subroutine. These are referred to as specific bindings, generic bindings, and final bindings respectively. 36A type-bound procedure may be identified by a binding name in the scope of the type definition. 37This name is the binding-name for a specific binding, and the generic-name for a generic binding whose 38generic-spec is generic-name. A final binding, or a generic binding whose generic-spec is not generic- 39name, has no binding name. 40The interface of a specific binding is that of the procedure specified by procedure-name or the interface 71 J3/07-007 WORKING DRAFT 2006/01/05 1specified by interface-name. NOTE 4.46 An example of a type and a type-bound procedure is: TYPE POINT REAL :: X, Y CONTAINS PROCEDURE, PASS :: LENGTH => POINT_LENGTH END TYPE POINT ... and in the module-subprogram-part of the same module: REAL FUNCTION POINT_LENGTH (A, B) CLASS (POINT), INTENT (IN) :: A, B POINT_LENGTH = SQRT ( (A%X - B%X)**2 + (A%Y - B%Y)**2 ) END FUNCTION POINT_LENGTH 2The same generic-spec may be used in several GENERIC statements within a single derived-type defi- 3nition. Each additional GENERIC statement with the same generic-spec extends the generic interface. NOTE 4.47 Unlike the situation with generic procedure names, a generic type-bound procedure name is not permitted to be the same as a specific type-bound procedure name in the same type (16.3). 4The default accessibility for the procedure bindings of a type is private if the type definition contains a 5binding-private-stmt, and public otherwise. The accessibility of a procedure binding may be explicitly 6declared by an access-spec; otherwise its accessibility is the default for the type definition in which it is 7declared. 8A public type-bound procedure is accessible via any accessible object of the type. A private type-bound 9procedure is accessible only within the module containing the type definition, and within its descendants. NOTE 4.48 The accessibility of a type-bound procedure is not affected by a PRIVATE statement in the component-part; the accessibility of a data component is not affected by a PRIVATE statement in the type-bound-procedure-part. 104.5.6 Final subroutines 114.5.6.1 Declaration R456 final-procedure-stmt is FINAL [ :: ] final-subroutine-name-list 12 13C483 (R456) A final-subroutine-name shall be the name of a module procedure with exactly one 14 dummy argument. That argument shall be nonoptional and shall be a nonpointer, nonallocat- 15 able, nonpolymorphic variable of the derived type being defined. All length type parameters of the dummy argument shall be assumed. The dummy argument shall not have INTENT(OUT). 16 17C484 (R456) A final-subroutine-name shall not be one previously specified as a final subroutine for 18 that type. 72 2006/01/05 WORKING DRAFT J3/07-007 1C485 (R456) A final subroutine shall not have a dummy argument with the same kind type parameters 2 and rank as the dummy argument of another final subroutine of that type. 3The FINAL statement specifies that each procedure it names is a final subroutine. A final subroutine might be executed when a data entity of that type is finalized (4.5.6.2). 4 5A derived type is finalizable if it has any final subroutines or if it has any nonpointer, nonallocatable 6component whose type is finalizable. A nonpointer data entity is finalizable if its type is finalizable. NOTE 4.49 Final subroutines are effectively always "accessible". They are called for entity finalization re- gardless of the accessibility of the type, its other type-bound procedures, or the subroutine name itself. NOTE 4.50 Final subroutines are not inherited through type extension and cannot be overridden. The final subroutines of the parent type are called after any additional final subroutines of an extended type are called. 74.5.6.2 The finalization process 8Only finalizable entities are finalized. When an entity is finalized, the following steps are carried out 9in sequence. 10 (1) If the dynamic type of the entity has a final subroutine whose dummy argument has the 11 same kind type parameters and rank as the entity being finalized, it is called with the entity 12 as an actual argument. Otherwise, if there is an elemental final subroutine whose dummy 13 argument has the same kind type parameters as the entity being finalized, it is called with 14 the entity as an actual argument. Otherwise, no subroutine is called at this point. 15 (2) All finalizable components that appear in the type definition are finalized in a processor- 16 dependent order. If the entity being finalized is an array, each finalizable component of each 17 element of that entity is finalized separately. 18 (3) If the entity is of extended type and the parent type is finalizable, the parent component is 19 finalized. 20If several entities are to be finalized as a consequence of an event specified in 4.5.6.3, the order in which 21they are finalized is processor-dependent. A final subroutine shall not reference or define an object that 22has already been finalized. 23If an object is not finalized, it retains its definition status and does not become undefined. 244.5.6.3 When finalization occurs 25When a pointer is deallocated its target is finalized. When an allocatable entity is deallocated, it is 26finalized. 27A nonpointer, nonallocatable object that is not a dummy argument or function result is finalized im- 28mediately before it would become undefined due to execution of a RETURN or END statement (16.6.6, item (3)). 29 30A nonpointer nonallocatable local variable of a BLOCK construct is finalized immediately before it would become undefined due to termination of the BLOCK construct (16.6.6, item (20)). 31 32If an executable construct references a function, the result is finalized after execution of the innermost 33executable construct containing the reference. 73 J3/07-007 WORKING DRAFT 2006/01/05 1If an executable construct references a structure constructor or array constructor, the entity created by 2the constructor is finalized after execution of the innermost executable construct containing the reference. 3If a specification expression in a scoping unit references a function, the result is finalized before execution 4of the executable constructs in the scoping unit. 5If a specification expression in a scoping unit references a structure constructor or array constructor, the 6entity created by the constructor is finalized before execution of the executable constructs in the scoping 7unit. 8When a procedure is invoked, a nonpointer, nonallocatable object that is an actual argument associated with an INTENT(OUT) dummy argument is finalized. 9 10When an intrinsic assignment statement is executed, the variable is finalized after evaluation of expr 11and before the definition of the variable. NOTE 4.51 If finalization is used for storage management, it often needs to be combined with defined assign- ment. 12If an object is allocated via pointer allocation and later becomes unreachable due to all pointers to that 13object having their pointer association status changed, it is processor dependent whether it is finalized. 14If it is finalized, it is processor dependent as to when the final subroutines are called. 154.5.6.4 Entities that are not finalized 16If image execution is terminated, either by an error (e.g. an allocation failure) or by execution of a STOP 17or END PROGRAM statement, entities existing immediately prior to termination are not finalized. NOTE 4.52 A nonpointer, nonallocatable object that has the SAVE attribute or that is declared in the main program, a module, or a submodule is never finalized as a direct consequence of the execution of a RETURN or END statement. A variable in a module or submodule is not finalized if it retains its definition status and value, even when there is no active procedure referencing the module or submodule. 4.5.7 Type extension 18 194.5.7.1 Concepts 20A nonsequence derived type that does not have the BIND attribute is an extensible type. 21An extensible type that does not have the EXTENDS attribute is a base type. A type that has the 22EXTENDS attribute is an extended type. The parent type of an extended type is the type named 23in the EXTENDS attribute specification. NOTE 4.53 The name of the parent type might be a local name introduced via renaming in a USE statement. 24A base type is an extension type of itself only. An extended type is an extension of itself and of all 25types for which its parent type is an extension. 26An abstract type is a type that has the ABSTRACT attribute. 74 2006/01/05 WORKING DRAFT J3/07-007 NOTE 4.54 A deferred binding (4.5.5) defers the implementation of a type-bound procedure to extensions of the type; it may appear only in an abstract type. The dynamic type of an object cannot be abstract; therefore, a deferred binding cannot be invoked. An extension of an abstract type need not be abstract if it has no deferred bindings. A short example of an abstract type is: TYPE, ABSTRACT :: FILE_HANDLE CONTAINS PROCEDURE(OPEN_FILE), DEFERRED, PASS(HANDLE) :: OPEN ... END TYPE For a more elaborate example see C.1.3. 14.5.7.2 Inheritance 2An extended type includes all of the type parameters, all of the components, and the nonoverridden 3(4.5.7.3) nonfinal procedure bindings of its parent type. These are inherited by the extended type from 4the parent type. They retain all of the attributes that they had in the parent type. Additional type 5parameters, components, and procedure bindings may be declared in the derived-type definition of the 6extended type. NOTE 4.55 Inaccessible components and bindings of the parent type are also inherited, but they remain inac- cessible in the extended type. Inaccessible entities occur if the type being extended is accessed via use association and has a private entity. NOTE 4.56 A base type is not required to have any components, bindings, or parameters; an extended type is not required to have more components, bindings, or parameters than its parent type. 7An extended type has a scalar, nonpointer, nonallocatable, parent component with the type and 8type parameters of the parent type. The name of this component is the parent type name. It has the 9accessibility of the parent type. Components of the parent component are inheritance associated 10(16.5.4) with the corresponding components inherited from the parent type. An ancestor component 11of a type is the parent component of the type or an ancestor component of the parent component. NOTE 4.57 A component or type parameter declared in an extended type shall not have the same name as any accessible component or type parameter of its parent type. NOTE 4.58 Examples: TYPE POINT ! A base type REAL :: X, Y END TYPE POINT TYPE, EXTENDS(POINT) :: COLOR_POINT ! An extension of TYPE(POINT) ! Components X and Y, and component name POINT, inherited from parent INTEGER :: COLOR 75 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 4.58 (cont.) END TYPE COLOR_POINT 14.5.7.3 Type-bound procedure overriding 2If a nongeneric binding specified in a type definition has the same binding name as a binding from the 3parent type then the binding specified in the type definition overrides the one from the parent type. 4The overriding binding and the overridden binding shall satisfy the following conditions. (1) Either both shall have a passed-object dummy argument or neither shall. 5 (2) If the overridden binding is pure then the overriding binding shall also be pure. 6 (3) Either both shall be elemental or neither shall. 7 (4) They shall have the same number of dummy arguments. 8 (5) Passed-object dummy arguments, if any, shall correspond by name and position. 9 10 (6) Dummy arguments that correspond by position shall have the same names and characteris- 11 tics, except for the type of the passed-object dummy arguments. 12 (7) Either both shall be subroutines or both shall be functions having the same result charac- teristics (12.3.3). 13 (8) If the overridden binding is PUBLIC then the overriding binding shall not be PRIVATE. 14 NOTE 4.59 The following is an example of procedure overriding, expanding on the example in Note 4.46. TYPE, EXTENDS (POINT) :: POINT_3D REAL :: Z CONTAINS PROCEDURE, PASS :: LENGTH => POINT_3D_LENGTH END TYPE POINT_3D ... and in the module-subprogram-part of the same module: REAL FUNCTION POINT_3D_LENGTH ( A, B ) CLASS (POINT_3D), INTENT (IN) :: A CLASS (POINT), INTENT (IN) :: B SELECT TYPE(B) CLASS IS(POINT_3D) POINT_3D_LENGTH = SQRT( (A%X-B%X)**2 + (A%Y-B%Y)**2 + (A%Z-B%Z)**2 ) RETURN END SELECT PRINT *, 'In POINT_3D_LENGTH, dynamic type of argument is incorrect.' STOP END FUNCTION POINT_3D_LENGTH 15If a generic binding specified in a type definition has the same generic-spec as an inherited binding, it 16extends the generic interface and shall satisfy the requirements specified in 12.4.3.4.5. 17A binding of a type and a binding of an extension of that type correspond if the latter binding is the 18same binding as the former, overrides a corresponding binding, or is an inherited corresponding binding. 4.5.8 Derived-type values 19 76 2006/01/05 WORKING DRAFT J3/07-007 1The component value of (1) a pointer component is its pointer association, 2 3 (2) an allocatable component is its allocation status and, if it is allocated, its dynamic type and 4 type parameters, bounds and value, and (3) a nonpointer nonallocatable component is its value. 5 6The set of values of a particular derived type consists of all possible sequences of the component values 7of its components. 4.5.9 Derived-type specifier 8 9A derived-type specifier is used in several contexts to specify a particular derived type and type param- 10eters. R457 derived-type-spec is type-name [ ( type-param-spec-list ) ] 11 R458 type-param-spec is [ keyword = ] type-param-value 12 C486 (R457) type-name shall be the name of an accessible derived type. 13 C487 (R457) type-param-spec-list shall appear only if the type is parameterized. 14 15C488 (R457) There shall be at most one type-param-spec corresponding to each parameter of the type. 16 If a type parameter does not have a default value, there shall be a type-param-spec corresponding 17 to that type parameter. 18C489 (R458) The keyword= may be omitted from a type-param-spec only if the keyword= has been 19 omitted from each preceding type-param-spec in the type-param-spec-list. C490 (R458) Each keyword shall be the name of a parameter of the type. 20 21C491 (R458) An asterisk may be used as a type-param-value in a type-param-spec only in the decla- 22 ration of a dummy argument or associate name or in the allocation of a dummy argument. 23Type parameter values that do not have type parameter keywords specified correspond to type param- 24eters in type parameter order (4.5.3.2). If a type parameter keyword is present, the value is assigned to 25the type parameter named by the keyword. If necessary, the value is converted according to the rules of intrinsic assignment (7.2.1.3) to a value of the same kind as the type parameter. 26 27The value of a type parameter for which no type-param-value has been specified is its default value. 4.5.10 Construction of derived-type values 28 29A derived-type definition implicitly defines a corresponding structure constructor that allows con- 30struction of values of that derived type. The type and type parameters of a constructed value are 31specified by a derived type specifier. R459 structure-constructor is derived-type-spec ( [ component-spec-list ] ) 32 R460 component-spec is [ keyword = ] component-data-source 33 34R461 component-data-source is expr 35 or data-target 36 or proc-target C492 (R459) The derived-type-spec shall not specify an abstract type (4.5.7). 37 77 J3/07-007 WORKING DRAFT 2006/01/05 C493 (R459) At most one component-spec shall be provided for a component. 1 2C494 (R459) If a component-spec is provided for an ancestor component, a component-spec shall not 3 be provided for any component that is inheritance associated with a subcomponent of that 4 ancestor component. 5C495 (R459) A component-spec shall be provided for a nonallocatable component unless it has default 6 initialization or is inheritance associated with a subcomponent of another component for which 7 a component-spec is provided. 8C496 (R460) The keyword= may be omitted from a component-spec only if the keyword= has been 9 omitted from each preceding component-spec in the constructor. C497 (R460) Each keyword shall be the name of a component of the type. 10 11C498 (R459) The type name and all components of the type for which a component-spec appears shall 12 be accessible in the scoping unit containing the structure constructor. 13C499 (R459) If derived-type-spec is a type name that is the same as a generic name, the component- 14 spec-list shall not be a valid actual-arg-spec-list for a function reference that is resolvable as a generic reference to that name (12.5.5.2). 15 16C4100 (R461) A data-target shall correspond to a nonprocedure pointer component; a proc-target shall 17 correspond to a procedure pointer component. C4101 (R461) A data-target shall have the same rank as its corresponding component. 18 NOTE 4.60 The form 'name(...)' is interpreted as a generic function-reference if possible; it is interpreted as a structure-constructor only if it cannot be interpreted as a generic function-reference. 19In the absence of a component keyword, each component-data-source is assigned to the corresponding 20component in component order (4.5.4.6). If a component keyword appears, the expr is assigned to the 21component named by the keyword. For a nonpointer component, the declared type and type parameters 22of the component and expr shall conform in the same way as for a variable and expr in an intrinsic 23assignment statement (7.2.1.2), as specified in Table 7.12. If necessary, each value of intrinsic type is 24converted according to the rules of intrinsic assignment (7.2.1.3) to a value that agrees in type and type 25parameters with the corresponding component of the derived type. For a nonpointer nonallocatable 26component, the shape of the expression shall conform with the shape of the component. 27If a component with default initialization has no corresponding component-data-source, then the default 28initialization is applied to that component. If an allocatable component has no corresponding component- 29data-source, then that component has an allocation status of unallocated. NOTE 4.61 Because no parent components appear in the defined component ordering, a value for a parent component can be specified only with a component keyword. Examples of equivalent values using types defined in Note 4.58: ! Create values with components x = 1.0, y = 2.0, color = 3. TYPE(POINT) :: PV = POINT(1.0, 2.0) ! Assume components of TYPE(POINT) ! are accessible here. ... COLOR_POINT( point=point(1,2), color=3) ! Value for parent component COLOR_POINT( point=PV, color=3) ! Available even if TYPE(point) 78 2006/01/05 WORKING DRAFT J3/07-007 NOTE 4.61 (cont.) ! has private components COLOR_POINT( 1, 2, 3) ! All components of TYPE(point) ! need to be accessible. 1A structure constructor shall not appear before the referenced type is defined. NOTE 4.62 This example illustrates a derived-type constant expression using a derived type defined in Note 4.20: PERSON (21, 'JOHN SMITH') This could also be written as PERSON (NAME = 'JOHN SMITH', AGE = 21) NOTE 4.63 An example constructor using the derived type GENERAL POINT defined in Note 4.27 is general_point(dim=3) ( [ 1., 2., 3. ] ) 2For a pointer component, the corresponding component-data-source shall be an allowable data-target or 3proc-target for such a pointer in a pointer assignment statement (7.2.2). If the component data source is 4a pointer, the association of the component is that of the pointer; otherwise, the component is pointer 5associated with the component data source. NOTE 4.64 For example, if the variable TEXT were declared (5.2) to be CHARACTER, DIMENSION (1:400), TARGET :: TEXT and BIBLIO were declared using the derived-type definition REFERENCE in Note 4.34 TYPE (REFERENCE) :: BIBLIO the statement BIBLIO = REFERENCE (1, 1987, 1, "This is the title of the referenced & &paper", TEXT) is valid and associates the pointer component SYNOPSIS of the object BIBLIO with the target object TEXT. 6If a component of a derived type is allocatable, the corresponding constructor expression shall either be 7a reference to the intrinsic function NULL with no arguments, an allocatable entity of the same rank, 8or shall evaluate to an entity of the same rank. If the expression is a reference to the intrinsic function 9NULL, the corresponding component of the constructor has a status of unallocated. If the expression 10is an allocatable entity, the corresponding component of the constructor has the same allocation status 11as that allocatable entity and, if it is allocated, the same dynamic type, bounds, and value; if a length 12parameter of the component is deferred, its value is the same as the corresponding parameter of the 79 J3/07-007 WORKING DRAFT 2006/01/05 1expression. Otherwise the corresponding component of the constructor has an allocation status of 2allocated and has the same bounds and value as the expression. NOTE 4.65 When the constructor is an actual argument, the allocation status of the allocatable component is available through the associated dummy argument. 4.5.11 Derived-type operations and assignment 3 4Intrinsic assignment of derived-type entities is described in 7.2.1. This part of ISO/IEC 1539 does 5not specify any intrinsic operations on derived-type entities. Any operation on derived-type entities 6or defined assignment (7.2.1.4) for derived-type entities shall be defined explicitly by a function or a subroutine, and a generic interface (4.5.2, 12.4.3.2). 7 84.6 Enumerations and enumerators 9An enumeration is a set of enumerators. An enumerator is a named integer constant. An enumeration 10definition specifies the enumeration and its set of enumerators of the corresponding integer kind. 11R462 enum-def is enum-def-stmt 12 enumerator-def-stmt 13 [ enumerator-def-stmt ] ... 14 end-enum-stmt R463 enum-def-stmt is ENUM, BIND(C) 15 R464 enumerator-def-stmt is ENUMERATOR [ :: ] enumerator-list 16 R465 enumerator is named-constant [ = scalar-int-initialization-expr ] 17 18R466 end-enum-stmt is END ENUM 19C4102 (R464) If = appears in an enumerator, a double-colon separator shall appear before the enu- 20 merator-list. 21For an enumeration, the kind is selected such that an integer type with that kind is interoperable (15.3.2) 22with the corresponding C enumeration type. The corresponding C enumeration type is the type that 23would be declared by a C enumeration specifier (6.7.2.2 of the C International Standard) that specified 24C enumeration constants with the same values as those specified by the enum-def , in the same order as 25specified by the enum-def . 26The companion processor (2.5.10) shall be one that uses the same representation for the types declared 27by all C enumeration specifiers that specify the same values in the same order. NOTE 4.66 If a companion processor uses an unsigned type to represent a given enumeration type, the Fortran processor will use the signed integer type of the same width for the enumeration, even though some of the values of the enumerators cannot be represented in this signed integer type. The types of any such enumerators will be interoperable with the type declared in the C enumeration. NOTE 4.67 The C International Standard guarantees the enumeration constants fit in a C int (6.7.2.2 of the C International Standard). Therefore, the Fortran processor can evaluate all enumerator values using the integer type with kind parameter C INT, and then determine the kind parameter of the 80 2006/01/05 WORKING DRAFT J3/07-007 NOTE 4.67 (cont.) integer type that is interoperable with the corresponding C enumerated type. NOTE 4.68 The C International Standard specifies that two enumeration types are compatible only if they specify enumeration constants with the same names and same values in the same order. This part of ISO/IEC 1539 further requires that a C processor that is to be a companion processor of a Fortran processor use the same representation for two enumeration types if they both specify enumeration constants with the same values in the same order, even if the names are different. 1An enumerator is treated as if it were explicitly declared with the PARAMETER attribute. The enu- 2merator is defined in accordance with the rules of intrinsic assignment (7.2) with the value determined 3as follows. 4 (1) If scalar-int-initialization-expr is specified, the value of the enumerator is the result of 5 scalar-int-initialization-expr. 6 (2) If scalar-int-initialization-expr is not specified and the enumerator is the first enumerator 7 in enum-def , the enumerator has the value 0. 8 (3) If scalar-int-initialization-expr is not specified and the enumerator is not the first enumer- 9 ator in enum-def , its value is the result of adding 1 to the value of the enumerator that 10 immediately precedes it in the enum-def . NOTE 4.69 Example of an enumeration definition: ENUM, BIND(C) ENUMERATOR :: RED = 4, BLUE = 9 ENUMERATOR YELLOW END ENUM The kind type parameter for this enumeration is processor dependent, but the processor is required to select a kind sufficient to represent the values 4, 9, and 10, which are the values of its enumerators. The following declaration might be equivalent to the above enumeration definition. INTEGER(SELECTED_INT_KIND(2)), PARAMETER :: RED = 4, BLUE = 9, YELLOW = 10 An entity of the same kind type parameter value can be declared using the intrinsic function KIND with one of the enumerators as its argument, for example INTEGER(KIND(RED)) :: X NOTE 4.70 There is no difference in the effect of declaring the enumerators in multiple ENUMERATOR statements or in a single ENUMERATOR statement. The order in which the enumerators in an enumeration definition are declared is significant, but the number of ENUMERATOR statements is not. 4.7 Construction of array values 11 12An array constructor is defined as a sequence of scalar values and is interpreted as a rank-one array where the element values are those specified in the sequence. 81 J3/07-007 WORKING DRAFT 2006/01/05 1R467 array-constructor is (/ ac-spec /) 2 or lbracket ac-spec rbracket 3R468 ac-spec is type-spec :: or [type-spec ::] ac-value-list 4 R469 lbracket is [ 5 R470 rbracket is ] 6 7R471 ac-value is expr 8 or ac-implied-do R472 ac-implied-do is ( ac-value-list , ac-implied-do-control ) 9 10R473 ac-implied-do-control is ac-do-variable = scalar-int-expr , scalar-int-expr [ , scalar-int-expr ] 11 12R474 ac-do-variable is do-variable 13C4103 (R468) If type-spec is omitted, each ac-value expression in the array-constructor shall have the 14 same type and kind type parameters. 15C4104 (R468) If type-spec specifies an intrinsic type, each ac-value expression in the array-constructor 16 shall be of an intrinsic type that is in type conformance with a variable of type type-spec as 17 specified in Table 7.12. 18C4105 (R468) If type-spec specifies a derived type, all ac-value expressions in the array-constructor 19 shall be of that derived type and shall have the same kind type parameter values as specified by 20 type-spec. 21C4106 (R472) The ac-do-variable of an ac-implied-do that is in another ac-implied-do shall not appear 22 as the ac-do-variable of the containing ac-implied-do. 23If type-spec is omitted, each ac-value expression in the array constructor shall have the same length type 24parameters; in this case, the type and type parameters of the array constructor are those of the ac-value 25expressions. 26If type-spec appears, it specifies the type and type parameters of the array constructor. Each ac-value 27expression in the array-constructor shall be compatible with intrinsic assignment to a variable of this 28type and type parameters. Each value is converted to the type parameters of the array-constructor in accordance with the rules of intrinsic assignment (7.2.1.3). 29 30The character length of an ac-value in an ac-implied-do whose iteration count is zero shall not depend 31on the value of the ac-do-variable and shall not depend on the value of an expression that is not an 32initialization expression. 33If an ac-value is a scalar expression, its value specifies an element of the array constructor. If an ac- 34value is an array expression, the values of the elements of the expression, in array element order (6.2.2.1), 35specify the corresponding sequence of elements of the array constructor. If an ac-value is an ac-implied- 36do, it is expanded to form a sequence of elements under the control of the ac-do-variable, as in the DO construct (8.1.7.5). 37 38For an ac-implied-do, the loop initialization and execution is the same as for a DO construct. 39An empty sequence forms a zero-sized array. 82 2006/01/05 WORKING DRAFT J3/07-007 NOTE 4.71 A one-dimensional array may be reshaped into any allowable array shape using the RESHAPE intrinsic function (13.7.146). An example is: X = (/ 3.2, 4.01, 6.5 /) Y = RESHAPE (SOURCE = [ 2.0, [ 4.5, 4.5 ], X ], SHAPE = [ 3, 2 ]) This results in Y having the 3 × 2 array of values: 2.0 3.2 4.5 4.01 4.5 6.5 NOTE 4.72 Examples of array constructors containing an implied DO are: (/ (I, I = 1, 1075) /) and [ 3.6, (3.6 / I, I = 1, N) ] NOTE 4.73 Using the type definition for PERSON in Note 4.20, an example of the construction of a derived- type array value is: [ PERSON (40, 'SMITH'), PERSON (20, 'JONES') ] NOTE 4.74 Using the type definition for LINE in Note 4.31, an example of the construction of a derived-type scalar value with a rank-2 array component is: LINE (RESHAPE ( [ 0.0, 0.0, 1.0, 2.0 ], [ 2, 2 ] ), 0.1, 1) The RESHAPE intrinsic function is used to construct a value that represents a solid line from (0, 0) to (1, 2) of width 0.1 centimeters. NOTE 4.75 Examples of zero-size array constructors are: [ INTEGER :: ] [ ( I, I = 1, 0) ] NOTE 4.76 An example of an array constructor that specifies a length type parameter: [ CHARACTER(LEN=7) :: 'Takata', 'Tanaka', 'Hayashi' ] In this constructor, without the type specification, it would have been necessary to specify all of 83 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 4.76 (cont.) the constants with the same character length. 84 2006/01/05 WORKING DRAFT J3/07-007 5 Attribute declarations and specifications 1 25.1 General 3Every data object has a type and rank and may have type parameters and other properties that determine 4the uses of the object. Collectively, these properties are the attributes of the object. The type of a 5named data object is either specified explicitly in a type declaration statement or determined implicitly 6by the first letter of its name (5.5). All of its attributes may be specified in a type declaration statement 7or individually in separate specification statements. 8A function has a type and rank and may have type parameters and other attributes that determine the 9uses of the function. The type, rank, and type parameters are the same as those of its result variable. 10A subroutine does not have a type, rank, or type parameters, but may have other attributes that 11determine the uses of the subroutine. 5.2 Type declaration statements 12 5.2.1 Syntax 13 R501 type-declaration-stmt is declaration-type-spec [ [ , attr-spec ] ... :: ] entity-decl-list 14 15The type declaration statement specifies the type of the entities in the entity declaration list. The type 16and type parameters are those specified by declaration-type-spec, except that the character length type 17parameter may be overridden for an entity by the appearance of * char-length in its entity-decl. 18R502 attr-spec is access-spec 19 or ALLOCATABLE 20 or ASYNCHRONOUS 21 or CONTIGUOUS 22 or dimension-spec 23 or EXTERNAL 24 or INTENT ( intent-spec ) 25 or INTRINSIC 26 or language-binding-spec 27 or OPTIONAL 28 or PARAMETER 29 or POINTER 30 or PROTECTED 31 or SAVE 32 or TARGET 33 or VALUE 34 or VOLATILE 35 C501 (R501) The same attr-spec shall not appear more than once in a given type-declaration-stmt. 36 37C502 (R501) If a language-binding-spec with a NAME= specifier appears, the entity-decl-list shall 38 consist of a single entity-decl. 39C503 (R501) If a language-binding-spec is specified, the entity-decl-list shall not contain any procedure 85 J3/07-007 WORKING DRAFT 2006/01/05 1 names. 2The type declaration statement also specifies the attributes whose keywords appear in the attr-spec, 3except that the DIMENSION attribute may be specified or overridden for an entity by the appearance 4of array-spec in its entity-decl. 5R503 entity-decl is object-name [( array-spec )] 6 [ lbracket co-array-spec rbracket ] 7 [ * char-length ] [ initialization ] or function-name [ * char-length ] 8 C504 (R503) If the entity is not of type character, * char-length shall not appear. 9 C505 (R501) If initialization appears, a double-colon separator shall appear before the entity-decl-list. 10 11C506 (R503) An initialization shall not appear if object-name is a dummy argument, a function result, 12 an object in a named common block unless the type declaration is in a block data program unit, 13 an object in blank common, an allocatable variable, an external function, an intrinsic function, 14 or an automatic object. C507 (R503) An initialization shall appear if the entity is a named constant (5.3.12). 15 16C508 (R503) The function-name shall be the name of an external function, an intrinsic function, a 17 function dummy procedure, a procedure pointer, or a statement function. 18R504 object-name is name C509 (R504) The object-name shall be the name of a data object. 19 20R505 initialization is = initialization-expr 21 or => null-init 22 or => initial-data-target 23R506 null-init is function-reference 24C510 (R503) If => appears in initialization, the entity shall have the POINTER attribute. If = 25 appears in initialization, the entity shall not have the POINTER attribute. 26C511 (R503) If initial-data-target appears, object-name shall be data-pointer-initialization compatible with it (4.5.4.5). 27 28C512 (R506) The function-reference shall be a reference to the NULL intrinsic function with no 29 arguments. 30A name that identifies a specific intrinsic function in a scoping unit has a type as specified in 13.6. An 31explicit type declaration statement is not required; however, it is permitted. Specifying a type for a 32generic intrinsic function name in a type declaration statement is not sufficient, by itself, to remove the 33generic properties from that function. 5.2.2 Automatic data objects 34 35An automatic data object is a nondummy data object with a type parameter or array bound that 36depends on the value of a specification-expr that is not an initialization expression. 37C513 An automatic object shall not be a local variable of a main program, module, or submodule. 86 2006/01/05 WORKING DRAFT J3/07-007 NOTE 5.1 An automatic object shall not have the SAVE attribute and shall not appear in a common block. 1If a type parameter in a declaration-type-spec or in a char-length in an entity-decl is defined by an 2expression that is not an initialization expression, the type parameter value is established on entry to 3the procedure or BLOCK construct and is not affected by any redefinition or undefinition of the variables 4in the expression during execution of the procedure or BLOCK construct. 55.2.3 Initialization 6The appearance of initialization in an entity-decl for an entity without the PARAMETER attribute 7specifies that the entity is a variable with explicit initialization. Explicit initialization alternatively 8may be specified in a DATA statement unless the variable is of a derived type for which default initial- 9ization is specified. If initialization is =initialization-expr, the variable is initially defined with the value 10specified by the initialization-expr; if necessary, the value is converted according to the rules of intrinsic 11assignment (7.2.1.3) to a value that agrees in type, type parameters, and shape with the variable. A 12variable, or part of a variable, shall not be explicitly initialized more than once in a program. If the 13variable is an array, it shall have its shape specified in either the type declaration statement or a previous 14attribute specification statement in the same scoping unit. 15If null-init appears, the initial association status of the object is disassociated. If initial-data-target 16appears, the object is initially associated with the target. 17Explicit initialization of a variable that is not in a common block implies the SAVE attribute, which 18may be confirmed by explicit specification. 5.2.4 Examples of type declaration statements 19 NOTE 5.2 REAL A (10) LOGICAL, DIMENSION (5, 5) :: MASK1, MASK2 COMPLEX :: CUBE_ROOT = (-0.5, 0.866) INTEGER, PARAMETER :: SHORT = SELECTED_INT_KIND (4) INTEGER (SHORT) K ! Range at least -9999 to 9999. REAL (KIND (0.0D0)) A REAL (KIND = 2) B COMPLEX (KIND = KIND (0.0D0)) :: C CHARACTER (LEN = 10, KIND = 2) A CHARACTER B, C *20 TYPE (PERSON) :: CHAIRMAN TYPE(NODE), POINTER :: HEAD => NULL ( ) TYPE (humongous_matrix (k=8, d=1000)) :: mat (The last line above uses a type definition from Note 4.27.) 205.3 Attributes 215.3.1 Constraints 22An attribute may be explicitly specified by an attr-spec in a type declaration statement or by an attribute specification statement (5.4). The following constraints apply to attributes. 87 J3/07-007 WORKING DRAFT 2006/01/05 1 2C514 An entity shall not be explicitly given any attribute more than once in a scoping unit. 3C515 An array-spec for a function result that does not have the ALLOCATABLE or POINTER 4 attribute shall be an explicit-shape-spec-list. 5C516 The ALLOCATABLE, POINTER, or OPTIONAL attribute shall not be specified for a dummy 6 argument of a procedure that has a proc-language-binding-spec. 5.3.2 Accessibility attribute 7 8The accessibility attribute specifies the accessibility of an entity via a particular identifier. 9R507 access-spec is PUBLIC 10 or PRIVATE C517 (R507) An access-spec shall appear only in the specification-part of a module. 11 12Identifiers that are specified in a module or accessible in that module by use association have either the 13PUBLIC or PRIVATE attribute. Identifiers for which an access-spec is not explicitly specified in 14that module have the default accessibility attribute for that module. The default accessibility attribute 15for a module is PUBLIC unless it has been changed by a PRIVATE statement (5.4.1). Only identifiers 16that have the PUBLIC attribute in that module are available to be accessed from that module by use 17association. NOTE 5.3 In order for an identifier to be accessed by use association, it must have the PUBLIC attribute in the module from which it is accessed. It can nonetheless have the PRIVATE attribute in a module in which it is accessed by use association, and therefore not be available for use association from that module. NOTE 5.4 An example of an accessibility specification is: REAL, PRIVATE :: X, Y, Z 185.3.3 ALLOCATABLE attribute 19An entity with the ALLOCATABLE attribute is a variable for which space is allocated by an AL- LOCATE statement (6.3.1) or by an intrinsic assignment statement (7.2.1.3). 20 215.3.4 ASYNCHRONOUS attribute 22An entity with the ASYNCHRONOUS attribute is a variable that may be subject to asynchronous input/output. 23 24The base object of a variable shall have the ASYNCHRONOUS attribute in a scoping unit if 25 (1) the variable appears in an executable statement or specification expression in that scoping 26 unit and 27 (2) any statement of the scoping unit is executed while the variable is a pending I/O storage sequence affector (9.5.2.5). 28 29Use of a variable in an asynchronous input/output statement can imply the ASYNCHRONOUS attribute; 88 2006/01/05 WORKING DRAFT J3/07-007 see subclause (9.5.2.5). 1 2An object may have the ASYNCHRONOUS attribute in a particular scoping unit without necessarily 3having it in other scoping units (11.2.2, 16.5.1.4). If an object has the ASYNCHRONOUS attribute, 4then all of its subobjects also have the ASYNCHRONOUS attribute. NOTE 5.5 The ASYNCHRONOUS attribute specifies the variables that might be associated with a pending input/output storage sequence (the actual memory locations on which asynchronous input/output is being performed) while the scoping unit is in execution. This information could be used by the compiler to disable certain code motion optimizations. The ASYNCHRONOUS attribute is similar to the VOLATILE attribute. It is intended to facilitate traditional code motion optimizations in the presence of asynchronous input/output. 55.3.5 BIND attribute for data entities 6The BIND attribute for a variable or common block specifies that it is capable of interoperating with a C variable that has external linkage (15.4). 7 R508 language-binding-spec is BIND (C [, NAME = scalar-char-initialization-expr ]) 8 9C518 An entity with the BIND attribute shall be a common block, variable, or procedure. 10C519 A variable with the BIND attribute shall be declared in the specification part of a module. C520 A variable with the BIND attribute shall be interoperable (15.3). 11 12C521 Each variable of a common block with the BIND attribute shall be interoperable. 13C522 (R508) The scalar-char-initialization-expr shall be of default character kind. If the value of the 14 scalar-char-initialization-expr after discarding leading and trailing blanks has nonzero length, 15 it shall be valid as an identifier on the companion processor. NOTE 5.6 The C International Standard provides a facility for creating C identifiers whose characters are not restricted to the C basic character set. Such a C identifier is referred to as a universal character name (6.4.3 of the C International Standard). The name of such a C identifier might include characters that are not part of the representation method used by the processor for type default character. If so, the C entity cannot be referenced from Fortran. 16The BIND attribute for a variable or common block implies the SAVE attribute, which may be confirmed 17by explicit specification. 185.3.6 CONTIGUOUS attribute 19C523 An entity with the CONTIGUOUS attribute shall be an array pointer or an assumed-shape 20 array. 21The CONTIGUOUS attribute specifies that an assumed-shape array can only be argument associated 22with a contiguous effective argument, or that an array pointer can only be pointer associated with a 23contiguous target. 24An object is contiguous if it is (1) an object with the CONTIGUOUS attribute, 25 89 J3/07-007 WORKING DRAFT 2006/01/05 (2) a nonpointer whole array that is not assumed-shape, 1 (3) an assumed-shape array that is argument associated with an array that is contiguous, 2 (4) an array allocated by an ALLOCATE statement, 3 (5) a pointer associated with a contiguous target, or 4 (6) a nonzero-sized array section (6.2.2) provided that 5 (a) its base object is contiguous, 6 (b) it does not have a vector subscript, 7 8 (c) the elements of the section, in array element order, are a subset of the base object 9 elements that are consecutive in array element order, 10 (d) if the array is of type character and a substring-range appears, the substring-range specifies all of the characters of the parent-string (6.1.1), 11 (e) only its final part-ref has nonzero rank, and 12 (f) it is not the real or imaginary part (6.1.3) of an array of type complex. 13 14An object is not contiguous if it is an array subobject, and (1) the object has two or more elements, 15 16 (2) the elements of the object in array element order are not consecutive in the elements of the 17 base object, (3) the object is not of type character with length zero, and 18 19 (4) the object is not of a derived type that has no ultimate components other than zero-sized 20 arrays and characters with length zero. 21It is processor-dependent whether any other object is contiguous. NOTE 5.7 If a derived type has only one component that is not zero-sized, it is processor-dependent whether a structure component of a contiguous array of that type is contiguous. That is, the derived type might contain padding on some processors. NOTE 5.8 The CONTIGUOUS attribute makes it easier for a processor to enable optimizations that de- pend on the memory layout of the object occupying a contiguous block of memory. Examples of CONTIGUOUS attribute specifications are: REAL, POINTER, CONTIGUOUS :: SPTR(:) REAL, CONTIGUOUS, DIMENSION(:,:) :: D 225.3.7 DIMENSION attribute 235.3.7.1 General 24The DIMENSION attribute specifies that an entity is an array, a co-array, or both. If an array-spec 25appears, it is an array. If a co-array-spec appears, it is a co-array. 26For an array, its array-spec specifies its rank or rank and shape. For a co-array, its co-array-spec specifies 27its co-rank or co-rank and co-bounds. NOTE 5.9 Unless it is a dummy argument, a co-array has the same bounds and co-bounds on every image. 90 2006/01/05 WORKING DRAFT J3/07-007 NOTE 5.9 (cont.) See Note 12.32 for further discussion of the bounds and co-bounds of dummy co-arrays. 1R509 dimension-spec is DIMENSION ( array-spec ) or DIMENSION [ ( array-spec ) ] lbracket co-array-spec rbracket 2 3C524 (R501) A co-array with the ALLOCATABLE attribute shall be specified with a co-array-spec 4 that is a deferred-co-shape-spec-list. 5C525 A co-array shall be a component or a variable that is not a function result. C526 A co-array shall not be of type IMAGE TEAM (13.8.2.7), C PTR, or C FUNPTR (15.3.3). 6 7C527 An entity whose type has a co-array ultimate component shall be a nonpointer nonallocatable 8 scalar, shall not be a co-array, and shall not be a function result. NOTE 5.10 A co-array is permitted to be of a derived type with pointer or allocatable components. The target of such a pointer component is always on the same image. 9C528 The SAVE attribute shall be specified for a co-array unless it is a dummy argument, declared 10 in the main program, or allocatable. NOTE 5.11 This requirement for the SAVE attribute has the effect that automatic co-arrays are not permitted; for example, the co-array WORK in the following code fragment is not valid. SUBROUTINE SOLVE3(N,A,B) INTEGER :: N REAL :: A(N)[*], B(N) REAL :: WORK(N)[*] ! Not permitted If this were permitted, it would require an implicit synchronization on entry to the procedure. Explicit-shape co-arrays that are declared in a subprogram and are not dummy arguments are required to have the SAVE attribute because otherwise they might be implemented as if they were automatic co-arrays. 11R510 array-spec is explicit-shape-spec-list 12 or assumed-shape-spec-list 13 or deferred-shape-spec-list 14 or assumed-size-spec 15 or implied-shape-spec-list 16R511 co-array-spec is deferred-co-shape-spec-list 17 or explicit-co-shape-spec 18C529 The sum of the rank and co-rank of an entity shall not exceed fifteen. NOTE 5.12 Examples of DIMENSION attribute specifications are: SUBROUTINE EX (N, A, B) 91 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 5.12 (cont.) REAL, DIMENSION (N, 10) :: W ! Automatic explicit-shape array REAL A (:), B (0:) ! Assumed-shape arrays REAL, POINTER :: D (:, :) ! Array pointer REAL, DIMENSION (:), POINTER :: P ! Array pointer REAL, ALLOCATABLE, DIMENSION (:) :: E ! Allocatable array REAL, PARAMETER :: V(0:*) = [0.1, 1.1] ! Implied-shape array 15.3.7.2 Explicit-shape array 2An explicit-shape array is a named array that is declared with an explicit-shape-spec-list. This specifies 3explicit values for the bounds in each dimension of the array. R512 explicit-shape-spec is [ lower-bound : ] upper-bound 4 5R513 lower-bound is specification-expr 6R514 upper-bound is specification-expr 7C530 (R512) An explicit-shape-spec whose bounds are not initialization expressions shall appear only 8 in a subprogram or interface body. 9An explicit-shape array that is a local variable of a subprogram or BLOCK construct may have bounds 10that are not initialization expressions. The bounds, and hence shape, are determined at entry to a 11procedure defined by the subprogram, or on execution of the BLOCK statement, by evaluating the 12bounds expressions. The bounds of such an array are unaffected by the redefinition or undefinition of 13any variable during execution of the procedure or BLOCK construct. 14The values of each lower-bound and upper-bound determine the bounds of the array along a particular 15dimension and hence the extent of the array in that dimension. The value of a lower bound or an upper 16bound may be positive, negative, or zero. The subscript range of the array in that dimension is the set 17of integer values between and including the lower and upper bounds, provided the upper bound is not 18less than the lower bound. If the upper bound is less than the lower bound, the range is empty, the 19extent in that dimension is zero, and the array is of zero size. If the lower-bound is omitted, the default 20value is 1. The rank is equal to the number of explicit-shape-specs. 215.3.7.3 Assumed-shape array 22An assumed-shape array is a nonallocatable nonpointer dummy argument array that takes its shape 23from the associated actual argument array. R515 assumed-shape-spec is [ lower-bound ] : 24 25The rank is equal to the number of colons in the assumed-shape-spec-list. 26The extent of a dimension of an assumed-shape array dummy argument is the extent of the corresponding 27dimension of the associated actual argument array. If the lower bound value is d and the extent of the 28corresponding dimension of the associated actual argument array is s, then the value of the upper bound 29is s + d - 1. If lower-bound appears it specifies the lower bound; otherwise the lower bound is 1. 305.3.7.4 Deferred-shape array 31A deferred-shape array is an allocatable array or an array pointer. 32An allocatable array is an array that has the ALLOCATABLE attribute and a specified rank, but its bounds, and hence shape, are determined by allocation or argument association. 92 2006/01/05 WORKING DRAFT J3/07-007 1 2An array pointer is an array with the POINTER attribute and a specified rank. Its bounds, and hence 3shape, are determined when it is associated with a target. 4R516 deferred-shape-spec is : 5C531 An array with the POINTER or ALLOCATABLE attribute shall have an array-spec that is a 6 deferred-shape-spec-list. 7The rank is equal to the number of colons in the deferred-shape-spec-list. 8The size, bounds, and shape of an unallocated allocatable array or a disassociated array pointer are 9undefined. No part of such an array shall be referenced or defined; however, the array may appear as an 10argument to an intrinsic inquiry function as specified in 13.1. 11The bounds of each dimension of an allocated allocatable array are those specified when the array 12is allocated or, if it is a dummy argument, when it is argument associated with an allocated actual 13argument. 14The bounds of each dimension of an associated array pointer, and hence its shape, may be specified (1) in an ALLOCATE statement (6.3.1) when the target is allocated, 15 (2) by pointer assignment (7.2.2), or 16 17 (3) if it is a dummy argument, by argument association with a nonpointer actual argument or 18 an associated pointer actual argument. 19The bounds of an array pointer or allocatable array are unaffected by any subsequent redefinition or 20undefinition of variables on which the bounds' expressions depend. 215.3.7.5 Assumed-size array 22An assumed-size array is a dummy argument array whose size is assumed from that of an associated 23actual argument. The rank and extents may differ for the actual and dummy arrays; only the size of the 24actual array is assumed by the dummy array. An assumed-size array is declared with an assumed-size- 25spec. R517 assumed-size-spec is [ explicit-shape-spec , ]... [ lower-bound : ] * 26 27C532 An assumed-size-spec shall not appear except as the declaration of the array bounds of a dummy 28 data argument. 29C533 An assumed-size array with INTENT (OUT) shall not be polymorphic, of a finalizable type, of 30 a type with an ultimate allocatable component, or of a type for which default initialization is 31 specified. 32The size of an assumed-size array is determined as follows. 33 (1) If the actual argument associated with the assumed-size dummy array is an array of any 34 type other than default character, the size is that of the actual array. 35 (2) If the actual argument associated with the assumed-size dummy array is an array element 36 of any type other than default character with a subscript order value of r (6.2.2.1) in an 37 array of size x, the size of the dummy array is x - r + 1. 38 (3) If the actual argument is a default character array, default character array element, or a 39 default character array element substring (6.1.1), and if it begins at character storage unit t 40 of an array with c character storage units, the size of the dummy array is MAX (INT ((c - t + 1)/e), 0), where e is the length of an element in the dummy character array. 41 93 J3/07-007 WORKING DRAFT 2006/01/05 1 (4) If the actual argument is of type default character and is a scalar that is not an array element 2 or array element substring designator, the size of the dummy array is MAX (INT (l/e), 0), 3 where e is the length of an element in the dummy character array and l is the length of the 4 actual argument. 5The rank is equal to one plus the number of explicit-shape-specs. 6An assumed-size array has no upper bound in its last dimension and therefore has no extent in its last 7dimension and no shape. An assumed-size array name shall not be written as a whole array reference 8except as an actual argument in a procedure reference for which the shape is not required. 9If a list of explicit-shape-specs appears, it specifies the bounds of the first rank-1 dimensions. If lower- 10bound appears it specifies the lower bound of the last dimension; otherwise that lower bound is 1. An 11assumed-size array may be subscripted or sectioned (6.2.2.2). The upper bound shall not be omitted 12from a subscript triplet in the last dimension. 13If an assumed-size array has bounds that are not initialization expressions, the bounds are determined 14at entry to the procedure. The bounds of such an array are unaffected by the redefinition or undefinition 15of any variable during execution of the procedure. 165.3.7.6 Implied-shape array 17An implied-shape array is a named constant that takes its shape from the initialization-expr in its 18declaration. An implied-shape array is declared with an implied-shape-spec-list. R518 implied-shape-spec is [ lower-bound : ] * 19 20C534 An implied-shape array shall be a named constant. 21The rank of an implied-shape array is the number of implied-shape-specs in the implied-shape-spec-list. 22The extent of each dimension of an implied-shape array is the same as the extent of the corresponding 23dimension of the initialization-expr. The lower bound of each dimension is lower-bound, if it appears, 24and 1 otherwise; the upper bound is one less than the sum of the lower bound and the extent. 255.3.7.7 Allocatable co-array 26A co-array with the ALLOCATABLE attribute has a specified co-rank, but its co-bounds are determined 27by allocation or argument association. 28R519 deferred-co-shape-spec is : 29C535 A co-array with the ALLOCATABLE attribute shall have a co-array-spec that is a deferred-co- 30 shape-spec-list. 31The co-rank of an allocatable co-array is equal to the number of colons in its deferred-co-shape-spec-list. 32The co-bounds of an unallocated allocatable co-array are undefined. No part of such a co-array shall be 33referenced or defined; however, the co-array may appear as an argument to an intrinsic inquiry function 34as specified in 13.1. 35The co-bounds of an allocated allocatable co-array are those specified when the co-array is allocated. 36The co-bounds of an allocatable co-array are unaffected by any subsequent redefinition or undefinition 37of the variables on which the bounds' expressions depend. 385.3.7.8 Explicit-co-shape co-array 94 2006/01/05 WORKING DRAFT J3/07-007 1An explicit-co-shape co-array is a named co-array that has its co-rank and co-bounds declared by 2an explicit-co-shape-spec. 3R520 explicit-co-shape-spec is [ [ lower-co-bound : ] upper-co-bound, ]... [ lower-co-bound : ] * 4 5C536 A co-array that does not have the ALLOCATABLE attribute shall have a co-array-spec that is 6 an explicit-co-shape-spec. 7The co-rank is equal to one plus the number of upper-co-bounds. 8R521 lower-co-bound is specification-expr 9R522 upper-co-bound is specification-expr 10C537 (R520) A lower-co-bound or upper-co-bound that is not an initialization expression shall appear 11 only in a subprogram or interface body. 12If an explicit-co-shape co-array has co-bounds that are not initialization expressions, the co-bounds are 13determined at entry to the procedure by evaluating the co-bounds expressions. The co-bounds of such 14a co-array are unaffected by the redefinition or undefinition of any variable during execution of the 15procedure. 16The values of each lower-co-bound and upper-co-bound determine the co-bounds of the array along a 17particular co-dimension. The subscript range of the array in that co-dimension is the set of integer values 18between and including the lower and upper co-bounds. If the lower co-bound is omitted, the default 19value is 1. The upper co-bound shall not be less than the lower co-bound. 205.3.8 EXTERNAL attribute 21The EXTERNAL attribute specifies that an entity is an external procedure, dummy procedure, 22procedure pointer, or block data subprogram. 23C538 An entity shall not have both the EXTERNAL attribute and the INTRINSIC attribute. 24C539 In an external subprogram, the EXTERNAL attribute shall not be specified for a procedure 25 defined by the subprogram. 26If an external procedure or dummy procedure is used as an actual argument or is the target of a procedure 27pointer assignment, it shall be declared to have the EXTERNAL attribute. 28A procedure that has both the EXTERNAL and POINTER attributes is a procedure pointer. 295.3.9 INTENT attribute 30The INTENT attribute specifies the intended use of a dummy argument. An INTENT (IN) dummy 31argument is suitable for receiving data from the invoking scoping unit, an INTENT (OUT) dummy 32argument is suitable for returning data to the invoking scoping unit, and an INTENT (INOUT) dummy 33argument is suitable for use both to receive data from and to return data to the invoking scoping unit. 34R523 intent-spec is IN 35 or OUT 36 or INOUT 37C540 An entity with the INTENT attribute shall be a dummy data object or a dummy procedure 38 pointer. 39C541 (R523) A nonpointer object with the INTENT (IN) attribute shall not appear in a variable 95 J3/07-007 WORKING DRAFT 2006/01/05 definition context (16.6.7). 1 2C542 A pointer with the INTENT (IN) attribute shall not appear in a pointer association context (16.6.8). 3 4The INTENT (IN) attribute for a nonpointer dummy argument specifies that it shall neither be de- 5fined nor become undefined during the execution of the procedure. The INTENT (IN) attribute for a 6pointer dummy argument specifies that during the execution of the procedure its association shall not 7be changed except that it may become undefined if the target is deallocated other than through the pointer (16.5.2.2.3). 8 9The INTENT (OUT) attribute for a nonpointer dummy argument specifies that the dummy argument 10becomes undefined on invocation of the procedure, except for any subcomponents that are default- 11initialized (4.5.4.5). Any actual argument that becomes associated with such a dummy argument shall 12be definable. The INTENT (OUT) attribute for a pointer dummy argument specifies that on invocation 13of the procedure the pointer association status of the dummy argument becomes undefined. Any actual 14argument associated with such a pointer dummy shall be a pointer variable. 15The INTENT (INOUT) attribute for a nonpointer dummy argument specifies that any actual argument 16associated with the dummy argument shall be definable. The INTENT (INOUT) attribute for a pointer 17dummy argument specifies that any actual argument associated with the dummy argument shall be a 18pointer variable. NOTE 5.13 The INTENT attribute for an allocatable dummy argument applies to both the allocation status and the definition status. An actual argument associated with an INTENT(OUT) allocatable dummy argument is deallocated on procedure invocation (6.3.3.1). 19If no INTENT attribute is specified for a dummy argument, its use is subject to the limitations of the argument associated entity (12.5.2). 20 NOTE 5.14 An example of INTENT specification is: SUBROUTINE MOVE (FROM, TO) USE PERSON_MODULE TYPE (PERSON), INTENT (IN) :: FROM TYPE (PERSON), INTENT (OUT) :: TO 21If an object has an INTENT attribute, then all of its subobjects have the same INTENT attribute. NOTE 5.15 If a dummy argument is a derived-type object with a pointer component, then the pointer as a pointer is a subobject of the dummy argument, but the target of the pointer is not. Therefore, the restrictions on subobjects of the dummy object apply to the pointer in contexts where it is used as a pointer, but not in contexts where it is dereferenced to indicate its target. For example, if X is a dummy argument of derived type with an integer pointer component P, and X has INTENT(IN), then the statement X%P => NEW_TARGET is prohibited, but 96 2006/01/05 WORKING DRAFT J3/07-007 NOTE 5.15 (cont.) X%P = 0 is allowed (provided that X%P is associated with a definable target). Similarly, the INTENT restrictions on pointer dummy arguments apply only to the association of the dummy argument; they do not restrict the operations allowed on its target. NOTE 5.16 Argument intent specifications serve several purposes in addition to documenting the intended use of dummy arguments. A processor can check whether an INTENT (IN) dummy argument is used in a way that could redefine it. A slightly more sophisticated processor could check to see whether an INTENT (OUT) dummy argument could possibly be referenced before it is defined. If the procedure's interface is explicit, the processor can also verify that actual arguments corresponding to INTENT (OUT) or INTENT (INOUT) dummy arguments are definable. A more sophisticated processor could use this information to optimize the translation of the referencing scoping unit by taking advantage of the fact that actual arguments corresponding to INTENT (IN) dummy arguments will not be changed and that any prior value of an actual argument corresponding to an INTENT (OUT) dummy argument will not be referenced and could thus be discarded. INTENT (OUT) means that the value of the argument after invoking the procedure is entirely the result of executing that procedure. If an argument should retain its current value rather than being redefined, INTENT (INOUT) should be used rather than INTENT (OUT), even if there is no explicit reference to the value of the dummy argument. INTENT (INOUT) is not equivalent to omitting the INTENT attribute. The actual argument corresponding to an INTENT (INOUT) dummy argument is always required to be definable, while an argument corresponding to a dummy argument without an INTENT attribute need be definable only if the dummy argument is actually redefined. 15.3.10 INTRINSIC attribute 2The INTRINSIC attribute specifies that the entity is an intrinsic procedure. It may be a generic procedure (13.5), a specific procedure (13.6), or both. 3 4If the specific name of an intrinsic procedure (13.6) is used as an actual argument, the name shall be 5explicitly specified to have the INTRINSIC attribute. An intrinsic procedure whose specific name is marked with a bullet (·) in 13.6 shall not be used as an actual argument. 6 7C543 If the name of a generic intrinsic procedure is explicitly declared to have the INTRINSIC at- 8 tribute, and it is also the generic name of one or more generic interfaces (12.4.3.2) accessible in 9 the same scoping unit, the procedures in the interfaces and the specific intrinsic procedures shall 10 all be functions or all be subroutines, and the characteristics of the specific intrinsic procedures 11 and the procedures in the interfaces shall differ as specified in 12.4.3.4.5. 125.3.11 OPTIONAL attribute 13The OPTIONAL attribute specifies that the dummy argument need not be associated with an actual argument in a reference to the procedure (12.5.2.13). 14 15C544 An entity with the OPTIONAL attribute shall be a dummy argument. 97 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 5.17 The PRESENT intrinsic function (13.7.138) can be used to determine whether an optional dummy argument is associated with an actual argument. 15.3.12 PARAMETER attribute 2The PARAMETER attribute specifies that an entity is a named constant. The entity has the value 3specified by its initialization-expr, converted, if necessary, to the type, type parameters and shape of the 4entity. 5C545 An entity with the PARAMETER attribute shall not be a variable, a co-array, or a procedure. 6A named constant shall not be referenced unless it has been defined previously in the same statement, 7defined in a prior statement, or made accessible by use or host association. NOTE 5.18 Examples of declarations with a PARAMETER attribute are: REAL, PARAMETER :: ONE = 1.0, Y = 4.1 / 3.0 INTEGER, DIMENSION (3), PARAMETER :: ORDER = (/ 1, 2, 3 /) TYPE(NODE), PARAMETER :: DEFAULT = NODE(0, NULL ( )) 85.3.13 POINTER attribute 9Entities with the POINTER attribute can be associated with different data objects or procedures 10during execution of a program. A pointer is either a data pointer or a procedure pointer. Procedure 11pointers are described in 12.4.3.6. 12C546 An entity with the POINTER attribute shall not have the ALLOCATABLE, INTRINSIC, or 13 TARGET attribute, and shall not be a co-array. 14C547 A procedure with the POINTER attribute shall have the EXTERNAL attribute. 15A data pointer shall not be referenced unless it is pointer associated with a target object that is defined. 16A data pointer shall not be defined unless it is pointer associated with a target object that is definable. 17If a data pointer is associated, the values of its deferred type parameters are the same as the values of 18the corresponding type parameters of its target. 19A procedure pointer shall not be referenced unless it is pointer associated with a target procedure. NOTE 5.19 Examples of POINTER attribute specifications are: TYPE (NODE), POINTER :: CURRENT, TAIL REAL, DIMENSION (:, :), POINTER :: IN, OUT, SWAP For a more elaborate example see C.2.1. 205.3.14 PROTECTED attribute 21The PROTECTED attribute imposes limitations on the usage of module entities. 22C548 The PROTECTED attribute shall be specified only in the specification part of a module. 98 2006/01/05 WORKING DRAFT J3/07-007 1C549 An entity with the PROTECTED attribute shall be a procedure pointer or variable. 2C550 An entity with the PROTECTED attribute shall not be in a common block. 3C551 A nonpointer object that has the PROTECTED attribute and is accessed by use association 4 shall not appear in a variable definition context (16.6.7) or as the data-target or proc-target in 5 a pointer-assignment-stmt. 6C552 A pointer that has the PROTECTED attribute and is accessed by use association shall not appear in a pointer association context (16.6.8). 7 8Other than within the module in which an entity is given the PROTECTED attribute, or within any of 9its descendants, (1) if it is a nonpointer object, it is not definable, and 10 11 (2) if it is a pointer, its association status shall not be changed except that it may become 12 undefined if its target is deallocated other than through the pointer (16.5.2.2.3) or if its 13 target becomes undefined by execution of a RETURN or END statement. 14If an object has the PROTECTED attribute, all of its subobjects have the PROTECTED attribute. NOTE 5.20 An example of the PROTECTED attribute: MODULE temperature REAL, PROTECTED :: temp_c, temp_f CONTAINS SUBROUTINE set_temperature_c(c) REAL, INTENT(IN) :: c temp_c = c temp_f = temp_c*(9.0/5.0) + 32 END SUBROUTINE END MODULE The PROTECTED attribute ensures that the variables temp_c and temp_f cannot be modified other than via the set_temperature_c procedure, thus keeping them consistent with each other. 155.3.15 SAVE attribute 16The SAVE attribute specifies that a local variable of a program unit or subprogram retains its association 17status, allocation status, definition status, and value after execution of a RETURN or END statement 18unless it is a pointer and its target becomes undefined (16.5.2.2.3(4)). If it is a local variable of a subprogram it is shared by all instances (12.6.2.4) of the subprogram. 19 20The SAVE attribute specifies that a local variable of a BLOCK construct retains its association status, 21allocation status, definition status, and value after termination of the construct unless it is a pointer 22and its target becomes undefined (16.5.2.2.3(5)). If the BLOCK construct is within a subprogram the variable is shared by all instances (12.6.2.4) of the subprogram. 23 24Giving a common block the SAVE attribute confers the attribute on all variables in the common block. 25C553 An entity with the SAVE attribute shall be a common block, variable, or procedure pointer. 26C554 The SAVE attribute shall not be specified for a dummy argument, a function result, an automatic 27 data object, or an object that is in a common block. 99 J3/07-007 WORKING DRAFT 2006/01/05 1A saved entity is an entity that has the SAVE attribute. An unsaved entity is an entity that does not 2have the SAVE attribute. 3The SAVE attribute has no effect on entities declared in a main program, module, or submodule. If 4a common block has the SAVE attribute in any other kind of scoping unit, it shall have the SAVE 5attribute in every scoping unit that is not a main program, module, or submodule. 65.3.16 TARGET attribute 7The TARGET attribute specifies that a data object may have a pointer associated with it (7.2.2). 8An object without the TARGET attribute shall not have an accessible pointer associated with it. 9C555 An entity with the TARGET attribute shall be a variable. 10C556 An entity with the TARGET attribute shall not have the POINTER attribute. NOTE 5.21 In addition to variables explicitly declared to have the TARGET attribute, the objects created by allocation of pointers (6.3.1.2) have the TARGET attribute. 11If an object has the TARGET attribute, then all of its nonpointer subobjects also have the TARGET 12attribute. NOTE 5.22 Examples of TARGET attribute specifications are: TYPE (NODE), TARGET :: HEAD REAL, DIMENSION (1000, 1000), TARGET :: A, B For a more elaborate example see C.2.2. NOTE 5.23 Every object designator that starts from a target object will have either the TARGET or POINTER attribute. If pointers are involved, the designator might not necessarily be a subobject of the original target object, but because pointers may point only to targets, there is no way to end up at a nonpointer that is not a target. 135.3.17 VALUE attribute The VALUE attribute specifies a type of argument association (12.5.2.5) for a dummy argument. 14 15C557 An entity with the VALUE attribute shall be a scalar dummy data object. 16C558 An entity with the VALUE attribute shall not have the ALLOCATABLE, INTENT(INOUT), INTENT(OUT), POINTER, or VOLATILE attributes. 17 18C559 If an entity has the VALUE attribute, any length type parameter value in its declaration shall 19 be omitted or specified by an initialization expression. 205.3.18 VOLATILE attribute 21The VOLATILE attribute specifies that an object may be referenced, defined, or become undefined, 22by means not specified by the program, or by another image without synchronization. 100 2006/01/05 WORKING DRAFT J3/07-007 1C560 An entity with the VOLATILE attribute shall be a variable that is not an INTENT(IN) dummy 2 argument. 3An object may have the VOLATILE attribute in a particular scoping unit without necessarily having 4it in other scoping units (11.2.2, 16.5.1.4). If an object has the VOLATILE attribute, then all of its 5subobjects also have the VOLATILE attribute. NOTE 5.24 The Fortran processor should use the most recent definition of a volatile object when a value is required. Likewise, it should make the most recent Fortran definition available. It is the programmer's responsibility to manage any interaction with non-Fortran processes. 6A pointer with the VOLATILE attribute may additionally have its association status, dynamic type and 7type parameters, and array bounds changed by means not specified by the program. NOTE 5.25 If the target of a pointer is referenced, defined, or becomes undefined, by means not specified by the program, while the pointer is associated with the target, then the pointer shall have the VOLATILE attribute. Usually a pointer should have the VOLATILE attribute if its target has the VOLATILE attribute. Similarly, all members of an EQUIVALENCE group should have the VOLATILE attribute if one member has the VOLATILE attribute. 8An allocatable object with the VOLATILE attribute may additionally have its allocation status, dynamic 9type and type parameters, and array bounds changed by means not specified by the program. 5.4 Attribute specification statements 10 5.4.1 Accessibility statement 11 R524 access-stmt is access-spec [ [ :: ] access-id-list ] 12 13R525 access-id is use-name 14 or generic-spec 15C561 (R524) An access-stmt shall appear only in the specification-part of a module. Only one ac- 16 cessibility statement with an omitted access-id-list is permitted in the specification-part of a 17 module. 18C562 (R525) Each use-name shall be the name of a named variable, procedure, derived type, named 19 constant, namelist group, or macro. 20An access-stmt with an access-id-list specifies the accessibility attribute (5.3.2), PUBLIC or PRIVATE, 21of each access-id in the list. An access-stmt without an access-id list specifies the default accessibility 22that applies to all potentially accessible identifiers in the specification-part of the module. The statement 23PUBLIC 24specifies a default of public accessibility. The statement 25PRIVATE 26specifies a default of private accessibility. If no such statement appears in a module, the default is public 27accessibility. 101 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 5.26 Examples of accessibility statements are: MODULE EX PRIVATE PUBLIC :: A, B, C, ASSIGNMENT (=), OPERATOR (+) 15.4.2 ALLOCATABLE statement R526 allocatable-stmt is ALLOCATABLE [ :: ] allocatable-decl-list 2 3R527 allocatable-decl is object-name [ ( array-spec ) ] [ lbracket co-array-spec rbracket ] 4 The ALLOCATABLE statement specifies the ALLOCATABLE attribute (5.3.3) for a list of objects. 5 NOTE 5.27 An example of an ALLOCATABLE statement is: REAL A, B (:), SCALAR ALLOCATABLE :: A (:, :), B, SCALAR 65.4.3 ASYNCHRONOUS statement R528 asynchronous-stmt is ASYNCHRONOUS [ :: ] object-name-list 7 8The ASYNCHRONOUS statement specifies the ASYNCHRONOUS attribute (5.3.4) for a list of 9objects. 105.4.4 BIND statement R529 bind-stmt is language-binding-spec [ :: ] bind-entity-list 11 12R530 bind-entity is entity-name or / common-block-name / 13 14C563 (R529) If the language-binding-spec has a NAME= specifier, the bind-entity-list shall consist of 15 a single bind-entity. The BIND statement specifies the BIND attribute (5.3.5) for a list of variables and common blocks. 16 175.4.5 CONTIGUOUS statement R531 contiguous-stmt is CONTIGUOUS [ :: ] object-name-list 18 The CONTIGUOUS statement specifies the CONTIGUOUS attribute (5.3.6) for a list of objects. 19 205.4.6 DATA statement R532 data-stmt is DATA data-stmt-set [ [ , ] data-stmt-set ] ... 21 The DATA statement specifies explicit initialization (5.2.3). 22 23A variable, or part of a variable, shall not be explicitly initialized more than once in a program. If a 24nonpointer object has been specified with default initialization in a type definition, it shall not appear 102 2006/01/05 WORKING DRAFT J3/07-007 1in a data-stmt-object-list. 2A variable that appears in a DATA statement and has not been typed previously may appear in a 3subsequent type declaration only if that declaration confirms the implicit typing. An array name, 4array section, or array element that appears in a DATA statement shall have had its array properties 5established by a previous specification statement. 6Except for variables in named common blocks, a named variable has the SAVE attribute if any part of 7it is initialized in a DATA statement, and this may be confirmed by explicit specification. R533 data-stmt-set is data-stmt-object-list / data-stmt-value-list / 8 9R534 data-stmt-object is variable 10 or data-implied-do 11R535 data-implied-do is ( data-i-do-object-list , data-i-do-variable = 12 scalar-int-initialization-expr , 13 scalar-int-initialization-expr [ , scalar-int-initialization-expr ] ) 14 15R536 data-i-do-object is array-element 16 or scalar-structure-component 17 or data-implied-do 18R537 data-i-do-variable is do-variable 19C564 A data-stmt-object or data-i-do-object shall not be a co-indexed variable. 20C565 (R534) In a variable that is a data-stmt-object, any subscript, section subscript, substring start- 21 ing point, and substring ending point shall be an initialization expression. 22C566 (R534) A variable whose designator appears as a data-stmt-object or a data-i-do-object shall 23 not be a dummy argument, made accessible by use association or host association, in a named 24 common block unless the DATA statement is in a block data program unit, in a blank common 25 block, a function name, a function result name, an automatic object, or an allocatable variable. 26C567 (R534) A data-i-do-object or a variable that appears as a data-stmt-object shall not be an object 27 designator in which a pointer appears other than as the entire rightmost part-ref . C568 (R536) The array-element shall be a variable. 28 C569 (R536) The scalar-structure-component shall be a variable. 29 30C570 (R536) The scalar-structure-component shall contain at least one part-ref that contains a sub- 31 script-list. 32C571 (R536) In an array-element or scalar-structure-component that is a data-i-do-object, any sub- 33 script shall be an initialization expression, and any primary within that subscript that is a 34 data-i-do-variable shall be a DO variable of this data-implied-do or of a containing data-implied- 35 do. R538 data-stmt-value is [ data-stmt-repeat * ] data-stmt-constant 36 37R539 data-stmt-repeat is scalar-int-constant 38 or scalar-int-constant-subobject 39C572 (R539) The data-stmt-repeat shall be positive or zero. If the data-stmt-repeat is a named con- 40 stant, it shall have been declared previously in the scoping unit or made accessible by use 103 J3/07-007 WORKING DRAFT 2006/01/05 1 association or host association. 2R540 data-stmt-constant is scalar-constant 3 or scalar-constant-subobject 4 or signed-int-literal-constant 5 or signed-real-literal-constant 6 or null-init 7 or initial-data-target 8 or structure-constructor 9C573 (R540) If a DATA statement constant value is a named constant or a structure constructor, the 10 named constant or derived type shall have been declared previously in the scoping unit or made 11 accessible by use or host association. C574 (R540) If a data-stmt-constant is a structure-constructor, it shall be an initialization expression. 12 13R541 int-constant-subobject is constant-subobject C575 (R541) int-constant-subobject shall be of type integer. 14 15R542 constant-subobject is designator C576 (R542) constant-subobject shall be a subobject of a constant. 16 17C577 (R542) Any subscript, substring starting point, or substring ending point shall be an initializa- 18 tion expression. 19The data-stmt-object-list is expanded to form a sequence of pointers and scalar variables, referred to 20as "sequence of variables" in subsequent text. A nonpointer array whose unqualified name appears 21as a data-stmt-object or data-i-do-object is equivalent to a complete sequence of its array elements in 22array element order (6.2.2.1). An array section is equivalent to the sequence of its array elements in 23array element order. A data-implied-do is expanded to form a sequence of array elements and structure components, under the control of the data-i-do-variable, as in the DO construct (8.1.7.5). 24 25The data-stmt-value-list is expanded to form a sequence of data-stmt-constants. A data-stmt-repeat 26indicates the number of times the following data-stmt-constant is to be included in the sequence; omission 27of a data-stmt-repeat has the effect of a repeat factor of 1. 28A zero-sized array or a data-implied-do with an iteration count of zero contributes no variables to the 29expanded sequence of variables, but a zero-length scalar character variable does contribute a variable 30to the expanded sequence. A data-stmt-constant with a repeat factor of zero contributes no data-stmt- 31constants to the expanded sequence of scalar data-stmt-constants. 32The expanded sequences of variables and data-stmt-constants are in one-to-one correspondence. Each 33data-stmt-constant specifies the initial value, initial data target, or null-init for the corresponding vari- 34able. The lengths of the two expanded sequences shall be the same. 35A data-stmt-constant shall be null-init or initial-data-target if and only if the corresponding data-stmt- 36object has the POINTER attribute. If data-stmt-constant is null-init, the initial association status of 37the corresponding data statement object is disassociated. If data-stmt-constant is initial-data-target the 38corresponding data statement object shall be data-pointer-initialization compatible with the initial data 39target; the data statement object is initially associated with the target. 40A data-stmt-constant other than null-init or initial-data-target shall be compatible with its corresponding 41variable according to the rules of intrinsic assignment (7.2.1.2). The variable is initially defined with 42the value specified by the data-stmt-constant; if necessary, the value is converted according to the rules 43of intrinsic assignment (7.2.1.3) to a value that agrees in type, type parameters, and shape with the 104 2006/01/05 WORKING DRAFT J3/07-007 1variable. NOTE 5.28 Examples of DATA statements are: CHARACTER (LEN = 10) NAME INTEGER, DIMENSION (0:9) :: MILES REAL, DIMENSION (100, 100) :: SKEW TYPE (NODE), POINTER :: HEAD_OF_LIST TYPE (PERSON) MYNAME, YOURNAME DATA NAME / 'JOHN DOE' /, MILES / 10 * 0 / DATA ((SKEW (K, J), J = 1, K), K = 1, 100) / 5050 * 0.0 / DATA ((SKEW (K, J), J = K + 1, 100), K = 1, 99) / 4950 * 1.0 / DATA HEAD_OF_LIST / NULL() / DATA MYNAME / PERSON (21, 'JOHN SMITH') / DATA YOURNAME % AGE, YOURNAME % NAME / 35, 'FRED BROWN' / The character variable NAME is initialized with the value JOHN DOE with padding on the right because the length of the constant is less than the length of the variable. All ten elements of the integer array MILES are initialized to zero. The two-dimensional array SKEW is initialized so that the lower triangle of SKEW is zero and the strict upper triangle is one. The structures MYNAME and YOURNAME are declared using the derived type PERSON from Note 4.20. The pointer HEAD OF LIST is declared using the derived type NODE from Note 4.39; it is initially disassociated. MYNAME is initialized by a structure constructor. YOURNAME is initialized by supplying a separate value for each component. 25.4.7 DIMENSION statement R543 dimension-stmt is DIMENSION [ :: ] dimension-decl-list 3 4R544 dimension-decl is array-name ( array-spec ) or co-name [ ( array-spec ) ] lbracket co-array-spec rbracket 5 The DIMENSION statement specifies the DIMENSION attribute (5.3.7) for a list of objects. 6 NOTE 5.29 An example of a DIMENSION statement is: DIMENSION A (10), B (10, 70), C (:) 75.4.8 INTENT statement R545 intent-stmt is INTENT ( intent-spec ) [ :: ] dummy-arg-name-list 8 The INTENT statement specifies the INTENT attribute (5.3.9) for the dummy arguments in the list. 9 NOTE 5.30 An example of an INTENT statement is: SUBROUTINE EX (A, B) INTENT (INOUT) :: A, B 105.4.9 OPTIONAL statement 105 J3/07-007 WORKING DRAFT 2006/01/05 R546 optional-stmt is OPTIONAL [ :: ] dummy-arg-name-list 1 2The OPTIONAL statement specifies the OPTIONAL attribute (5.3.11) for the dummy arguments 3in the list. NOTE 5.31 An example of an OPTIONAL statement is: SUBROUTINE EX (A, B) OPTIONAL :: B 45.4.10 PARAMETER statement 5The PARAMETER statement specifies the PARAMETER attribute (5.3.12) and the values for the 6 named constants in the list. R547 parameter-stmt is PARAMETER ( named-constant-def -list ) 7 8R548 named-constant-def is named-constant = initialization-expr 9If a named constant is defined by a PARAMETER statement, it shall not be subsequently declared to 10have a type or type parameter value that differs from the type and type parameters it would have if 11declared implicitly (5.5). A named array constant defined by a PARAMETER statement shall have its 12shape specified in a prior specification statement. 13The value of each named constant is that specified by the corresponding initialization expression; if 14necessary, the value is converted according to the rules of intrinsic assignment (7.2.1.3) to a value that 15agrees in type, type parameters, and shape with the named constant. NOTE 5.32 An example of a PARAMETER statement is: PARAMETER (MODULUS = MOD (28, 3), NUMBER_OF_SENATORS = 100) 165.4.11 POINTER statement R549 pointer-stmt is POINTER [ :: ] pointer-decl-list 17 18R550 pointer-decl is object-name [ ( deferred-shape-spec-list ) ] 19 or proc-entity-name The POINTER statement specifies the POINTER attribute (5.3.13) for a list of entities. 20 NOTE 5.33 An example of a POINTER statement is: TYPE (NODE) :: CURRENT POINTER :: CURRENT, A (:, :) 215.4.12 PROTECTED statement R551 protected-stmt is PROTECTED [ :: ] entity-name-list 22 The PROTECTED statement specifies the PROTECTED attribute (5.3.14) for a list of entities. 23 106 2006/01/05 WORKING DRAFT J3/07-007 15.4.13 SAVE statement R552 save-stmt is SAVE [ [ :: ] saved-entity-list ] 2 3R553 saved-entity is object-name 4 or proc-pointer-name or / common-block-name / 5 6R554 proc-pointer-name is name 7C578 (R552) If a SAVE statement with an omitted saved entity list appears in a scoping unit, no 8 other appearance of the SAVE attr-spec or SAVE statement is permitted in that scoping unit. 9A SAVE statement with a saved entity list specifies the SAVE attribute (5.3.15) for a list of entities. 10A SAVE statement without a saved entity list is treated as though it contained the names of all allowed 11items in the same scoping unit. NOTE 5.34 An example of a SAVE statement is: SAVE A, B, C, / BLOCKA /, D 125.4.14 TARGET statement 13R555 target-stmt is TARGET [ :: ] target-decl-list R556 target-decl is object-name [ ( array-spec ) ] 14 [ lbracket co-array-spec rbracket ] 15 The TARGET statement specifies the TARGET attribute (5.3.16) for a list of objects. 16 NOTE 5.35 An example of a TARGET statement is: TARGET :: A (1000, 1000), B 175.4.15 VALUE statement R557 value-stmt is VALUE [ :: ] dummy-arg-name-list 18 The VALUE statement specifies the VALUE attribute (5.3.17) for a list of dummy arguments. 19 205.4.16 VOLATILE statement R558 volatile-stmt is VOLATILE [ :: ] object-name-list 21 The VOLATILE statement specifies the VOLATILE attribute (5.3.18) for a list of objects. 22 235.5 IMPLICIT statement 24In a scoping unit, an IMPLICIT statement specifies a type, and possibly type parameters, for all 25implicitly typed data entities whose names begin with one of the letters specified in the statement. 26Alternatively, it may indicate that no implicit typing rules are to apply in a particular scoping unit. 107 J3/07-007 WORKING DRAFT 2006/01/05 1R559 implicit-stmt is IMPLICIT implicit-spec-list 2 or IMPLICIT NONE R560 implicit-spec is declaration-type-spec ( letter-spec-list ) 3 R561 letter-spec is letter [ ­ letter ] 4 5C579 (R559) If IMPLICIT NONE is specified in a scoping unit, it shall precede any PARAMETER 6 statements that appear in the scoping unit and there shall be no other IMPLICIT statements 7 in the scoping unit. 8C580 (R561) If the minus and second letter appear, the second letter shall follow the first letter 9 alphabetically. 10A letter-spec consisting of two letters separated by a minus is equivalent to writing a list containing all 11of the letters in alphabetical order in the alphabetic sequence from the first letter through the second 12letter. For example, A­C is equivalent to A, B, C. The same letter shall not appear as a single letter, or 13be included in a range of letters, more than once in all of the IMPLICIT statements in a scoping unit. 14In each scoping unit, there is a mapping, which may be null, between each of the letters A, B, ..., Z 15and a type (and type parameters). An IMPLICIT statement specifies the mapping for the letters in 16its letter-spec-list. IMPLICIT NONE specifies the null mapping for all the letters. If a mapping is not 17specified for a letter, the default for a program unit or an interface body is default integer if the letter 18is I, J, ..., or N and default real otherwise, and the default for an internal or module procedure is the 19mapping in the host scoping unit. 20Any data entity that is not explicitly declared by a type declaration statement, is not an intrinsic 21function, and is not made accessible by use association or host association is declared implicitly to be of 22the type (and type parameters) mapped from the first letter of its name, provided the mapping is not 23null. The mapping for the first letter of the data entity shall either have been established by a prior 24IMPLICIT statement or be the default mapping for the letter. The mapping may be to a derived type 25that is inaccessible in the local scope if the derived type is accessible in the host scoping unit. The data 26entity is treated as if it were declared in an explicit type declaration in the outermost scoping unit in 27which it appears. An explicit type specification in a FUNCTION statement overrides an IMPLICIT 28statement for the name of the result variable of that function subprogram. NOTE 5.36 The following are examples of the use of IMPLICIT statements: MODULE EXAMPLE_MODULE IMPLICIT NONE ... INTERFACE FUNCTION FUN (I) ! Not all data entities need to INTEGER FUN ! be declared explicitly END FUNCTION FUN END INTERFACE CONTAINS FUNCTION JFUN (J) ! All data entities need to INTEGER JFUN, J ! be declared explicitly. ... END FUNCTION JFUN END MODULE EXAMPLE_MODULE SUBROUTINE SUB IMPLICIT COMPLEX (C) 108 2006/01/05 WORKING DRAFT J3/07-007 NOTE 5.36 (cont.) C = (3.0, 2.0) ! C is implicitly declared COMPLEX ... CONTAINS SUBROUTINE SUB1 IMPLICIT INTEGER (A, C) C = (0.0, 0.0) ! C is host associated and of ! type complex Z = 1.0 ! Z is implicitly declared REAL A = 2 ! A is implicitly declared INTEGER CC = 1 ! CC is implicitly declared INTEGER ... END SUBROUTINE SUB1 SUBROUTINE SUB2 Z = 2.0 ! Z is implicitly declared REAL and ! is different from the variable of ! the same name in SUB1 ... END SUBROUTINE SUB2 SUBROUTINE SUB3 USE EXAMPLE_MODULE ! Accesses integer function FUN ! by use association Q = FUN (K) ! Q is implicitly declared REAL and ... ! K is implicitly declared INTEGER END SUBROUTINE SUB3 END SUBROUTINE SUB NOTE 5.37 The following is an example of a mapping to a derived type that is inaccessible in the local scope: PROGRAM MAIN IMPLICIT TYPE(BLOB) (A) TYPE BLOB INTEGER :: I END TYPE BLOB TYPE(BLOB) :: B CALL STEVE CONTAINS SUBROUTINE STEVE INTEGER :: BLOB .. AA = B .. END SUBROUTINE STEVE END PROGRAM MAIN In the subroutine STEVE, it is not possible to explicitly declare a variable to be of type BLOB because BLOB has been given a different meaning, but implicit mapping for the letter A still maps to type BLOB, so AA is of type BLOB. 15.6 NAMELIST statement 109 J3/07-007 WORKING DRAFT 2006/01/05 1A NAMELIST statement specifies a group of named data objects, which may be referred to by a single name for the purpose of data transfer (9.5, 10.11). 2 3R562 namelist-stmt is NAMELIST 4 / namelist-group-name / namelist-group-object-list 5 [ [ , ] / namelist-group-name / namelist-group-object-list ] ... 6 C581 (R562) The namelist-group-name shall not be a name accessed by use association. 7 8R563 namelist-group-object is variable-name C582 (R563) A namelist-group-object shall not be an assumed-size array. 9 10C583 (R562) A namelist-group-object shall not have the PRIVATE attribute if the namelist-group- 11 name has the PUBLIC attribute. 12The order in which the variables are specified in the NAMELIST statement determines the order in 13which the values appear on output. 14Any namelist-group-name may occur more than once in the NAMELIST statements in a scoping unit. 15The namelist-group-object-list following each successive appearance of the same namelist-group-name in 16a scoping unit is treated as a continuation of the list for that namelist-group-name. 17A namelist group object may be a member of more than one namelist group. 18A namelist group object shall either be accessed by use or host association or shall have its type, type 19parameters, and shape specified by previous specification statements or the procedure heading in the 20same scoping unit or by the implicit typing rules in effect for the scoping unit. If a namelist group object 21is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall 22confirm the implied type and type parameters. NOTE 5.38 An example of a NAMELIST statement is: NAMELIST /NLIST/ A, B, C 5.7 Storage association of data objects 23 245.7.1 EQUIVALENCE statement 255.7.1.1 General 26An EQUIVALENCE statement is used to specify the sharing of storage units by two or more objects in a scoping unit. This causes storage association (16.5.3) of the objects that share the storage units. 27 NOTE 5.39 The co-size of a co-array is not a constant, therefore co-arrays are not allowed in COMMON or EQUIVALENCE. 28If the equivalenced objects have differing type or type parameters, the EQUIVALENCE statement does 29not cause type conversion or imply mathematical equivalence. If a scalar and an array are equivalenced, 30the scalar does not have array properties and the array does not have the properties of a scalar. R564 equivalence-stmt is EQUIVALENCE equivalence-set-list 110 2006/01/05 WORKING DRAFT J3/07-007 1 R565 equivalence-set is ( equivalence-object , equivalence-object-list ) 2 3R566 equivalence-object is variable-name 4 or array-element 5 or substring 6C584 (R566) An equivalence-object shall not be a designator with a base object that is a dummy 7 argument, a pointer, an allocatable variable, a derived-type object that has an allocatable ulti- 8 mate component, an object of a nonsequence derived type, an object of a derived type that has 9 a pointer at any level of component selection, an automatic object, a function name, an entry 10 name, a result name, a variable with the BIND attribute, a variable in a common block that 11 has the BIND attribute, or a named constant. C585 (R566) An equivalence-object shall not be a designator that has more than one part-ref . 12 C586 (R566) An equivalence-object shall not be a co-array or a subobject thereof. 13 C587 (R566) An equivalence-object shall not have the TARGET attribute. 14 15C588 (R566) Each subscript or substring range expression in an equivalence-object shall be an integer initialization expression (7.1.12). 16 17C589 (R565) If an equivalence-object is of type default integer, default real, double precision real, 18 default complex, default logical, default bits, or numeric sequence type, all of the objects in the 19 equivalence set shall be of these types. 20C590 (R565) If an equivalence-object is of type default character or character sequence type, all of the 21 objects in the equivalence set shall be of these types. 22C591 (R565) If an equivalence-object is of a sequence derived type that is not a numeric sequence or 23 character sequence type, all of the objects in the equivalence set shall be of the same type with 24 the same type parameter values. 25C592 (R565) If an equivalence-object is of an intrinsic type other than default integer, default real, 26 double precision real, default complex, default logical, or default character, all of the objects in 27 the equivalence set shall be of the same type with the same kind type parameter value. 28C593 (R566) If an equivalence-object has the PROTECTED attribute, all of the objects in the equiv- 29 alence set shall have the PROTECTED attribute. C594 (R566) The name of an equivalence-object shall not be a name made accessible by use association. 30 C595 (R566) A substring shall not have length zero. 31 NOTE 5.40 The EQUIVALENCE statement allows the equivalencing of sequence structures and the equiv- alencing of objects of intrinsic type with nondefault type parameters, but there are strict rules regarding the appearance of these objects in an EQUIVALENCE statement. A structure that appears in an EQUIVALENCE statement shall be a sequence structure. If a sequence structure is not of numeric sequence type or of character sequence type, it shall be equivalenced only to objects of the same type with the same type parameter values. A structure of a numeric sequence type shall be equivalenced only to another structure of a numeric sequence type, an object of default integer type, default real type, double precision real type, default complex type, default logical type, or default bits such that components of the structure ultimately 111 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 5.40 (cont.) become associated only with objects of these types. A structure of a character sequence type shall be equivalenced only to an object of default character type or another structure of a character sequence type. An object of intrinsic type with nondefault kind type parameters shall not be equivalenced to objects of different type or kind type parameters. Further rules on the interaction of EQUIVALENCE statements and default initialization are given in 16.5.3.4. 15.7.1.2 Equivalence association 2An EQUIVALENCE statement specifies that the storage sequences (16.5.3.2) of the data objects specified 3in an equivalence-set are storage associated. All of the nonzero-sized sequences in the equivalence-set, if 4any, have the same first storage unit, and all of the zero-sized sequences in the equivalence-set, if any, 5are storage associated with one another and with the first storage unit of any nonzero-sized sequences. 6This causes the storage association of the data objects in the equivalence-set and may cause storage 7association of other data objects. 85.7.1.3 Equivalence of default character objects 9A data object of type default character shall not be equivalenced to an object that is not of type default 10character and not of a character sequence type. The lengths of equivalenced default character objects 11need not be the same. 12An EQUIVALENCE statement specifies that the storage sequences of all the default character data 13objects specified in an equivalence-set are storage associated. All of the nonzero-sized sequences in the 14equivalence-set, if any, have the same first character storage unit, and all of the zero-sized sequences in 15the equivalence-set, if any, are storage associated with one another and with the first character storage 16unit of any nonzero-sized sequences. This causes the storage association of the data objects in the 17equivalence-set and may cause storage association of other data objects. NOTE 5.41 For example, using the declarations: CHARACTER (LEN = 4) :: A, B CHARACTER (LEN = 3) :: C (2) EQUIVALENCE (A, C (1)), (B, C (2)) the association of A, B, and C can be illustrated graphically as: 1 2 3 4 5 6 7 |--- --- A --- ---| |--- --- B --- ---| |--- C(1) ---| |--- C(2) ---| 185.7.1.4 Array names and array element designators 19For a nonzero-sized array, the use of the array name unqualified by a subscript list as an equivalence- 20object has the same effect as using an array element designator that identifies the first element of the 21array. 112 2006/01/05 WORKING DRAFT J3/07-007 15.7.1.5 Restrictions on EQUIVALENCE statements 2An EQUIVALENCE statement shall not specify that the same storage unit is to occur more than once 3in a storage sequence. NOTE 5.42 For example: REAL, DIMENSION (2) :: A REAL :: B EQUIVALENCE (A (1), B), (A (2), B) ! Not standard-conforming is prohibited, because it would specify the same storage unit for A (1) and A (2). 4An EQUIVALENCE statement shall not specify that consecutive storage units are to be nonconsecutive. NOTE 5.43 For example, the following is prohibited: REAL A (2) DOUBLE PRECISION D (2) EQUIVALENCE (A (1), D (1)), (A (2), D (2)) ! Not standard-conforming 55.7.2 COMMON statement 65.7.2.1 General 7The COMMON statement specifies blocks of physical storage, called common blocks, that can be 8accessed by any of the scoping units in a program. Thus, the COMMON statement provides a global data facility based on storage association (16.5.3). 9 10The common blocks specified by the COMMON statement may be named and are called named com- 11mon blocks, or may be unnamed and are called blank common. 12R567 common-stmt is COMMON 13 [ / [ common-block-name ] / ] common-block-object-list 14 [ [ , ] / [ common-block-name ] / common-block-object-list ] ... 15 16R568 common-block-object is variable-name [ ( array-spec ) ] 17 or proc-pointer-name C596 (R568) An array-spec in a common-block-object shall be an explicit-shape-spec-list. 18 19C597 (R568) Only one appearance of a given variable-name or proc-pointer-name is permitted in all 20 common-block-object-lists within a scoping unit. 21C598 (R568) A common-block-object shall not be a dummy argument, an allocatable variable, a 22 derived-type object with an ultimate component that is allocatable, an automatic object, a 23 function name, an entry name, a variable with the BIND attribute, a co-array, or a result name. 24C599 (R568) If a common-block-object is of a derived type, it shall be a sequence type (4.5.2.3) or a 25 type with the BIND attribute and it shall have no default initialization. 26C5100 (R568) A variable-name or proc-pointer-name shall not be a name made accessible by use 113 J3/07-007 WORKING DRAFT 2006/01/05 1 association. 2In each COMMON statement, the data objects whose names appear in a common block object list 3following a common block name are declared to be in that common block. If the first common block 4name is omitted, all data objects whose names appear in the first common block object list are specified to 5be in blank common. Alternatively, the appearance of two slashes with no common block name between 6them declares the data objects whose names appear in the common block object list that follows to be 7in blank common. 8Any common block name or an omitted common block name for blank common may occur more than 9once in one or more COMMON statements in a scoping unit. The common block list following each 10successive appearance of the same common block name in a scoping unit is treated as a continuation of 11the list for that common block name. Similarly, each blank common block object list in a scoping unit 12is treated as a continuation of blank common. The form variable-name (array-spec) specifies the DIMENSION attribute for that variable. 13 14If derived-type objects of numeric sequence type (4.5.2) or character sequence type (4.5.2) appear in 15common, it is as if the individual components were enumerated directly in the common list. NOTE 5.44 Examples of COMMON statements are: COMMON /BLOCKA/ A, B, D (10, 30) COMMON I, J, K 165.7.2.2 Common block storage sequence 17For each common block in a scoping unit, a common block storage sequence is formed as follows: 18 (1) A storage sequence is formed consisting of the sequence of storage units in the storage 19 sequences (16.5.3.2) of all data objects in the common block object lists for the common 20 block. The order of the storage sequences is the same as the order of the appearance of the 21 common block object lists in the scoping unit. 22 (2) The storage sequence formed in (1) is extended to include all storage units of any storage 23 sequence associated with it by equivalence association. The sequence shall be extended only 24 by adding storage units beyond the last storage unit. Data objects associated with an entity 25 in a common block are considered to be in that common block. 26Only COMMON statements and EQUIVALENCE statements appearing in the scoping unit contribute 27to common block storage sequences formed in that scoping unit. 285.7.2.3 Size of a common block 29The size of a common block is the size of its common block storage sequence, including any extensions 30of the sequence resulting from equivalence association. 315.7.2.4 Common association 32Within a program, the common block storage sequences of all nonzero-sized common blocks with the 33same name have the same first storage unit, and the common block storage sequences of all zero-sized 34common blocks with the same name are storage associated with one another. Within a program, the 35common block storage sequences of all nonzero-sized blank common blocks have the same first storage 36unit and the storage sequences of all zero-sized blank common blocks are associated with one another and 37with the first storage unit of any nonzero-sized blank common blocks. This results in the association of 114 2006/01/05 WORKING DRAFT J3/07-007 1objects in different scoping units. Use association or host association may cause these associated objects 2to be accessible in the same scoping unit. 3A nonpointer object of default integer type, default real type, double precision real type, default complex 4type, default logical type, or numeric sequence type shall be associated only with nonpointer objects of 5these types. 6A nonpointer object of type default character or character sequence type shall be associated only with 7nonpointer objects of these types. 8A nonpointer object of a derived type that is not a numeric sequence or character sequence type shall 9be associated only with nonpointer objects of the same type with the same type parameter values. 10A nonpointer object of intrinsic type other than default integer, default real, double precision real, 11default complex, default logical, or default character shall be associated only with nonpointer objects of 12the same type and type parameters. 13A data pointer shall be storage associated only with data pointers of the same type and rank. Data 14pointers that are storage associated shall have deferred the same type parameters; corresponding non- 15deferred type parameters shall have the same value. A procedure pointer shall be storage associated 16only with another procedure pointer; either both interfaces shall be explicit or both interfaces shall be 17implicit. If the interfaces are explicit, the characteristics shall be the same. If the interfaces are implicit, 18either both shall be subroutines or both shall be functions with the same type and type parameters. 19An object with the TARGET attribute shall be storage associated only with another object that has 20the TARGET attribute and the same type and type parameters. NOTE 5.45 A common block is permitted to contain sequences of different storage units, provided each scoping unit that accesses the common block specifies an identical sequence of storage units for the common block. For example, this allows a single common block to contain both numeric and character storage units. Association in different scoping units between objects of default type, objects of double precision real type, and sequence structures is permitted according to the rules for equivalence objects (5.7.1). 215.7.2.5 Differences between named common and blank common 22A blank common block has the same properties as a named common block, except for the following. 23 (1) Execution of a RETURN or END statement might cause data objects in a named common 24 block to become undefined unless the common block has the SAVE attribute or is declared 25 in a module or submodule, but never causes data objects in blank common to become undefined (16.6.6). 26 27 (2) Named common blocks of the same name shall be of the same size in all scoping units of a 28 program in which they appear, but blank common blocks may be of different sizes. 29 (3) A data object in a named common block may be initially defined by means of a DATA 30 statement or type declaration statement in a block data program unit (11.3), but objects in 31 blank common shall not be initially defined. 5.7.3 Restrictions on common and equivalence 32 33An EQUIVALENCE statement shall not cause the storage sequences of two different common blocks to 34be associated. 115 J3/07-007 WORKING DRAFT 2006/01/05 1Equivalence association shall not cause a derived-type object with default initialization to be associated 2with an object in a common block. 3Equivalence association shall not cause a common block storage sequence to be extended by adding 4storage units preceding the first storage unit of the first object specified in a COMMON statement for 5the common block. NOTE 5.46 For example, the following is not permitted: COMMON /X/ A REAL B (2) EQUIVALENCE (A, B (2)) ! Not standard-conforming 116 2006/01/05 WORKING DRAFT J3/07-007 6 Use of data objects 1 2The appearance of a data object designator in a context that requires its value is termed a reference. A 3reference is permitted only if the data object is defined. A reference to a pointer is permitted only if the 4pointer is associated with a target object that is defined. A data object becomes defined with a value 5when events described in 16.6.5 occur. 6R601 variable is designator 7 or expr C601 (R601) designator shall not be a constant or a subobject of a constant. 8 C602 (R601) expr shall be a reference to a function that has a pointer result. 9 10A variable is either the data object denoted by designator or the target of expr. 11R602 variable-name is name C603 (R602) variable-name shall be the name of a variable. 12 13R603 designator is object-name 14 or array-element 15 or array-section 16 or complex-part-designator 17 or structure-component 18 or substring 19R604 logical-variable is variable C604 (R604) logical-variable shall be of type logical. 20 21R605 default-logical-variable is variable C605 (R605) default-logical-variable shall be of type default logical. 22 23R606 char-variable is variable C606 (R606) char-variable shall be of type character. 24 25R607 default-char-variable is variable C607 (R607) default-char-variable shall be of type default character. 26 27R608 int-variable is variable C608 (R608) int-variable shall be of type integer. 28 NOTE 6.1 For example, given the declarations: CHARACTER (10) A, B (10) TYPE (PERSON) P ! See Note 4.20 then A, B, B (1), B (1:5), P % AGE, and A (1:1) are all variables. 117 J3/07-007 WORKING DRAFT 2006/01/05 1A constant (3.2.2) is a literal constant or a named constant. A literal constant is a scalar denoted by a 2syntactic form, which indicates its type, type parameters, and value. A named constant is a constant 3that has a name; the name has the PARAMETER attribute (5.3.12, 5.4.10). A reference to a constant 4is always permitted; redefinition of a constant is never permitted. 56.1 Scalars 6.1.1 Substrings 6 A substring is a contiguous portion of a character string (4.4.5). 7 R609 substring is parent-string ( substring-range ) 8 9R610 parent-string is scalar-variable-name 10 or array-element 11 or scalar-structure-component 12 or scalar-constant R611 substring-range is [ scalar-int-expr ] : [ scalar-int-expr ] 13 C609 (R610) parent-string shall be of type character. 14 15The value of the first scalar-int-expr in substring-range is called the starting point and the value of 16the second one is called the ending point. The length of a substring is the number of characters in the substring and is MAX (l - f + 1, 0), where f and l are the starting and ending points, respectively. 17 18Let the characters in the parent string be numbered 1, 2, 3, ..., n, where n is the length of the parent 19string. Then the characters in the substring are those from the parent string from the starting point and 20proceeding in sequence up to and including the ending point. Both the starting point and the ending 21point shall be within the range 1, 2, ..., n unless the starting point exceeds the ending point, in which 22case the substring has length zero. If the starting point is not specified, the default value is 1. If the 23ending point is not specified, the default value is n. 24If the parent is a variable, the substring is also a variable. NOTE 6.2 Examples of character substrings are: B(1)(1:5) array element as parent string P%NAME(1:1) structure component as parent string ID(4:9) scalar variable name as parent string '0123456789'(N:N) character constant as parent string 6.1.2 Structure components 25 26A structure component is part of an object of derived type; it may be referenced by an object 27designator. A structure component may be a scalar or an array. R612 data-ref is part-ref [ % part-ref ] ... 28 R613 part-ref is part-name [ ( section-subscript-list ) ] [ image-selector ] 29 C610 (R612) Each part-name except the rightmost shall be of derived type. 30 31C611 (R612) Each part-name except the leftmost shall be the name of a component of the declared 118 2006/01/05 WORKING DRAFT J3/07-007 1 type of the preceding part-name. C612 (R612) If the rightmost part-name is of abstract type, data-ref shall be polymorphic. 2 C613 (R612) The leftmost part-name shall be the name of a data object. 3 4C614 (R613) If a section-subscript-list appears, the number of section-subscripts shall equal the rank 5 of part-name. 6C615 (R613) If image-selector appears, the number of co-subscripts shall be equal to the co-rank of 7 part-name. C616 (R613) If image-selector appears and part-name is an array, section-subscript-list shall appear. 8 9C617 (R612) If image-selector appears, data-ref shall not be, or have a direct component, of type IMAGE TEAM (13.8.2.7), C PTR, or C FUNPTR (15.3.3). 10 C618 (R612) A data-ref that is a co-indexed object shall not have a pointer ultimate component. 11 NOTE 6.3 This restriction is needed to avoid a disallowed pointer assignment for a component, such as Z[P] = Z ! Not allowed if Z has a pointer component Z = Z[P] ! Not allowed if Z has a pointer component 12The rank of a part-ref of the form part-name is the rank of part-name. The rank of a part-ref that has 13a section subscript list is the number of subscript triplets and vector subscripts in the list. 14C619 (R612) There shall not be more than one part-ref with nonzero rank. A part-name to the right 15 of a part-ref with nonzero rank shall not have the ALLOCATABLE or POINTER attribute. 16The rank of a data-ref is the rank of the part-ref with nonzero rank, if any; otherwise, the rank is zero. 17The base object of a data-ref is the data object whose name is the leftmost part name. 18The type and type parameters, if any, of a data-ref are those of the rightmost part name. 19A data-ref with more than one part-ref is a subobject of its base object if none of the part-names, 20except for possibly the rightmost, are pointers. If the rightmost part-name is the only pointer, then the 21data-ref is a subobject of its base object in contexts that pertain to its pointer association status but 22not in any other contexts. NOTE 6.4 If X is an object of derived type with a pointer component P, then the pointer X%P is a subobject of X when considered as a pointer ­ that is in contexts where it is not dereferenced. However the target of X%P is not a subobject of X. Thus, in contexts where X%P is dereferenced to refer to the target, it is not a subobject of X. 23R614 structure-component is data-ref 24C620 (R614) There shall be more than one part-ref and the rightmost part-ref shall be of the form 25 part-name. 26A structure component shall be neither referenced nor defined before the declaration of the base object. 27A structure component is a pointer only if the rightmost part name is defined to have the POINTER 28attribute. 119 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 6.5 Examples of structure components are: SCALAR_PARENT%SCALAR_FIELD scalar component of scalar parent ARRAY_PARENT(J)%SCALAR_FIELD component of array element parent ARRAY_PARENT(1:N)%SCALAR_FIELD component of array section parent For a more elaborate example see C.3.1. NOTE 6.6 The syntax rules are structured such that a data-ref that ends in a component name without a following subscript list is a structure component, even when other component names in the data- ref are followed by a subscript list. A data-ref that ends in a component name with a following subscript list is either an array element or an array section. A data-ref of nonzero rank that ends with a substring-range is an array section. A data-ref of zero rank that ends with a substring-range is a substring. 1A subcomponent of an object of derived type is a component of that object or of a subobject of that 2object. 3A data-ref shall not be a co-indexed object that has a pointer subcomponent. A data-ref that is a 4co-indexed object shall not be, or have a subcomponent, of type IMAGE TEAM (13.8.2.7), C PTR, or C FUNPTR (15.3.3). 5 J3 internal note Unresolved Technical Issue 089 I'm just so sure the sky is going to fall in if the user dares to do this, but why are we adding uncheckable requirements? (Well, ok it's theoretically checkable at runtime only.) And why is this requirement placed here? None of the other stuff which uses the term "sub- component" is here, this is just the definition. It probably belongs in a separate subclause for co-indexed objects... which might clean up some of the other mess that is being made of clause 6. We REALLY ought not to be placing type requirements on runtime values. That is UNAC- CEPTABLE. I am not kidding ­ note the careful design of the object-oriented stuff to avoid such requirements. If the co-array folk don't have the time to design the facility properly, omit it, don't go and make a complete pig's ear of the standard. It is not beyond the wit of man to design this to be compile-time checkable. Back to the original question ­ why is the sky going to fall in? I do not believe that the conse- quences of allowing this justify the complexity of these arbitrary restrictions. Furthermore, the restrictions are ineffective. There are standard-conforming ways (using TRANSFER) to "hide" the type of the value and restore it later, on another image. 6.1.3 Complex parts 6 7A complex part designator is used to designate the real or imaginary part of a complex data object, 8independently of the other part. 9R615 complex-part-designator is designator % RE 10 or designator % IM C621 (R615) The designator shall be of complex type. 11 12If complex-part-designator is designator%RE it designates the real part of designator. If it is designa- 13tor%IM it designates the imaginary part of designator. The type of a complex-part-designator is real, 120 2006/01/05 WORKING DRAFT J3/07-007 1and its kind and shape are those of the designator. NOTE 6.7 The following are examples of complex part designators: impedance%re !-- Same value as REAL(impedance) fft%im !-- Same value as AIMAG(fft) x%im = 0.0 !-- Sets the imaginary part of X to zero 6.1.4 Type parameter inquiry 2 3A type parameter inquiry is used to inquire about a type parameter of a data object. It applies to 4both intrinsic and derived types. 5R616 type-param-inquiry is designator % type-param-name 6C622 (R616) The type-param-name shall be the name of a type parameter of the declared type of the 7 object designated by the designator. 8A deferred type parameter of a pointer that is not associated or of an unallocated allocatable variable 9shall not be inquired about. NOTE 6.8 A type-param-inquiry has a syntax like that of a structure component reference, but it does not have the same semantics. It is not a variable and thus can never be assigned to. It may be used only as a primary in an expression. It is scalar even if designator is an array. The intrinsic type parameters can also be inquired about by using the intrinsic functions KIND and LEN. NOTE 6.9 The following are examples of type parameter inquiries: a%kind !-- A is real. Same value as KIND(a). s%len !-- S is character. Same value as LEN(s). b(10)%kind !-- Inquiry about an array element. p%dim !-- P is of the derived type general_point. See Note 4.27 for the definition of the general_point type used in the last example above. 6.2 Arrays 10 11An array is a set of scalar data, all of the same type and type parameters, whose individual elements 12are arranged in a rectangular pattern. The scalar data that make up an array are the array elements. 13No order of reference to the elements of an array is indicated by the appearance of the array designator, except where array element ordering (6.2.2.1) is specified. 14 6.2.1 Whole arrays 15 16A whole array is a named array, which may be either a named constant (5.3.12, 5.4.10) or a variable; 17no subscript list is appended to the name. 121 J3/07-007 WORKING DRAFT 2006/01/05 1The appearance of a whole array variable in an executable construct specifies all the elements of the 2array (2.4.5). An assumed-size array is permitted to appear as a whole array in an executable construct 3only as an actual argument in a procedure reference that does not require the shape. 4The appearance of a whole array name in a nonexecutable statement specifies the entire array except for the appearance of a whole array name in an equivalence set (5.7.1.4). 5 6.2.2 Array elements and array sections 6 7R617 array-element is data-ref C623 (R617) Every part-ref shall have rank zero and the last part-ref shall contain a subscript-list. 8 9R618 array-section is data-ref [ ( substring-range ) ] 10 or complex-part-designator 11C624 (R618) Exactly one part-ref shall have nonzero rank, and either the final part-ref shall have 12 a section-subscript-list with nonzero rank, another part-ref shall have nonzero rank, or the 13 complex-part-designator shall be an array. C625 (R618) If a substring-range appears, the rightmost part-name shall be of type character. 14 15R619 subscript is scalar-int-expr 16R620 section-subscript is subscript 17 or subscript-triplet 18 or vector-subscript R621 subscript-triplet is [ subscript ] : [ subscript ] [ : stride ] 19 20R622 stride is scalar-int-expr 21R623 vector-subscript is int-expr C626 (R623) A vector-subscript shall be an integer array expression of rank one. 22 23C627 (R621) The second subscript shall not be omitted from a subscript-triplet in the last dimension 24 of an assumed-size array. 25An array element is a scalar. An array section is an array. If a substring-range is present in an array- 26section, each element is the designated substring of the corresponding element of the array section. 27The value of a subscript in an array element shall be within the bounds for that dimension. NOTE 6.10 For example, with the declarations: REAL A (10, 10) CHARACTER (LEN = 10) B (5, 5, 5) A (1, 2) is an array element, A (1:N:2, M) is a rank-one array section, and B (:, :, :) (2:3) is an array of shape (5, 5, 5) whose elements are substrings of length 2 of the corresponding elements of B. NOTE 6.11 Unless otherwise specified, an array element or array section does not have an attribute of the whole array. In particular, an array element or an array section does not have the POINTER or 122 2006/01/05 WORKING DRAFT J3/07-007 NOTE 6.11 (cont.) ALLOCATABLE attribute. NOTE 6.12 Examples of array elements and array sections are: ARRAY_A(1:N:2)%ARRAY_B(I, J)%STRING(K)(:) array section SCALAR_PARENT%ARRAY_FIELD(J) array element SCALAR_PARENT%ARRAY_FIELD(1:N) array section SCALAR_PARENT%ARRAY_FIELD(1:N)%SCALAR_FIELD array section 16.2.2.1 Array element order 2The elements of an array form a sequence known as the array element order. The position of an array 3element in this sequence is determined by the subscript order value of the subscript list designating the 4element. The subscript order value is computed from the formulas in Table 6.1. Table 6.1: Subscript order value Rank Subscript bounds Subscript list Subscript order value 1 j1:k1 s1 1 + (s1 - j1) 1 + (s1 - j1) 2 j1:k1,j2:k2 s1,s2 +(s2 - j2) × d1 1 + (s1 - j1) 3 j1:k1,j2:k2,j3:k3 s1,s2,s3 +(s2 - j2) × d1 +(s3 - j3) × d2 × d1 · · · · · · · · · · · · 1 + (s1 - j1) +(s2 - j2) × d1 +(s3 - j3) × d2 × d1 15 j1:k1,...,j15:k15 s1,...,s15 +... +(s15 - j15) × d14 ×d13 × ... × d1 Notes for Table 6.1: 1) di = max (ki -ji +1, 0) is the size of the ith dimension. 2) If the size of the array is nonzero, ji si ki for all i = 1, 2, ..., 15. 56.2.2.2 Array sections 6An array section is an array subobject optionally followed by a substring range. 7In an array-section having a section-subscript-list, each subscript-triplet and vector-subscript in the 8section subscript list indicates a sequence of subscripts, which may be empty. Each subscript in such a 9sequence shall be within the bounds for its dimension unless the sequence is empty. The array section is 10the set of elements from the array determined by all possible subscript lists obtainable from the single 11subscripts or sequences of subscripts specified by each section subscript. 12In an array-section with no section-subscript-list, the rank and shape of the array is the rank and shape 13of the part-ref with nonzero rank; otherwise, the rank of the array section is the number of subscript 14triplets and vector subscripts in the section subscript list. The shape is the rank-one array whose ith 123 J3/07-007 WORKING DRAFT 2006/01/05 1element is the number of integer values in the sequence indicated by the ith subscript triplet or vector 2subscript. If any of these sequences is empty, the array section has size zero. The subscript order of the 3elements of an array section is that of the array data object that the array section represents. 46.2.2.2.1 Subscript triplet 5A subscript triplet designates a regular sequence of subscripts consisting of zero or more subscript values. 6The third expression in the subscript triplet is the increment between the subscript values and is called 7the stride. The subscripts and stride of a subscript triplet are optional. An omitted first subscript in a 8subscript triplet is equivalent to a subscript whose value is the lower bound for the array and an omitted 9second subscript is equivalent to the upper bound. An omitted stride is equivalent to a stride of 1. 10The stride shall not be zero. 11When the stride is positive, the subscripts specified by a triplet form a regularly spaced sequence of 12integers beginning with the first subscript and proceeding in increments of the stride to the largest such 13integer not greater than the second subscript; the sequence is empty if the first subscript is greater than 14the second. NOTE 6.13 For example, suppose an array is declared as A (5, 4, 3). The section A (3 : 5, 2, 1 : 2) is the array of shape (3, 2): A (3, 2, 1) A (3, 2, 2) A (4, 2, 1) A (4, 2, 2) A (5, 2, 1) A (5, 2, 2) 15When the stride is negative, the sequence begins with the first subscript and proceeds in increments of 16the stride down to the smallest such integer equal to or greater than the second subscript; the sequence 17is empty if the second subscript is greater than the first. NOTE 6.14 For example, if an array is declared B (10), the section B (9 : 1 : ­2) is the array of shape (5) whose elements are B (9), B (7), B (5), B (3), and B (1), in that order. NOTE 6.15 A subscript in a subscript triplet need not be within the declared bounds for that dimension if all values used in selecting the array elements are within the declared bounds. For example, if an array is declared as B (10), the array section B (3 : 11 : 7) is the array of shape (2) consisting of the elements B (3) and B (10), in that order. 186.2.2.2.2 Vector subscript 19A vector subscript designates a sequence of subscripts corresponding to the values of the elements 20of the expression. Each element of the expression shall be defined. A many-one array section is an 21array section with a vector subscript having two or more elements with the same value. A many-one 22array section shall appear neither on the left of the equals in an assignment statement nor as an input 23item in a READ statement. 24An array section with a vector subscript shall not be argument associated with a dummy array that 25is defined or redefined. An array section with a vector subscript shall not be the target in a pointer 26assignment statement. An array section with a vector subscript shall not be an internal file. 124 2006/01/05 WORKING DRAFT J3/07-007 NOTE 6.16 For example, suppose Z is a two-dimensional array of shape [5, 7] and U and V are one-dimensional arrays of shape (3) and (4), respectively. Assume the values of U and V are: U = [ 1, 3, 2 ] V = [ 2, 1, 1, 3 ] Then Z (3, V) consists of elements from the third row of Z in the order: Z (3, 2) Z (3, 1) Z (3, 1) Z (3, 3) and Z (U, 2) consists of the column elements: Z (1, 2) Z (3, 2) Z (2, 2) and Z (U, V) consists of the elements: Z (1, 2) Z (1, 1) Z (1, 1) Z (1, 3) Z (3, 2) Z (3, 1) Z (3, 1) Z (3, 3) Z (2, 2) Z (2, 1) Z (2, 1) Z (2, 3) Because Z (3, V) and Z (U, V) contain duplicate elements from Z, the sections Z (3, V) and Z (U, V) shall not be redefined as sections. 6.2.3 Image selectors 1 2An image selector specifies the image index for co-array data. 3R624 image-selector is lbracket co-subscript-list rbracket 4R625 co-subscript is scalar-int-expr 5The number of co-subscripts shall be equal to the co-rank of the object. The value of a co-subscript in 6an image selector shall be within the co-bounds for its co-dimension. Taking account of the co-bounds, 7the co-subscript list in an image selector determines the image index in the same way that a subscript 8list in an array element determines the subscript order value (6.2.2.1), taking account of the bounds. An 9image selector shall specify an image index value that is not greater than the number of images. NOTE 6.17 For example, if there are 16 images and the co-array A is declared REAL :: A(10)[5,*] A(:)[1,4] is valid because it specifies image 16, but A(:)[2,4] is invalid because it specifies image 17. 6.3 Dynamic association 10 116.3.1 ALLOCATE statement 12The ALLOCATE statement dynamically creates pointer targets and allocatable variables. 13R626 allocate-stmt is ALLOCATE ( [ type-spec :: ] allocation-list [, alloc-opt-list ] ) 125 J3/07-007 WORKING DRAFT 2006/01/05 1R627 alloc-opt is ERRMSG = errmsg-variable 2 or MOLD = source-expr 3 or SOURCE = source-expr 4 or STAT = stat-variable 5R628 stat-variable is scalar-int-variable 6R629 errmsg-variable is scalar-default-char-variable 7R630 source-expr is expr 8R631 allocation is allocate-object [ ( allocate-shape-spec-list ) ] [ lbracket allocate-co-array-spec rbracket ] 9 10R632 allocate-object is variable-name 11 or structure-component R633 allocate-shape-spec is [ lower-bound-expr : ] upper-bound-expr 12 13R634 lower-bound-expr is scalar-int-expr 14R635 upper-bound-expr is scalar-int-expr R636 allocate-co-array-spec is [ allocate-co-shape-spec-list , ] [ lower-bound-expr : ] * 15 R637 allocate-co-shape-spec is [ lower-bound-expr : ] upper-bound-expr 16 C628 (R632) Each allocate-object shall be a nonprocedure pointer or an allocatable variable. 17 18C629 (R626) If any allocate-object has a deferred type parameter, is unlimited polymorphic, or is of 19 abstract type, either type-spec or source-expr shall appear. 20C630 (R626) If a type-spec appears, it shall specify a type with which each allocate-object is type 21 compatible. 22C631 (R626) A type-param-value in a type-spec shall be an asterisk if and only if each allocate-object 23 is a dummy argument for which the corresponding type parameter is assumed. 24C632 (R626) If a type-spec appears, the kind type parameter values of each allocate-object shall be 25 the same as the corresponding type parameter values of the type-spec. 26C633 (R631) If allocate-object is an array either allocate-shape-spec-list shall appear or source-expr 27 shall appear and have the same rank as allocate-object. If allocate-object is scalar, allocate- 28 shape-spec-list shall not appear. C634 (R631) An allocate-co-array-spec shall appear if and only if the allocate-object is a co-array. 29 30C635 (R631) The number of allocate-shape-specs in an allocate-shape-spec-list shall be the same as the 31 rank of the allocate-object. The number of allocate-co-shape-specs in an allocate-co-array-spec 32 shall be one less than the co-rank of the allocate-object. C636 (R627) No alloc-opt shall appear more than once in a given alloc-opt-list. 33 C637 (R626) At most one of source-expr and type-spec shall appear. 34 35C638 (R626) Each allocate-object shall be type compatible (4.3.1.3) with source-expr. If SOURCE= 36 appears, source-expr shall be a scalar or have the same rank as each allocate-object. 37C639 (R626) Corresponding kind type parameters of allocate-object and source-expr shall have the 126 2006/01/05 WORKING DRAFT J3/07-007 1 same values. C640 (R626) type-spec shall not specify a type that has a co-array ultimate component. 2 C641 (R630) The declared type of source-expr shall not have a co-array ultimate component. 3 C642 (R632) An allocate-object shall not be a co-indexed object. 4 NOTE 6.18 If a co-array is of a derived type that has an allocatable component, the component shall be allocated by its own image: TYPE(SOMETHING), ALLOCATABLE :: T[:] ... ALLOCATE(T[*]) ! Allowed - implies synchronization ALLOCATE(T%AAC(N)) ! Allowed - allocated by its own image ALLOCATE(T[Q]%AAC(N)) ! Not allowed, because it is not ! necessarily executed on image Q. 5An allocate-object or a bound or type parameter of an allocate-object shall not depend on the value of 6stat-variable, the value of errmsg-variable, or on the value, bounds, length type parameters, allocation 7status, or association status of any allocate-object in the same ALLOCATE statement. 8source-expr shall not be allocated within the ALLOCATE statement in which it appears; nor shall it 9depend on the value, bounds, deferred type parameters, allocation status, or association status of any 10allocate-object in that statement. 11If type-spec is specified, each allocate-object is allocated with the specified dynamic type and type pa- 12rameter values; if source-expr is specified, each allocate-object is allocated with the dynamic type and 13type parameter values of source-expr; otherwise, each allocate-object is allocated with its dynamic type 14the same as its declared type. 15If type-spec appears and the value of a type parameter it specifies differs from the value of the corre- 16sponding nondeferred type parameter specified in the declaration of any allocate-object, an error condition 17occurs. If the value of a nondeferred length type parameter of an allocate-object differs from the value 18of the corresponding type parameter of source-expr, an error condition occurs. 19If a type-param-value in a type-spec in an ALLOCATE statement is an asterisk, it denotes the current 20value of that assumed type parameter. If it is an expression, subsequent redefinition or undefinition of 21any entity in the expression does not affect the type parameter value. NOTE 6.19 An example of an ALLOCATE statement is: ALLOCATE (X (N), B (-3 : M, 0:9), STAT = IERR_ALLOC) 22When an ALLOCATE statement is executed for an array for which allocate-shape-spec-list is specified, 23the values of the lower bound and upper bound expressions determine the bounds of the array. Subse- 24quent redefinition or undefinition of any entities in the bound expressions do not affect the array bounds. 25If the lower bound is omitted, the default value is 1. If the upper bound is less than the lower bound, 26the extent in that dimension is zero and the array has zero size. 27When an ALLOCATE statement is executed for a co-array, the values of the lower co-bound and upper 28co-bound expressions determine the co-bounds of the co-array. Subsequent redefinition or undefinition 127 J3/07-007 WORKING DRAFT 2006/01/05 1of any entities in the co-bound expressions do not affect the co-bounds. If the lower co-bound is omitted, 2the default value is 1. The upper co-bound shall not be less than the lower co-bound. 3The value of each lower-bound-expr and each upper-bound-expr in an allocate-co-array-spec shall be the 4same on each image. 5If an allocation specifies a co-array, its dynamic type and the values of each length type parameter shall 6be the same on each image. 7There is implicit synchronization of all images in association with each ALLOCATE statement that 8involves one or more co-arrays. On each image, execution of the segment (8.5.1) following the statement 9is delayed until all other images have executed the same statement the same number of times. NOTE 6.20 When an image executes an ALLOCATE statement, communication is not necessarily involved apart from any required for synchronization. The image allocates its co-array and records how the corresponding co-arrays on other images are to be addressed. The processor is not required to detect violations of the rule that the bounds are the same on all images, nor is it responsible for detecting or resolving deadlock problems (such as two images waiting on different ALLOCATE statements). 10If source-expr is a pointer, it shall be associated with a target. If source-expr is allocatable, it shall be 11allocated. 12When an ALLOCATE statement is executed for an array with no allocate-shape-spec-list, the bounds 13of source-expr determine the bounds of the array. Subsequent changes to the bounds of source-expr do 14not affect the array bounds. 15If SOURCE= appears, source-expr shall be conformable (2.4.5) with allocation. If the value of a non- 16deferred length type parameter of allocate-object is different from the value of the corresponding type 17parameter of source-expr, an error condition occurs. On successful allocation, if allocate-object and 18source-expr have the same rank the value of allocate-object becomes that of source-expr, otherwise the 19value of each element of allocate-object becomes that of source-expr. 20If MOLD= appears and source-expr is a variable, its value need not be defined. J3 internal note Unresolved Technical Issue 081 Should we require allocatables to be allocated, or only when they have deferred type parameters? Furthermore, we should probably extend MOLD= (and SOURCE=) to be able to specify the shape, when no array-spec is provided, so the user can write ALLOCATE(A,MOLD=B) instead of ALLOCATE(A(LBOUND(B,1):UBOUND(B,1),LBOUND(B,2):UBOUND(B,2)),MOLD=B) NOTE 6.21 An example of an ALLOCATE statement in which the value and dynamic type are determined by reference to another object is: CLASS(*), ALLOCATABLE :: NEW CLASS(*), POINTER :: OLD ! ... 128 2006/01/05 WORKING DRAFT J3/07-007 NOTE 6.21 (cont.) ALLOCATE (NEW, SOURCE=OLD) ! Allocate NEW with the value and dynamic type of OLD A more extensive example is given in C.3.2. 1The STAT= specifier is described in 6.3.4. 2If an error condition occurs during execution of an ALLOCATE statement that does not contain the 3STAT= specifier, execution of the program is terminated. 4The ERRMSG= specifier is described in 6.3.5. 56.3.1.1 Allocation of allocatable variables 6The allocation status of an allocatable entity is one of the following at any time. 7 (1) The status of an allocatable variable becomes allocated if it is allocated by an ALLOCATE 8 statement, if it is allocated during assignment, or if it is given that status by the allocation 9 transfer procedure (13.7.124). An allocatable variable with this status may be referenced, 10 defined, or deallocated; allocating it causes an error condition in the ALLOCATE statement. The intrinsic function ALLOCATED (13.7.10) returns true for such a variable. 11 12 (2) An allocatable variable has a status of unallocated if it is not allocated. The status of 13 an allocatable variable becomes unallocated if it is deallocated (6.3.3) or if it is given that 14 status by the allocation transfer procedure. An allocatable variable with this status shall 15 not be referenced or defined. It shall not be supplied as an actual argument corresponding 16 to a nonallocatable dummy argument, except to certain intrinsic inquiry functions. It may 17 be allocated with the ALLOCATE statement. Deallocating it causes an error condition in 18 the DEALLOCATE statement. The intrinsic function ALLOCATED (13.7.10) returns false 19 for such a variable. 20At the beginning of execution of a program, allocatable variables are unallocated. 21When the allocation status of an allocatable variable changes, the allocation status of any associated 22allocatable variable changes accordingly. Allocation of an allocatable variable establishes values for the 23deferred type parameters of all associated allocatable variables. 24An unsaved allocatable local variable of a procedure has a status of unallocated at the beginning of 25each invocation of the procedure. An unsaved allocatable local variable of a module or submodule, or 26a subobject thereof, has an initial status of unallocated. An unsaved local variable of a construct has a 27status of unallocated at the beginning of each execution of the construct. 28When an object of derived type is created by an ALLOCATE statement, any allocatable ultimate 29components have an allocation status of unallocated. 306.3.1.2 Allocation of pointer targets 31Allocation of a pointer creates an object that implicitly has the TARGET attribute. Following successful 32execution of an ALLOCATE statement for a pointer, the pointer is associated with the target and may 33be used to reference or define the target. Additional pointers may become associated with the pointer 34target or a part of the pointer target by pointer assignment. It is not an error to allocate a pointer 35that is already associated with a target. In this case, a new pointer target is created as required by the 36attributes of the pointer and any array bounds, type, and type parameters specified by the ALLOCATE 37statement. The pointer is then associated with this new target. Any previous association of the pointer 38with a target is broken. If the previous target had been created by allocation, it becomes inaccessible 39unless other pointers are associated with it. The ASSOCIATED intrinsic function (13.7.15) may be used 129 J3/07-007 WORKING DRAFT 2006/01/05 1to determine whether a pointer that does not have undefined association status is associated. 2At the beginning of execution of a function whose result is a pointer, the association status of the result 3pointer is undefined. Before such a function returns, it shall either associate a target with this pointer 4or cause the association status of this pointer to become disassociated. 56.3.2 NULLIFY statement 6The NULLIFY statement causes pointers to be disassociated. R638 nullify-stmt is NULLIFY ( pointer-object-list ) 7 8R639 pointer-object is variable-name 9 or structure-component 10 or proc-pointer-name C643 (R639) Each pointer-object shall have the POINTER attribute. 11 12A pointer-object shall not depend on the value, bounds, or association status of another pointer-object 13in the same NULLIFY statement. NOTE 6.22 When a NULLIFY statement is applied to a polymorphic pointer (4.3.1.3), its dynamic type becomes the declared type. 146.3.3 DEALLOCATE statement 15The DEALLOCATE statement causes allocatable variables to be deallocated; it causes pointer tar- 16gets to be deallocated and the pointers to be disassociated. R640 deallocate-stmt is DEALLOCATE ( allocate-object-list [ , dealloc-opt-list ] ) 17 C644 (R640) Each allocate-object shall be a nonprocedure pointer or an allocatable variable. 18 19R641 dealloc-opt is STAT = stat-variable 20 or ERRMSG = errmsg-variable C645 (R641) No dealloc-opt shall appear more than once in a given dealloc-opt-list. 21 22An allocate-object shall not depend on the value, bounds, allocation status, or association status of 23another allocate-object in the same DEALLOCATE statement; it also shall not depend on the value of 24the stat-variable or errmsg-variable in the same DEALLOCATE statement. 25The STAT= specifier is described in 6.3.4. 26If an error condition occurs during execution of a DEALLOCATE statement that does not contain the 27STAT= specifier, execution of the program is terminated. 28The ERRMSG= specifier is described in 6.3.5. NOTE 6.23 An example of a DEALLOCATE statement is: DEALLOCATE (X, B) 296.3.3.1 Deallocation of allocatable variables 130 2006/01/05 WORKING DRAFT J3/07-007 1Deallocating an unallocated allocatable variable causes an error condition in the DEALLOCATE state- 2ment. Deallocating an allocatable variable with the TARGET attribute causes the pointer association 3status of any pointer associated with it to become undefined. 4When the execution of a procedure is terminated by execution of a RETURN or END statement, an 5unsaved allocatable local variable of the procedure retains its allocation and definition status if it is a 6function result variable or a subobject thereof; otherwise, it is deallocated. 7When a BLOCK construct terminates, an unsaved allocatable local variable of the construct is deallo- 8cated. NOTE 6.24 The ALLOCATED intrinsic function may be used to determine whether a variable is allocated or unallocated. 9If an executable construct references a function whose result is either allocatable or a structure with 10a subobject that is allocatable, and the function reference is executed, an allocatable result and any 11subobject that is an allocated allocatable entity in the result returned by the function is deallocated 12after execution of the innermost executable construct containing the reference. 13If a function whose result is either allocatable or a structure with an allocatable subobject is referenced 14in the specification part of a scoping unit or BLOCK construct, and the function reference is executed, 15an allocatable result and any subobject that is an allocated allocatable entity in the result returned by 16the function is deallocated before execution of the executable constructs of the scoping unit or block. 17When a procedure is invoked, any allocated allocatable object that is an actual argument associated with 18an INTENT(OUT) allocatable dummy argument is deallocated; any allocated allocatable object that is a subobject of an actual argument associated with an INTENT(OUT) dummy argument is deallocated. 19 20When an intrinsic assignment statement (7.2.1.3) is executed, any non-co-array allocated allocatable 21subobject of the variable is deallocated before the assignment takes place. 22When a variable of derived type is deallocated, any allocated allocatable subobject is deallocated. 23If an allocatable component is a subobject of a finalizable object, that object is finalized before the 24component is automatically deallocated. 25The effect of automatic deallocation is the same as that of a DEALLOCATE statement without a 26dealloc-opt-list. NOTE 6.25 In the following example: SUBROUTINE PROCESS REAL, ALLOCATABLE :: TEMP(:) REAL, ALLOCATABLE, SAVE :: X(:) ... END SUBROUTINE PROCESS on return from subroutine PROCESS, the allocation status of X is preserved because X has the SAVE attribute. TEMP does not have the SAVE attribute, so it will be deallocated if it was allo- cated. On the next invocation of PROCESS, TEMP will have an allocation status of unallocated. 27There is implicit synchronization of all images in association with each DEALLOCATE statement that 28involves one or more co-arrays. On each image, execution of the segment (8.5.1) following the statement 131 J3/07-007 WORKING DRAFT 2006/01/05 1is delayed until all other images have executed the same statement the same number of times. 2There is also an implicit synchronization of all images in association with the deallocation of a co-array 3or co-array subcomponent caused by the execution of a RETURN or END statement or the termination 4of a BLOCK construct. 56.3.3.2 Deallocation of pointer targets 6If a pointer appears in a DEALLOCATE statement, its association status shall be defined. Deallocating 7a pointer that is disassociated or whose target was not created by an ALLOCATE statement causes an 8error condition in the DEALLOCATE statement. If a pointer is associated with an allocatable entity, 9the pointer shall not be deallocated. 10If a pointer appears in a DEALLOCATE statement, it shall be associated with the whole of an object 11that was created by allocation. Deallocating a pointer target causes the pointer association status of 12any other pointer that is associated with the target or a portion of the target to become undefined. 6.3.4 STAT= specifier 13 14stat-variable shall not be allocated or deallocated within the ALLOCATE or DEALLOCATE statement 15in which it appears; nor shall it depend on the value, bounds, deferred type parameters, allocation status, 16or association status of any allocate-object in that statement. 17If the STAT= specifier appears, successful execution of the ALLOCATE or DEALLOCATE statement 18causes the stat-variable to become defined with a value of zero. 19If an error condition occurs during the execution of the ALLOCATE or DEALLOCATE statement, the 20stat-variable becomes defined with a processor-dependent positive integer value and each allocate-object 21will have a processor-dependent status: 22 · each allocate-object that was successfully allocated shall have an allocation status of allocated or 23 a pointer association status of associated; 24 · each allocate-object that was successfully deallocated shall have an allocation status of unallocated 25 or a pointer association status of disassociated; 26 · each allocate-object that was not successfully allocated or deallocated shall retain its previous 27 allocation status or pointer association status. NOTE 6.26 The status of objects that were not successfully allocated or deallocated can be individually checked with the ALLOCATED or ASSOCIATED intrinsic functions. 6.3.5 ERRMSG= specifier 28 29errmsg-variable shall not be allocated or deallocated within the ALLOCATE or DEALLOCATE state- 30ment in which it appears; nor shall it depend on the value, bounds, deferred type parameters, allocation 31status, or association status of any allocate-object in that statement. 32If an error condition occurs during execution of an ALLOCATE or DEALLOCATE statement, the 33processor shall assign an explanatory message to errmsg-variable. If no such condition occurs, the 34processor shall not change the value of errmsg-variable. 132 2006/01/05 WORKING DRAFT J3/07-007 7 Expressions and assignment 1 7.1 Expressions 2 37.1.1 General 4An expression represents either a data reference or a computation, and its value is either a scalar or 5an array. An expression is formed from operands, operators, and parentheses. 6An operand is either a scalar or an array. An operation is either intrinsic (7.1.5) or defined (7.1.6). More 7complicated expressions can be formed using operands which are themselves expressions. 8Evaluation of an expression produces a value, which has a type, type parameters (if appropriate), and a shape (7.1.9). The co-rank of an expression that is not a variable is zero. 9 7.1.2 Form of an expression 10 117.1.2.1 Expression categories 12An expression is defined in terms of several categories: primary, level-1 expression, level-2 expression, 13level-3 expression, level-4 expression, and level-5 expression. 14These categories are related to the different operator precedence levels and, in general, are defined in 15terms of other categories. The simplest form of each expression category is a primary. 167.1.2.2 Primary 17R701 primary is constant 18 or designator 19 or array-constructor 20 or structure-constructor 21 or function-reference 22 or type-param-inquiry 23 or type-param-name or ( expr ) 24 C701 (R701) The type-param-name shall be the name of a type parameter. 25 C702 (R701) The designator shall not be a whole assumed-size array. 26 NOTE 7.1 Examples of a primary are: Example Syntactic class 1.0 constant 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' (I:I) designator [ 1.0, 2.0 ] array-constructor PERSON (12, 'Jones') structure-constructor F (X, Y) function-reference X%KIND type-param-inquiry 133 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 7.1 (cont.) KIND type-param-name (S + T) (expr) 17.1.2.3 Level-1 expressions 2Defined unary operators have the highest operator precedence (Table 7.2). Level-1 expressions are 3primaries optionally operated on by defined unary operators: R702 level-1-expr is [ defined-unary-op ] primary 4 R703 defined-unary-op is . letter [ letter ] ... . 5 6C703 (R703) A defined-unary-op shall not contain more than 63 letters and shall not be the same as 7 any intrinsic-operator or logical-literal-constant. NOTE 7.2 Simple examples of a level-1 expression are: Example Syntactic class A primary (R701) .INVERSE. B level-1-expr (R702) A more complicated example of a level-1 expression is: .INVERSE. (A + B) 87.1.2.4 Level-2 expressions 9Level-2 expressions are level-1 expressions optionally involving the numeric operators power-op, mult-op, 10and add-op. R704 mult-operand is level-1-expr [ power-op mult-operand ] 11 R705 add-operand is [ add-operand mult-op ] mult-operand 12 R706 level-2-expr is [ [ level-2-expr ] add-op ] add-operand 13 14R707 power-op is ** 15R708 mult-op is * or / 16 17R709 add-op is + 18 or ­ NOTE 7.3 Simple examples of a level-2 expression are: Example Syntactic class Remarks A level-1-expr A is a primary. (R702) B ** C mult-operand B is a level-1-expr, ** is a power-op, and C is a mult-operand. (R704) D * E add-operand D is an add-operand, * is a mult-op, and E is a mult-operand. (R705) 134 2006/01/05 WORKING DRAFT J3/07-007 NOTE 7.3 (cont.) +1 level-2-expr + is an add-op and 1 is an add-operand. (R706) F - I level-2-expr F is a level-2-expr, ­ is an add-op, and I is an add-operand. (R706) A more complicated example of a level-2 expression is: - A + D * E + B ** C 17.1.2.5 Level-3 expressions 2Level-3 expressions are level-2 expressions optionally involving the character operator and bits concate- 3nation operator concat-op. R710 level-3-expr is [ level-3-expr concat-op ] level-2-expr 4 R711 concat-op is // 5 NOTE 7.4 Simple examples of a level-3 expression are: Example Syntactic class A level-2-expr (R706) B // C level-3-expr (R710) A more complicated example of a level-3 expression is: X // Y // 'ABCD' 67.1.2.6 Level-4 expressions 7Level-4 expressions are level-3 expressions optionally involving the relational operators rel-op. R712 level-4-expr is [ level-3-expr rel-op ] level-3-expr 8 9R713 rel-op is .EQ. 10 or .NE. 11 or .LT. 12 or .LE. 13 or .GT. 14 or .GE. 15 or == 16 or /= 17 or < 18 or <= 19 or > 20 or >= NOTE 7.5 Simple examples of a level-4 expression are: 135 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 7.5 (cont.) Example Syntactic class A level-3-expr (R710) B == C level-4-expr (R712) D < E level-4-expr (R712) A more complicated example of a level-4 expression is: (A + B) /= C 17.1.2.7 Level-5 expressions 2Level-5 expressions are level-4 expressions optionally involving the logical and bits operators not-op, 3and-op, or-op, and equiv-op. R714 and-operand is [ not-op ] level-4-expr 4 R715 or-operand is [ or-operand and-op ] and-operand 5 R716 equiv-operand is [ equiv-operand or-op ] or-operand 6 R717 level-5-expr is [ level-5-expr equiv-op ] equiv-operand 7 8R718 not-op is .NOT. 9R719 and-op is .AND. 10R720 or-op is .OR. 11R721 equiv-op is .EQV. 12 or .NEQV. 13 or .XOR. NOTE 7.6 Simple examples of a level-5 expression are: Example Syntactic class A level-4-expr (R712) .NOT. B and-operand (R714) C .AND. D or-operand (R715) E .OR. F equiv-operand (R716) G .EQV. H level-5-expr (R717) S .NEQV. T level-5-expr (R717) A more complicated example of a level-5 expression is: A .AND. B .EQV. .NOT. C 147.1.2.8 General form of an expression 15Expressions are level-5 expressions optionally involving defined binary operators. Defined binary oper- ators have the lowest operator precedence (Table 7.2). 16 R722 expr is [ expr defined-binary-op ] level-5-expr 17 R723 defined-binary-op is . letter [ letter ] ... . 18 136 2006/01/05 WORKING DRAFT J3/07-007 1C704 (R723) A defined-binary-op shall not contain more than 63 letters and shall not be the same as 2 any intrinsic-operator or logical-literal-constant. NOTE 7.7 Simple examples of an expression are: Example Syntactic class A level-5-expr (R717) B.UNION.C expr (R722) More complicated examples of an expression are: (B .INTERSECT. C) .UNION. (X - Y) A + B == C * D .INVERSE. (A + B) A + B .AND. C * D E // G == H (1:10) 7.1.3 Precedence of operators 3 4There is a precedence among the intrinsic and extension operations corresponding to the form of expres- 5sions specified in 7.1.2, which determines the order in which the operands are combined unless the order 6is changed by the use of parentheses. This precedence order is summarized in Table 7.2. Table 7.2: Categories of operations and relative precedence Category of operation Operators Precedence Extension defined-unary-op Highest Numeric ** . Numeric *, / . Numeric unary +, ­ . Numeric binary +, ­ . Character // . Relational .EQ., .NE., .LT., .LE., .GT., .GE., ==, /=, <, <=, >, >= . Logical, Bits .NOT. . Logical, Bits .AND. . Logical, Bits .OR. . Logical, Bits .EQV., .NEQV., .XOR. . Extension defined-binary-op Lowest 7The precedence of a defined operation is that of its operator. NOTE 7.8 For example, in the expression -A ** 2 the exponentiation operator (**) has precedence over the negation operator (­); therefore, the operands of the exponentiation operator are combined to form an expression that is used as the operand of the negation operator. The interpretation of the above expression is the same as the interpretation of the expression - (A ** 2) 137 J3/07-007 WORKING DRAFT 2006/01/05 1The general form of an expression (7.1.2) also establishes a precedence among operators in the same 2syntactic class. This precedence determines the order in which the operands are to be combined in 3determining the interpretation of the expression unless the order is changed by the use of parentheses. NOTE 7.9 In interpreting a level-2-expr containing two or more binary operators + or ­, each operand (add- operand) is combined from left to right. Similarly, the same left-to-right interpretation for a mult- operand in add-operand, as well as for other kinds of expressions, is a consequence of the general form. However, for interpreting a mult-operand expression when two or more exponentiation operators ** combine level-1-expr operands, each level-1-expr is combined from right to left. For example, the expressions 2.1 + 3.4 + 4.9 2.1 * 3.4 * 4.9 2.1 / 3.4 / 4.9 2 ** 3 ** 4 'AB' // 'CD' // 'EF' have the same interpretations as the expressions (2.1 + 3.4) + 4.9 (2.1 * 3.4) * 4.9 (2.1 / 3.4) / 4.9 2 ** (3 ** 4) ('AB' // 'CD') // 'EF' As a consequence of the general form (7.1.2), only the first add-operand of a level-2-expr may be preceded by the identity (+) or negation (­) operator. These formation rules do not permit expressions containing two consecutive numeric operators, such as A ** ­B or A + ­B. However, expressions such as A ** (­B) and A + (­B) are permitted. The rules do allow a binary operator or an intrinsic unary operator to be followed by a defined unary operator, such as: A * .INVERSE. B - .INVERSE. (B) As another example, in the expression A .OR. B .AND. C the general form implies a higher precedence for the .AND. operator than for the .OR. opera- tor; therefore, the interpretation of the above expression is the same as the interpretation of the expression A .OR. (B .AND. C) NOTE 7.10 An expression may contain more than one category of operator. The logical expression L .OR. A + B >= C where A, B, and C are of type real, and L is of type logical, contains a numeric operator, a relational operator, and a logical operator. This expression would be interpreted the same as the expression 138 2006/01/05 WORKING DRAFT J3/07-007 NOTE 7.10 (cont.) L .OR. ((A + B) >= C) NOTE 7.11 If (1) The operator ** is extended to type logical, (2) The operator .STARSTAR. is defined to duplicate the function of ** on type real, (3) .MINUS. is defined to duplicate the unary operator ­, and (4) L1 and L2 are type logical and X and Y are type real, then in precedence: L1 ** L2 is higher than X * Y; X * Y is higher than X .STARSTAR. Y; and .MINUS. X is higher than ­X. 7.1.4 Evaluation of operations 1 2An intrinsic operation requires the values of its operands. 3The evaluation of a function reference shall neither affect nor be affected by the evaluation of any other 4entity within the statement. If a function reference causes definition or undefinition of an actual argument 5of the function, that argument or any associated entities shall not appear elsewhere in the same statement. 6However, execution of a function reference in the logical expression in an IF statement (8.1.8.4), the mask 7expression in a WHERE statement (7.2.3.1), or the subscripts and strides in a FORALL statement (7.2.4) 8is permitted to define variables in the statement that is conditionally executed. NOTE 7.12 For example, the statements A (I) = F (I) Y = G (X) + X are prohibited if the reference to F defines or undefines I or the reference to G defines or undefines X. However, in the statements IF (F (X)) A = X WHERE (G (X)) B = X F or G may define X. 9The appearance of an array constructor requires the evaluation of each scalar-int-expr of the ac-implied- 10do-control in any ac-implied-do it may contain. 11When an elemental binary operation is applied to a scalar and an array or to two arrays of the same 12shape, the operation is performed element-by-element on corresponding array elements of the array 13operands. NOTE 7.13 For example, the array expression A + B 139 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 7.13 (cont.) produces an array of the same shape as A and B. The individual array elements of the result have the values of the first element of A added to the first element of B, the second element of A added to the second element of B, etc. 1When an elemental unary operator operates on an array operand, the operation is performed element- 2by-element, and the result is the same shape as the operand. NOTE 7.14 If an elemental operation is intrinsically pure or is implemented by a pure elemental function (12.8), the element operations may be performed simultaneously or in any order. 7.1.5 Intrinsic operations 3 47.1.5.1 Definitions 5An intrinsic operation is either an intrinsic unary operation or an intrinsic binary operation. An 6intrinsic unary operation is an operation of the form intrinsic-operator x2 where x2 is of an intrinsic type (4.4) listed in Table 7.3 for the unary intrinsic operator. 7 8An intrinsic binary operation is an operation of the form x1 intrinsic-operator x2 where x1 and 9x2 are of the intrinsic types (4.4) listed in Table 7.3 for the binary intrinsic operator and are in shape conformance (7.1.10). 10 11A numeric intrinsic operation is an intrinsic operation for which the intrinsic-operator is a numeric 12operator (+, ­, *, /, or **). A numeric intrinsic operator is the operator in a numeric intrinsic 13operation. 14The character intrinsic operation is the intrinsic operation for which the intrinsic-operator is (//) 15and both operands are of type character. The operands shall have the same kind type parameter. The 16character intrinsic operator is the operator in a character intrinsic operation. 17A logical intrinsic operation is an intrinsic operation for which the intrinsic-operator is .AND., .OR., 18.XOR., .NOT., .EQV., or .NEQV. and both operands are of type logical. A logical intrinsic operator 19is the operator in a logical intrinsic operation. 20A bits intrinsic operation is an intrinsic operation for which the intrinsic-operator is //, .AND., .OR., 21.XOR., .NOT., .EQV., or .NEQV. and at least one operand is of type bits. A bits intrinsic operator 22is the operator in a bits intrinsic operation. 23A relational intrinsic operator is an intrinsic-operator that is .EQ., .NE., .GT., .GE., .LT., .LE., 24==, /=, >, >=, <, or <=. A relational intrinsic operation is an intrinsic operation for which the 25intrinsic-operator is a relational intrinsic operator. A numeric relational intrinsic operation is a 26relational intrinsic operation for which both operands are of numeric type. A character relational 27intrinsic operation is a relational intrinsic operation for which both operands are of type character. 28The kind type parameters of the operands of a character relational intrinsic operation shall be the same. 29A bits relational intrinsic operation is a relational intrinsic operation for which at least one of the 30operands is of type bits. 31The interpretations defined in subclause 7.1.5 apply to both scalars and arrays; the interpretation for 32arrays is obtained by applying the interpretation for scalars element by element. 140 2006/01/05 WORKING DRAFT J3/07-007 NOTE 7.15 For example, if X is of type real, J is of type integer, and INT is the real-to-integer intrinsic conversion function, the expression INT (X + J) is an integer expression and X + J is a real expression. Table 7.3: Type of operands and results for intrinsic operators Intrinsic operator Type of Type of Type of op x1 x2 [x1] op x2 Unary +, ­ I, R, Z I, R, Z I I, R, Z I, R, Z Binary +, ­, *, /, ** R I, R, Z R, R, Z Z I, R, Z Z, Z, Z // C C C B B B I I, R, Z, B L, L, L, L .EQ., .NE., R I, R, Z, B L, L, L, L ==, /= Z I, R, Z, B L, L, L, L B I, R, Z, B L, L, L, L C C L I I, R, B L, L, L .GT., .GE., .LT., .LE. R I, R, B L, L, L >, >=, <, <= B I, R, B L, L, L C C L .NOT. L, B L, B L L L .AND., .OR., .EQV., .NEQV., .XOR. B B,I B I B B Note: The symbols I, R, Z, C, L, and B stand for the types integer, real, complex, character, logical, and bits, respectively. Where more than one type for x2 is given, the type of the result of the operation is given in the same relative position in the next column. 141 J3/07-007 WORKING DRAFT 2006/01/05 J3 internal note Unresolved Technical Issue 104 Real-bits mixed-mode comparisons considered harmful. The feature of intrinsic mixed-mode comparisions between BITS and REAL is, in my opinion, a serious misfeature. I am speaking particularly about .LT., .LE., .GT., and .GE.. I understand perfectly well that BITS work like unsigned integers for comparisons between them- selves. I understand perfectly well that it is very convenient to do mixed-mode comparisons with BITS and INTEGER, and that when doing so, converting to "unsigned" is a reasonable thing to do... though see next paragraph. There are two schools of thought on this (what to convert mixed-mode operations between un- signed and signed integer to), "value-preserving" and "unsigned-preserving". Interestingly enough the BITS proposal picked "unsigned-preserving" which is what most (not all) K&R C compilers did, and some K&R C compilers and the C standard picked "value-preserving". This decision might profitably bear further consideration, but in any case is not the topic of this UTI! What BITS has also added is mixed-mode REAL and BITS comparison. Here, bits don't act like unsigned integers at all! In fact it is fair to say this operation doesn't have any coherent mathematical theory behind it, being totally processor-dependent on the internal representation of said REALs. Having "IF (X<1)" doing a totally different operation from "IF (X<1.)" is IMO an extraordinarily poor design, and likely to be error-prone to use in practice. It is also unnecessary; the three people in the world who actually want to sort a mixture of REALs and BITSs can do "IF (X, >=, ==, and /=. The permitted types for 7operands of the relational intrinsic operators are specified in 7.1.5.1. 8The operators <, <=, >, >=, ==, and /= always have the same interpretations as the operators .LT., 9.LE., .GT., .GE., .EQ., and .NE., respectively. 10If both operands of a bits relational operation do not have the same kind type parameter, the operand 11with the smaller kind type parameter is converted to the same kind as the other operand. If one operand 12of a bits relational operation is not of type bits, it is converted to type bits with the same kind type 13parameter as the other operand. Any conversion takes place before the operation is evaluated. NOTE 7.26 As shown in Table 7.3, a relational intrinsic operator cannot be used to compare the value of an expression of a numeric type with one of type character or logical. Also, two operands of type logical cannot be compared, a complex operand may be compared with another numeric operand only when the operator is .EQ., .NE., ==, or /=, and two character operands cannot be compared unless they have the same kind type parameter value. 14Evaluation of a relational intrinsic operation produces a result of type default logical. 15The interpretation of the relational intrinsic operators is given in Table 7.11, where x1 denotes the 16operand to the left of the operator and x2 denotes the operand to the right of the operator. Table 7.11: Interpretation of the relational intrinsic operators Operator Representing Use of operator Interpretation .LT. Less than x1 .LT. x2 x1 less than x2 < Less than x1 < x2 x1 less than x2 .LE. Less than or equal to x1 .LE. x2 x1 less than or equal to x2 <= Less than or equal to x1 <= x2 x1 less than or equal to x2 .GT. Greater than x1 .GT. x2 x1 greater than x2 > Greater than x1 > x2 x1 greater than x2 .GE. Greater than or equal to x1 .GE. x2 x1 greater than or equal to x2 >= Greater than or equal to x1 >= x2 x1 greater than or equal to x2 .EQ. Equal to x1 .EQ. x2 x1 equal to x2 == Equal to x1 == x2 x1 equal to x2 .NE. Not equal to x1 .NE. x2 x1 not equal to x2 /= Not equal to x1 /= x2 x1 not equal to x2 17A numeric relational intrinsic operation is interpreted as having the logical value true if and only if the 18values of the operands satisfy the relation specified by the operator. In the numeric relational operation 148 2006/01/05 WORKING DRAFT J3/07-007 1 x1 rel-op x2 2 3if the types or kind type parameters of x1 and x2 differ, their values are converted to the type and kind 4type parameter of the expression x1 + x2 before evaluation. 5A character relational intrinsic operation is interpreted as having the logical value true if and only if the 6values of the operands satisfy the relation specified by the operator. 7For a character relational intrinsic operation, the operands are compared one character at a time in 8order, beginning with the first character of each character operand. If the operands are of unequal 9length, the shorter operand is treated as if it were extended on the right with blanks to the length of 10the longer operand. If both x1 and x2 are of zero length, x1 is equal to x2; if every character of x1 is 11the same as the character in the corresponding position in x2, x1 is equal to x2. Otherwise, at the first 12position where the character operands differ, the character operand x1 is considered to be less than x2 13if the character value of x1 at this position precedes the value of x2 in the collating sequence (4.4.5.4); 14x1 is greater than x2 if the character value of x1 at this position follows the value of x2 in the collating 15sequence. NOTE 7.27 The collating sequence depends partially on the processor; however, the result of the use of the operators .EQ., .NE., ==, and /= does not depend on the collating sequence. For nondefault character types, the blank padding character is processor dependent. 16A bits relational intrinsic operation is interpreted as having the logical value true if and only if the values 17of the operands satisfy the relation specified by the operator. 18For a bits relational intrinsic operation, x1 and x2 are equal if and only if each corresponding bit has 19the same value. If x1 and x2 are not equal, and the leftmost unequal corresponding bit of x1 is 1 and 20x2 is 0 then x1 is greater than x2; otherwise x1 is less than x2. 217.1.5.6.2 Evaluation of relational intrinsic operations 22Once the interpretation of a relational intrinsic operation is established, the processor may evaluate 23any other expression that is relationally equivalent, provided that the integrity of parentheses in any 24expression is not violated. NOTE 7.28 For example, the processor may choose to evaluate the expression I > J where I and J are integer variables, as J - I < 0 25Two relational intrinsic operations are relationally equivalent if their logical values are equal for all 26possible values of their primaries. 7.1.6 Defined operations 27 149 J3/07-007 WORKING DRAFT 2006/01/05 17.1.6.1 Definitions 2A defined operation is either a defined unary operation or a defined binary operation. A defined 3unary operation is an operation that has the form defined-unary-op x2 or intrinsic-operator x2 and that is defined by a function and a generic interface (4.5.2, 12.4.3.4). 4 5A function defines the unary operation op x2 if 6 (1) the function is specified with a FUNCTION (12.6.2.2) or ENTRY (12.6.2.6) statement that 7 specifies one dummy argument d2, (2) either 8 9 (a) a generic interface (12.4.3.2) provides the function with a generic-spec of OPERA- TOR (op), or 10 11 (b) there is a generic binding (4.5.2) in the declared type of x2 with a generic-spec of 12 OPERATOR (op) and there is a corresponding binding to the function in the dynamic 13 type of x2, (3) 14 the type of d2 is compatible with the dynamic type of x2, (4) 15 the type parameters, if any, of d2 match the corresponding type parameters of x2, and (5) either 16 (a) 17 the rank of x2 matches that of d2 or (b) the function is elemental and there is no other function that defines the operation. 18 19If d2 is an array, the shape of x2 shall match the shape of d2. 20A defined binary operation is an operation that has the form x1 defined-binary-op x2 or x1 intrinsic- 21operator x2 and that is defined by a function and a generic interface. 22A function defines the binary operation x1 op x2 if 23 (1) the function is specified with a FUNCTION (12.6.2.2) or ENTRY (12.6.2.6) statement that 24 specifies two dummy arguments, d1 and d2, (2) either 25 26 (a) a generic interface (12.4.3.2) provides the function with a generic-spec of OPERA- TOR (op), or 27 28 (b) there is a generic binding (4.5.2) in the declared type of x1 or x2 with a generic- 29 spec of OPERATOR (op) and there is a corresponding binding to the function in the 30 dynamic type of x1 or x2, respectively, (3) 31 the types of d1 and d2 are compatible with the dynamic types of x1 and x2, respectively, 32 (4) the type parameters, if any, of d1 and d2 match the corresponding type parameters of x1 33 and x2, respectively, and (5) either 34 (a) 35 the ranks of x1 and x2 match those of d1 and d2 or 36 (b) the function is elemental, x1 and x2 are conformable, and there is no other function 37 that defines the operation. 38If d1 or d2 is an array, the shapes of x1 and x2 shall match the shapes of d1 and d2, respectively. NOTE 7.29 An intrinsic operator may be used as the operator in a defined operation. In such a case, the generic properties of the operator are extended. 150 2006/01/05 WORKING DRAFT J3/07-007 1An extension operation is a defined operation in which the operator is of the form defined-unary-op 2or defined-binary-op. Such an operator is called an extension operator. The operator used in an 3extension operation may be such that a generic interface for the operator may specify more than one 4function. A defined elemental operation is a defined operation for which the function is elemental (12.8). 5 67.1.6.2 Interpretation of a defined operation 7The interpretation of a defined operation is provided by the function that defines the operation. 8The operators <, <=, >, >=, ==, and /= always have the same interpretations as the operators .LT., 9.LE., .GT., .GE., .EQ., and .NE., respectively. 107.1.6.3 Evaluation of a defined operation 11Once the interpretation of a defined operation is established, the processor may evaluate any other 12expression that is equivalent, provided that the integrity of parentheses is not violated. 13Two expressions of derived type are equivalent if their values are equal for all possible values of their 14primaries. 7.1.7 Evaluation of operands 15 16It is not necessary for a processor to evaluate all of the operands of an expression, or to evaluate entirely 17each operand, if the value of the expression can be determined otherwise. NOTE 7.30 This principle is most often applicable to logical expressions, zero-sized arrays, and zero-length strings, but it applies to all expressions. For example, in evaluating the expression X > Y .OR. L (Z) where X, Y, and Z are real and L is a function of type logical, the function reference L (Z) need not be evaluated if X is greater than Y. Similarly, in the array expression W (Z) + A where A is of size zero and W is a function, the function reference W (Z) need not be evaluated. 18If a statement contains a function reference in a part of an expression that need not be evaluated, all 19entities that would have become defined in the execution of that reference become undefined at the 20completion of evaluation of the expression containing the function reference. NOTE 7.31 In the examples in Note 7.30, if L or W defines its argument, evaluation of the expressions under the specified conditions causes Z to become undefined, no matter whether or not L(Z) or W(Z) is evaluated. 21If a statement contains a function reference in a part of an expression that need not be evaluated, no 22invocation of that function in that part of the expression shall execute an image control statement other 23than CRITICAL or END CRITICAL. 151 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 7.32 This restriction is intended to avoid inadvertant deadlock caused by optimization. 7.1.8 Integrity of parentheses 1 2The rules for evaluation specified in subclause 7.1.5 state certain conditions under which a processor 3may evaluate an expression that is different from the one specified by applying the rules given in 7.1.2 4and rules for interpretation specified in subclause 7.1.5. However, any expression in parentheses shall be 5treated as a data entity. NOTE 7.33 For example, in evaluating the expression A + (B ­ C) where A, B, and C are of numeric types, the difference of B and C shall be evaluated before the addition operation is performed; the processor shall not evaluate the mathematically equivalent expression (A + B) ­ C. 7.1.9 Type, type parameters, and shape of an expression 6 7The type, type parameters, and shape of an expression depend on the operators and on the types, type 8parameters, and shapes of the primaries used in the expression, and are determined recursively from 9the syntactic form of the expression. The type of an expression is one of the intrinsic types (4.4) or a derived type (4.5). 10 11If an expression is a polymorphic primary or defined operation, the type parameters and the declared and 12dynamic types of the expression are the same as those of the primary or defined operation. Otherwise 13the type parameters and dynamic type of the expression are the same as its declared type and type 14parameters; they are referred to simply as the type and type parameters of the expression. 15R724 logical-expr is expr C705 (R724) logical-expr shall be of type logical. 16 17R725 char-expr is expr C706 (R725) char-expr shall be of type character. 18 19R726 default-char-expr is expr C707 (R726) default-char-expr shall be of type default character. 20 21R727 int-expr is expr C708 (R727) int-expr shall be of type integer. 22 23R728 numeric-expr is expr C709 (R728) numeric-expr shall be of type integer, real, or complex. 24 257.1.9.1 Type, type parameters, and shape of a primary 26The type, type parameters, and shape of a primary are determined according to whether the primary is a 27constant, variable, array constructor, structure constructor, function reference, type parameter inquiry, 28type parameter name, or parenthesized expression. If a primary is a constant, its type, type parameters, 29and shape are those of the constant. If it is a structure constructor, it is scalar and its type and type 30parameters are as described in 4.5.10. If it is an array constructor, its type, type parameters, and shape 31are as described in 4.7. If it is a variable or function reference, its type, type parameters, and shape are 32those of the variable (5.2, 5.3) or the function reference (12.5.3), respectively. If the function reference 152 2006/01/05 WORKING DRAFT J3/07-007 1is generic (12.4.3.2, 13.5) then its type, type parameters, and shape are those of the specific function 2referenced, which is determined by the types, type parameters, and ranks of its actual arguments as 3specified in 12.5.5.2. If it is a type parameter inquiry or type parameter name, it is a scalar integer with 4the kind of the type parameter. 5If a primary is a parenthesized expression, its type, type parameters, and shape are those of the expres- 6sion. 7The associated target object is referenced if a pointer appears as (1) a primary in an intrinsic or defined operation, 8 (2) the expr of a parenthesized primary, or 9 (3) the only primary on the right-hand side of an intrinsic assignment statement. 10 11The type, type parameters, and shape of the primary are those of the current target. If the pointer is 12not associated with a target, it may appear as a primary only as an actual argument in a reference to 13a procedure whose corresponding dummy argument is declared to be a pointer, or as the target in a 14pointer assignment statement. 15A disassociated array pointer or an unallocated allocatable array has no shape but does have rank. 16The type, type parameters, and rank of the result of the NULL intrinsic function depend on context (13.7.131). 17 187.1.9.2 Type, type parameters, and shape of the result of an operation 19The type of the result of an intrinsic operation [x1] op x2 is specified by Table 7.3. The shape of the 20result of an intrinsic operation is the shape of x2 if op is unary or if x1 is scalar, and is the shape of x1 21otherwise. 22The type, type parameters, and shape of the result of a defined operation [x1] op x2 are specified by the function defining the operation (7.1.6). 23 24An expression of an intrinsic type has a kind type parameter. An expression of type character also has 25a character length parameter. 26The type parameters of the result of an intrinsic operation are as follows. 27 (1) For an expression x1 // x2 where // is the character intrinsic operator and x1 and x2 are 28 of type character, the character length parameter is the sum of the lengths of the operands 29 and the kind type parameter is the kind type parameter of x1, which shall be the same as 30 the kind type parameter of x2. 31 (2) For an expression op x2 where op is an intrinsic unary operator and x2 is of type integer, 32 real, complex, logical, or bits, the kind type parameter of the expression is that of the 33 operand. 34 (3) For an expression x1 op x2 where op is a numeric intrinsic binary operator with one operand 35 of type integer and the other of type real or complex, the kind type parameter of the 36 expression is that of the real or complex operand. 37 (4) For an expression x1 op x2 where op is a numeric intrinsic binary operator with both 38 operands of the same type and kind type parameters, or with one real and one complex 39 with the same kind type parameters, the kind type parameter of the expression is identical 40 to that of each operand. In the case where both operands are integer with different kind type 41 parameters, the kind type parameter of the expression is that of the operand with the greater 42 decimal exponent range if the decimal exponent ranges are different; if the decimal exponent 43 ranges are the same, the kind type parameter of the expression is processor dependent, but 44 it is the same as that of one of the operands. In the case where both operands are any 45 of type real or complex with different kind type parameters, the kind type parameter of 153 J3/07-007 WORKING DRAFT 2006/01/05 1 the expression is that of the operand with the greater decimal precision if the decimal 2 precisions are different; if the decimal precisions are the same, the kind type parameter of 3 the expression is processor dependent, but it is the same as that of one of the operands. 4 (5) For an expression x1 op x2 where op is a logical intrinsic binary operator with both operands 5 of the same kind type parameter, the kind type parameter of the expression is identical to 6 that of each operand. In the case where both operands are of type logical with different 7 kind type parameters, the kind type parameter of the expression is processor dependent, 8 but it is the same as that of one of the operands. 9 (6) For an expression x1 // x2 where both operands are of type bits, the kind type parameter 10 of the expression is the sum of the kind type parameters of the operands. 11 (7) For an expression x1 op x2 where op is a bits intrinsic binary operator other than //, the 12 kind type parameter of the expression is the maximum of the kind type parameters of x1 13 and x2. 14 (8) For an expression x1 op x2 where op is a relational intrinsic operator, the expression has 15 the default logical kind type parameter. 16C710 The kind type parameter of the result of a bits concatenation operation expression shall be a 17 bits kind type parameter value supported by the processor. 7.1.10 Conformability rules for elemental operations 18 19An elemental operation is an intrinsic operation or a defined elemental operation. Two entities are 20in shape conformance if both are arrays of the same shape, or one or both are scalars. 21For all elemental binary operations, the two operands shall be in shape conformance. In the case where 22one is a scalar and the other an array, the scalar is treated as if it were an array of the same shape as 23the array operand with every element, if any, of the array equal to the value of the scalar. 7.1.11 Specification expression 24 25A specification expression is an expression with limitations that make it suitable for use in speci- 26fications such as length type parameters (C404) and array bounds (R513, R514). A specification-expr 27shall be an initialization expression unless it is in an interface body (12.4.3.2), the specification part of a subprogram or BLOCK construct, or the declaration-type-spec of a FUNCTION statement (12.6.2.2). 28 29R729 specification-expr is scalar-int-expr C711 (R729) The scalar-int-expr shall be a restricted expression. 30 31A restricted expression is an expression in which each operation is intrinsic and each primary is (1) a constant or subobject of a constant, 32 33 (2) an object designator with a base object that is a dummy argument that has neither the OPTIONAL nor the INTENT (OUT) attribute, 34 (3) an object designator with a base object that is in a common block, 35 36 (4) an object designator with a base object that is made accessible by use association or host 37 association, 38 (5) an object designator with a base object that is a local variable of the procedure containing 39 the BLOCK construct in which the restricted expression appears, 40 (6) an object designator with a base object that is a local variable of an outer BLOCK construct 41 containing the BLOCK construct in which the restricted expression appears, 42 (7) an array constructor where each element and each scalar-int-expr of each ac-implied-do- 43 control is a restricted expression, (8) a structure constructor where each component is a restricted expression, 44 154 2006/01/05 WORKING DRAFT J3/07-007 (9) a specification inquiry where each designator or function argument is 1 (a) a restricted expression or 2 (b) a variable whose properties inquired about are not 3 (i) dependent on the upper bound of the last dimension of an assumed-size array, 4 (ii) deferred, or 5 (iii) defined by an expression that is not a restricted expression, 6 7 (10) a reference to any other standard intrinsic function where each argument is a restricted 8 expression, (11) a reference to a specification function where each argument is a restricted expression, 9 (12) a type parameter of the derived type being defined, 10 11 (13) an ac-do-variable within an array constructor where each scalar-int-expr of the correspond- 12 ing ac-implied-do-control is a restricted expression, or (14) a restricted expression enclosed in parentheses, 13 14where each subscript, section subscript, substring starting point, substring ending point, and type pa- 15rameter value is a restricted expression, and where any final subroutine that is invoked is pure. 16A specification inquiry is a reference to (1) an array inquiry function (13.5.7), 17 (2) the bit inquiry function BIT SIZE, 18 (3) the character inquiry function LEN, 19 (4) the kind inquiry function KIND, 20 (5) the bits kind inquiry function BITS KIND, 21 (6) the character inquiry function NEW LINE, 22 (7) a numeric inquiry function (13.5.6), 23 (8) a type parameter inquiry (6.1.4), 24 (9) an IEEE inquiry function (14.9.1), 25 (10) the function C SIZEOF from the intrinsic module ISO C BINDING (15.2.3.6) , or 26 27 (11) the COMPILER VERSION or COMPILER OPTIONS inquiry functions from the intrinsic module ISO FORTRAN ENV (13.8.2.3, 13.8.2.4). 28 29A function is a specification function if it is a pure function, is not a standard intrinsic function, is 30not an internal function, is not a statement function, and does not have a dummy procedure argument. 31Evaluation of a specification expression shall not directly or indirectly cause a procedure defined by the 32subprogram in which it appears to be invoked. NOTE 7.34 Specification functions are nonintrinsic functions that may be used in specification expressions to determine the attributes of data objects. The requirement that they be pure ensures that they cannot have side effects that could affect other objects being declared in the same specification-part. The requirement that they not be internal ensures that they cannot inquire, via host association, about other objects being declared in the same specification-part. The prohibition against recursion avoids the creation of a new instance of a procedure while construction of one is in progress. 33A variable in a specification expression shall have its type and type parameters, if any, specified by a 34previous declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, 35or by host or use association. If a variable in a specification expression is typed by the implicit typing 36rules, its appearance in any subsequent type declaration statement shall confirm the implied type and 37type parameters. 155 J3/07-007 WORKING DRAFT 2006/01/05 1If a specification expression includes a specification inquiry that depends on a type parameter or an 2array bound of an entity specified in the same specification-part, the type parameter or array bound 3shall be specified in a prior specification of the specification-part. The prior specification may be to the 4left of the specification inquiry in the same statement, but shall not be within the same entity-decl. If a 5specification expression includes a reference to the value of an element of an array specified in the same 6specification-part, the array shall be completely specified in prior declarations. 7If a specification expression in a module or submodule includes a reference to a generic entity, that 8generic entity shall have no specific procedures defined in the module or submodule subsequent to the 9specification expression. NOTE 7.35 The following are examples of specification expressions: LBOUND (B, 1) + 5 ! B is an assumed-shape dummy array M + LEN (C) ! M and C are dummy arguments 2 * PRECISION (A) ! A is a real variable made accessible ! by a USE statement 7.1.12 Initialization expression 10 11An initialization expression is an expression with limitations that make it suitable for use as a kind 12type parameter, initializer, or named constant. It is an expression in which each operation is intrinsic, 13and each primary is (1) a constant or subobject of a constant, 14 15 (2) an array constructor where each element and each scalar-int-expr of each ac-implied-do- 16 control is an initialization expression, (3) a structure constructor where each component-spec corresponding to 17 (a) an allocatable component is a reference to the intrinsic function NULL, 18 19 (b) a pointer component is a reference to the intrinsic function NULL or an initialization 20 target, and (c) any other component is an initialization expression, 21 22 (4) a reference to an elemental standard intrinsic function, where each argument is an initial- 23 ization expression, 24 (5) a reference to a transformational standard intrinsic function other than NULL, where each 25 argument is an initialization expression, 26 (6) A reference to the transformational intrinsic function NULL that does not have an argu- 27 ment with a type parameter that is assumed or is defined by an expression that is not an 28 initialization expression, 29 (7) a reference to the transformational function IEEE SELECTED REAL KIND from the in- 30 trinsic module IEEE ARITHMETIC (14), where each argument is an initialization expres- 31 sion, (8) a specification inquiry where each designator or function argument is 32 (a) an initialization expression or 33 (b) a variable whose properties inquired about are not 34 (i) assumed, 35 (ii) deferred, or 36 (iii) defined by an expression that is not an initialization expression, 37 (9) a kind type parameter of the derived type being defined, 38 156 2006/01/05 WORKING DRAFT J3/07-007 (10) a data-i-do-variable within a data-implied-do, 1 2 (11) an ac-do-variable within an array constructor where each scalar-int-expr of the correspond- 3 ing ac-implied-do-control is an initialization expression, or (12) an initialization expression enclosed in parentheses, 4 5and where each subscript, section subscript, substring starting point, substring ending point, and type 6parameter value is an initialization expression. 7R730 initialization-expr is expr C712 (R730) initialization-expr shall be an initialization expression. 8 9R731 char-initialization-expr is char-expr C713 (R731) char-initialization-expr shall be an initialization expression. 10 11R732 int-initialization-expr is int-expr C714 (R732) int-initialization-expr shall be an initialization expression. 12 13R733 logical-initialization-expr is logical-expr C715 (R733) logical-initialization-expr shall be an initialization expression. 14 15If an initialization expression includes a specification inquiry that depends on a type parameter or an 16array bound of an entity specified in the same specification-part, the type parameter or array bound 17shall be specified in a prior specification of the specification-part. The prior specification may be to the 18left of the specification inquiry in the same statement, but shall not be within the same entity-decl. 19If an initialization expression in a module or submodule includes a reference to a generic entity, that 20generic entity shall have no specific procedures defined in the module or submodule subsequent to the 21initialization expression. NOTE 7.36 The following are examples of initialization expressions: 3 -3 + 4 'AB' 'AB' // 'CD' ('AB' // 'CD') // 'EF' SIZE (A) DIGITS (X) + 4 4.0 * atan(1.0) ceiling(number_of_decimal_digits / log10(radix(0.0))) where A is an explicit-shaped array with constant bounds and X is of type default real. 7.2 Assignment 22 7.2.1 Assignment statement 23 24A variable may be defined or redefined by execution of an assignment statement. 257.2.1.1 General form 157 J3/07-007 WORKING DRAFT 2006/01/05 1R734 assignment-stmt is variable = expr C716 (R734) The variable shall not be a whole assumed-size array. 2 NOTE 7.37 Examples of an assignment statement are: A = 3.5 + X * Y I = INT (A) 3An assignment-stmt shall meet the requirements of either a defined assignment statement or an intrinsic 4assignment statement. 57.2.1.2 Intrinsic assignment statement 6An intrinsic assignment statement is an assignment statement that is not a defined assignment statement (7.2.1.4). In an intrinsic assignment statement, 7 (1) if the variable is polymorphic it shall be allocatable, 8 9 (2) if variable is a co-indexed object, it shall not be of a type that has an allocatable ultimate 10 component, (3) if expr is an array then the variable shall also be an array, 11 12 (4) the shapes of the variable and expr shall conform unless the variable is an allocatable array 13 that has the same rank as expr and is neither a co-array nor a co-indexed object, (5) if the variable is an allocatable co-array or co-indexed object, it shall not be polymorphic, 14 15 (6) if the variable is polymorphic it shall be type compatible with expr and have the same rank; 16 otherwise the declared types of the variable and expr shall conform as specified in Table 17 7.12, 18 (7) if the variable is of derived type each kind type parameter of the variable shall have the 19 same value as the corresponding type parameter of expr, and 20 (8) if the variable is of derived type each length type parameter of the variable shall have the 21 same value as the corresponding type parameter of expr unless the variable is allocatable, 22 is not a co-array or co-indexed object, and its corresponding type parameter is deferred. 23 Table 7.12: Type conformance for the intrinsic assignment statement Type of the variable Type of expr integer integer, real, complex, bits real integer, real, complex, bits complex integer, real, complex, bits ISO 10646, ASCII, or default character ISO 10646, ASCII, or default character other character character of the same kind type parameter as the variable logical logical, bits bits integer, real, complex, bits derived type same derived type as the variable 24A numeric intrinsic assignment statement is an intrinsic assignment statement for which the vari- 25able and expr are of numeric type. A character intrinsic assignment statement is an intrinsic 26assignment statement for which the variable and expr are of type character. A logical intrinsic as- 27signment statement is an intrinsic assignment statement for which the variable and expr are of type 28logical. A bits intrinsic assignment statement is an intrinsic assignment statement for which either 29the variable or expr is of type bits. A derived-type intrinsic assignment statement is an intrinsic assignment statement for which the variable and expr are of derived type. 158 2006/01/05 WORKING DRAFT J3/07-007 1 2An array intrinsic assignment statement is an intrinsic assignment statement for which the variable is an array. The variable shall not be a many-one array section (6.2.2.2.2). 3 4If the variable is a pointer, it shall be associated with a definable target such that the type, type 5parameters, and shape of the target and expr conform. 67.2.1.3 Interpretation of intrinsic assignments 7Execution of an intrinsic assignment causes, in effect, the evaluation of the expression expr and all 8expressions within variable (7.1), the possible conversion of expr to the type and type parameters of the 9variable (Table 7.13), and the definition of the variable with the resulting value. The execution of the 10assignment shall have the same effect as if the evaluation of expr and the evaluation of all expressions 11in variable occurred before any portion of the variable is defined by the assignment. The evaluation of 12expressions within variable shall neither affect nor be affected by the evaluation of expr. No value is 13assigned to the variable if it is of type character and zero length, or is an array of size zero. 14If the variable is a pointer, the value of expr is assigned to the target of the variable. 15If the variable is an allocated allocatable variable, it is deallocated if expr is an array of different shape, 16any of the corresponding length type parameter values of the variable and expr differ, or the variable 17is polymorphic and the dynamic type of the variable and expr differ. If the variable is or becomes an 18unallocated allocatable variable, then it is allocated with each deferred type parameter equal to the 19corresponding type parameter of expr, with the shape of expr, with each lower bound equal to the 20corresponding element of LBOUND(expr), and if the variable is polymorphic, with the same dynamic 21type as expr. NOTE 7.38 For example, given the declaration CHARACTER(:),ALLOCATABLE :: NAME then after the assignment statement NAME = 'Dr. '//FIRST_NAME//' '//SURNAME NAME will have the length LEN(FIRST NAME)+LEN(SURNAME)+5, even if it had previously been unallocated, or allocated with a different length. However, for the assignment statement NAME(:) = 'Dr. '//FIRST_NAME//' '//SURNAME NAME must already be allocated at the time of the assignment; the assigned value is truncated or blank padded to the previously allocated length of NAME. 22Both variable and expr may contain references to any portion of the variable. NOTE 7.39 For example, in the character intrinsic assignment statement: STRING (2:5) = STRING (1:4) the assignment of the first character of STRING to the second character does not affect the evaluation of STRING (1:4). If the value of STRING prior to the assignment was 'ABCDEF', the 159 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 7.39 (cont.) value following the assignment is 'AABCDF'. 1If expr is a scalar and the variable is an array, the expr is treated as if it were an array of the same 2shape as the variable with every element of the array equal to the scalar value of expr. 3If the variable is an array, the assignment is performed element-by-element on corresponding array 4elements of the variable and expr. NOTE 7.40 For example, if A and B are arrays of the same shape, the array intrinsic assignment A = B assigns the corresponding elements of B to those of A; that is, the first element of B is assigned to the first element of A, the second element of B is assigned to the second element of A, etc. If C is an allocatable array of rank 1, then C = PACK(ARRAY,ARRAY>0) will cause C to contain all the positive elements of ARRAY in array element order; if C is not allocated or is allocated with the wrong size, it will be re-allocated to be of the correct size to hold the result of PACK. 5The processor may perform the element-by-element assignment in any order. NOTE 7.41 For example, the following program segment results in the values of the elements of array X being reversed: REAL X (10) ... X (1:10) = X (10:1:-1) 6For a numeric intrinsic assignment statement, the variable and expr may have different numeric types 7or different kind type parameters, in which case the value of expr is converted to the type and kind type 8parameter of the variable according to the rules of Table 7.13. Table 7.13: Numeric conversion and the assignment statement Type of the variable Value Assigned integer INT (expr, KIND = KIND (variable)) real REAL (expr, KIND = KIND (variable)) complex CMPLX (expr, KIND = KIND (variable)) Note: The functions INT, REAL, CMPLX, and KIND are the generic functions defined in 13.7. 9For a logical intrinsic assignment statement, the variable and expr may have different kind type param- 10eters, in which case the value of expr is converted to the kind type parameter of the variable. 11For a character intrinsic assignment statement, the variable and expr may have different character length 12parameters in which case the conversion of expr to the length of the variable is as follows. 160 2006/01/05 WORKING DRAFT J3/07-007 1 (1) If the length of the variable is less than that of expr, the value of expr is truncated from 2 the right until it is the same length as the variable. 3 (2) If the length of the variable is greater than that of expr, the value of expr is extended on 4 the right with blanks until it is the same length as the variable. 5If the variable and expr have different kind type parameters, each character c in expr is converted to the kind type parameter of the variable by ACHAR(IACHAR(c),KIND(variable)). 6 NOTE 7.42 For nondefault character types, the blank padding character is processor dependent. When assign- ing a character expression to a variable of a different kind, each character of the expression that is not representable in the kind of the variable is replaced by a processor-dependent character. 7For a bits intrinsic assignment statement, the variable and expr may have different types or different 8kind type parameters, in which case the value of expr is converted to the type and kind type parameter 9of the variable according to the rules of Table 7.14. Table 7.14: Bits conversion and the assignment statement Type of the variable Value Assigned integer INT (expr, KIND = KIND (variable)) real REAL (expr, KIND = KIND (variable)) complex CMPLX (expr, KIND = KIND (variable)) logical LOGICAL (expr, KIND = KIND (variable)) bits BITS (expr, KIND = KIND (variable)) Note: The functions BITS, INT, REAL, CMPLX, LOGICAL, and KIND are the generic functions defined in 13.7. NOTE 7.43 Bits assignment is not always the same as the result of the TRANSFER intrinsic, because: · bits assignment operates elementally, whereas TRANSFER does not preserve array element boundaries; · for scalars, if the source is larger TRANSFER uses those bits which occur first in memory whereas bits assignment always uses the "rightmost" bits (according to the model for bits values), independent of the endianness of the processor's memory addressing; · if the source is smaller, TRANSFER uses it for the part of the result which occurs first in memory address order and leaves the rest of the result processor-dependent, whereas bits assignment copies the source to the rightmost bits and makes the remaining bits all zero. 10A derived-type intrinsic assignment is performed as if each component of the variable were assigned 11from the corresponding component of expr using pointer assignment (7.2.2) for each pointer component, 12defined assignment for each nonpointer nonallocatable component of a type that has a type-bound defined 13assignment consistent with the component, intrinsic assignment for each other nonpointer nonallocatable 14component, and intrinsic assignment for each allocated co-array component. For unallocated co-array 15components, the corresponding component of the variable shall be unallocated. For a non-co-array 16allocatable component the following sequence of operations is applied. (1) If the component of the variable is allocated, it is deallocated. 17 18 (2) If the component of the value of expr is allocated, the corresponding component of the 19 variable is allocated with the same dynamic type and type parameters as the component 161 J3/07-007 WORKING DRAFT 2006/01/05 1 of the value of expr. If it is an array, it is allocated with the same bounds. The value of 2 the component of the value of expr is then assigned to the corresponding component of the 3 variable using defined assignment if the declared type of the component has a type-bound 4 defined assignment consistent with the component, and intrinsic assignment for the dynamic 5 type of that component otherwise. 6The processor may perform the component-by-component assignment in any order or by any means that 7has the same effect. NOTE 7.44 For an example of a derived-type intrinsic assignment statement, if C and D are of the same derived type with a pointer component P and nonpointer components S, T, U, and V of type integer, logical, character, and another derived type, respectively, the intrinsic C = D pointer assigns D%P to C%P. It assigns D%S to C%S, D%T to C%T, and D%U to C%U using intrinsic assignment. It assigns D%V to C%V using defined assignment if objects of that type have a compatible type-bound defined assignment, and intrinsic assignment otherwise. NOTE 7.45 If an allocatable component of expr is unallocated, the corresponding component of the variable has an allocation status of unallocated after execution of the assignment. 87.2.1.4 Defined assignment statement 9A defined assignment statement is an assignment statement that is defined by a subroutine and a 10generic interface (4.5.2, 12.4.3.4.3) that specifies ASSIGNMENT (=). A defined elemental assign- ment statement is a defined assignment statement for which the subroutine is elemental (12.8). 11 12A subroutine defines the defined assignment x1 = x2 if 13 (1) the subroutine is specified with a SUBROUTINE (12.6.2.3) or ENTRY (12.6.2.6) statement 14 that specifies two dummy arguments, d1 and d2, (2) either 15 16 (a) a generic interface (12.4.3.2) provides the subroutine with a generic-spec of ASSIGN- MENT (=), or 17 18 (b) there is a generic binding (4.5.2) in the declared type of x1 or x2 with a generic-spec 19 of ASSIGNMENT (=) and there is a corresponding binding to the subroutine in the 20 dynamic type of x1 or x2, respectively, (3) 21 the types of d1 and d2 are compatible with the dynamic types of x1 and x2, respectively, 22 (4) the type parameters, if any, of d1 and d2 match the corresponding type parameters of x1 23 and x2, respectively, and (5) either 24 (a) 25 the ranks of x1 and x2 match those of d1 and d2 or 26 (b) the subroutine is elemental, x1 and x2 are conformable, and there is no other subrou- 27 tine that defines the operation. 28If d1 or d2 is an array, the shapes of x1 and x2 shall match the shapes of d1 and d2, respectively. 297.2.1.5 Interpretation of defined assignment statements 162 2006/01/05 WORKING DRAFT J3/07-007 1The interpretation of a defined assignment is provided by the subroutine that defines it. 2If the defined assignment is an elemental assignment and the the variable in the assignment is an array, 3the defined assignment is performed element-by-element, on corresponding elements of the variable and 4expr. If expr is a scalar, it is treated as if it were an array of the same shape as the variable with every 5element of the array equal to the scalar value of expr. NOTE 7.46 The rules of defined assignment (12.4.3.4.3), procedure references (12.5), subroutine references (12.5.4), and elemental subroutine arguments (12.8.3) ensure that the defined assignment has the same effect as if the evaluation of all operations in x2 and x1 occurs before any portion of x1 is defined. If an elemental assignment is defined by a pure elemental subroutine, the element assignments may be performed simultaneously or in any order. 7.2.2 Pointer assignment 6 77.2.2.1 General 8Pointer assignment causes a pointer to become associated with a target or causes its pointer association 9status to become disassociated or undefined. Any previous association between the pointer and a target 10is broken. 11Pointer assignment for a pointer component of a structure may also take place by execution of a derived- type intrinsic assignment statement (7.2.1.3). 12 137.2.2.2 Syntax 14R735 pointer-assignment-stmt is data-pointer-object [ (bounds-spec-list) ] => data-target 15 or data-pointer-object (bounds-remapping-list ) => data-target 16 or proc-pointer-object => proc-target 17R736 data-pointer-object is variable-name 18 or scalar-variable % data-pointer-component-name 19C717 (R735) If data-target is not unlimited polymorphic, data-pointer-object shall be type compatible (4.3.1.3) with it and the corresponding kind type parameters shall be equal. 20 21C718 (R735) If data-target is unlimited polymorphic, data-pointer-object shall be unlimited polymor- 22 phic, of a sequence derived type, or of a type with the BIND attribute. 23C719 (R735) If bounds-spec-list is specified, the number of bounds-specs shall equal the rank of data- 24 pointer-object. 25C720 (R735) If bounds-remapping-list is specified, the number of bounds-remappings shall equal the 26 rank of data-pointer-object. 27C721 (R735) If bounds-remapping-list is not specified, the ranks of data-pointer-object and data-target 28 shall be the same. C722 (R736) A variable-name shall have the POINTER attribute. 29 C723 (R736) A scalar-variable shall be a data-ref . 30 31C724 (R736) A data-pointer-component-name shall be the name of a component of scalar-variable 32 that is a data pointer. C725 (R736) A data-pointer-object shall not be a co-indexed object. 163 J3/07-007 WORKING DRAFT 2006/01/05 1 2R737 bounds-spec is lower-bound-expr : 3R738 bounds-remapping is lower-bound-expr : upper-bound-expr 4R739 data-target is variable 5 or expr 6C726 (R739) A variable shall have either the TARGET or POINTER attribute, and shall not be an 7 array section with a vector subscript. C727 (R739) A data-target shall not be a co-indexed object. 8 NOTE 7.47 A data pointer and its target are always on the same image. A co-array may be of a derived type with pointer or allocatable subcomponents. For example, if PTR is a pointer component, Z[P]%PTR is a reference to the target of component PTR of Z on image P. This target is on image P and its association with Z[P]%PTR must have been established by the execution of an ALLOCATE statement or a pointer assignment on image P. C728 (R739) An expr shall be a reference to a function whose result is a data pointer. 9 10R740 proc-pointer-object is proc-pointer-name 11 or proc-component-ref 12R741 proc-component-ref is scalar-variable % procedure-component-name C729 (R741) The scalar-variable shall be a data-ref . 13 14C730 (R741) The procedure-component-name shall be the name of a procedure pointer component of 15 the declared type of scalar-variable. 16R742 proc-target is expr 17 or procedure-name 18 or proc-component-ref C731 (R742) An expr shall be a reference to a function whose result is a procedure pointer. 19 20C732 (R742) A procedure-name shall be the name of an external, internal, module, or dummy proce- 21 dure, a procedure pointer, or a specific intrinsic function listed in 13.6 and not marked with a bullet (·). 22 C733 (R742) The proc-target shall not be a nonintrinsic elemental procedure. 23 247.2.2.3 Data pointer assignment 25If data-pointer-object is not polymorphic (4.3.1.3) and data-target is polymorphic with dynamic type 26that differs from its declared type, the assignment target is the ancestor component of data-target that 27has the type of data-pointer-object. Otherwise, the assignment target is data-target. 28If data-target is not a pointer, data-pointer-object becomes pointer associated with the assignment target. 29Otherwise, the pointer association status of data-pointer-object becomes that of data-target; if data-target 30is associated with an object, data-pointer-object becomes associated with the assignment target. If data- 31target is allocatable, it shall be allocated. 32If data-pointer-object is polymorphic, it assumes the dynamic type of data-target. If data-pointer-object 33is of sequence derived type or a type with the BIND attribute, the dynamic type of data-target shall be 164 2006/01/05 WORKING DRAFT J3/07-007 1that derived type. 2If data-target is a disassociated pointer, all nondeferred type parameters of the declared type of data- 3pointer-object that correspond to nondeferred type parameters of data-target shall have the same values 4as the corresponding type parameters of data-target. 5Otherwise, all nondeferred type parameters of the declared type of data-pointer-object shall have the 6same values as the corresponding type parameters of data-target. 7If data-pointer-object has nondeferred type parameters that correspond to deferred type parameters of 8data-target, data-target shall not be a pointer with undefined association status. 9If data-pointer-object has the CONTIGUOUS attribute, data-target shall be contiguous. 10If bounds-remapping-list is specified, data-target shall be contiguous (5.3.6) or of rank one. It shall not 11be a disassociated or undefined pointer, and the size of data-target shall not be less than the size of 12data-pointer-object. The elements of the target of data-pointer-object, in array element order (6.2.2.1), are the first SIZE(data-pointer-object) elements of data-target. 13 14If no bounds-remapping-list is specified, the extent of a dimension of data-pointer-object is the extent of 15the corresponding dimension of data-target. If bounds-spec-list appears, it specifies the lower bounds; 16otherwise, the lower bound of each dimension is the result of the intrinsic function LBOUND (13.7.97) 17applied to the corresponding dimension of data-target. The upper bound of each dimension is one less 18than the sum of the lower bound and the extent. 197.2.2.4 Procedure pointer assignment 20If the proc-target is not a pointer, proc-pointer-object becomes pointer associated with proc-target. Other- 21wise, the pointer association status of proc-pointer-object becomes that of proc-target; if proc-target is 22associated with a procedure, proc-pointer-object becomes associated with the same procedure. 23If proc-target is the name of an internal procedure the host instance of proc-pointer-object becomes 24the innermost currently executing instance of the host procedure. Otherwise if proc-target has a host 25instance the host instance of proc-pointer-object becomes that instance. Otherwise proc-pointer-object 26has no host instance. 27If proc-pointer-object has an explicit interface, its characteristics shall be the same as proc-target except 28that proc-target may be pure even if proc-pointer-object is not pure and proc-target may be an elemental 29intrinsic procedure even if proc-pointer-object is not elemental. 30If the characteristics of proc-pointer-object or proc-target are such that an explicit interface is required, 31both proc-pointer-object and proc-target shall have an explicit interface. 32If proc-pointer-object has an implicit interface and is explicitly typed or referenced as a function, proc- 33target shall be a function. If proc-pointer-object has an implicit interface and is referenced as a subroutine, 34proc-target shall be a subroutine. 35If proc-target and proc-pointer-object are functions, they shall have the same type; corresponding type 36parameters shall either both be deferred or both have the same value. 37If procedure-name is a specific procedure name that is also a generic name, only the specific procedure 38is associated with pointer-object. 397.2.2.5 Examples 165 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 7.48 The following are examples of pointer assignment statements. (See Note 12.16 for declarations of P and BESSEL.) NEW_NODE % LEFT => CURRENT_NODE SIMPLE_NAME => TARGET_STRUCTURE % SUBSTRUCT % COMPONENT PTR => NULL ( ) ROW => MAT2D (N, :) WINDOW => MAT2D (I-1:I+1, J-1:J+1) POINTER_OBJECT => POINTER_FUNCTION (ARG_1, ARG_2) EVERY_OTHER => VECTOR (1:N:2) WINDOW2 (0:, 0:) => MAT2D (ML:MU, NL:NU) ! P is a procedure pointer and BESSEL is a procedure with a ! compatible interface. P => BESSEL ! Likewise for a structure component. STRUCT % COMPONENT => BESSEL NOTE 7.49 It is possible to obtain different-rank views of parts of an object by specifying upper bounds in pointer assignment statements. This requires that the object be either rank one or contiguous. Consider the following example, in which a matrix is under consideration. The matrix is stored as a rank-one object in MYDATA because its diagonal is needed for some reason ­ the diagonal cannot be gotten as a single object from a rank-two representation. The matrix is represented as a rank-two view of MYDATA. real, target :: MYDATA ( NR*NC ) ! An automatic array real, pointer :: MATRIX ( :, : ) ! A rank-two view of MYDATA real, pointer :: VIEW_DIAG ( : ) MATRIX( 1:NR, 1:NC ) => MYDATA ! The MATRIX view of the data VIEW_DIAG => MYDATA( 1::NR+1 ) ! The diagonal of MATRIX Rows, columns, or blocks of the matrix can be accessed as sections of MATRIX. Rank remapping can be applied to CONTIGUOUS arrays, for example: REAL, CONTIGUOUS, POINTER :: A(:) REAL, CONTIGUOUS, TARGET :: B(:,:) ! Dummy argument A(1:SIZE(B)) => B ! Linear view of a rank-2 array 7.2.3 Masked array assignment ­ WHERE 1 27.2.3.1 General form of the masked array assignment 3A masked array assignment is either a WHERE statement or a WHERE construct. It is used to 4mask the evaluation of expressions and assignment of values in array assignment statements, according 5to the value of a logical array expression. R743 where-stmt is WHERE ( mask-expr ) where-assignment-stmt 6 7R744 where-construct is where-construct-stmt 8 [ where-body-construct ] ... 166 2006/01/05 WORKING DRAFT J3/07-007 1 [ masked-elsewhere-stmt 2 [ where-body-construct ] ... ] ... 3 [ elsewhere-stmt 4 [ where-body-construct ] ... ] 5 end-where-stmt R745 where-construct-stmt is [where-construct-name:] WHERE ( mask-expr ) 6 7R746 where-body-construct is where-assignment-stmt 8 or where-stmt 9 or where-construct 10R747 where-assignment-stmt is assignment-stmt 11R748 mask-expr is logical-expr R749 masked-elsewhere-stmt is ELSEWHERE (mask-expr) [where-construct-name] 12 R750 elsewhere-stmt is ELSEWHERE [where-construct-name] 13 R751 end-where-stmt is END WHERE [where-construct-name] 14 C734 (R747) A where-assignment-stmt that is a defined assignment shall be elemental. 15 16C735 (R744) If the where-construct-stmt is identified by a where-construct-name, the corresponding 17 end-where-stmt shall specify the same where-construct-name. If the where-construct-stmt is 18 not identified by a where-construct-name, the corresponding end-where-stmt shall not specify 19 a where-construct-name. If an elsewhere-stmt or a masked-elsewhere-stmt is identified by a 20 where-construct-name, the corresponding where-construct-stmt shall specify the same where- 21 construct-name. C736 (R746) A statement that is part of a where-body-construct shall not be a branch target statement. 22 23If a where-construct contains a where-stmt, a masked-elsewhere-stmt, or another where-construct then 24each mask-expr within the where-construct shall have the same shape. In each where-assignment-stmt, 25the mask-expr and the variable being defined shall be arrays of the same shape. NOTE 7.50 Examples of a masked array assignment are: WHERE (TEMP > 100.0) TEMP = TEMP - REDUCE_TEMP WHERE (PRESSURE <= 1.0) PRESSURE = PRESSURE + INC_PRESSURE TEMP = TEMP - 5.0 ELSEWHERE RAINING = .TRUE. END WHERE 267.2.3.2 Interpretation of masked array assignments 27When a WHERE statement or a where-construct-stmt is executed, a control mask is established. In 28addition, when a WHERE construct statement is executed, a pending control mask is established. If 29the statement does not appear as part of a where-body-construct, the mask-expr of the statement is 30evaluated, and the control mask is established to be the value of mask-expr. The pending control mask 31is established to have the value .NOT. mask-expr upon execution of a WHERE construct statement that 32does not appear as part of a where-body-construct. The mask-expr is evaluated only once. 167 J3/07-007 WORKING DRAFT 2006/01/05 1Each statement in a WHERE construct is executed in sequence. 2Upon execution of a masked-elsewhere-stmt, the following actions take place in sequence. (1) 3 The control mask mc is established to have the value of the pending control mask. (2) 4 The pending control mask is established to have the value mc .AND. (.NOT. mask-expr). (3) 5 The control mask mc is established to have the value mc .AND. mask-expr. 6The mask-expr is evaluated at most once. 7Upon execution of an ELSEWHERE statement, the control mask is established to have the value of the 8pending control mask. No new pending control mask value is established. 9Upon execution of an ENDWHERE statement, the control mask and pending control mask are es- 10tablished to have the values they had prior to the execution of the corresponding WHERE construct 11statement. Following the execution of a WHERE statement that appears as a where-body-construct, the 12control mask is established to have the value it had prior to the execution of the WHERE statement. NOTE 7.51 The establishment of control masks and the pending control mask is illustrated with the following example: WHERE(cond1) ! Statement 1 . . . ELSEWHERE(cond2) ! Statement 2 . . . ELSEWHERE ! Statement 3 . . . END WHERE Following execution of statement 1, the control mask has the value cond1 and the pending control mask has the value .NOT. cond1. Following execution of statement 2, the control mask has the value (.NOT. cond1) .AND. cond2 and the pending control mask has the value (.NOT. cond1) .AND. (.NOT. cond2). Following execution of statement 3, the control mask has the value (.NOT. cond1) .AND. (.NOT. cond2). The false condition values are propagated through the execution of the masked ELSEWHERE statement. 13Upon execution of a WHERE construct statement that is part of a where-body-construct, the pending 14control mask is established to have the value mc .AND. (.NOT. mask-expr). The control mask is then 15established to have the value mc .AND. mask-expr. The mask-expr is evaluated at most once. 16Upon execution of a WHERE statement that is part of a where-body-construct, the control mask is 17established to have the value mc .AND. mask-expr. The pending mask is not altered. 18If a nonelemental function reference occurs in the expr or variable of a where-assignment-stmt or in a 19mask-expr, the function is evaluated without any masked control; that is, all of its argument expressions 20are fully evaluated and the function is fully evaluated. If the result is an array and the reference is not 21within the argument list of a nonelemental function, elements corresponding to true values in the control 22mask are selected for use in evaluating the expr, variable or mask-expr. 23If an elemental operation or function reference occurs in the expr or variable of a where-assignment-stmt 24or in a mask-expr, and is not within the argument list of a nonelemental function reference, the operation 25is performed or the function is evaluated only for the elements corresponding to true values of the control 26mask. 27If an array constructor appears in a where-assignment-stmt or in a mask-expr, the array constructor is 168 2006/01/05 WORKING DRAFT J3/07-007 1evaluated without any masked control and then the where-assignment-stmt is executed or the mask-expr 2is evaluated. 3When a where-assignment-stmt is executed, the values of expr that correspond to true values of the 4control mask are assigned to the corresponding elements of the variable. 5The value of the control mask is established by the execution of a WHERE statement, a WHERE con- 6struct statement, an ELSEWHERE statement, a masked ELSEWHERE statement, or an ENDWHERE 7statement. Subsequent changes to the value of entities in a mask-expr have no effect on the value of the 8control mask. The execution of a function reference in the mask expression of a WHERE statement is 9permitted to affect entities in the assignment statement. NOTE 7.52 Examples of function references in masked array assignments are: WHERE (A > 0.0) A = LOG (A) ! LOG is invoked only for positive elements. A = A / SUM (LOG (A)) ! LOG is invoked for all elements ! because SUM is transformational. END WHERE 107.2.4 FORALL 117.2.4.1 Form of the FORALL Construct 12The FORALL construct allows multiple assignments, masked array (WHERE) assignments, and nested 13FORALL constructs and statements to be controlled by a single forall-triplet-spec-list and scalar-mask- 14expr. 15R752 forall-construct is forall-construct-stmt 16 [forall-body-construct ] ... 17 end-forall-stmt R753 forall-construct-stmt is [forall-construct-name :] FORALL forall-header 18 R754 forall-header is ( [ type-spec :: ] forall-triplet-spec-list [, scalar-mask-expr] ) 19 R755 forall-triplet-spec is index-name = subscript : subscript [ : stride] 20 21R619 subscript is scalar-int-expr 22R622 stride is scalar-int-expr 23R756 forall-body-construct is forall-assignment-stmt 24 or where-stmt 25 or where-construct 26 or forall-construct 27 or forall-stmt 28R757 forall-assignment-stmt is assignment-stmt 29 or pointer-assignment-stmt R758 end-forall-stmt is END FORALL [forall-construct-name ] 30 31C737 (R758) If the forall-construct-stmt has a forall-construct-name, the end-forall-stmt shall have 32 the same forall-construct-name. If the end-forall-stmt has a forall-construct-name, the forall- 169 J3/07-007 WORKING DRAFT 2006/01/05 1 construct-stmt shall have the same forall-construct-name. C738 (R754) type-spec shall specify type integer. 2 C739 (R754) The scalar-mask-expr shall be scalar and of type logical. 3 4C740 (R754) Any procedure referenced in the scalar-mask-expr, including one referenced by a defined operation, shall be a pure procedure (12.7). 5 C741 (R755) The index-name shall be a named scalar variable of type integer. 6 7C742 (R755) A subscript or stride in a forall-triplet-spec shall not contain a reference to any index- 8 name in the forall-triplet-spec-list in which it appears. 9C743 (R756) A statement in a forall-body-construct shall not define an index-name of the forall- 10 construct. 11C744 (R756) Any procedure referenced in a forall-body-construct, including one referenced by a defined 12 operation, assignment, or finalization, shall be a pure procedure. C745 (R756) A forall-body-construct shall not be a branch target. 13 C746 (R757) The variable in an assignment-stmt that is a forall-assignment-stmt shall be a designator. 14 NOTE 7.53 An example of a FORALL construct is: REAL :: A(10, 10), B(10, 10) = 1.0 . . . FORALL (I = 1:10, J = 1:10, B(I, J) /= 0.0) A(I, J) = REAL (I + J - 2) B(I, J) = A(I, J) + B(I, J) * REAL (I * J) END FORALL NOTE 7.54 An assignment statement that is a FORALL body construct may be a scalar or array assignment statement, or a defined assignment statement. The variable being defined will normally use each index name in the forall-triplet-spec-list. For example FORALL (I = 1:N, J = 1:N) A(:, I, :, J) = 1.0 / REAL(I + J - 1) END FORALL broadcasts scalar values to rank-two subarrays of A. NOTE 7.55 An example of a FORALL construct containing a pointer assignment statement is: TYPE ELEMENT REAL ELEMENT_WT CHARACTER (32), POINTER :: NAME END TYPE ELEMENT TYPE(ELEMENT) CHART(200) REAL WEIGHTS (1000) 170 2006/01/05 WORKING DRAFT J3/07-007 NOTE 7.55 (cont.) CHARACTER (32), TARGET :: NAMES (1000) . . . FORALL (I = 1:200, WEIGHTS (I + N - 1) > .5) CHART(I) % ELEMENT_WT = WEIGHTS (I + N - 1) CHART(I) % NAME => NAMES (I + N - 1) END FORALL The results of this FORALL construct cannot be achieved with a WHERE construct because a pointer assignment statement is not permitted in a WHERE construct. 1An index-name in a forall-construct has a scope of the construct (16.4). It is a scalar variable that has 2the type and type parameters that it would have if it were the name of a variable in the scoping unit 3that includes the FORALL, and this type shall be integer type; it has no other attributes. NOTE 7.56 The use of index-name variables in a FORALL construct does not affect variables of the same name, for example: INTEGER :: X = -1 REAL A(5, 4) J = 100 . . . FORALL (X = 1:5, J = 1:4) A (X, J) = J END FORALL After execution of the FORALL, the variables X and J have the values -1 and 100 and A has the value 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 47.2.4.2 Execution of the FORALL construct 57.2.4.2.1 Execution stages 6There are three stages in the execution of a FORALL construct: (1) determination of the values for index-name variables, 7 (2) evaluation of the scalar-mask-expr, and 8 (3) execution of the FORALL body constructs. 9 107.2.4.2.2 Determination of the values for index variables 11The subscript and stride expressions in the forall-triplet-spec-list are evaluated. These expressions may 12be evaluated in any order. The set of values that a particular index-name variable assumes is determined 13as follows. 14 (1) The lower bound m1, the upper bound m2, and the stride m3 are of type integer with the 15 same kind type parameter as the index-name. Their values are established by evaluating 171 J3/07-007 WORKING DRAFT 2006/01/05 1 the first subscript, the second subscript, and the stride expressions, respectively, including, 2 if necessary, conversion to the kind type parameter of the index-name according to the rules 3 for numeric conversion (Table 7.13). If a stride does not appear, m3 has the value 1. The 4 value m3 shall not be zero. 5 (2) Let the value of max be (m2-m1+m3)/m3. If max 0 for some index-name, the execution 6 of the construct is complete. Otherwise, the set of values for the index-name is where k = 1, 2, ..., max. 7 m1 + (k - 1) × m3 8The set of combinations of index-name values is the Cartesian product of the sets defined by each triplet 9specification. An index-name becomes defined when this set is evaluated. 107.2.4.2.3 Evaluation of the mask expression 11The scalar-mask-expr, if any, is evaluated for each combination of index-name values. If there is no 12scalar-mask-expr, it is as if it appeared with the value true. The index-name variables may be primaries 13in the scalar-mask-expr. 14The active combination of index-name values is defined to be the subset of all possible combinations (7.2.4.2.2) for which the scalar-mask-expr has the value true. 15 NOTE 7.57 The index-name variables may appear in the mask, for example FORALL (I=1:10, J=1:10, A(I) > 0.0 .AND. B(J) < 1.0) . . . 167.2.4.2.4 Execution of the FORALL body constructs 17The forall-body-constructs are executed in the order in which they appear. Each construct is executed 18for all active combinations of the index-name values with the following interpretation: 19Execution of a forall-assignment-stmt that is an assignment-stmt causes the evaluation of expr and all 20expressions within variable for all active combinations of index-name values. These evaluations may be 21done in any order. After all these evaluations have been performed, each expr value is assigned to the 22corresponding variable. The assignments may occur in any order. 23Execution of a forall-assignment-stmt that is a pointer-assignment-stmt causes the evaluation of all 24expressions within data-target and data-pointer-object or proc-target and proc-pointer-object, the de- 25termination of any pointers within data-pointer-object or proc-pointer-object, and the determination of 26the target for all active combinations of index-name values. These evaluations may be done in any 27order. After all these evaluations have been performed, each data-pointer-object or proc-pointer-object 28is associated with the corresponding target. These associations may occur in any order. 29In a forall-assignment-stmt, a defined assignment subroutine shall not reference any variable that be- 30comes defined by the statement. NOTE 7.58 The following FORALL construct contains two assignment statements. The assignment to array B uses the values of array A computed in the previous statement, not the values A had prior to execution of the FORALL. FORALL (I = 2:N-1, J = 2:N-1 ) A (I, J) = A(I, J-1) + A(I, J+1) + A(I-1, J) + A(I+1, J) B (I, J) = 1.0 / A(I, J) 172 2006/01/05 WORKING DRAFT J3/07-007 NOTE 7.58 (cont.) END FORALL Computations that would otherwise cause error conditions can be avoided by using an appropriate scalar-mask-expr that limits the active combinations of the index-name values. For example: FORALL (I = 1:N, Y(I) /= 0.0) X(I) = 1.0 / Y(I) END FORALL 1Each statement in a where-construct (7.2.3) within a forall-construct is executed in sequence. When 2a where-stmt, where-construct-stmt or masked-elsewhere-stmt is executed, the statement's mask-expr is 3evaluated for all active combinations of index-name values as determined by the outer forall-constructs, 4masked by any control mask corresponding to outer where-constructs. Any where-assignment-stmt is 5executed for all active combinations of index-name values, masked by the control mask in effect for the 6where-assignment-stmt. NOTE 7.59 This FORALL construct contains a WHERE statement and an assignment statement. INTEGER A(5,4), B(5,4) FORALL ( I = 1:5 ) WHERE ( A(I,:) == 0 ) A(I,:) = I B (I,:) = I / A(I,:) END FORALL When executed with the input array 0 0 0 0 1 1 1 0 A = 2 2 0 2 1 0 2 3 0 0 0 0 the results will be 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 1 A = 2 2 3 2 B = 1 1 1 1 1 4 2 3 4 1 2 1 5 5 5 5 1 1 1 1 For an example of a FORALL construct containing a WHERE construct with an ELSEWHERE statement, see C.4.5. 7Execution of a forall-stmt or forall-construct causes the evaluation of the subscript and stride expressions 8in the forall-triplet-spec-list for all active combinations of the index-name values of the outer FORALL 9construct. The set of combinations of index-name values for the inner FORALL is the union of the 10sets defined by these bounds and strides for each active combination of the outer index-name values; it 11also includes the outer index-name values. The scalar-mask-expr is then evaluated for all combinations 12of the index-name values of the inner construct to produce a set of active combinations for the inner 13construct. If there is no scalar-mask-expr, it is as if it appeared with the value true. Each statement in 173 J3/07-007 WORKING DRAFT 2006/01/05 1the inner FORALL is then executed for each active combination of the index-name values. NOTE 7.60 This FORALL construct contains a nested FORALL construct. It assigns the transpose of the strict lower triangle of array A (the section below the main diagonal) to the strict upper triangle of A. INTEGER A (3, 3) FORALL (I = 1:N-1 ) FORALL ( J=I+1:N ) A(I,J) = A(J,I) END FORALL END FORALL If prior to execution N = 3 and 0 3 6 A = 1 4 7 2 5 8 then after execution 0 1 2 A = 1 4 5 2 5 8 27.2.4.3 The FORALL statement 3The FORALL statement allows a single assignment statement or pointer assignment to be controlled by 4a set of index values and an optional mask expression. 5R759 forall-stmt is FORALL forall-header forall-assignment-stmt 6A FORALL statement is equivalent to a FORALL construct containing a single forall-body-construct 7that is a forall-assignment-stmt. The scope of an index-name in a forall-stmt is the statement itself (16.4). 8 NOTE 7.61 Examples of FORALL statements are: FORALL (I=1:N) A(I,I) = X(I) This statement assigns the elements of vector X to the elements of the main diagonal of matrix A. FORALL (I = 1:N, J = 1:N) X(I,J) = 1.0 / REAL (I+J-1) Array element X(I,J) is assigned the value (1.0 / REAL (I+J-1)) for values of I and J between 1 and N, inclusive. FORALL (I=1:N, J=1:N, Y(I,J) /= 0 .AND. I /= J) X(I,J) = 1.0 / Y(I,J) This statement takes the reciprocal of each nonzero off-diagonal element of array Y(1:N, 1:N) 174 2006/01/05 WORKING DRAFT J3/07-007 NOTE 7.61 (cont.) and assigns it to the corresponding element of array X. Elements of Y that are zero or on the diagonal do not participate, and no assignments are made to the corresponding elements of X. The results from the execution of the example in Note 7.60 could be obtained with a single FORALL statement: FORALL ( I = 1:N-1, J=1:N, J > I ) A(I,J) = A(J,I) For more examples of FORALL statements, see C.4.6. 17.2.4.4 Restrictions on FORALL constructs and statements 2A many-to-one assignment is more than one assignment to the same object, or association of more 3than one target with the same pointer, whether the object is referenced directly or indirectly through a 4pointer. A many-to-one assignment shall not occur within a single statement in a FORALL construct or 5statement. It is possible to assign or pointer assign to the same object in different assignment statements 6in a FORALL construct. NOTE 7.62 The appearance of each index-name in the identification of the left-hand side of an assignment statement is helpful in eliminating many-to-one assignments, but it is not sufficient to guarantee there will be none. For example, the following is allowed FORALL (I = 1:10) A (INDEX (I)) = B(I) END FORALL if and only if INDEX(1:10) contains no repeated values. 7Within the scope of a FORALL construct, a nested FORALL statement or FORALL construct shall 8not have the same index-name. The forall-header expressions within a nested FORALL may depend on 9the values of outer index-name variables. 175 J3/07-007 WORKING DRAFT 2006/01/05 176 2006/01/05 WORKING DRAFT J3/07-007 18 Execution control 8.1 Executable constructs containing blocks 2 38.1.1 General 4The following are executable constructs that contain blocks: (1) ASSOCIATE construct; 5 (2) BLOCK construct; 6 (3) CASE construct; 7 (4) CRITICAL construct; 8 (5) DO construct; 9 (6) IF construct; 10 (7) SELECT TYPE construct. 11 12 There is also a nonblock form of the DO construct. 13A block is a sequence of executable constructs that is treated as a unit. R801 block is [ execution-part-construct ] ... 14 15Executable constructs may be used to control which blocks of a program are executed or how many times 16a block is executed. Blocks are always bounded by statements that are particular to the construct in 17which they are embedded; however, in some forms of the DO construct, a sequence of executable constructs without 18 a terminating boundary statement shall obey all other rules governing blocks (8.1.2). NOTE 8.1 A block need not contain any executable constructs. Execution of such a block has no effect. NOTE 8.2 An example of a construct containing a block is: IF (A > 0.0) THEN B = SQRT (A) ! These two statements C = LOG (A) ! form a block. END IF 8.1.2 Rules governing blocks 19 208.1.2.1 Control flow in blocks 21Transfer of control to the interior of a block from outside the block is prohibited. Transfers within a 22block and transfers from the interior of a block to outside the block may occur. Subroutine and function references (12.5.3, 12.5.4) may appear in a block. 23 248.1.2.2 Execution of a block 177 J3/07-007 WORKING DRAFT 2006/01/05 1Execution of a block begins with the execution of the first executable construct in the block. Execution 2of the block is completed when the last executable construct in the sequence is executed, when a branch 3(8.2) within the block that has a branch target outside the block occurs, when a RETURN statement 4within the block is executed, or when an EXIT or CYCLE statement that belongs to a construct that 5contains the block is executed. NOTE 8.3 The action that takes place at the terminal boundary depends on the particular construct and on the block within that construct. It is usually a transfer of control. 68.1.3 ASSOCIATE construct 7The ASSOCIATE construct associates named entities with expressions or variables during the exe- 8cution of its block. These named construct entities (16.4) are associating entities (16.5.1.6). The names 9are associate names. 108.1.3.1 Form of the ASSOCIATE construct 11R802 associate-construct is associate-stmt 12 block 13 end-associate-stmt 14R803 associate-stmt is [ associate-construct-name : ] ASSOCIATE (association-list ) 15 16R804 association is associate-name => selector 17R805 selector is expr 18 or variable 19C801 (R804) If selector is not a variable or is a variable that has a vector subscript, associate-name shall not appear in a variable definition context (16.6.7). 20 21C802 (R804) An associate-name shall not be the same as another associate-name in the same associate- 22 stmt. C803 (R805) expr shall not be a reference to a function that has a pointer result. 23 R806 end-associate-stmt is END ASSOCIATE [ associate-construct-name ] 24 25C804 (R806) If the associate-stmt of an associate-construct specifies an associate-construct-name, 26 the corresponding end-associate-stmt shall specify the same associate-construct-name. If the 27 associate-stmt of an associate-construct does not specify an associate-construct-name, the cor- 28 responding end-associate-stmt shall not specify an associate-construct-name. 298.1.3.2 Execution of the ASSOCIATE construct 30Execution of an ASSOCIATE construct causes execution of its associate-stmt followed by execution 31of its block. During execution of that block each associate name identifies an entity, which is associ- 32ated (16.5.1.6) with the corresponding selector. The associating entity assumes the declared type and 33type parameters of the selector. If and only if the selector is polymorphic, the associating entity is 34polymorphic. 35The other attributes of the associating entity are described in 8.1.3.3. 36It is permissible to branch to an end-associate-stmt only from within its ASSOCIATE construct. 178 2006/01/05 WORKING DRAFT J3/07-007 18.1.3.3 Attributes of associate names 2Within a SELECT TYPE or ASSOCIATE construct, each associating entity has the same rank as its 3associated selector. The lower bound of each dimension is the result of the intrinsic function LBOUND 4(13.7.97) applied to the corresponding dimension of selector. The upper bound of each dimension is one 5less than the sum of the lower bound and the extent. The associating entity has the ASYNCHRONOUS 6or VOLATILE attribute if and only if the selector is a variable and has the attribute. The associating 7entity has the TARGET attribute if and only if the selector is a variable and has either the TARGET 8or POINTER attribute. If the associating entity is polymorphic, it assumes the dynamic type and type 9parameter values of the selector. If the selector has the OPTIONAL attribute, it shall be present. The 10associating entity is contiguous if and only if the selector is contiguous. 11If the selector (8.1.3.1) is not permitted to appear in a variable definition context (16.6.7), the associate 12name shall not appear in a variable definition context. 138.1.3.4 Examples of the ASSOCIATE construct NOTE 8.4 The following example illustrates an association with an expression. ASSOCIATE ( Z => EXP(-(X**2+Y**2)) * COS(THETA) ) PRINT *, A+Z, A-Z END ASSOCIATE The following example illustrates an association with a derived-type variable. ASSOCIATE ( XC => AX%B(I,J)%C ) XC%DV = XC%DV + PRODUCT(XC%EV(1:N)) END ASSOCIATE The following example illustrates association with an array section. ASSOCIATE ( ARRAY => AX%B(I,:)%C ) ARRAY(N)%EV = ARRAY(N-1)%EV END ASSOCIATE The following example illustrates multiple associations. ASSOCIATE ( W => RESULT(I,J)%W, ZX => AX%B(I,J)%D, ZY => AY%B(I,J)%D ) W = ZX*X + ZY*Y END ASSOCIATE 148.1.4 BLOCK construct 15The BLOCK construct is an executable construct which may contain declarations. 16R807 block-construct is block-stmt 17 [ specification-part ] 18 block 19 end-block-stmt R808 block-stmt is [ block-construct-name : ] BLOCK 20 R809 end-block-stmt is END BLOCK [ block-construct-name ] 21 179 J3/07-007 WORKING DRAFT 2006/01/05 1C805 (R807) The specification-part of a BLOCK construct shall not contain a COMMON, EQUIVA- 2 LENCE, IMPLICIT, INTENT, NAMELIST, OPTIONAL, or USE statement. 3C806 (R807) A SAVE statement in a BLOCK construct shall contain a saved-entity-list that does not 4 specify a common-block-name. J3 internal note Unresolved Technical Issue 084 It would be better to allow the USE statement. Some work is required to handle modules going out of scope on exiting a BLOCK construct. 5C807 (R807) If the block-stmt of a block-construct specifies a block-construct-name, the corresponding 6 end-block-stmt shall specify the same block-construct-name. If the block-stmt does not specify 7 a block-construct-name, the corresponding end-block-stmt shall not specify a block-construct- 8 name. 9Except for the ASYNCHRONOUS and VOLATILE statements, specifications in a BLOCK construct declare construct entities whose scope is that of the BLOCK construct (16.4). 10 11Execution of a BLOCK construct causes evaluation of the specification expressions within its specification 12part in a processor-dependent order, followed by execution of its block. 138.1.5 CASE construct 148.1.5.1 Form of the CASE construct 15The CASE construct selects for execution at most one of its constituent blocks. The selection is based 16on the value of an expression. 17R810 case-construct is select-case-stmt 18 [ case-stmt 19 block ] ... 20 end-select-stmt R811 select-case-stmt is [ case-construct-name : ] SELECT CASE ( case-expr ) 21 R812 case-stmt is CASE case-selector [case-construct-name] 22 R813 end-select-stmt is END SELECT [ case-construct-name ] 23 24C808 (R810) If the select-case-stmt of a case-construct specifies a case-construct-name, the corre- 25 sponding end-select-stmt shall specify the same case-construct-name. If the select-case-stmt 26 of a case-construct does not specify a case-construct-name, the corresponding end-select-stmt 27 shall not specify a case-construct-name. If a case-stmt specifies a case-construct-name, the 28 corresponding select-case-stmt shall specify the same case-construct-name. 29R814 case-expr is scalar-int-expr 30 or scalar-char-expr 31 or scalar-logical-expr 32R815 case-selector is ( case-value-range-list ) 33 or DEFAULT C809 (R810) No more than one of the selectors of one of the CASE statements shall be DEFAULT. 34 35R816 case-value-range is case-value 36 or case-value : 180 2006/01/05 WORKING DRAFT J3/07-007 1 or : case-value 2 or case-value : case-value 3R817 case-value is scalar-int-initialization-expr 4 or scalar-char-initialization-expr 5 or scalar-logical-initialization-expr 6C810 (R810) For a given case-construct, each case-value shall be of the same type as case-expr. For 7 character type, the kind type parameters shall be the same; character length differences are 8 allowed. C811 (R810) A case-value-range using a colon shall not be used if case-expr is of type logical. 9 10C812 (R810) For a given case-construct, the case-value-ranges shall not overlap; that is, there shall 11 be no possible value of the case-expr that matches more than one case-value-range. 128.1.5.2 Execution of a CASE construct 13The execution of the SELECT CASE statement causes the case expression to be evaluated. The resulting 14value is called the case index. For a case value range list, a match occurs if the case index matches any 15of the case value ranges in the list. For a case index with a value of c, a match is determined as follows. 16 (1) If the case value range contains a single value v without a colon, a match occurs for type 17 logical if the expression c .EQV. v is true, and a match occurs for type integer or character 18 if the expression c == v is true. 19 (2) If the case value range is of the form low : high, a match occurs if the expression low <= c 20 .AND. c <= high is true. (3) 21 If the case value range is of the form low :, a match occurs if the expression low <= c is true. 22 (4) If the case value range is of the form : high, a match occurs if the expression c <= high is 23 true. (5) If no other selector matches and a DEFAULT selector appears, it matches the case index. 24 (6) If no other selector matches and the DEFAULT selector does not appear, there is no match. 25 26The block following the CASE statement containing the matching selector, if any, is executed. This 27completes execution of the construct. 28It is permissible to branch to an end-select-stmt only from within its CASE construct. 298.1.5.3 Examples of CASE constructs NOTE 8.5 An integer signum function: INTEGER FUNCTION SIGNUM (N) SELECT CASE (N) CASE (:-1) SIGNUM = -1 CASE (0) SIGNUM = 0 CASE (1:) SIGNUM = 1 END SELECT END 181 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 8.6 A code fragment to check for balanced parentheses: CHARACTER (80) :: LINE ... LEVEL = 0 SCAN_LINE: DO I = 1, 80 CHECK_PARENS: SELECT CASE (LINE (I:I)) CASE ('(') LEVEL = LEVEL + 1 CASE (')') LEVEL = LEVEL - 1 IF (LEVEL < 0) THEN PRINT *, 'UNEXPECTED RIGHT PARENTHESIS' EXIT SCAN_LINE END IF CASE DEFAULT ! Ignore all other characters END SELECT CHECK_PARENS END DO SCAN_LINE IF (LEVEL > 0) THEN PRINT *, 'MISSING RIGHT PARENTHESIS' END IF NOTE 8.7 The following three fragments are equivalent: IF (SILLY == 1) THEN CALL THIS ELSE CALL THAT END IF SELECT CASE (SILLY == 1) CASE (.TRUE.) CALL THIS CASE (.FALSE.) CALL THAT END SELECT SELECT CASE (SILLY) CASE DEFAULT CALL THAT CASE (1) CALL THIS END SELECT NOTE 8.8 A code fragment showing several selections of one block: SELECT CASE (N) CASE (1, 3:5, 8) ! Selects 1, 3, 4, 5, 8 CALL SUB CASE DEFAULT 182 2006/01/05 WORKING DRAFT J3/07-007 NOTE 8.8 (cont.) CALL OTHER END SELECT 18.1.6 CRITICAL construct 2A CRITICAL construct limits execution of a block to one image at a time. 3R818 critical-construct is critical-stmt 4 block 5 end-critical-stmt R819 critical-stmt is [ critical-construct-name : ] CRITICAL 6 R820 end-critical-stmt is END CRITICAL [ critical-construct-name ] 7 8C813 (R818) If the critical-stmt of a critical-construct specifies a critical-construct-name, the corre- 9 sponding end-critical-stmt shall specify the same critical-construct-name. If the critical-stmt of a 10 critical-construct does not specify a critical-construct-name, the corresponding end-critical-stmt 11 shall not specify a critical-construct-name. C814 (R818) The block of a critical-construct shall not contain an image control statement. 12 13Execution of the CRITICAL construct is completed when execution of its block is completed. 14The processor shall ensure that once an image has commenced executing block, no other image shall 15commence executing it until the image has completed executing it. If image T is the next to execute the 16construct after image M, the segments (8.5.1) that executed before the construct on image M precede 17the segments that execute after the construct on image T. No image control statement shall be executed 18during the execution of a critical construct by the image executing the CRITICAL construct. NOTE 8.9 If more than one image executes the block of a CRITICAL construct, its execution by one image always either precedes or succeeds its execution by another image. Typically no other statement ordering is needed. Consider the following example: CRITICAL GLOBAL_COUNTER[1] = GLOBAL_COUNTER[1] + 1 END CRITICAL The definition of GLOBAL COUNTER[1] by a particular image will always precede the reference to the same variable by the next image to execute the block. NOTE 8.10 The following example permits a large number of jobs to be shared among the images: INTEGER :: NUM_JOBS[*], JOB IF (THIS_IMAGE() == 1) READ(*,*) NUM_JOBS SYNC ALL DO CRITICAL JOB = NUM_JOBS[1] 183 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 8.10 (cont.) NUM_JOBS[1] = JOB - 1 END CRITICAL IF (JOB > 0) THEN ! Work on JOB ELSE EXIT END IF END DO SYNC ALL 18.1.7 DO construct 28.1.7.1 General 3The DO construct specifies the repeated execution of a sequence of executable constructs. Such a 4repeated sequence is called a loop. 5The number of iterations of a loop may be determined at the beginning of execution of the DO construct, 6or may be left indefinite ("DO forever" or DO WHILE). Except in the case of a DO CONCURRENT 7construct, the loop can be terminated immediately (8.1.7.5.4). The current iteration of the loop may be curtailed by executing a CYCLE statement (8.1.7.5.3). 8 9There are three phases in the execution of a DO construct: initiation of the loop, execution of the loop 10range, and termination of the loop. 11The DO CONCURRENT construct is a DO construct whose DO statement contains the CON- 12CURRENT keyword. 138.1.7.2 Forms of the DO construct 14The DO construct may be written in either a block form or a nonblock form. 15R821 do-construct is block-do-construct 16 or nonblock-do-construct 178.1.7.2.1 Form of the block DO construct 18R822 block-do-construct is do-stmt 19 do-block 20 end-do 21R823 do-stmt is label-do-stmt 22 or nonlabel-do-stmt R824 label-do-stmt is [ do-construct-name : ] DO label [ loop-control ] 23 R825 nonlabel-do-stmt is [ do-construct-name : ] DO [ loop-control ] 24 25R826 loop-control is [ , ] do-variable = scalar-int-expr, scalar-int-expr 26 [ , scalar-int-expr ] 27 or [ , ] WHILE ( scalar-logical-expr ) or [ , ] CONCURRENT forall-header 28 29R827 do-variable is scalar-int-variable-name 184 2006/01/05 WORKING DRAFT J3/07-007 C815 (R827) The do-variable shall be a variable of type integer. 1 2 R828 do-block is block 3R829 end-do is end-do-stmt 4 or continue-stmt R830 end-do-stmt is END DO [ do-construct-name ] 5 6C816 (R822) If the do-stmt of a block-do-construct specifies a do-construct-name, the corresponding 7 end-do shall be an end-do-stmt specifying the same do-construct-name. If the do-stmt of a 8 block-do-construct does not specify a do-construct-name, the corresponding end-do shall not 9 specify a do-construct-name. C817 (R822) If the do-stmt is a nonlabel-do-stmt, the corresponding end-do shall be an end-do-stmt. 10 11 C818 (R822) If the do-stmt is a label-do-stmt, the corresponding end-do shall be identified with the 12 same label. 13 8.1.7.2.2 Form of the nonblock DO construct 14 R831 nonblock-do-construct is action-term-do-construct 15 or outer-shared-do-construct 16 R832 action-term-do-construct is label-do-stmt 17 do-body 18 do-term-action-stmt 19 R833 do-body is [ execution-part-construct ] ... 20 R834 do-term-action-stmt is action-stmt 21 C819 (R834) A do-term-action-stmt shall not be an arithmetic-if-stmt, continue-stmt, cycle-stmt, end-function-stmt, 22 end-mp-subprogram-stmt, end-program-stmt, end-subroutine-stmt, exit-stmt, goto-stmt, return-stmt, or stop- 23 stmt. 24 C820 (R831) The do-term-action-stmt shall be identified with a label and the corresponding label-do-stmt shall refer 25 to the same label. 26 R835 outer-shared-do-construct is label-do-stmt 27 do-body 28 shared-term-do-construct 29 R836 shared-term-do-construct is outer-shared-do-construct 30 or inner-shared-do-construct 31 R837 inner-shared-do-construct is label-do-stmt 32 do-body 33 do-term-shared-stmt 34 R838 do-term-shared-stmt is action-stmt 35 C821 (R838) A do-term-shared-stmt shall not be an arithmetic-if-stmt, cycle-stmt, end-function-stmt, end-program- 36 stmt, end-mp-subprogram-stmt, end-subroutine-stmt, exit-stmt, goto-stmt, return-stmt, or stop-stmt. 37 C822 (R836) The do-term-shared-stmt shall be identified with a label and all of the label-do-stmts of the inner-shared- 38 do-construct and outer-shared-do-construct shall refer to the same label. 39 The do-term-action-stmt, do-term-shared-stmt, or shared-term-do-construct following the do-body of a nonblock DO con- 40 struct is called the DO termination of that construct. 41 Within a scoping unit, all DO constructs whose DO statements refer to the same label are nonblock DO constructs, and 42 share the statement identified by that label. 185 J3/07-007 WORKING DRAFT 2006/01/05 18.1.7.3 Range of the DO construct 2The range of a block DO construct is the do-block, which shall satisfy the rules for blocks (8.1.2). In 3particular, transfer of control to the interior of such a block from outside the block is prohibited. It 4is permitted to branch to the end-do of a block DO construct only from within the range of that DO 5construct. 6 The range of a nonblock DO construct consists of the do-body and the following DO termination. The end of such a 7 range is not bounded by a particular statement as for the other executable constructs (e.g., END IF); nevertheless, the 8 range satisfies the rules for blocks (8.1.2). Transfer of control into the do-body or to the DO termination from outside the 9 range is prohibited; in particular, it is permitted to branch to a do-term-shared-stmt only from within the range of the 10 corresponding inner-shared-do-construct. 118.1.7.4 Active and inactive DO constructs 12A DO construct is either active or inactive. Initially inactive, a DO construct becomes active only 13when its DO statement is executed. Once active, the DO construct becomes inactive only when it terminates (8.1.7.5.4). 14 158.1.7.5 Execution of a DO construct 168.1.7.5.1 Loop initiation 17When the DO statement is executed, the DO construct becomes active. If loop-control is 18 [ , ] do-variable = scalar-int-expr1 , scalar-int-expr2 [ , scalar-int-expr3 ] 19the following steps are performed in sequence. 20 (1) The initial parameter m1, the terminal parameter m2, and the incrementation parameter 21 m3 are of type integer with the same kind type parameter as the do-variable. Their values 22 are established by evaluating scalar-int-expr1, scalar-int-expr2, and scalar-int-expr3, re- 23 spectively, including, if necessary, conversion to the kind type parameter of the do-variable 24 according to the rules for numeric conversion (Table 7.13). If scalar-int-expr3 does not 25 appear, m3 has the value 1. The value of m3 shall not be zero. (2) 26 The DO variable becomes defined with the value of the initial parameter m1. 27 (3) The iteration count is established and is the value of the expression (m2 - m1 + m3)/m3, 28 unless that value is negative, in which case the iteration count is 0. NOTE 8.11 The iteration count is zero whenever: m1 > m2 and m3 > 0, or m1 < m2 and m3 < 0. 29If loop-control is omitted, no iteration count is calculated. The effect is as if a large positive iteration 30count, impossible to decrement to zero, were established. If loop-control is [ , ] WHILE (scalar-logical- 31expr), the effect is as if loop-control were omitted and the following statement inserted as the first 32statement of the do-block: 33IF (.NOT. (scalar- logical-expr )) EXIT 34For a DO CONCURRENT construct, the values of the index variables for the iterations of the construct are determined by the rules for the index variables of the FORALL construct (7.2.4.2.2 and 7.2.4.2.3). 35 36An index-name in a DO CONCURRENT construct has a scope of the construct (16.4). It is a scalar 186 2006/01/05 WORKING DRAFT J3/07-007 1variable that has the type and type parameters that it would have if it were the name of a variable in the 2scoping unit that includes the construct, and this type shall be integer type; it has no other attributes. 3At the completion of the execution of the DO statement, the execution cycle begins. 48.1.7.5.2 The execution cycle 5The execution cycle of a DO construct that is not a DO CONCURRENT construct consists of the 6following steps performed in sequence repeatedly until termination. 7 (1) The iteration count, if any, is tested. If it is zero, the loop terminates and the DO construct 8 becomes inactive. If loop-control is [ , ] WHILE (scalar-logical-expr), the scalar-logical-expr 9 is evaluated; if the value of this expression is false, the loop terminates and the DO construct 10 becomes inactive. If, as a result, all of the DO constructs sharing the do-term-shared-stmt are inactive, 11 the execution of all of these constructs is complete. However, if some of the DO constructs sharing the 12 do-term-shared-stmt are active, execution continues with step (3) of the execution cycle of the active DO 13 construct whose DO statement was most recently executed. (2) The range of the loop is executed. 14 15 (3) The iteration count, if any, is decremented by one. The DO variable, if any, is incremented 16 by the value of the incrementation parameter m3. 17 Except for the incrementation of the DO variable that occurs in step (3), the DO variable shall neither 18 be redefined nor become undefined while the DO construct is active. 19 The range of a DO CONCURRENT construct is executed for all of the active combinations of the 20 index-name values. Each execution of the range is an iteration. The executions may occur in any order. 21 8.1.7.5.3 CYCLE statement 22 Execution of the range of the loop may be curtailed by executing a CYCLE statement from within the 23 range of the loop. R839 cycle-stmt is CYCLE [ do-construct-name ] 24 25 C823 (R839) If a do-construct-name appears, the CYCLE statement shall be within the range of that 26 do-construct; otherwise, it shall be within the range of at least one do-construct. 27 C824 (R839) A cycle-stmt shall not appear within the range of a DO CONCURRENT construct if it 28 belongs to an outer construct. 29 A CYCLE statement belongs to a particular DO construct. If the CYCLE statement contains a DO 30 construct name, it belongs to that DO construct; otherwise, it belongs to the innermost DO construct 31 in which it appears. 32 Execution of a CYCLE statement that belongs to a DO construct that is not a DO CONCURRENT 33 construct causes immediate progression to step (3) of the current execution cycle of the DO construct 34 to which it belongs. If this construct is a nonblock DO construct, the do-term-action-stmt or do-term-shared-stmt is 35 not executed. 36Execution of a CYCLE statement that belongs to a DO CONCURRENT construct completes execution 37of that iteration of the construct. 38In a block DO construct, a transfer of control to the end-do has the same effect as execution of a CYCLE 39statement belonging to that construct. In a nonblock DO construct, transfer of control to the do-term-action-stmt 40 or do-term-shared-stmt causes that statement to be executed. Unless a further transfer of control results, step (3) of the 41 current execution cycle of the DO construct is then executed. 187 J3/07-007 WORKING DRAFT 2006/01/05 18.1.7.5.4 Loop termination 2For a DO construct that is not a DO CONCURRENT construct, the loop terminates, and the DO 3construct becomes inactive, when any of the following occurs. 4 (1) The iteration count is determined to be zero or the scalar-logical-expr is false, when tested during step (1) of the above execution cycle. 5 (2) An EXIT statement belonging to the DO construct is executed. 6 7 (3) An EXIT or CYCLE statement that belongs to an outer construct and is within the range 8 of the DO construct is executed. 9 (4) Control is transferred from a statement within the range of a DO construct to a statement 10 that is neither the end-do nor within the range of the same DO construct. (5) A RETURN statement within the range of the DO construct is executed. 11 12For a DO CONCURRENT construct, the loop terminates, and the DO construct becomes inactive when 13all of the iterations have completed execution. 14When a DO construct becomes inactive, the DO variable, if any, of the DO construct retains its last 15defined value. 168.1.7.6 Restrictions on DO CONCURRENT constructs 17C825 A RETURN statement shall not appear within a DO CONCURRENT construct. 18C826 A branch (8.2) within a DO CONCURRENT construct shall not have a branch target that is 19 outside the construct. 20C827 A reference to a nonpure procedure shall not appear within a DO CONCURRENT construct. 21C828 A reference to the procedure IEEE GET FLAG, IEEE SET HALTING MODE, or IEEE GET - 22 HALTING MODE from the intrinsic module IEEE EXCEPTIONS, shall not appear within a 23 DO CONCURRENT construct. 24The following additional restrictions apply to DO CONCURRENT constructs. 25 · A variable that is referenced in an iteration shall either be previously defined during that iteration, 26 or shall not be defined or become undefined during any other iteration of the current execution of 27 the construct. A variable that is defined or becomes undefined by more than one iteration of the 28 current execution of the construct becomes undefined when the current execution of the construct 29 terminates. 30 · A pointer that is referenced in an iteration either shall be previously pointer associated during that 31 iteration, or shall not have its pointer association changed during any iteration. A pointer that has 32 its pointer association changed in more than one iteration has a processor dependent association 33 status when the construct terminates. 34 · An allocatable object that is allocated in more than one iteration shall be subsequently deallocated 35 during the same iteration in which it was allocated. An object that is allocated or deallocated in 36 only one iteration shall not be deallocated, allocated, referenced, defined, or become undefined in 37 a different iteration. 38 · An input/output statement shall not write data to a file record or position in one iteration and 39 read from the same record or position in a different iteration of the same execution of the construct. 40 · Records written by output statements in the loop range to a sequential access file appear in the 41 file in an indeterminate order. 188 2006/01/05 WORKING DRAFT J3/07-007 NOTE 8.12 The restrictions on referencing variables defined in an iteration of a DO CONCURRENT construct apply to any procedure invoked within the loop. NOTE 8.13 The restrictions on the statements in the loop range of a DO CONCURRENT construct are designed to ensure there are no data dependencies between iterations of the loop. This permits code optimizations that might otherwise be difficult or impossible because they would depend on characteristics of the program not visible to the compiler. 18.1.7.7 Examples of DO constructs NOTE 8.14 The following program fragment computes a tensor product of two arrays: DO I = 1, M DO J = 1, N C (I, J) = SUM (A (I, J, :) * B (:, I, J)) END DO END DO NOTE 8.15 The following program fragment contains a DO construct that uses the WHILE form of loop- control. The loop will continue to execute until an end-of-file or input/output error is encountered, at which point the DO statement terminates the loop. When a negative value of X is read, the program skips immediately to the next READ statement, bypassing most of the range of the loop. READ (IUN, '(1X, G14.7)', IOSTAT = IOS) X DO WHILE (IOS == 0) IF (X >= 0.) THEN CALL SUBA (X) CALL SUBB (X) ... CALL SUBZ (X) ENDIF READ (IUN, '(1X, G14.7)', IOSTAT = IOS) X END DO NOTE 8.16 The following example behaves exactly the same as the one in Note 8.15. However, the READ statement has been moved to the interior of the range, so that only one READ statement is needed. Also, a CYCLE statement has been used to avoid an extra level of IF nesting. DO ! A "DO WHILE + 1/2" loop READ (IUN, '(1X, G14.7)', IOSTAT = IOS) X IF (IOS /= 0) EXIT IF (X < 0.) CYCLE CALL SUBA (X) CALL SUBB (X) 189 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 8.16 (cont.) . . . CALL SUBZ (X) END DO NOTE 8.17 The following example represents a case in which the user knows that the elements of the array IND form a permutation of the integers 1, ..., N. The DO CONCURRENT construct makes it easier for the processor to generate vector gather/scatter code, unroll the loop, or parallelize the code for this loop, potentially improving performance. INTEGER :: A(N,N),IND(N) DO CONCURRENT (I=1:N, J=1:N) A(IND(I),IND(J)) = A(IND(I),IND(J)) + 1 END DO NOTE 8.18 Additional examples of DO constructs are in C.5.3. 18.1.8 IF construct and statement 28.1.8.1 Form of the IF construct 3The IF construct selects for execution at most one of its constituent blocks. The selection is based on 4a sequence of logical expressions. 5R840 if-construct is if-then-stmt 6 block 7 [ else-if-stmt 8 block ] ... 9 [ else-stmt 10 block ] 11 end-if-stmt R841 if-then-stmt is [ if-construct-name : ] IF ( scalar-logical-expr ) THEN 12 R842 else-if-stmt is ELSE IF ( scalar-logical-expr ) THEN [ if-construct-name ] 13 R843 else-stmt is ELSE [ if-construct-name ] 14 R844 end-if-stmt is END IF [ if-construct-name ] 15 16C829 (R840) If the if-then-stmt of an if-construct specifies an if-construct-name, the corresponding 17 end-if-stmt shall specify the same if-construct-name. If the if-then-stmt of an if-construct does 18 not specify an if-construct-name, the corresponding end-if-stmt shall not specify an if-construct- 19 name. If an else-if-stmt or else-stmt specifies an if-construct-name, the corresponding if-then- 20 stmt shall specify the same if-construct-name. 218.1.8.2 Execution of an IF construct 22At most one of the blocks in the IF construct is executed. If there is an ELSE statement in the construct, 23exactly one of the blocks in the construct is executed. The scalar logical expressions are evaluated in 190 2006/01/05 WORKING DRAFT J3/07-007 1the order of their appearance in the construct until a true value is found or an ELSE statement or END 2IF statement is encountered. If a true value or an ELSE statement is found, the block immediately 3following is executed and this completes the execution of the construct. The scalar logical expressions 4in any remaining ELSE IF statements of the IF construct are not evaluated. If none of the evaluated 5expressions is true and there is no ELSE statement, the execution of the construct is completed without 6the execution of any block within the construct. 7It is permissible to branch to an END IF statement only from within its IF construct. Execution of an 8END IF statement has no effect. 98.1.8.3 Examples of IF constructs NOTE 8.19 IF (CVAR == 'RESET') THEN I = 0; J = 0; K = 0 END IF PROOF_DONE: IF (PROP) THEN WRITE (3, '(''QED'')') STOP ELSE PROP = NEXTPROP END IF PROOF_DONE IF (A > 0) THEN B = C/A IF (B > 0) THEN D = 1.0 END IF ELSE IF (C > 0) THEN B = A/C D = -1.0 ELSE B = ABS (MAX (A, C)) D = 0 END IF 108.1.8.4 IF statement 11The IF statement controls the execution of a single action statement based on a single logical expression. R845 if-stmt is IF ( scalar-logical-expr ) action-stmt 12 13C830 (R845) The action-stmt in the if-stmt shall not be an end-function-stmt, end-mp-subprogram- 14 stmt, end-program-stmt, end-subroutine-stmt, or if-stmt. 15Execution of an IF statement causes evaluation of the scalar logical expression. If the value of the 16expression is true, the action statement is executed. If the value is false, the action statement is not 17executed and execution continues. 18The execution of a function reference in the scalar logical expression may affect entities in the action 19statement. 191 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 8.20 An example of an IF statement is: IF (A > 0.0) A = LOG (A) 18.1.9 SELECT TYPE construct 28.1.9.1 Form of the SELECT TYPE construct 3The SELECT TYPE construct selects for execution at most one of its constituent blocks. The 4selection is based on the dynamic type of an expression. A name is associated with the expression or variable (16.4, 16.5.1.6), in the same way as for the ASSOCIATE construct. 5 6R846 select-type-construct is select-type-stmt 7 [ type-guard-stmt 8 block ] ... 9 end-select-type-stmt 10R847 select-type-stmt is [ select-construct-name : ] SELECT TYPE ( [ associate-name => ] selector ) 11 C831 (R847) If selector is not a named variable, associate-name => shall appear. 12 13C832 (R847) If selector is not a variable or is a variable that has a vector subscript, associate-name shall not appear in a variable definition context (16.6.7). 14 C833 (R847) The selector in a select-type-stmt shall be polymorphic. 15 16R848 type-guard-stmt is TYPE IS ( type-spec ) [ select-construct-name ] 17 or CLASS IS ( derived-type-spec ) [ select-construct-name ] or CLASS DEFAULT [ select-construct-name ] 18 19C834 (R848) The type-spec or derived-type-spec shall specify that each length type parameter is as- 20 sumed. 21C835 (R848) The type-spec or derived-type-spec shall not specify a sequence derived type or a type 22 with the BIND attribute. 23C836 (R848) If selector is not unlimited polymorphic, the type-spec or derived-type-spec shall specify 24 an extension of the declared type of selector. 25C837 (R848) For a given select-type-construct, the same type and kind type parameter values shall 26 not be specified in more than one TYPE IS type-guard-stmt and shall not be specified in more 27 than one CLASS IS type-guard-stmt. 28C838 (R848) For a given select-type-construct, there shall be at most one CLASS DEFAULT type- 29 guard-stmt. R849 end-select-type-stmt is END SELECT [ select-construct-name ] 30 31C839 (R846) If the select-type-stmt of a select-type-construct specifies a select-construct-name, the 32 corresponding end-select-type-stmt shall specify the same select-construct-name. If the select- 33 type-stmt of a select-type-construct does not specify a select-construct-name, the corresponding 34 end-select-type-stmt shall not specify a select-construct-name. If a type-guard-stmt specifies a 35 select-construct-name, the corresponding select-type-stmt shall specify the same select-construct- 36 name. 192 2006/01/05 WORKING DRAFT J3/07-007 1The associate name of a SELECT TYPE construct is the associate-name if specified; otherwise it is the 2name that constitutes the selector. 38.1.9.2 Execution of the SELECT TYPE construct 4Execution of a SELECT TYPE construct whose selector is not a variable causes the selector expression 5to be evaluated. 6A SELECT TYPE construct selects at most one block to be executed. During execution of that block, the associate name identifies an entity, which is associated (16.5.1.6) with the selector. 7 8A TYPE IS type guard statement matches the selector if the dynamic type and kind type parameter 9values of the selector are the same as those specified by the statement. A CLASS IS type guard 10statement matches the selector if the dynamic type of the selector is an extension of the type specified 11by the statement and the kind type parameter values specified by the statement are the same as the 12corresponding type parameter values of the dynamic type of the selector. 13The block to be executed is selected as follows. 14 (1) If a TYPE IS type guard statement matches the selector, the block following that statement 15 is executed. 16 (2) Otherwise, if exactly one CLASS IS type guard statement matches the selector, the block 17 following that statement is executed. 18 (3) Otherwise, if several CLASS IS type guard statements match the selector, one of these 19 statements must specify a type that is an extension of all the types specified in the others; 20 the block following that statement is executed. 21 (4) Otherwise, if there is a CLASS DEFAULT type guard statement, the block following that 22 statement is executed. NOTE 8.21 This algorithm does not examine the type guard statements in source text order when it looks for a match; it selects the most particular type guard when there are several potential matches. 23Within the block following a TYPE IS type guard statement, the associating entity (16.5.5) is not 24polymorphic (4.3.1.3), has the type named in the type guard statement, and has the type parameter 25values of the selector. 26Within the block following a CLASS IS type guard statement, the associating entity is polymorphic and 27has the declared type named in the type guard statement. The type parameter values of the associating 28entity are the corresponding type parameter values of the selector. 29Within the block following a CLASS DEFAULT type guard statement, the associating entity is poly- 30morphic and has the same declared type as the selector. The type parameter values of the associating 31entity are those of the declared type of the selector. NOTE 8.22 If the declared type of the selector is T, specifying CLASS DEFAULT has the same effect as specifying CLASS IS (T). 32The other attributes of the associating entity are described in 8.1.3.3. 33It is permissible to branch to an end-select-type-stmt only from within its SELECT TYPE construct. 348.1.9.3 Examples of the SELECT TYPE construct 193 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 8.23 TYPE POINT REAL :: X, Y END TYPE POINT TYPE, EXTENDS(POINT) :: POINT_3D REAL :: Z END TYPE POINT_3D TYPE, EXTENDS(POINT) :: COLOR_POINT INTEGER :: COLOR END TYPE COLOR_POINT TYPE(POINT), TARGET :: P TYPE(POINT_3D), TARGET :: P3 TYPE(COLOR_POINT), TARGET :: C CLASS(POINT), POINTER :: P_OR_C P_OR_C => C SELECT TYPE ( A => P_OR_C ) CLASS IS ( POINT ) ! "CLASS ( POINT ) :: A" implied here PRINT *, A%X, A%Y ! This block gets executed TYPE IS ( POINT_3D ) ! "TYPE ( POINT_3D ) :: A" implied here PRINT *, A%X, A%Y, A%Z END SELECT NOTE 8.24 The following example illustrates the omission of associate-name. It uses the declarations from Note 8.23. P_OR_C => P3 SELECT TYPE ( P_OR_C ) CLASS IS ( POINT ) ! "CLASS ( POINT ) :: P_OR_C" implied here PRINT *, P_OR_C%X, P_OR_C%Y TYPE IS ( POINT_3D ) ! "TYPE ( POINT_3D ) :: P_OR_C" implied here PRINT *, P_OR_C%X, P_OR_C%Y, P_OR_C%Z ! This block gets executed END SELECT 18.1.10 EXIT statement 2The EXIT statement provides one way of terminating a construct. R850 exit-stmt is EXIT [ construct-name ] 3 4C840 If a construct-name appears, the EXIT statement shall be within that construct; otherwise, it 5 shall be within the range of at least one do-construct. 6An EXIT statement belongs to a particular construct. If the EXIT statement contains a construct 7name, it belongs to that construct; otherwise, it belongs to the innermost DO construct in which it 8appears. 194 2006/01/05 WORKING DRAFT J3/07-007 1 C841 An exit-stmt shall not belong to a DO CONCURRENT construct, nor shall it appear within 2 the range of a DO CONCURRENT construct if it belongs to a construct that contains that DO 3 CONCURRENT construct. 4 When an EXIT statement that belongs to a DO construct is executed, it terminates the loop (8.1.7.5.4) 5 and any active loops contained within the terminated loop. When an EXIT statement that belongs to 6 a non-DO construct is executed, it terminates any active loops contained within that construct, and 7 completes execution of that construct. 8.2 Branching 8 9 Branching is used to alter the normal execution sequence. A branch causes a transfer of control from 10 one statement in a scoping unit to a labeled branch target statement in the same scoping unit. Branching 11 may be caused by a GOTO statement, a computed GOTO statement, an arithmetic IF statement, a 12 CALL statement that has an alt-return-spec, or an input/output statement that has an END= or ERR= 13 specifier. Although procedure references and control constructs can cause transfer of control, they are 14 not branches. A branch target statement is an action-stmt, an associate-stmt, an end-associate- 15 stmt, an if-then-stmt, an end-if-stmt, a select-case-stmt, an end-select-stmt, a select-type-stmt, an end- 16 select-type-stmt, a do-stmt, an end-do-stmt, block-stmt, end-block-stmt, critical-stmt, end-critical-stmt, 17 a forall-construct-stmt, a do-term-action-stmt, a do-term-shared-stmt, or a where-construct-stmt. 18 8.2.1 GO TO statement 19 5 20 R851 goto-stmt is GO TO label 21 C842 (R851) The label shall be the statement label of a branch target statement that appears in the 22 same scoping unit as the goto-stmt. 23 Execution of a GO TO statement causes a transfer of control so that the branch target statement 24 identified by the label is executed next. 8.2.2 Computed GO TO statement 25 26 R852 computed-goto-stmt is GO TO ( label-list ) [ , ] scalar-int-expr 27 C843 (R852 Each label in label-list shall be the statement label of a branch target statement that appears in the same 28 scoping unit as the computed-goto-stmt. NOTE 8.25 The same statement label may appear more than once in a label list. 29 Execution of a computed GO TO statement causes evaluation of the scalar integer expression. If this value is i such 30 that 1 i n where n is the number of labels in label-list, a transfer of control occurs so that the next statement executed 31 is the one identified by the ith label in the list of labels. If i is less than 1 or greater than n, the execution sequence 32 continues as though a CONTINUE statement were executed. 338.2.3 Arithmetic IF statement 34 R853 arithmetic-if-stmt is IF ( scalar-numeric-expr ) label , label , label 35 C844 (R853) Each label shall be the label of a branch target statement that appears in the same scoping unit as the 36 arithmetic-if-stmt. 37 C845 (R853) The scalar-numeric-expr shall not be of type complex. 195 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 8.26 The same label may appear more than once in one arithmetic IF statement. 1 Execution of an arithmetic IF statement causes evaluation of the numeric expression followed by a transfer of control. 2 The branch target statement identified by the first label, the second label, or the third label is executed next depending 3 on whether the value of the numeric expression is less than zero, equal to zero, or greater than zero, respectively. 48.3 CONTINUE statement 5Execution of a CONTINUE statement has no effect. 6R854 continue-stmt is CONTINUE 78.4 STOP statement R855 stop-stmt is STOP [ stop-code ] 8 9R856 stop-code is scalar-char-initialization-expr 10 or scalar-int-initialization-expr C846 (R856) The scalar-char-initialization-expr shall be of default kind. 11 C847 (R856) The scalar-int-initialization-expr shall be of default kind. 12 13Execution of a STOP statement causes normal termination of execution of that image. If each image 14of a set of images executes a STOP statement immediately following the execution of a construct that 15performs a synchronization of the images in the set, normal termination of execution occurs for all of 16the images in the set; the executions of all other images are terminated. If termination of execution of 17an image occurs for some other reason, termination of execution occurs on all other images. J3 internal note Unresolved Technical Issue 005 1. Context-dependent meaning (immediately after SYNC ALL) is a bad idea, especially since "immediately following" is not well-defined. 2. Mixing "normal termination" and "error termination" is also probably a bad idea. In the past, STOP has always been "normal", and various other terminations have been "error" (DEALLOCATE of an unallocated allocatable). We have never felt the need to have a special statement for causing error termination, and having "STOP,ALL::" do "normal" termination on some images and "error" termination on other images is baroque. 3. We do not need to have semantics like "what happens when the user presses Control-C"; we have never had anything in the Fortran standard that did that before either. 4. Notation (editorial): we should probably define the term "error termination" and use it in the multiple places we mean that, instead of merely omitting "normal" before "termination". 196 2006/01/05 WORKING DRAFT J3/07-007 J3 internal note (cont.) J3 internal note Unresolved Technical Issue 006 There is no explanation, let alone an adequate one, of when this (termination of execution of remote images) occurs. That means that there is no reason for the processor to terminate any other image, it can just let them run. Surely we want to at least terminate a remote image at the next attempt to SYNC with the image that executes "STOP,ALL::". NOTE 8.27 If all images execute a SYNC ALL statement and immediately afterwards execute a STOP state- ment, normal termination of execution occurs on all images. If only a subset of the images have their executions terminate normally, how soon termination takes place on the other images is processor dependent. 1When an image is terminated by a STOP statement, its stop code, if any, is made available in a 2processor-dependent manner. If any exception (14) is signaling on that image, the processor shall issue 3a warning indicating which exceptions are signaling; this warning shall be on the unit identified by the 4named constant ERROR UNIT (13.8.2.5). It is recommended that the stop code is made available by 5formatted output to the same unit. NOTE 8.28 When normal termination occurs on more than one image, it is expected that a processor-dependent summary of the stop codes and signaling exceptions will be made available. NOTE 8.29 If the stop-code is an integer, it is recommended that the value also be used as the process exit status, if the processor supports that concept. If the integer stop-code is used as the process exit status, the processor might be able to interpret only values within a limited range, or only a limited portion of the integer value (for example, only the least-significant 8 bits). If the stop-code is of type character or does not appear, or if an END PROGRAM statement is executed, it is recommended that the value zero be supplied as the process exit status, if the processor supports that concept. 8.5 Image execution control 6 8.5.1 Image control statements 7 8The execution sequence on each image is as specified in 2.3.6. 9An image control statement affects the execution ordering between images. Each of the following is 10an image control statement: 11 · SYNC ALL statement; 12 · SYNC TEAM statement; 13 · SYNC IMAGES statement; 14 · SYNC MEMORY statement; 197 J3/07-007 WORKING DRAFT 2006/01/05 1 · NOTIFY statement; 2 · QUERY statement; 3 · ALLOCATE or DEALLOCATE statement involving a co-array; · CRITICAL or END CRITICAL statement (8.1.6); 4 5 · OPEN statement with a TEAM= specifier; 6 · CLOSE statement; 7 · END, END BLOCK, or RETURN statement that involves an implicit deallocation of a co-array; 8 · END PROGRAM statement; 9 · CALL statement for a collective subroutine (13.1) or the FORM TEAM intrinsic subroutine (13.7.69). 10 11During an execution of a statement that contains more than one reference to a procedure, at most one 12reference shall cause execution of an image control statement other than CRITICAL, END CRITICAL, 13or CLOSE for a file with a connect term of only one image. 14On each image, the sequence of statements executed before the first image control statement, between 15the execution of two image control statements, or after the last image control statement is known as 16a segment. The segment executed immediately before the execution of an image control statement 17includes the evaluation of all expressions within the statement. 18By execution of image control statements or user-defined ordering (8.5.6), the program can ensure that 19the execution of the ith segment on image P, Pi, either precedes or succeeds the execution of the jth 20segment on another image Q, Qj. If the program does not ensure this, segments Pi and Qj are unordered; 21depending on the relative execution speeds of the images, some or all of the execution of the segment Pi 22may take place at the same time as some or all of the execution of the segment Qj. NOTE 8.30 The set of all segments on all images is partially ordered: the segment Pi precedes segment Qj if and only if there is a sequence of segments starting with Pi and ending with Qj such that each segment of the sequence precedes the next either because they are on the same image or because of the execution of image control statements. 23A scalar co-variable that is of type default integer, default logical, default real, or default bits, and has 24the VOLATILE attribute (5.3.18) may be referenced during the execution of a segment that is unordered 25relative to the execution of a segment in which the co-variable is defined. Otherwise, 26 · if a co-array variable is defined on an image in a segment, it shall not be referenced, defined, or 27 become undefined in a segment on another image unless the segments are ordered, 28 · if the allocation of an allocatable subobject of a co-array or the pointer association of a pointer 29 subobject of a co-array is changed on an image in a segment, that subobject shall not be referenced 30 or defined in a segment on another image unless the segments are ordered, and 31 · if a procedure invocation on image P is in execution in segments Pi, Pi , ..., Pk and defines a +1 32 non-co-array dummy argument, the argument associated entity shall not be referenced, defined, or 33 become undefined on another image Q in a segment Qj unless Qj precedes Pi or succeeds Pk. 198 2006/01/05 WORKING DRAFT J3/07-007 NOTE 8.31 Apart from the effects of volatile variables, the processor may optimize the execution of a segment as if it were the only image in execution. NOTE 8.32 The model upon which the interpretation of a program is based is that there is a permanent memory location for each co-array variable and that all images can access it. In practice, an image may make a copy of a non-volatile co-array variable (in cache or a register, for example) and, as an optimization, defer copying a changed value back to the permanent location while it is still being used. Since the variable is not volatile, it is safe to defer this transfer until the end of the current segment and thereafter to reload from permanent memory any co-array variable that was not defined within the segment. It would not be safe to defer these actions beyond the end of the current segment since another image might reference the variable then. 1If an image P writes a record during the execution of Pi to a file that is opened for direct access with a 2TEAM= specifier, no other image Q shall read or write the record during execution of a segment that 3is unordered with Pi. Furthermore, it shall not read the record in a segment that succeeds Pi unless 4 · after image P writes the record, it executes a FLUSH statement (9.8) for the file during the 5 execution of a segment Pk, where k >= i, and 6 · before image Q reads the record, it executes a FLUSH statement for the file during the execution 7 of a segment Qj that succeeds Pk. NOTE 8.33 The incorrect sequencing of image control statements can halt execution indefinitely. For example, one image might be executing a SYNC ALL statement while another is executing an ALLOCATE statement for a co-array; or one image might be executing a blocking QUERY statement for which an image in its image set never executes the corresponding NOTIFY statement. 88.5.2 SYNC ALL statement R857 sync-all-stmt is SYNC ALL [ ( [ sync-stat-list ] ) ] 9 10R858 sync-stat is STAT = stat-variable 11 or ERRMSG = errmsg-variable 12C848 No specifier shall appear more than once in a given sync-stat-list. 13The STAT= and ERRMSG= specifiers for image execution control statements are described in 8.5.7. 14Execution of a SYNC ALL statement performs a synchronization of all images. Execution on an image, 15M, of the segment following the SYNC ALL statement is delayed until each other image has executed a 16SYNC ALL statement as many times as has image M. The segments that executed before the SYNC ALL 17statement on an image precede the segments that execute after the SYNC ALL statement on another 18image. NOTE 8.34 If synchronization is required when the images commence statement execution, a SYNC ALL statement should be the first executable statement of the main program. This is necessary if the code relies on the initialization of a co-array variable on another image. 199 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 8.35 The processor might have special hardware or employ an optimized algorithm to make the SYNC ALL statement execute efficiently. Here is a simple example of its use. Image 1 reads data and broadcasts it to other images: REAL :: P[*] ... SYNC ALL IF (THIS_IMAGE()==1) THEN READ (*,*) P DO I = 2, NUM_IMAGES() P[I] = P END DO END IF SYNC ALL 18.5.3 SYNC TEAM statement R859 sync-team-stmt is SYNC TEAM ( image-team [ , sync-stat-list ] ) 2 3R860 image-team is scalar-variable 4C849 The image-team shall be a scalar variable of type IMAGE TEAM from the intrinsic module 5 ISO FORTRAN ENV. 6Execution of a SYNC TEAM statement performs a team synchronization, which is a synchronization 7of the images in a team. The team is specified by the value of image-team and shall include the executing 8image. All images of the team shall execute a SYNC TEAM statement with a value of image-team that 9was constructed by corresponding invocations of the intrinsic function FORM TEAM for the team. They 10do not commence executing subsequent statements until all images in the team have executed a SYNC 11TEAM statement for the team an equal number of times since FORM TEAM was invoked for the team. 12If images M and T are any two members of the team, the segments that execute before the statement 13on image M precede the segments that execute after the statement on image T. 14Execution of an OPEN statement with a TEAM= specifier, a CLOSE statement for a unit whose connect 15team consists of more than one image, or a CALL statement for a collective subroutine is interpreted 16as if an execution of a SYNC TEAM statement for the team occurred at the beginning and end of 17execution of the statement. The team is identified by the value of image-team in the statement, is the 18set of all images for a collective subroutine with no TEAM argument, or is the connect team for the 19CLOSE statement. NOTE 8.36 Execution of the FORM TEAM intrinsic subroutine also performs a team synchronization. J3 internal note Unresolved Technical Issue 086 What happens if image-team identifies a team that does not include the image executing the SYNC TEAM statement? (For example, it could be an empty image set.) It would be friendly for this to raise an error in the statement rather than making the program non-conformant. 200 2006/01/05 WORKING DRAFT J3/07-007 NOTE 8.37 In this example the images are divided into two teams, one for an ocean calculation and one for an atmosphere calculation. USE, INTRINSIC :: ISO_FORTRAN_ENV TYPE(IMAGE_TEAM) :: TEAM INTEGER :: N2, STEP, NSTEPS LOGICAL :: OCEAN N2 = NUM_IMAGES()/2 OCEAN = (THIS_IMAGE()<=N2) IF (OCEAN) THEN CALL FORM_TEAM (TEAM, [ (I, I=1,N2) ] ) ELSE CALL FORM_TEAM (TEAM, [ (I, I=N2+1,NUM_IMAGES()) ] ) END IF : ! Initial calculation SYNC ALL DO STEP = 1, NSTEPS IF (OCEAN) THEN DO : ! Ocean calculation SYNC TEAM (TEAM) IF ( ... ) EXIT ! Ready to swap data END DO ELSE DO : ! Atmosphere calculation SYNC TEAM (TEAM) IF ( ... ) EXIT ! Ready to swap data END DO END IF SYNC ALL : ! Swap data END DO In the inner loops, each set of images first works entirely with its own data and each image synchronizes with the rest of its team. The number of synchronizations for the ocean team might differ from the number for the atmosphere team. The SYNC ALL statement that follows is needed to ensure that both teams have done their calculations before data are swapped. 18.5.4 SYNC IMAGES statement R861 sync-images-stmt is SYNC IMAGES ( image-set [ , sync-stat-list ] ) 2 3R862 image-set is int-expr 4 or * 5C850 An image-set that is an int-expr shall be scalar or of rank one. 6If image-set is an array expression, the value of each element shall be positive and not greater than the 7number of images, and there shall be no repeated values. 8If image-set is a scalar expression, its value shall be positive and not greater than the number of images. 201 J3/07-007 WORKING DRAFT 2006/01/05 1An image-set that is an asterisk specifies all images. 2Execution of a SYNC IMAGES statement performs a synchronization of the image with each of the 3other images in the image-set. Execution on an image, M, of the segment following the SYNC IMAGES 4statement is delayed until each other image T in the image-set has executed a SYNC IMAGES statement 5with M in its image-set as many times as image M has executed a SYNC IMAGES statement with T in 6the image-set. The segments that executed before the SYNC IMAGES statement on image M precede 7the segments that execute after the SYNC IMAGES statement on image T. NOTE 8.38 A SYNC IMAGES statement that specifies the single image value THIS IMAGE() in its image set is allowed. This simplifies writing programs for an arbitrary number of images by allowing correct execution in the limiting case of the number of images being equal to one. NOTE 8.39 Execution of SYNC IMAGES (*) on all images has the same effect as execution of SYNC ALL on all images, but SYNC ALL might have better performance. SYNC IMAGES statements are not required to specify the entire image set, or even the same image set, on all images participating in the synchronization. In the following example, image 1 will wait for each of the other images to complete its use of the data. The other images wait for image 1 to set up the data, but do not wait on any of the other images. IF (THIS_IMAGE() == 1) then ! Set up co-array data needed by all other images SYNC IMAGES(*) ELSE SYNC IMAGES(1) ! Use the data set up by image 1 END IF NOTE 8.40 Execution of a SYNC TEAM statement causes all the images of the team to wait for each other. There might, however, be situations where this is not efficient. In the following example, each image synchronizes with its neighbor. INTEGER :: ME, NE, STEP, NSTEPS NE = NUM_IMAGES() ME = THIS_IMAGE() ! Initial calculation SYNC ALL DO STEP = 1, NSTEPS IF (ME > 1) SYNC IMAGES(ME-1) ! Perform calculation IF (ME < NE) SYNC IMAGES(ME+1) END DO SYNC ALL The calculation starts on image 1 since all the others will be waiting on SYNC IMAGES(ME- 1). When this is done, image 2 can start and image 1 can perform its second calculation. This continues until they are all executing different steps at the same time. Eventually, image 1 will 202 2006/01/05 WORKING DRAFT J3/07-007 NOTE 8.40 (cont.) finish and then the others will finish one by one. The SYNC IMAGES syntax involves image-set rather than image-team to allow the set of images to vary from image to image. 18.5.5 NOTIFY and QUERY statements R863 notify-stmt is NOTIFY ( image-set [ , sync-stat-list ] ) 2 R864 query-stmt is QUERY ( image-set [ , query-spec-list ] ) 3 4R865 query-spec is READY = scalar-logical-variable 5 or sync-stat C851 (R864) No specifier shall appear more than once in a given query-spec-list. 6 7Execution on image M of a NOTIFY statement with a different image T in its image-set increments by 81 a record of the number of times, NM T , image M executed such a NOTIFY statement. 9A QUERY statement is blocking if and only if it has no READY= specifier. A QUERY statement is 10satisfied on completion of its execution if and only if it is a blocking QUERY statement or it set the 11variable specified by its READY= specifier to true. 12Let QM T denote the number of times image M has completed the execution of a satisfied QUERY 13statement with a different image T in its image set. Completion of execution on image M of a blocking 14QUERY statement is delayed until, for each different T in its image set, NTM > QM T . 15Execution of a non-blocking QUERY statement on image M causes the scalar-logical-variable of its 16READY= specifier to be assigned the value false if, for a different image T in the image set, NTM 17QM T ; otherwise, true is assigned. 18A NOTIFY statement execution on image T and a satisfied QUERY statement on image M correspond 19if and only if 20 · the NOTIFY statement's image set includes image M, 21 · the QUERY statement's image set includes image T, and 22 · after execution of both statements has completed, NT M = QM T . 23Segments on an image executed before the execution of a NOTIFY statement precede the segments on 24other images that follow its corresponding QUERY statements. NOTE 8.41 The NOTIFY and QUERY statements can be used to order statement executions between a producer and consumer image. INTEGER,PARAMETER :: PRODUCER = 1, CONSUMER = 2 INTEGER :: VALUE[*] LOGICAL :: READY SELECT CASE (THIS_IMAGE()) CASE (PRODUCER) VALUE[CONSUMER] = 3 203 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 8.41 (cont.) NOTIFY (CONSUMER) CASE (CONSUMER) WaitLoop: DO QUERY (PRODUCER,READY=READY) IF (READY) EXIT WaitLoop ! Statements neither referencing VALUE[CONSUMER], nor causing it to ! become defined or undefined END DO WaitLoop ! references to VALUE CASE DEFAULT ! Statements neither referencing VALUE[CONSUMER], nor causing it to ! become defined or undefined END SELECT Unlike SYNC IMAGES statements, the number of notifications and corresponding queries may be unequal. A program can complete with an excess number of notifies. NOTE 8.42 NOTIFY/QUERY pairs can be used in place of SYNC ALL and SYNC IMAGES to achieve better load balancing and allow one image to proceed with calculations while another image is catching up. For example, IF (THIS_IMAGE()==1) THEN DO I=1,100 ... ! Primary processing of column I NOTIFY(2) ! Done with column I END DO SYNC IMAGES(2) ELSE IF (THIS_IMAGE()==2) THEN DO I=1,100 QUERY(1) ! Wait until image 1 is done with column I ... ! Secondary processing of column I END DO SYNC IMAGES(1) END IF 18.5.6 SYNC MEMORY statement 2The SYNC MEMORY statement provides a means of dividing a segment on an image into two segments, 3each of which can be ordered in some user-defined way with respect to segments on other images. R866 sync-memory-stmt is SYNC MEMORY [ ( [ sync-stat-list ] ) ] 4 NOTE 8.43 SYNC MEMORY usually suppresses compiler optimizations that might reorder memory operations across the segment boundary defined by the SYNC MEMORY statement and ensures that all memory operations initiated in the preceding segments in its image complete before any memory operations in the subsequent segment in its image are initiated. It needs to do this unless it can establish that failure to do so could not alter processing on another image. 204 2006/01/05 WORKING DRAFT J3/07-007 1All of the other image control statements include the effect of executing a SYNC MEMORY statement. 2In addition, the other image control statements cause some form of cooperation with other images for 3the purpose of ordering execution between images. NOTE 8.44 A common example of user-written code that can be used in conjunction with SYNC MEMORY to implement specialized schemes for segment ordering is the spin-wait loop. For example: LOGICAL,VOLATILE :: LOCKED[*] = .TRUE. INTEGER :: IAM, P, Q IAM = THIS_IMAGE() IF (IAM == P) THEN ! Preceding segment SYNC MEMORY ! A LOCKED[Q] = .FALSE. ! segment Pi SYNC MEMORY ! B ELSE IF (IAM == Q) THEN DO WHILE (LOCKED); END DO ! segment Qj SYNC MEMORY ! C ! Subsequent segment END IF Here, image Q does not complete the segment Qj until image P executes segment Pi. This ensures that executions of segments before Pi on image P precede executions of segments on image Q after Qj. The first SYNC MEMORY statement (A) ensures that the compiler does not reorder the following statement (locking) with the previous statements, since the lock should be freed only after the work has been completed. The definition of LOCKED[Q] might be deferred to the end of segment Pi. The second SYNC MEMORY statement (B) ends that segment immediately after the definition, minimizing any delay in releasing the lock in segment Qj. The third SYNC MEMORY statement (C) marks the beginning of a new segment, informing the compiler that the values of co-array variables referenced in that segment might have been changed by other images in preceding segments, so need to be loaded from memory. NOTE 8.45 As a second example, the user might have access to an external procedure that performs synchro- nization between images. That library procedure will not necessarily be aware of the mechanisms used by the processor to manage remote data references and definitions, and therefore not, by itself, be able to ensure the correct memory state before and after its reference. The SYNC MEM- ORY statement provides the needed memory ordering that enables the safe use of the external synchronization routine. For example: INTEGER :: IAM REAL :: X[*] IAM = THIS_IMAGE() IF (IAM == 1) X = 1.0 SYNC MEMORY 205 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 8.45 (cont.) CALL EXTERNAL_SYNC() SYNC MEMORY IF (IAM == 2) WRITE(*,*) X[1] where executing the subroutine EXTERNAL SYNC has an image synchronization effect similar to executing a SYNC ALL statement. 8.5.7 STAT= and ERRMSG= specifiers in image execution control statements 1 2If the STAT= specifier appears, successful execution of the SYNC ALL, SYNC TEAM, SYNC IMAGES, 3SYNC MEMORY, NOTIFY, or QUERY statement causes the specified variable to become defined with 4the value zero. If an error occurs during execution of one of these statements, the variable becomes 5defined with a processor-dependent positive integer value. If an error condition occurs during execution 6of a SYNC ALL, SYNC TEAM, SYNC IMAGES, SYNC MEMORY, NOTIFY, or QUERY statement 7that does not contain the STAT= specifier, execution of all images is terminated. 8If the ERRMSG= specifier appears and an error condition occurs during execution of the SYNC ALL, 9SYNC TEAM, SYNC IMAGES, SYNC MEMORY, NOTIFY, or QUERY statement, the processor shall 10assign an explanatory message to the specified variable. If no such condition occurs, the processor shall 11not change the value of the variable. NOTE 8.46 Which errors, if any, are diagnosed is processor dependent. The processor might check that a valid set of images has been provided, with no out-of-range or repeated values. It might test for network time-outs. While the overall program would probably not be able to recover from the failure of an image, it could perhaps provide information on what failed and be able to save some of the program state to a file. 206 2006/01/05 WORKING DRAFT J3/07-007 9 Input/output statements 1 2Input statements provide the means of transferring data from external media to internal storage or 3from an internal file to internal storage. This process is called reading. Output statements provide 4the means of transferring data from internal storage to external media or from internal storage to an 5internal file. This process is called writing. Some input/output statements specify that editing of the 6data is to be performed. 7In addition to the statements that transfer data, there are auxiliary input/output statements to ma- 8nipulate the external medium, or to describe or inquire about the properties of the connection to the 9external medium. 10The input/output statements are the OPEN, CLOSE, READ, WRITE, PRINT, BACKSPACE, END- 11FILE, REWIND, FLUSH, WAIT, and INQUIRE statements. 12The READ statement is a data transfer input statement. The WRITE statement and the PRINT 13statement are data transfer output statements. The OPEN statement and the CLOSE state- 14ment are file connection statements. The INQUIRE statement is a file inquiry statement. The 15BACKSPACE, ENDFILE, and REWIND statements are file positioning statements. 16A file is composed of either a sequence of file storage units (9.2.4) or a sequence of records, which 17provide an extra level of organization to the file. A file composed of records is called a record file. A 18file composed of file storage units is called a stream file. A processor may allow a file to be viewed 19both as a record file and as a stream file; in this case the relationship between the file storage units when 20viewed as a stream file and the records when viewed as a record file is processor dependent. A file is either an external file (9.2) or an internal file (9.3). 21 229.1 Records 23A record is a sequence of values or a sequence of characters. For example, a line on a terminal is usually 24considered to be a record. However, a record does not necessarily correspond to a physical entity. There 25are three kinds of records: (1) formatted; 26 (2) unformatted; 27 (3) endfile. 28 NOTE 9.1 What is called a "record" in Fortran is commonly called a "logical record". There is no concept in Fortran of a "physical record." 299.1.1 Formatted record 30A formatted record consists of a sequence of characters that are representable in the processor; 31however, a processor may prohibit some control characters (3.1) from appearing in a formatted record. 32The length of a formatted record is measured in characters and depends primarily on the number of 33characters put into the record when it is written. However, it may depend on the processor and the 34external medium. The length may be zero. Formatted records may be read or written only by formatted input/output statements. 35 207 J3/07-007 WORKING DRAFT 2006/01/05 1Formatted records may be prepared by means other than Fortran. 29.1.2 Unformatted record 3An unformatted record consists of a sequence of values in a processor-dependent form and may contain 4data of any type or may contain no data. The length of an unformatted record is measured in file storage 5units (9.2.4) and depends on the output list (9.5.3) used when it is written, as well as on the processor 6and the external medium. The length may be zero. Unformatted records may be read or written only by unformatted input/output statements. 7 89.1.3 Endfile record 9An endfile record is written explicitly by the ENDFILE statement; the file shall be connected for 10sequential access. An endfile record is written implicitly to a file connected for sequential access when 11the most recent data transfer statement referring to the file is a data transfer output statement, no 12intervening file positioning statement referring to the file has been executed, and 13 (1) a REWIND or BACKSPACE statement references the unit to which the file is connected, 14 or 15 (2) the unit is closed, either explicitly by a CLOSE statement, implicitly by a program termi- 16 nation not caused by an error condition, or implicitly by another OPEN statement for the 17 same unit. 18An endfile record may occur only as the last record of a file. An endfile record does not have a length 19property. NOTE 9.2 An endfile record does not necessarily have any physical embodiment. The processor may use a record count or other means to register the position of the file at the time an ENDFILE statement is executed, so that it can take appropriate action when that position is reached again during a read operation. The endfile record, however it is implemented, is considered to exist for the BACKSPACE statement (9.7.2). 209.2 External files 21An external file is any file that exists in a medium external to the program. 22At any given time, there is a processor-dependent set of allowed access methods, a processor-dependent 23set of allowed forms, a processor-dependent set of allowed actions, and a processor-dependent set of 24allowed record lengths for a file. NOTE 9.3 For example, the processor-dependent set of allowed actions for a printer would likely include the write action, but not the read action. 25A file may have a name; a file that has a name is called a named file. The name of a named file is 26represented by a character string value. The set of allowable names for a file is processor dependent. NOTE 9.4 Named files that are opened with the TEAM= specifier (9.4.5.17) have the same name on each image of the team. Apart from this, whether a named file on one image is the same as a file with the same name on another image is processor dependent. For code portability, if different files are 208 2006/01/05 WORKING DRAFT J3/07-007 NOTE 9.4 (cont.) needed on each image, different file names should be used. One technique is to incorporate the image number as part of the name. An external file that is connected to a unit has a position property (9.2.3). 1 NOTE 9.5 For more explanatory information on external files, see C.6.1. 29.2.1 File existence 3At any given time, there is a processor-dependent set of external files that exist for a program. A file 4may be known to the processor, yet not exist for a program at a particular time. NOTE 9.6 Security reasons may prevent a file from existing for a program. A newly created file may exist but contain no records. 5To create a file means to cause a file to exist that did not exist previously. To delete a file means to 6terminate the existence of the file. 7All input/output statements may refer to files that exist. An INQUIRE, OPEN, CLOSE, WRITE, 8PRINT, REWIND, FLUSH, or ENDFILE statement also may refer to a file that does not exist. Execu- 9tion of a WRITE, PRINT, or ENDFILE statement referring to a preconnected file that does not exist 10creates the file. 119.2.2 File access 12There are three methods of accessing the data of an external file: sequential, direct, and stream. Some 13files may have more than one allowed access method; other files may be restricted to one access method. NOTE 9.7 For example, a processor may allow only sequential access to a file on magnetic tape. Thus, the set of allowed access methods depends on the file and the processor. 14The method of accessing a file is determined when the file is connected to a unit (9.4.3) or when the file is created if the file is preconnected (9.4.4). 15 169.2.2.1 Sequential access 17Sequential access is a method of accessing the records of an external record file in order. 18When connected for sequential access, an external file has the following properties. 19 (1) The order of the records is the order in which they were written if the direct access method 20 is not a member of the set of allowed access methods for the file. If the direct access method 21 is also a member of the set of allowed access methods for the file, the order of the records 22 is the same as that specified for direct access. In this case, the first record accessible by 23 sequential access is the record whose record number is 1 for direct access. The second record 24 accessible by sequential access is the record whose record number is 2 for direct access, etc. 25 A record that has not been written since the file was created shall not be read. 26 (2) The records of the file are either all formatted or all unformatted, except that the last record 27 of the file may be an endfile record. Unless the previous reference to the file was a data 209 J3/07-007 WORKING DRAFT 2006/01/05 1 transfer output statement, the last record, if any, of the file shall be an endfile record. 2 (3) The records of the file shall be read or written only by sequential access input/output 3 statements. 4 (4) Each record shall be read or written by a single image. The processor shall ensure that once 5 an image commences transferring the data of a record to the file, no other image transfers 6 data to the file until the whole record has been transferred. 79.2.2.2 Direct access 8Direct access is a method of accessing the records of an external record file in arbitrary order. 9When connected for direct access, an external file has the following properties. 10 (1) Each record of the file is uniquely identified by a positive integer called the record number. 11 The record number of a record is specified when the record is written. Once established, 12 the record number of a record can never be changed. The order of the records is the order 13 of their record numbers. NOTE 9.8 A record cannot be deleted; however, a record may be rewritten. 14 (2) The records of the file are either all formatted or all unformatted. If the sequential access 15 method is also a member of the set of allowed access methods for the file, its endfile record, 16 if any, is not considered to be part of the file while it is connected for direct access. If the 17 sequential access method is not a member of the set of allowed access methods for the file, 18 the file shall not contain an endfile record. (3) The records of the file shall be read or written only by direct access input/output statements. 19 (4) All records of the file have the same length. 20 21 (5) Records need not be read or written in the order of their record numbers. Any record may 22 be written into the file while it is connected to a unit. For example, it is permissible to write 23 record 3, even though records 1 and 2 have not been written. Any record may be read from 24 the file while it is connected to a unit, provided that the record has been written since the 25 file was created, and if a READ statement for this connection is permitted. 26 (6) The records of the file shall not be read or written using list-directed formatting (10.10), namelist formatting (10.11), or a nonadvancing input/output statement (9.2.3.1). 27 289.2.2.3 Stream access Stream access is a method of accessing the file storage units (9.2.4) of an external stream file. 29 30The properties of an external file connected for stream access depend on whether the connection is for 31unformatted or formatted access. 32When connected for unformatted stream access, an external file has the following properties. 33 (1) The file storage units of the file shall be read or written only by stream access input/output 34 statements. 35 (2) Each file storage unit in the file is uniquely identified by a positive integer called the position. 36 The first file storage unit in the file is at position 1. The position of each subsequent file 37 storage unit is one greater than that of its preceding file storage unit. 38 (3) If it is possible to position the file, the file storage units need not be read or written in 39 order of their position. For example, it might be permissible to write the file storage unit 40 at position 3, even though the file storage units at positions 1 and 2 have not been written. 41 Any file storage unit may be read from the file while it is connected to a unit, provided that 210 2006/01/05 WORKING DRAFT J3/07-007 1 the file storage unit has been written since the file was created, and if a READ statement 2 for this connection is permitted. 3When connected for formatted stream access, an external file has the following properties. 4 (1) Some file storage units of the file may contain record markers; this imposes a record structure 5 on the file in addition to its stream structure. There might or might not be a record marker 6 at the end of the file. If there is no record marker at the end of the file, the final record is 7 incomplete. (2) No maximum length (9.4.5.13) is applicable to these records. 8 (3) Writing an empty record with no record marker has no effect. 9 NOTE 9.9 Because the record structure is determined from the record markers that are stored in the file itself, an incomplete record at the end of the file is necessarily not empty. 10 (4) The file storage units of the file shall be read or written only by formatted stream access input/output statements. 11 12 (5) Each file storage unit in the file is uniquely identified by a positive integer called the position. 13 The first file storage unit in the file is at position 1. The relationship between positions of 14 successive file storage units is processor dependent; not all positive integers need correspond 15 to valid positions. 16 (6) If it is possible to position the file, the file position can be set to a position that was 17 previously identified by the POS= specifier in an INQUIRE statement. NOTE 9.10 There may be some character positions in the file that do not correspond to characters written; this is because on some processors a record marker may be written to the file as a carriage-return/line- feed or other sequence. The means of determining the position in a file connected for stream access is via the POS= specifier in an INQUIRE statement (9.9.2.21). 18 (7) A processor may prohibit some control characters (3.1) from appearing in a formatted stream 19 file. 9.2.3 File position 20 21Execution of certain input/output statements affects the position of an external file. Certain circum- 22stances can cause the position of a file to become indeterminate. 23The initial point of a file is the position just before the first record or file storage unit. The terminal 24point is the position just after the last record or file storage unit. If there are no records or file storage 25units in the file, the initial point and the terminal point are the same position. 26If a record file is positioned within a record, that record is the current record; otherwise, there is no 27current record. 28Let n be the number of records in the file. If 1 < i n and a file is positioned within the ith record or 29between the (i - 1)th record and the ith record, the (i - 1)th record is the preceding record. If n 1 30and the file is positioned at its terminal point, the preceding record is the nth and last record. If n = 0 31or if a file is positioned at its initial point or within the first record, there is no preceding record. 32If 1 i < n and a file is positioned within the ith record or between the ith and (i + 1)th record, the 33(i+1)th record is the next record. If n 1 and the file is positioned at its initial point, the first record 34is the next record. If n = 0 or if a file is positioned at its terminal point or within the nth (last) record, 35there is no next record. 211 J3/07-007 WORKING DRAFT 2006/01/05 1For a file connected for stream access, the file position is either between two file storage units, at the 2initial point of the file, at the terminal point of the file, or undefined. 9.2.3.1 Advancing and nonadvancing input/output 3 4An advancing input/output statement always positions a record file after the last record read or 5written, unless there is an error condition. 6A nonadvancing input/output statement may position a record file at a character position within 7the current record, or a subsequent record (10.8.2). Using nonadvancing input/output, it is possible to 8read or write a record of the file by a sequence of input/output statements, each accessing a portion 9of the record. It is also possible to read variable-length records and be notified of their lengths. If a 10nonadvancing output statement leaves a file positioned within a current record and no further output 11statement is executed for the file before it is closed or a BACKSPACE, ENDFILE, or REWIND statement 12is executed for it, the effect is as if the output statement were the corresponding advancing output 13statement. 149.2.3.2 File position prior to data transfer 15The positioning of the file prior to data transfer depends on the method of access: sequential, direct, or 16stream. 17For sequential access on input, if there is a current record, the file position is not changed. Otherwise, 18the file is positioned at the beginning of the next record and this record becomes the current record. 19Input shall not occur if there is no next record or if there is a current record and the last data transfer 20statement accessing the file performed output. 21If the file contains an endfile record, the file shall not be positioned after the endfile record prior to data 22transfer. However, a REWIND or BACKSPACE statement may be used to reposition the file. 23For sequential access on output, if there is a current record, the file position is not changed and the 24current record becomes the last record of the file. Otherwise, a new record is created as the next record 25of the file; this new record becomes the last and current record of the file and the file is positioned at 26the beginning of this record. 27For direct access, the file is positioned at the beginning of the record specified by the REC= specifier. 28This record becomes the current record. 29For stream access, the file is positioned immediately before the file storage unit specified by the POS= 30specifier; if there is no POS= specifier, the file position is not changed. 31File positioning for child data transfer statements is described in 9.5.4.7. 329.2.3.3 File position after data transfer 33If an error condition (9.10) occurred, the position of the file is indeterminate. If no error condition 34occurred, but an end-of-file condition (9.10) occurred as a result of reading an endfile record, the file is 35positioned after the endfile record. 36For unformatted stream access, if no error condition occurred, the file position is not changed. For 37unformatted stream output, if the file position exceeds the previous terminal point of the file, the 38terminal point is set to the file position. NOTE 9.11 An unformatted stream output statement with a POS= specifier and an empty output list can have the effect of extending the terminal point of a file without actually writing any data. 212 2006/01/05 WORKING DRAFT J3/07-007 1For formatted stream input, if an end-of-file condition occurred, the file position is not changed. 2For nonadvancing input, if no error condition or end-of-file condition occurred, but an end-of-record 3condition (9.10) occurred, the file is positioned after the record just read. If no error condition, end-of- 4file condition, or end-of-record condition occurred in a nonadvancing input statement, the file position 5is not changed. If no error condition occurred in a nonadvancing output statement, the file position is 6not changed. 7In all other cases, the file is positioned after the record just read or written and that record becomes the 8preceding record. 9For a formatted stream output statement, if no error condition occurred, the terminal point of the file 10is set to the highest-numbered position to which data was transferred by the statement. NOTE 9.12 The highest-numbered position might not be the current one if the output involved T or TL edit descriptors (10.8.1.1) and the statement is a nonadvancing output statement. 9.2.4 File storage units 11 12A file storage unit is the basic unit of storage in a stream file or an unformatted record file. It is the 13unit of file position for stream access, the unit of record length for unformatted files, and the unit of file 14size for all external files. 15Every value in a stream file or an unformatted record file shall occupy an integer number of file storage 16units; if the stream or record file is unformatted, this number shall be the same for all scalar values of 17the same type and type parameters. The number of file storage units required for an item of a given type 18and type parameters may be determined using the IOLENGTH= specifier of the INQUIRE statement (9.9.3). 19 20For a file connected for unformatted stream access, the processor shall not have alignment restrictions 21that prevent a value of any type from being stored at any positive integer file position. 22The number of bits in a file storage unit is given by the constant FILE STORAGE SIZE (13.8.2.6) 23defined in the intrinsic module ISO FORTRAN ENV. It is recommended that the file storage unit be 24an 8-bit octet where this choice is practical. NOTE 9.13 The requirement that every data value occupy an integer number of file storage units implies that data items inherently smaller than a file storage unit will require padding. This suggests that the file storage unit be small to avoid wasted space. Ideally, the file storage unit would be chosen such that padding is never required. A file storage unit of one bit would always meet this goal, but would likely be impractical because of the alignment requirements. The prohibition on alignment restrictions prohibits the processor from requiring data alignments larger than the file storage unit. The 8-bit octet is recommended as a good compromise that is small enough to accommodate the requirements of many applications, yet not so small that the data alignment requirements are likely to cause significant performance problems. 259.3 Internal files 213 J3/07-007 WORKING DRAFT 2006/01/05 1Internal files provide a means of transferring and converting data from internal storage to internal 2storage. 3An internal file is a record file with the following properties. 4 (1) The file is a variable of default, ASCII, or ISO 10646 character type that is not an array 5 section with a vector subscript. (2) A record of an internal file is a scalar character variable. 6 7 (3) If the file is a scalar character variable, it consists of a single record whose length is the same 8 as the length of the scalar character variable. If the file is a character array, it is treated 9 as a sequence of character array elements. Each array element, if any, is a record of the 10 file. The ordering of the records of the file is the same as the ordering of the array elements 11 in the array (6.2.2.1) or the array section (6.2.2.2). Every record of the file has the same 12 length, which is the length of an array element in the array. 13 (4) A record of the internal file becomes defined by writing the record. If the number of 14 characters written in a record is less than the length of the record, the remaining portion 15 of the record is filled with blanks. The number of characters to be written shall not exceed 16 the length of the record. (5) A record may be read only if the record is defined. 17 18 (6) A record of an internal file may become defined (or undefined) by means other than an 19 output statement. For example, the character variable may become defined by a character 20 assignment statement. 21 (7) An internal file is always positioned at the beginning of the first record prior to data transfer, except for child data transfer statements (9.5.4.7). This record becomes the current record. 22 23 (8) The initial value of a connection mode (9.4.1) is the value that would be implied by an 24 initial OPEN statement without the corresponding keyword. 25 (9) Reading and writing records shall be accomplished only by sequential access formatted input/output statements. 26 27 (10) An internal file shall not be specified as the unit in a file connection statement or a file 28 positioning statement. 299.4 File connection 30A unit, specified by an io-unit, provides a means for referring to a file. 31R901 io-unit is file-unit-number 32 or * 33 or internal-file-variable 34R902 file-unit-number is scalar-int-expr 35R903 internal-file-variable is char-variable C901 (R903) The char-variable shall not be an array section with a vector subscript. 36 37C902 (R903) The char-variable shall be of type default character, ASCII character, or ISO 10646 38 character. 39A unit is either an external unit or an internal unit. An external unit is used to refer to an external file 40and is specified by an asterisk or a file-unit-number. The value of file-unit-number shall be nonnegative, 41equal to one of the named constants INPUT UNIT, OUTPUT UNIT, or ERROR UNIT of the ISO - 42FORTRAN ENV module (13.8.2), or a NEWUNIT value (9.4.5.10). An internal unit is used to refer 43to an internal file and is specified by an internal-file-variable or a file-unit-number whose value is equal 44to the unit argument of an active derived-type input/output procedure (9.5.4.7). The value of a file- 214 2006/01/05 WORKING DRAFT J3/07-007 1unit-number shall identify a valid unit. 2The external unit identified by a particular value of a scalar-int-expr is the same external unit in all 3program units of the program, and on all images. NOTE 9.14 In the example: SUBROUTINE A READ (6) X ... SUBROUTINE B N = 6 REWIND N the value 6 used in both program units identifies the same external unit. 4An asterisk identifies particular processor-dependent external units that are preconnected for format- 5ted sequential access (9.5.4.2). These units are also identified by unit numbers defined by the named constants INPUT UNIT and OUTPUT UNIT of the ISO FORTRAN ENV module (13.8.2). 6 7This part of ISO/IEC 1539 identifies a processor-dependent external unit for the purpose of error re- 8porting. This unit shall be preconnected for sequential formatted output. The processor may define this 9to be the same as the output unit identified by an asterisk. This unit is also identified by a unit number 10defined by the named constant ERROR UNIT of the ISO FORTRAN ENV intrinsic module. 119.4.1 Connection modes 12A connection for formatted input/output has several changeable modes: the blank interpretation mode 13(10.8.6), delimiter mode (10.10.4, 10.11.4.1), sign mode (10.8.4), decimal edit mode (10.8.8), I/O round- 14ing mode (10.7.2.3.7), pad mode (9.5.4.4.2), and scale factor (10.8.5). A connection for unformatted input/output has no changeable modes. 15 16Values for the modes of a connection are established when the connection is initiated. If the connection 17is initiated by an OPEN statement, the values are as specified, either explicitly or implicitly, by the 18OPEN statement. If the connection is initiated other than by an OPEN statement (that is, if the file is 19an internal file or preconnected file) the values established are those that would be implied by an initial 20OPEN statement without the corresponding keywords. 21The scale factor cannot be explicitly specified in an OPEN statement; it is implicitly 0. 22The modes of a connection to an external file may be changed by a subsequent OPEN statement that 23modifies the connection. 24The modes of a connection may be temporarily changed by a corresponding keyword specifier in a 25data transfer statement or by an edit descriptor. Keyword specifiers take effect at the beginning of 26execution of the data transfer statement. Edit descriptors take effect when they are encountered in 27format processing. When a data transfer statement terminates, the values for the modes are reset to the 28values in effect immediately before the data transfer statement was executed. 299.4.2 Unit existence 30At any given time, there is a processor-dependent set of external units that exist for a program. 31All input/output statements may refer to units that exist. The CLOSE, INQUIRE, and WAIT state- 215 J3/07-007 WORKING DRAFT 2006/01/05 1ments also may refer to units that do not exist. 29.4.3 Connection of a file to a unit 3An external unit has a property of being connected or not connected. If connected, it refers to an 4external file. An external unit may become connected by preconnection or by the execution of an OPEN 5statement. The property of connection is symmetric; the unit is connected to a file if and only if the file 6is connected to the unit. 7Every input/output statement except an OPEN, CLOSE, INQUIRE, or WAIT statement shall refer to 8a unit that is connected to a file and thereby make use of or affect that file. A file may be connected and not exist (9.2.1). 9 NOTE 9.15 An example is a preconnected external file that has not yet been written. 10A unit shall not be connected to more than one file at the same time, and a file shall not be connected to 11more than one unit at the same time. However, means are provided to change the status of an external 12unit and to connect a unit to a different file. 13This part of ISO/IEC 1539 defines means of portable interoperation with C. C streams are described 14in 7.19.2 of the C International Standard. Whether a unit can be connected to a file that is also 15connected to a C stream is processor dependent. If a unit is connected to a file that is also connected to 16a C stream, the results of performing input/output operations on such a file are processor dependent. 17It is processor dependent whether the files connected to the units INPUT UNIT, OUTPUT UNIT, 18and ERROR UNIT correspond to the predefined C text streams standard input, standard output, and 19standard error. If a procedure defined by means of Fortran and a procedure defined by means other than 20Fortran perform input/output operations on the same external file, the results are processor dependent. 21A procedure defined by means of Fortran and a procedure defined by means other than Fortran can perform input/output operations on different external files without interference. 22 23After an external unit has been disconnected by the execution of a CLOSE statement, it may be con- 24nected again within the same program to the same file or to a different file. After an external file has 25been disconnected by the execution of a CLOSE statement, it may be connected again within the same 26program to the same unit or to a different unit. NOTE 9.16 The only means of referencing a file that has been disconnected is by the appearance of its name in an OPEN or INQUIRE statement. There might be no means of reconnecting an unnamed file once it is disconnected. 27An internal unit is always connected to the internal file designated by the variable that identifies the 28unit. NOTE 9.17 For more explanatory information on file connection properties, see C.6.5. 299.4.4 Preconnection 30Preconnection means that the unit is connected to a file at the beginning of execution of the program 31and therefore it may be specified in input/output statements without the prior execution of an OPEN 32statement. 216 2006/01/05 WORKING DRAFT J3/07-007 19.4.5 OPEN statement 2An OPEN statement initiates or modifies the connection between an external file and a specified unit. 3The OPEN statement may be used to connect an existing file to a unit, create a file that is preconnected, 4create a file and connect it to a unit, or change certain modes of a connection between a file and a unit. 5An external unit may be connected by an OPEN statement in any program unit of a program and, once 6connected, a reference to it may appear in any program unit of the program. 7If the file to be connected to the unit does not exist but is the same as the file to which the unit is 8preconnected, the modes specified by an OPEN statement become a part of the connection. 9If the file to be connected to the unit is not the same as the file to which the unit is connected, the effect 10is as if a CLOSE statement without a STATUS= specifier had been executed for the unit immediately 11prior to the execution of an OPEN statement. 12If a unit is connected to a file that exists, execution of an OPEN statement for that unit is permitted. 13If the FILE= specifier is not included in such an OPEN statement, the file to be connected to the unit 14is the same as the file to which the unit is already connected. 15If the file to be connected to the unit is the same as the file to which the unit is connected, only the 16specifiers for changeable modes (9.4.1) may have values different from those currently in effect. If the 17POSITION= specifier appears in such an OPEN statement, the value specified shall not disagree with 18the current position of the file. If the STATUS= specifier is included in such an OPEN statement, it shall 19be specified with the value OLD. Execution of such an OPEN statement causes any new values of the 20specifiers for changeable modes to be in effect, but does not cause any change in any of the unspecified 21specifiers and the position of the file is unaffected. The ERR=, IOSTAT=, and IOMSG= specifiers from 22any previously executed OPEN statement have no effect on any currently executed OPEN statement. 23A STATUS= specifier with a value of OLD is always allowed when the file to be connected to the unit is 24the same as the file to which the unit is connected. In this case, if the status of the file was SCRATCH 25before execution of the OPEN statement, the file will still be deleted when the unit is closed, and the 26file is still considered to have a status of SCRATCH. 27If a file is already connected to a unit, an OPEN statement on that file with a different unit shall not 28be executed. R904 open-stmt is OPEN ( connect-spec-list ) 29 30R905 connect-spec is [ UNIT = ] file-unit-number 31 or ACCESS = scalar-default-char-expr 32 or ACTION = scalar-default-char-expr 33 or ASYNCHRONOUS = scalar-default-char-expr 34 or BLANK = scalar-default-char-expr 35 or DECIMAL = scalar-default-char-expr 36 or DELIM = scalar-default-char-expr 37 or ENCODING = scalar-default-char-expr 38 or ERR = label 39 or FILE = file-name-expr 40 or FORM = scalar-default-char-expr 41 or IOMSG = iomsg-variable 42 or IOSTAT = scalar-int-variable 43 or NEWUNIT = scalar-int-variable 44 or PAD = scalar-default-char-expr 45 or POSITION = scalar-default-char-expr 46 or RECL = scalar-int-expr 217 J3/07-007 WORKING DRAFT 2006/01/05 1 or ROUND = scalar-default-char-expr 2 or SIGN = scalar-default-char-expr 3 or STATUS = scalar-default-char-expr 4 or TEAM = image-team 5R906 file-name-expr is scalar-default-char-expr 6R907 iomsg-variable is scalar-default-char-variable 7C903 No specifier shall appear more than once in a given connect-spec-list. 8C904 (R904) If the NEWUNIT= specifier does not appear, a file-unit-number shall be specified; if 9 the optional characters UNIT= are omitted, the file-unit-number shall be the first item in the 10 connect-spec-list. 11C905 (R904) The label used in the ERR= specifier shall be the statement label of a branch target 12 statement that appears in the same scoping unit as the OPEN statement. C906 (R904) If a NEWUNIT= specifier appears, a file-unit-number shall not appear. 13 14If the STATUS= specifier has the value NEW or REPLACE, the FILE= specifier shall appear. If the 15STATUS= specifier has the value SCRATCH, the FILE= specifier shall not appear. If the STATUS= 16specifier has the value OLD, the FILE= specifier shall appear unless the unit is connected and the file 17connected to the unit exists. 18If the NEWUNIT= specifier appears in an OPEN statement, either the FILE= specifier shall appear, 19or the STATUS= specifier shall appear with a value of SCRATCH. The unit identified by a NEWUNIT 20value shall not be preconnected. 21A specifier that requires a scalar-default-char-expr may have a limited list of character values. These 22values are listed for each such specifier. Any trailing blanks are ignored. The value specified is without 23regard to case. Some specifiers have a default value if the specifier is omitted. 24The IOSTAT=, ERR=, and IOMSG= specifiers are described in 9.10. NOTE 9.18 An example of an OPEN statement is: OPEN (10, FILE = 'employee.names', ACTION = 'READ', PAD = 'YES') NOTE 9.19 For more explanatory information on the OPEN statement, see C.6.4. 259.4.5.1 ACCESS= specifier in the OPEN statement 26The scalar-default-char-expr shall evaluate to SEQUENTIAL, DIRECT, or STREAM. The ACCESS= 27specifier specifies the access method for the connection of the file as being sequential, direct, or stream. 28If this specifier is omitted, the default value is SEQUENTIAL. For an existing file, the specified access 29method shall be included in the set of allowed access methods for the file. For a new file, the processor 30creates the file with a set of allowed access methods that includes the specified method. 319.4.5.2 ACTION= specifier in the OPEN statement 32The scalar-default-char-expr shall evaluate to READ, WRITE, or READWRITE. READ specifies that 33the WRITE, PRINT, and ENDFILE statements shall not refer to this connection. WRITE specifies 218 2006/01/05 WORKING DRAFT J3/07-007 1that READ statements shall not refer to this connection. READWRITE permits any input/output 2statements to refer to this connection. If this specifier is omitted, the default value is processor dependent. 3If READWRITE is included in the set of allowable actions for a file, both READ and WRITE also shall 4be included in the set of allowed actions for that file. For an existing file, the specified action shall be 5included in the set of allowed actions for the file. For a new file, the processor creates the file with a set 6of allowed actions that includes the specified action. 79.4.5.3 ASYNCHRONOUS= specifier in the OPEN statement 8The scalar-default-char-expr shall evaluate to YES or NO. If YES is specified, asynchronous input/output 9on the unit is allowed. If NO is specified, asynchronous input/output on the unit is not allowed. If this 10specifier is omitted, the default value is NO. 119.4.5.4 BLANK= specifier in the OPEN statement 12The scalar-default-char-expr shall evaluate to NULL or ZERO. The BLANK= specifier is permitted only 13for a connection for formatted input/output. It specifies the current value of the blank interpretation 14mode (10.8.6, 9.5.2.6) for input for this connection. This mode has no effect on output. It is a changeable 15mode (9.4.1). If this specifier is omitted in an OPEN statement that initiates a connection, the default 16value is NULL. 179.4.5.5 DECIMAL= specifier in the OPEN statement 18The scalar-default-char-expr shall evaluate to COMMA or POINT. The DECIMAL= specifier is per- 19mitted only for a connection for formatted input/output. It specifies the current value of the decimal 20edit mode (10.6, 10.8.8, 9.5.2.7) for this connection. This is a changeable mode (9.4.1). If this specifier 21is omitted in an OPEN statement that initiates a connection, the default value is POINT. 229.4.5.6 DELIM= specifier in the OPEN statement 23The scalar-default-char-expr shall evaluate to APOSTROPHE, QUOTE, or NONE. The DELIM= spec- 24ifier is permitted only for a connection for formatted input/output. It specifies the current value of the 25delimiter mode (9.5.2.8) for list-directed (10.10.4) and namelist (10.11.4.1) output for the connection. 26This mode has no effect on input. It is a changeable mode (9.4.1). If this specifier is omitted in an 27OPEN statement that initiates a connection, the default value is NONE. 289.4.5.7 ENCODING= specifier in the OPEN statement 29The scalar-default-char-expr shall evaluate to UTF-8 or DEFAULT. The ENCODING= specifier is 30permitted only for a connection for formatted input/output. The value UTF-8 specifies that the encoding 31form of the file is UTF-8 as specified by ISO/IEC 10646-1:2000. Such a file is called a Unicode file, 32and all characters therein are of ISO 10646 character type. The value UTF-8 shall not be specified if 33the processor does not support the ISO 10646 character type. The value DEFAULT specifies that the 34encoding form of the file is processor-dependent. If this specifier is omitted in an OPEN statement that 35initiates a connection, the default value is DEFAULT. 369.4.5.8 FILE= specifier in the OPEN statement 37The value of the FILE= specifier is the name of the file to be connected to the specified unit. Any trailing 38blanks are ignored. The file-name-expr shall be a name that is allowed by the processor. If this specifier 39is omitted and the unit is not connected to a file, the STATUS= specifier shall be specified with a value 40of SCRATCH; in this case, the connection is made to a processor-dependent file. The interpretation of 41case is processor dependent. 219 J3/07-007 WORKING DRAFT 2006/01/05 19.4.5.9 FORM= specifier in the OPEN statement 2The scalar-default-char-expr shall evaluate to FORMATTED or UNFORMATTED. The FORM= spec- 3ifier determines whether the file is being connected for formatted or unformatted input/output. If this 4specifier is omitted, the default value is UNFORMATTED if the file is being connected for direct access 5or stream access, and the default value is FORMATTED if the file is being connected for sequential 6access. For an existing file, the specified form shall be included in the set of allowed forms for the file. 7For a new file, the processor creates the file with a set of allowed forms that includes the specified form. 89.4.5.10 NEWUNIT= specifier in the OPEN statement 9The variable is defined with a processor determined NEWUNIT value if no error occurs during the 10execution of the OPEN statement. If an error occurs, the processor shall not change the value of the 11variable. 12A NEWUNIT value is a negative number, and shall not be equal to -1, any of the named constants 13ERROR UNIT, INPUT UNIT, or OUTPUT UNIT from the ISO FORTRAN ENV intrinsic module 14(13.8.2), any value used by the processor for the unit argument to a user-defined derived-type in- 15put/output procedure, nor any previous NEWUNIT value that identifies a file that is currently con- 16nected. 179.4.5.11 PAD= specifier in the OPEN statement 18The scalar-default-char-expr shall evaluate to YES or NO. The PAD= specifier is permitted only for a 19connection for formatted input/output. It specifies the current value of the pad mode (9.5.4.4.2, 9.5.2.10) 20for input for this connection. This mode has no effect on output. It is a changeable mode (9.4.1). If this 21specifier is omitted in an OPEN statement that initiates a connection, the default value is YES. 229.4.5.12 POSITION= specifier in the OPEN statement 23The scalar-default-char-expr shall evaluate to ASIS, REWIND, or APPEND. The connection shall be 24for sequential or stream access. A new file is positioned at its initial point. REWIND positions an 25existing file at its initial point. APPEND positions an existing file such that the endfile record is the 26next record, if it has one. If an existing file does not have an endfile record, APPEND positions the 27file at its terminal point. ASIS leaves the position unchanged if the file exists and already is connected. 28ASIS leaves the position unspecified if the file exists but is not connected. If this specifier is omitted, 29the default value is ASIS. 309.4.5.13 RECL= specifier in the OPEN statement 31The value of the RECL= specifier shall be positive. It specifies the length of each record in a file being 32connected for direct access, or specifies the maximum length of a record in a file being connected for 33sequential access. This specifier shall not appear when a file is being connected for stream access. This 34specifier shall appear when a file is being connected for direct access. If this specifier is omitted when 35a file is being connected for sequential access, the default value is processor dependent. If the file is 36being connected for formatted input/output, the length is the number of characters for all records that 37contain only characters of type default character. When a record contains any nondefault characters, 38the effect of the RECL= specifier is processor dependent. If the file is being connected for unformatted 39input/output, the length is measured in file storage units. For an existing file, the value of the RECL= 40specifier shall be included in the set of allowed record lengths for the file. For a new file, the processor 41creates the file with a set of allowed record lengths that includes the specified value. 429.4.5.14 ROUND= specifier in the OPEN statement 220 2006/01/05 WORKING DRAFT J3/07-007 1The scalar-default-char-expr shall evaluate to one of UP, DOWN, ZERO, NEAREST, COMPATIBLE, 2or PROCESSOR DEFINED. The ROUND= specifier is permitted only for a connection for formatted 3input/output. It specifies the current value of the I/O rounding mode (10.7.2.3.7, 9.5.2.13) for this 4connection. This is a changeable mode (9.4.1). If this specifier is omitted in an OPEN statement that initiates a connection, the I/O rounding mode is processor dependent; it shall be one of the above modes. 5 NOTE 9.20 A processor is free to select any I/O rounding mode for the default mode. The mode might correspond to UP, DOWN, ZERO, NEAREST, or COMPATIBLE; or it might be a completely different I/O rounding mode. 69.4.5.15 SIGN= specifier in the OPEN statement 7The scalar-default-char-expr shall evaluate to one of PLUS, SUPPRESS, or PROCESSOR DEFINED. 8The SIGN= specifier is permitted only for a connection for formatted input/output. It specifies the 9current value of the sign mode (10.8.4, 9.5.2.14) for this connection. This is a changeable mode (9.4.1). 10If this specifier is omitted in an OPEN statement that initiates a connection, the default value is PRO- 11CESSOR DEFINED. 129.4.5.16 STATUS= specifier in the OPEN statement 13The scalar-default-char-expr shall evaluate to OLD, NEW, SCRATCH, REPLACE, or UNKNOWN. If 14OLD is specified, the file shall exist. If NEW is specified, the file shall not exist. 15Successful execution of an OPEN statement with NEW specified creates the file and changes the status 16to OLD. If REPLACE is specified and the file does not already exist, the file is created and the status is 17changed to OLD. If REPLACE is specified and the file does exist, the file is deleted, a new file is created 18with the same name, and the status is changed to OLD. If SCRATCH is specified, the file is created 19and connected to the specified unit for use by the program but is deleted at the execution of a CLOSE 20statement referring to the same unit or at the normal termination of the program. NOTE 9.21 SCRATCH shall not be specified with a named file. 21If UNKNOWN is specified, the status is processor dependent. If this specifier is omitted, the default 22value is UNKNOWN. 239.4.5.17 TEAM= specifier in the OPEN statement 24The image-team specifies the connect team for the unit, which is the set of images that are permitted 25to reference the unit. The team shall include the executing image. If there is no TEAM= specifier, the 26connect team consists of only the executing image. 27All images in the connect team, and no others, shall execute the same OPEN statement with identical 28values for the connect-specs. There is an implicit team synchronization. 29If the OPEN statement has a STATUS= specifier with the value SCRATCH, the processor shall connect 30the same file to the unit on all images in the connect team. 31If the connect team contains more than one image, the OPEN statement shall 32 · specify direct access or 33 · specify sequential access and have an ACTION= specifier that evaluates to WRITE. 221 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 9.22 Writing to a sequential file from more than one image without using synchronization is permitted, but is only useful for situations in which the ordering of records is unimportant. An example is for diagnostic output that is labeled with the image index. 1Units connected to a preconnected file, other than the unit identified by the value INPUT UNIT in 2the intrinsic module ISO FORTRAN ENV have a connect team consisting of all the images. The unit 3identified by the value INPUT UNIT in the intrinsic module ISO FORTRAN ENV is preconnected with 4a connect team consisting of image 1 on image 1 and is not preconnected on other images. NOTE 9.23 The input unit identified by * is therefore only available on the image with index one. File position- ing statements and READ are not allowed for preconnected units, including units preconnected to OUTPUT UNIT and ERROR UNIT, if the number of images is greater than one. The FLUSH and INQUIRE statements are always allowed for preconnected units. 59.4.6 CLOSE statement 6The CLOSE statement is used to terminate the connection of a specified unit to an external file. 7Execution of a CLOSE statement for a unit may occur in any program unit of a program and need not 8occur in the same program unit as the execution of an OPEN statement referring to that unit. 9Execution of a CLOSE statement performs a wait operation for any pending asynchronous data transfer 10operations for the specified unit. 11Execution of a CLOSE statement specifying a unit that does not exist or has no file connected to it is 12permitted and affects no file or unit. 13After a unit has been disconnected by execution of a CLOSE statement, it may be connected again 14within the same program, either to the same file or to a different file. After a named file has been 15disconnected by execution of a CLOSE statement, it may be connected again within the same program, 16either to the same unit or to a different unit, provided that the file still exists. 17At normal termination of execution of a program, all units that are connected are closed. Each unit 18is closed with status KEEP unless the file status prior to termination of execution was SCRATCH, in 19which case the unit is closed with status DELETE. NOTE 9.24 The effect is as though a CLOSE statement without a STATUS= specifier were executed on each connected unit. R908 close-stmt is CLOSE ( close-spec-list ) 20 21R909 close-spec is [ UNIT = ] file-unit-number 22 or IOSTAT = scalar-int-variable 23 or IOMSG = iomsg-variable 24 or ERR = label 25 or STATUS = scalar-default-char-expr 26C907 No specifier shall appear more than once in a given close-spec-list. 27C908 A file-unit-number shall be specified in a close-spec-list; if the optional characters UNIT= are 28 omitted, the file-unit-number shall be the first item in the close-spec-list. 222 2006/01/05 WORKING DRAFT J3/07-007 1C909 (R909) The label used in the ERR= specifier shall be the statement label of a branch target 2 statement that appears in the same scoping unit as the CLOSE statement. 3The scalar-default-char-expr has a limited list of character values. Any trailing blanks are ignored. The 4value specified is without regard to case. 5The IOSTAT=, ERR=, and IOMSG= specifiers are described in 9.10. 6If an image executes a CLOSE statement, all images in the connect team of the unit specified shall execute 7a CLOSE statement for the unit with the same disposition. There is an implicit team synchronization 8associated with the execution of a CLOSE statement for a unit with a connect team that has more than one image (8.5.3). 9 NOTE 9.25 An example of a CLOSE statement is: CLOSE (10, STATUS = 'KEEP') NOTE 9.26 For more explanatory information on the CLOSE statement, see C.6.6. 109.4.6.1 STATUS= specifier in the CLOSE statement 11The scalar-default-char-expr shall evaluate to KEEP or DELETE. The STATUS= specifier determines 12the disposition of the file that is connected to the specified unit. KEEP shall not be specified for a file 13whose status prior to execution of a CLOSE statement is SCRATCH. If KEEP is specified for a file that 14exists, the file continues to exist after the execution of a CLOSE statement. If KEEP is specified for a 15file that does not exist, the file will not exist after the execution of a CLOSE statement. If DELETE is 16specified, the file will not exist after the execution of a CLOSE statement. If this specifier is omitted, the 17default value is KEEP, unless the file status prior to execution of the CLOSE statement is SCRATCH, 18in which case the default value is DELETE. 199.5 Data transfer statements 209.5.1 General 21The READ statement is the data transfer input statement. The WRITE statement and the 22PRINT statement are the data transfer output statements. 23R910 read-stmt is READ ( io-control-spec-list ) [ input-item-list ] or READ format [ , input-item-list ] 24 R911 write-stmt is WRITE ( io-control-spec-list ) [ output-item-list ] 25 R912 print-stmt is PRINT format [ , output-item-list ] 26 NOTE 9.27 Examples of data transfer statements are: READ (6, *) SIZE READ 10, A, B WRITE (6, 10) A, S, J PRINT 10, A, S, J 223 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 9.27 (cont.) 10 FORMAT (2E16.3, I5) 19.5.2 Control information list 29.5.2.1 Syntax 3A control information list is an io-control-spec-list. It governs data transfer. 4R913 io-control-spec is [ UNIT = ] io-unit 5 or [ FMT = ] format 6 or [ NML = ] namelist-group-name 7 or ADVANCE = scalar-default-char-expr 8 or ASYNCHRONOUS = scalar-char-initialization-expr 9 or BLANK = scalar-default-char-expr 10 or DECIMAL = scalar-default-char-expr 11 or DELIM = scalar-default-char-expr 12 or END = label 13 or EOR = label 14 or ERR = label 15 or ID = scalar-int-variable 16 or IOMSG = iomsg-variable 17 or IOSTAT = scalar-int-variable 18 or PAD = scalar-default-char-expr 19 or POS = scalar-int-expr 20 or REC = scalar-int-expr 21 or ROUND = scalar-default-char-expr 22 or SIGN = scalar-default-char-expr 23 or SIZE = scalar-int-variable 24C910 No specifier shall appear more than once in a given io-control-spec-list. 25C911 An io-unit shall be specified in an io-control-spec-list; if the optional characters UNIT= are 26 omitted, the io-unit shall be the first item in the io-control-spec-list. C912 (R913) A DELIM= or SIGN= specifier shall not appear in a read-stmt. 27 C913 (R913) A BLANK=, PAD=, END=, EOR=, or SIZE= specifier shall not appear in a write-stmt. 28 29C914 (R913) The label in the ERR=, EOR=, or END= specifier shall be the statement label of a 30 branch target statement that appears in the same scoping unit as the data transfer statement. C915 (R913) A namelist-group-name shall be the name of a namelist group. 31 32C916 (R913) A namelist-group-name shall not appear if an input-item-list or an output-item-list 33 appears in the data transfer statement. C917 (R913) An io-control-spec-list shall not contain both a format and a namelist-group-name. 34 35C918 (R913) If format appears without a preceding FMT=, it shall be the second item in the io- 36 control-spec-list and the first item shall be io-unit. 37C919 (R913) If namelist-group-name appears without a preceding NML=, it shall be the second item 38 in the io-control-spec-list and the first item shall be io-unit. 39C920 (R913) If io-unit is not a file-unit-number, the io-control-spec-list shall not contain a REC= 224 2006/01/05 WORKING DRAFT J3/07-007 1 specifier or a POS= specifier. 2C921 (R913) If the REC= specifier appears, an END= specifier shall not appear, a namelist-group- 3 name shall not appear, and the format, if any, shall not be an asterisk. 4C922 (R913) An ADVANCE= specifier may appear only in a formatted sequential or stream in- 5 put/output statement with explicit format specification (10.2) whose control information list 6 does not contain an internal-file-variable as the io-unit. C923 (R913) If an EOR= specifier appears, an ADVANCE= specifier also shall appear. 7 C924 (R913) If a SIZE= specifier appears, an ADVANCE= specifier also shall appear. 8 9C925 (R913) The scalar-char-initialization-expr in an ASYNCHRONOUS= specifier shall be of type 10 default character and shall have the value YES or NO. 11C926 (R913) An ASYNCHRONOUS= specifier with a value YES shall not appear unless io-unit is a 12 file-unit-number. 13C927 (R913) If an ID= specifier appears, an ASYNCHRONOUS= specifier with the value YES shall 14 also appear. C928 (R913) If a POS= specifier appears, the io-control-spec-list shall not contain a REC= specifier. 15 16C929 (R913) If a DECIMAL=, BLANK=, PAD=, SIGN=, or ROUND= specifier appears, a format 17 or namelist-group-name shall also appear. 18C930 (R913) If a DELIM= specifier appears, either format shall be an asterisk or namelist-group-name 19 shall appear. 20A SIZE= specifier may appear only in an input statement that contains an ADVANCE= specifier with 21the value NO. 22An EOR= specifier may appear only in an input statement that contains an ADVANCE= specifier with 23the value NO. 24If the data transfer statement contains a format or namelist-group-name, the statement is a formatted input/output statement; otherwise, it is an unformatted input/output statement. 25 26The ADVANCE=, ASYNCHRONOUS=, DECIMAL=, BLANK=, DELIM=, PAD=, SIGN=, and 27ROUND= specifiers have a limited list of character values. Any trailing blanks are ignored. The 28values specified are without regard to case. 29The IOSTAT=, ERR=, EOR=, END=, and IOMSG= specifiers are described in 9.10. NOTE 9.28 An example of a READ statement is: READ (IOSTAT = IOS, UNIT = 6, FMT = '(10F8.2)') A, B 309.5.2.2 Format specification in a data transfer statement 31The format specifier supplies a format specification or specifies list-directed formatting for a formatted input/output statement. 32 33R914 format is default-char-expr 34 or label 225 J3/07-007 WORKING DRAFT 2006/01/05 1 or * 2C931 (R914) The label shall be the label of a FORMAT statement that appears in the same scoping 3 unit as the statement containing the FMT= specifier. The default-char-expr shall evaluate to a valid format specification (10.2.1 and 10.2.2). 4 NOTE 9.29 A default-char-expr includes a character constant. 5If default-char-expr is an array, it is treated as if all of the elements of the array were specified in array 6element order and were concatenated. If format is *, the statement is a list-directed input/output statement. 7 NOTE 9.30 An example in which the format is a character expression is: READ (6, FMT = "(" // CHAR_FMT // ")" ) X, Y, Z where CHAR FMT is a default character variable. 89.5.2.3 NML= specifier in a data transfer statement 9The NML= specifier supplies the namelist-group-name (5.6). This name identifies a particular collection 10of data objects on which transfer is to be performed. If a namelist-group-name appears, the statement is a namelist input/output statement. 11 129.5.2.4 ADVANCE= specifier in a data transfer statement 13The scalar-default-char-expr shall evaluate to YES or NO. The ADVANCE= specifier determines wheth- 14er advancing input/output occurs for a nonchild input/output statement. If YES is specified for a 15nonchild input/output statement, advancing input/output occurs. If NO is specified, nonadvancing in- 16put/output occurs (9.2.3.1). If this specifier is omitted from a nonchild input/output statement that 17allows the specifier, the default value is YES. A formatted child input/output statement is a nonadvanc- ing input/output statement, and any ADVANCE= specifier is ignored. 18 199.5.2.5 ASYNCHRONOUS= specifier in a data transfer statement 20The ASYNCHRONOUS= specifier determines whether this input/output statement is synchronous or 21asynchronous. If YES is specified, the statement and the input/output operation are asynchronous. 22If NO is specified or if the specifier is omitted, the statement and the input/output operation are 23synchronous. 24Asynchronous input/output is permitted only for external files opened with an ASYNCHRONOUS= 25specifier with the value YES in the OPEN statement. NOTE 9.31 Both synchronous and asynchronous input/output are allowed for files opened with an ASYN- CHRONOUS= specifier of YES. For other files, only synchronous input/output is allowed; this includes files opened with an ASYNCHRONOUS= specifier of NO, files opened without an ASYN- CHRONOUS= specifier, preconnected files accessed without an OPEN statement, and internal files. 226 2006/01/05 WORKING DRAFT J3/07-007 NOTE 9.31 (cont.) The ASYNCHRONOUS= specifier value in a data transfer statement is an initialization expression because it effects compiler optimizations and, therefore, needs to be known at compile time. 1The processor may perform an asynchronous data transfer operation asynchronously, but it is not re- 2quired to do so. For each external file, records and file storage units read or written by asynchronous 3data transfer statements are read, written, and processed in the same order as they would have been if 4the data transfer statements were synchronous. 5If a variable is used in an asynchronous data transfer statement as (1) an item in an input/output list, 6 (2) a group object in a namelist, or 7 (3) a SIZE= specifier 8 9the base object of the data-ref is implicitly given the ASYNCHRONOUS attribute in the scoping unit 10of the data transfer statement. This attribute may be confirmed by explicit declaration. 11When an asynchronous input/output statement is executed, the set of storage units specified by the 12item list or NML= specifier, plus the storage units specified by the SIZE= specifier, is defined to be the pending input/output storage sequence for the data transfer operation. 13 NOTE 9.32 A pending input/output storage sequence is not necessarily a contiguous set of storage units. 14A pending input/output storage sequence affector is a variable of which any part is associated with a storage unit in a pending input/output storage sequence. 15 169.5.2.6 BLANK= specifier in a data transfer statement 17The scalar-default-char-expr shall evaluate to NULL or ZERO. The BLANK= specifier temporarily 18changes (9.4.1) the blank interpretation mode (10.8.6, 9.4.5.4) for the connection. If the specifier is 19omitted, the mode is not changed. 209.5.2.7 DECIMAL= specifier in a data transfer statement 21The scalar-default-char-expr shall evaluate to COMMA or POINT. The DECIMAL= specifier temporar- 22ily changes (9.4.1) the decimal edit mode (10.6, 10.8.8, 9.4.5.5) for the connection. If the specifier is 23omitted, the mode is not changed. 249.5.2.8 DELIM= specifier in a data transfer statement 25The scalar-default-char-expr shall evaluate to APOSTROPHE, QUOTE, or NONE. The DELIM= spec- 26ifier temporarily changes (9.4.1) the delimiter mode (10.10.4, 10.11.4.1, 9.4.5.6) for the connection. If 27the specifier is omitted, the mode is not changed. 289.5.2.9 ID= specifier in a data transfer statement 29Successful execution of an asynchronous data transfer statement containing an ID= specifier causes the 30variable specified in the ID= specifier to become defined with a processor determined value. This value 31is referred to as the identifier of the data transfer operation. It can be used in a subsequent WAIT or 32INQUIRE statement to identify the particular data transfer operation. 33If an error occurs during the execution of a data transfer statement containing an ID= specifier, the variable specified in the ID= specifier becomes undefined. 227 J3/07-007 WORKING DRAFT 2006/01/05 1A child data transfer statement shall not specify the ID= specifier. 29.5.2.10 PAD= specifier in a data transfer statement 3The scalar-default-char-expr shall evaluate to YES or NO. The PAD= specifier temporarily changes 4(9.4.1) the pad mode (9.5.4.4.2, 9.4.5.11) for the connection. If the specifier is omitted, the mode is not 5changed. 69.5.2.11 POS= specifier in a data transfer statement 7The POS= specifier specifies the file position in file storage units. This specifier may appear in a data 8transfer statement only if the statement specifies a unit connected for stream access. A child data 9transfer statement shall not specify this specifier. 10A processor may prohibit the use of POS= with particular files that do not have the properties necessary 11to support random positioning. A processor may also prohibit positioning a particular file to any 12position prior to its current file position if the file does not have the properties necessary to support such 13positioning. NOTE 9.33 A unit that is connected to a device or data stream might not be positionable. 14If the file is connected for formatted stream access, the file position specified by POS= shall be equal to 15either 1 (the beginning of the file) or a value previously returned by a POS= specifier in an INQUIRE 16statement for the file. 179.5.2.12 REC= specifier in a data transfer statement 18The REC= specifier specifies the number of the record that is to be read or written. This specifier 19may appear only in an input/output statement that specifies a unit connected for direct access; it 20shall not appear in a child data transfer statement. If the control information list contains a REC= 21specifier, the statement is a direct access input/output statement. A child data transfer statement 22is a direct access data transfer statement if the parent is a direct access data transfer statement. Any 23other data transfer statement is a sequential access input/output statement or a stream access 24input/output statement, depending on whether the file connection is for sequential access or stream 25access. 269.5.2.13 ROUND= specifier in a data transfer statement 27The scalar-default-char-expr shall evaluate to one of the values specified in 9.4.5.14. The ROUND= 28specifier temporarily changes (9.4.1) the I/O rounding mode (10.7.2.3.7, 9.4.5.14) for the connection. If 29the specifier is omitted, the mode is not changed. 309.5.2.14 SIGN= specifier in a data transfer statement 31The scalar-default-char-expr shall evaluate to PLUS, SUPPRESS, or PROCESSOR DEFINED. The 32SIGN= specifier temporarily changes (9.4.1) the sign mode (10.8.4, 9.4.5.15) for the connection. If the 33specifier is omitted, the mode is not changed. 349.5.2.15 SIZE= specifier in a data transfer statement 35When a synchronous nonadvancing input statement terminates, the variable specified in the SIZE= 36specifier becomes defined with the count of the characters transferred by data edit descriptors during execution of the current input statement. Blanks inserted as padding (9.5.4.4.2) are not counted. 37 228 2006/01/05 WORKING DRAFT J3/07-007 1For asynchronous nonadvancing input, the storage units specified in the SIZE= specifier become defined 2with the count of the characters transferred when the corresponding wait operation is executed. 9.5.3 Data transfer input/output list 3 4An input/output list specifies the entities whose values are transferred by a data transfer input/output 5statement. 6R915 input-item is variable 7 or io-implied-do 8R916 output-item is expr 9 or io-implied-do R917 io-implied-do is ( io-implied-do-object-list , io-implied-do-control ) 10 11R918 io-implied-do-object is input-item 12 or output-item 13R919 io-implied-do-control is do-variable = scalar-int-expr , scalar-int-expr [ , scalar-int-expr ] 14 C932 (R915) A variable that is an input-item shall not be a whole assumed-size array. 15 C933 (R915) A variable that is an input-item shall not be a procedure pointer. 16 C934 (R919) The do-variable shall be a named scalar variable of type integer. 17 18C935 (R918) In an input-item-list, an io-implied-do-object shall be an input-item. In an output-item- 19 list, an io-implied-do-object shall be an output-item. C936 (R916) An expression that is an output-item shall not have a value that is a procedure pointer. 20 21An input-item shall not appear as, nor be associated with, the do-variable of any io-implied-do that 22contains the input-item. NOTE 9.34 A constant, an expression involving operators or function references that does not have a pointer result, or an expression enclosed in parentheses shall not appear as an input list item. 23If an input item is a pointer, it shall be associated with a definable target and data are transferred from 24the file to the associated target. If an output item is a pointer, it shall be associated with a target and 25data are transferred from the target to the file. NOTE 9.35 Data transfers always involve the movement of values between a file and internal storage. A pointer as such cannot be read or written. Therefore, a pointer shall not appear as an item in an input/output list unless it is associated with a target that can receive a value (input) or can deliver a value (output). 26If an input item or an output item is allocatable, it shall be allocated. 27A list item shall not be polymorphic unless it is processed by a user-defined derived-type input/output procedure (9.5.4.7). 28 29The do-variable of an io-implied-do that is in another io-implied-do shall not appear as, nor be associated 229 J3/07-007 WORKING DRAFT 2006/01/05 1with, the do-variable of the containing io-implied-do. 2The following rules describing whether to expand an input/output list item are re-applied to each 3expanded list item until none of the rules apply. 4 · If an array appears as an input/output list item, it is treated as if the elements, if any, were 5 specified in array element order (6.2.2.1). However, no element of that array may affect the value 6 of any expression in the input-item, nor may any element appear more than once in an input-item. NOTE 9.36 For example: INTEGER A (100), J (100) ... READ *, A (A) ! Not allowed READ *, A (LBOUND (A, 1) : UBOUND (A, 1)) ! Allowed READ *, A (J) ! Allowed if no two elements ! of J have the same value A(1) = 1; A(10) = 10 READ *, A (A (1) : A (10)) ! Not allowed 7 · If a list item of derived type in an unformatted input/output statement is not processed by a 8 user-defined derived-type input/output procedure (9.5.4.7), and if any subobject of that list item 9 would be processed by a user-defined derived-type input/output procedure, the list item is treated 10 as if all of the components of the object were specified in the list in component order (4.5.4.6); 11 those components shall be accessible in the scoping unit containing the input/output statement 12 and shall not be pointers or allocatable. 13 · An effective input/output list item of derived type in an unformatted input/output statement is 14 treated as a single value in a processor-dependent form unless the list item or a subobject thereof is processed by a user-defined derived-type input/output procedure (9.5.4.7). 15 NOTE 9.37 The appearance of a derived-type object as an input/output list item in an unformatted in- put/output statement is not equivalent to the list of its components. Unformatted input/output involving derived-type list items forms the single exception to the rule that the appearance of an aggregate list item (such as an array) is equivalent to the appearance of its expanded list of component parts. This exception permits the processor greater latitude in improving efficiency or in matching the processor-dependent sequence of values for a derived-type object to similar sequences for aggregate objects used by means other than Fortran. However, formatted input/output of all list items and unformatted input/output of list items other than those of derived types adhere to the above rule. 16 · If a list item of derived type in a formatted input/output statement is not processed by a user- 17 defined derived-type input/output procedure, that list item is treated as if all of the components 18 of the list item were specified in the list in component order; those components shall be accessible in the scoping unit containing the input/output statement and shall not be pointers or allocatable. 19 20 · If a derived-type list item is not treated as a list of its individual components, that list item's 21 ultimate components shall not have the POINTER or ALLOCATABLE attribute unless that list item is processed by a user-defined derived-type input/output procedure. 22 23 · The scalar objects resulting when a data transfer statement's list items are expanded according 24 to the rules in this subclause for handling array and derived-type list items are called effective 230 2006/01/05 WORKING DRAFT J3/07-007 1 items. Zero-sized arrays and io-implied-dos with an iteration count of zero do not contribute to 2 the effective list items. A scalar character item of zero length is an effective list item. NOTE 9.38 In a formatted input/output statement, edit descriptors are associated with effective list items, which are always scalar. The rules in 9.5.3 determine the set of effective list items corresponding to each actual list item in the statement. These rules might have to be applied repetitively until all of the effective list items are scalar items. 3 · For an io-implied-do, the loop initialization and execution are the same as for a DO construct (8.1.7.5). 4 NOTE 9.39 An example of an output list with an implied DO is: WRITE (LP, FMT = '(10F8.2)') (LOG (A (I)), I = 1, N + 9, K), G 5 · An input/output list shall not contain an item of nondefault character type if the input/output 6 statement specifies an internal file of default character type. An input/output list shall not con- 7 tain an item of nondefault character type other than ISO 10646 or ASCII character type if the 8 input/output statement specifies an internal file of ISO 10646 character type. An input/output 9 list shall not contain a character item of any character type other than ASCII character type if the input/output statement specifies an internal file of ASCII character type. 10 9.5.4 Execution of a data transfer input/output statement 11 12Execution of a WRITE or PRINT statement for a file that does not exist creates the file unless an error 13condition occurs. 14The effect of executing a synchronous data transfer input/output statement shall be as if the following 15operations were performed in the order specified. (1) Determine the direction of data transfer. 16 (2) Identify the unit. 17 18 (3) Perform a wait operation for all pending input/output operations for the unit. If an error, 19 end-of-file, or end-of-record condition occurs during any of the wait operations, steps 4 20 through 8 are skipped for the current data transfer statement. (4) Establish the format if one is specified. 21 (5) If the statement is not a child data transfer statement (9.5.4.7), 22 (a) position the file prior to data transfer (9.2.3.2), and 23 (b) for formatted data transfer, set the left tab limit (10.8.1.1). 24 25 (6) Transfer data between the file and the entities specified by the input/output list (if any) or 26 namelist. (7) Determine whether an error, end-of-file, or end-of-record condition has occurred. 27 28 (8) Position the file after data transfer (9.2.3.3) unless the statement is a child data transfer statement (9.5.4.7). 29 (9) Cause any variable specified in a SIZE= specifier to become defined. 30 31 (10) If an error, end-of-file, or end-of-record condition occurred, processing continues as specified 32 in 9.10; otherwise any variable specified in an IOSTAT= specifier is assigned the value zero. 33The effect of executing an asynchronous data transfer input/output statement shall be as if the following 34operations were performed in the order specified. 231 J3/07-007 WORKING DRAFT 2006/01/05 (1) Determine the direction of data transfer. 1 (2) Identify the unit. 2 (3) Establish the format if one is specified. 3 4 (4) Position the file prior to data transfer (9.2.3.2) and, for formatted data transfer, set the left tab limit (10.8.1.1). 5 6 (5) Establish the set of storage units identified by the input/output list. For a READ statement, 7 this might require some or all of the data in the file to be read if an input variable is used 8 as a scalar-int-expr in an io-implied-do-control in the input/output list, as a subscript, 9 substring-range, stride, or is otherwise referenced. 10 (6) Initiate an asynchronous data transfer between the file and the entities specified by the 11 input/output list (if any) or namelist. The asynchronous data transfer may complete (and 12 an error, end-of-file, or end-of-record condition may occur) during the execution of this data 13 transfer statement or during a later wait operation. 14 (7) Determine whether an error, end-of-file, or end-of-record condition has occurred. The con- 15 ditions may occur during the execution of this data transfer statement or during the corre- 16 sponding wait operation, but not both. 17 Also, any of these conditions that would have occurred during the corresponding wait oper- 18 ation for a previously pending data transfer operation that does not have an ID= specifier 19 may occur during the execution of this data transfer statement. J3 internal note Unresolved Technical Issue 091 Contradiction; two paragraphs earlier, we say it occurs during the execution of the original i/o statement or "during a later wait operation". There is no wait operation in an async i/o statement. The best fix for this is to probably add an additional action to the list: "Optionally, perform a wait operation for a pending input/output operation for this unit." Also, note the difference in specification between this item (para 1) and the text four paragraphs after the list on wait operations. These should be consistent, and preferably specified only once. (8) Position the file as if the data transfer had finished (9.2.3.3). 20 (9) Cause any variable specified in a SIZE= specifier to become undefined. 21 22 (10) If an error, end-of-file, or end-of-record condition occurred, processing continues as specified 23 in 9.10; otherwise any variable specified in an IOSTAT= specifier is assigned the value zero. 24For an asynchronous data transfer statement, the data transfers may occur during execution of the 25statement, during execution of the corresponding wait operation, or anywhere between. The data transfer 26operation is considered to be pending until a corresponding wait operation is performed. 27For asynchronous output, a pending input/output storage sequence affector (9.5.2.5) shall not be rede- 28fined, become undefined, or have its pointer association status changed. 29For asynchronous input, a pending input/output storage sequence affector shall not be referenced, be- 30come defined, become undefined, become associated with a dummy argument that has the VALUE 31attribute, or have its pointer association status changed. 32Error, end-of-file, and end-of-record conditions in an asynchronous data transfer operation may occur 33during execution of either the data transfer statement or the corresponding wait operation. If an ID= 34specifier does not appear in the initiating data transfer statement, the conditions may occur during the 35execution of any subsequent data transfer or wait operation for the same unit. When a condition occurs 36for a previously executed asynchronous data transfer statement, a wait operation is performed for all 37pending data transfer operations on that unit. When a condition occurs during a subsequent statement, 38any actions specified by IOSTAT=, IOMSG=, ERR=, END=, and EOR= specifiers for that statement 39are taken. 232 2006/01/05 WORKING DRAFT J3/07-007 NOTE 9.40 Because end-of-file and error conditions for asynchronous data transfer statements without an ID= specifier may be reported by the processor during the execution of a subsequent data transfer statement, it may be impossible for the user to determine which input/output statement caused the condition. Reliably detecting which READ statement caused an end-of-file condition requires that all asynchronous READ statements for the unit include an ID= specifier. 19.5.4.1 Direction of data transfer 2Execution of a READ statement causes values to be transferred from a file to the entities specified by 3the input list, if any, or specified within the file itself for namelist input. Execution of a WRITE or 4PRINT statement causes values to be transferred to a file from the entities specified by the output list 5and format specification, if any, or by the namelist-group-name for namelist output. 69.5.4.2 Identifying a unit 7A data transfer input/output statement that contains an input/output control list includes a UNIT= 8specifier that identifies an external or internal unit. A READ statement that does not contain an 9input/output control list specifies a particular processor-dependent unit, which is the same as the unit 10identified by * in a READ statement that contains an input/output control list. The PRINT statement 11specifies some other processor-dependent unit, which is the same as the unit identified by * in a WRITE statement. Thus, each data transfer input/output statement identifies an external or internal unit. 12 13The unit identified by an unformatted data transfer statement shall be an external unit. 14The unit identified by a data transfer input/output statement shall be connected to a file when execution 15of the statement begins. NOTE 9.41 The unit may be preconnected. 169.5.4.3 Establishing a format 17If the input/output control list contains * as a format, list-directed formatting is established. If namelist- 18group-name appears, namelist formatting is established. If no format or namelist-group-name is speci- 19fied, unformatted data transfer is established. Otherwise, the format specified by format is established. 20For output to an internal file, a format specification that is in the file or is associated with the file shall 21not be specified. 229.5.4.4 Data transfer 23Data are transferred between the file and the entities specified by the input/output list or namelist. 24The list items are processed in the order of the input/output list for all data transfer input/output 25statements except namelist formatted data transfer statements. The list items for a namelist input 26statement are processed in the order of the entities specified within the input records. The list items 27for a namelist output statement are processed in the order in which the variables are specified in the 28namelist-group-object-list. Effective items are derived from the input/output list items as described in 299.5.3. 30All values needed to determine which entities are specified by an input/output list item are determined 31at the beginning of the processing of that item. 32All values are transmitted to or from the entities specified by a list item prior to the processing of any succeeding list item for all data transfer input/output statements. 233 J3/07-007 WORKING DRAFT 2006/01/05 1 NOTE 9.42 In the example, READ (N) N, X (N) the old value of N identifies the unit, but the new value of N is the subscript of X. 2All values following the name= part of the namelist entity (10.11) within the input records are transmit- 3ted to the matching entity specified in the namelist-group-object-list prior to processing any succeeding 4entity within the input record for namelist input statements. If an entity is specified more than once 5within the input record during a namelist formatted data transfer input statement, the last occurrence 6of the entity specifies the value or values to be used for that entity. 7An input list item, or an entity associated with it, shall not contain any portion of an established format 8specification. If the input/output item is a pointer, data are transferred between the file and the associated target. 9 10If an internal file has been specified, an input/output list item shall not be in the file or associated with 11the file. NOTE 9.43 The file is a data object. 12A DO variable becomes defined and its iteration count established at the beginning of processing of the 13items that constitute the range of an io-implied-do. 14On output, every entity whose value is to be transferred shall be defined. 159.5.4.4.1 Unformatted data transfer 16During unformatted data transfer, data are transferred without editing between the file and the entities 17specified by the input/output list. If the file is connected for sequential or direct access, exactly one 18record is read or written. 19A value in the file is stored in a contiguous sequence of file storage units, beginning with the file storage 20unit immediately following the current file position. 21After each value is transferred, the current file position is moved to a point immediately after the last 22file storage unit of the value. 23On input from a file connected for sequential or direct access, the number of file storage units required 24by the input list shall be less than or equal to the number of file storage units in the record. 25On input, if the file storage units transferred do not contain a value with the same type and type 26parameters as the input list entity, then the resulting value of the entity is processor-dependent except 27in the following cases. 28 (1) A complex entity may correspond to two real values with the same kind type parameter as 29 the complex entity. 30 (2) A default character list entity of length n may correspond to n default characters stored in 31 the file, regardless of the length parameters of the entities that were written to these storage 32 units of the file. If the file is connected for stream input, the characters may have been 33 written by formatted stream output. 234 2006/01/05 WORKING DRAFT J3/07-007 1On output to a file connected for unformatted direct access, the output list shall not specify more values 2than can fit into the record. If the file is connected for direct access and the values specified by the 3output list do not fill the record, the remainder of the record is undefined. 4If the file is connected for unformatted sequential access, the record is created with a length sufficient 5to hold the values from the output list. This length shall be one of the set of allowed record lengths for 6the file and shall not exceed the value specified in the RECL= specifier, if any, of the OPEN statement 7that established the connection. If the file is not connected for unformatted input/output, unformatted data transfer is prohibited. 8 99.5.4.4.2 Formatted data transfer 10During formatted data transfer, data are transferred with editing between the file and the entities 11specified by the input/output list or by the namelist-group-name. Format control is initiated and editing 12is performed as described in Clause 10. 13The current record and possibly additional records are read or written. If the file is not connected for formatted input/output, formatted data transfer is prohibited. 14 15During advancing input when the pad mode has the value NO, the input list and format specification 16shall not require more characters from the record than the record contains. 17During advancing input when the pad mode has the value YES, blank characters are supplied by the 18processor if the input list and format specification require more characters from the record than the 19record contains. 20During nonadvancing input when the pad mode has the value NO, an end-of-record condition (9.10) 21occurs if the input list and format specification require more characters from the record than the record 22contains, and the record is complete (9.2.2.3). If the record is incomplete, an end-of-file condition occurs 23instead of an end-of-record condition. 24During nonadvancing input when the pad mode has the value YES, blank characters are supplied by 25the processor if an effective item and its corresponding data edit descriptors require more characters 26from the record than the record contains. If the record is incomplete, an end-of-file condition occurs; 27otherwise an end-of-record condition occurs. 28If the file is connected for direct access, the record number is increased by one as each succeeding record 29is read or written. 30On output, if the file is connected for direct access or is an internal file and the characters specified by 31the output list and format do not fill a record, blank characters are added to fill the record. 32On output, the output list and format specification shall not specify more characters for a record than 33have been specified by a RECL= specifier in the OPEN statement or the record length of an internal 34file. 359.5.4.5 List-directed formatting 36If list-directed formatting has been established, editing is performed as described in 10.10. 379.5.4.6 Namelist formatting 38If namelist formatting has been established, editing is performed as described in 10.11. 235 J3/07-007 WORKING DRAFT 2006/01/05 1Every allocatable namelist-group-object in the namelist group shall be allocated and every namelist- 2group-object that is a pointer shall be associated with a target. If a namelist-group-object is polymorphic 3or has an ultimate component that is allocatable or a pointer, that object shall be processed by a user- defined derived-type input/output procedure (9.5.4.7). 4 9.5.4.7 User-defined derived-type input/output 5 6User-defined derived-type input/output procedures allow a program to override the default handling of derived-type objects and values in data transfer input/output statements described in 9.5.3. 7 8A user-defined derived-type input/output procedure is a procedure accessible by a dtio-generic-spec 9(12.4.3.2). A particular user-defined derived-type input/output procedure is selected as described in 109.5.4.7.3. 9.5.4.7.1 Executing user-defined derived-type input/output data transfers 11 12If a derived-type input/output procedure is selected as specified in 9.5.4.7.3, the processor shall call the se- 13lected user-defined derived-type input/output procedure for any appropriate data transfer input/output 14statements executed in that scoping unit. The user-defined derived-type input/output procedure controls 15the actual data transfer operations for the derived-type list item. 16A data transfer statement that includes a derived-type list item and that causes a user-defined derived- 17type input/output procedure to be invoked is called a parent data transfer statement. A data 18transfer statement that is executed while a parent data transfer statement is being processed and that 19specifies the unit passed into a user-defined derived-type input/output procedure is called a child data 20transfer statement. NOTE 9.44 A user-defined derived-type input/output procedure will usually contain child data transfer state- ments that read values from or write values to the current record or at the current file position. The effect of executing the user-defined derived-type input/output procedure is similar to that of substituting the list items from any child data transfer statements into the parent data transfer statement's list items, along with similar substitutions in the format specification. NOTE 9.45 A particular execution of a READ, WRITE or PRINT statement can be both a parent and a child data transfer statement. A user-defined derived-type input/output procedure can indirectly call itself or another user-defined derived-type input/output procedure by executing a child data transfer statement containing a list item of derived type, where a matching interface is accessible for that derived type. If a user-defined derived-type input/output procedure calls itself indirectly in this manner, it shall be declared RECURSIVE. 21A child data transfer statement is processed differently from a nonchild data transfer statement in the 22following ways. 23 · Executing a child data transfer statement does not position the file prior to data transfer. 24 · An unformatted child data transfer statement does not position the file after data transfer is 25 complete. · Any ADVANCE= specifier in a child input/output statement is ignored. 26 9.5.4.7.2 User-defined derived-type input/output procedures 27 236 2006/01/05 WORKING DRAFT J3/07-007 1For a particular derived type and a particular set of kind type parameter values, there are four possible 2sets of characteristics for user-defined derived-type input/output procedures; one each for formatted 3input, formatted output, unformatted input, and unformatted output. The user need not supply all four 4procedures. The procedures are specified to be used for derived-type input/output by interface blocks (12.4.3.2) or by generic bindings (4.5.5), with a dtio-generic-spec (R1208). 5 6In the four interfaces, which specify the characteristics of user-defined procedures for derived-type in- put/output, the following syntax term is used: 7 8R920 dtv-type-spec is TYPE( derived-type-spec ) or CLASS( derived-type-spec ) 9 10C937 (R920) If derived-type-spec specifies an extensible type, the CLASS keyword shall be used; 11 otherwise, the TYPE keyword shall be used. C938 (R920) All length type parameters of derived-type-spec shall be assumed. 12 13If the dtio-generic-spec is READ (FORMATTED), the characteristics shall be the same as those specified 14by the following interface: 15 SUBROUTINE my_read_routine_formatted & 16 (dtv, & 17 unit, & 18 iotype, v_list, & 19 iostat, iomsg) 20 ! the derived-type variable 21 dtv-type-spec , INTENT(INOUT) :: dtv 22 INTEGER, INTENT(IN) :: unit ! unit number 23 ! the edit descriptor string 24 CHARACTER (LEN=*), INTENT(IN) :: iotype 25 INTEGER, INTENT(IN) :: v_list(:) 26 INTEGER, INTENT(OUT) :: iostat 27 CHARACTER (LEN=*), INTENT(INOUT) :: iomsg 28 END 29If the dtio-generic-spec is READ (UNFORMATTED), the characteristics shall be the same as those 30specified by the following interface: 31 SUBROUTINE my_read_routine_unformatted & 32 (dtv, & 33 unit, & 34 iostat, iomsg) 35 ! the derived-type variable 36 dtv-type-spec , INTENT(INOUT) :: dtv 37 INTEGER, INTENT(IN) :: unit 38 INTEGER, INTENT(OUT) :: iostat 39 CHARACTER (LEN=*), INTENT(INOUT) :: iomsg 40 END 41If the dtio-generic-spec is WRITE (FORMATTED), the characteristics shall be the same as those spec- 42ified by the following interface: SUBROUTINE my_write_routine_formatted & 237 J3/07-007 WORKING DRAFT 2006/01/05 1 2 (dtv, & 3 unit, & 4 iotype, v_list, & 5 iostat, iomsg) 6 ! the derived-type value/variable 7 dtv-type-spec , INTENT(IN) :: dtv 8 INTEGER, INTENT(IN) :: unit 9 ! the edit descriptor string 10 CHARACTER (LEN=*), INTENT(IN) :: iotype 11 INTEGER, INTENT(IN) :: v_list(:) 12 INTEGER, INTENT(OUT) :: iostat 13 CHARACTER (LEN=*), INTENT(INOUT) :: iomsg 14 END 15If the dtio-generic-spec is WRITE (UNFORMATTED), the characteristics shall be the same as those 16specified by the following interface: 17 SUBROUTINE my_write_routine_unformatted & 18 (dtv, & 19 unit, & 20 iostat, iomsg) 21 ! the derived-type value/variable 22 dtv-type-spec , INTENT(IN) :: dtv 23 INTEGER, INTENT(IN) :: unit 24 INTEGER, INTENT(OUT) :: iostat 25 CHARACTER (LEN=*), INTENT(INOUT) :: iomsg 26 END 27The actual specific procedure names (the my_..._routine_... procedure names above) are not signifi- 28cant. In the discussion here and elsewhere, the dummy arguments in these interfaces are referred by the 29names given above; the names are, however, arbitrary. 30When a user-defined derived-type input/output procedure is invoked, the processor shall pass a unit 31argument that has a value as follows. 32 · If the parent data transfer statement uses a file-unit-number, the value of the unit argument shall 33 be that of the file-unit-number. 34 · If the parent data transfer statement is a WRITE statement with an asterisk unit or a PRINT 35 statement, the unit argument shall have the same value as the OUTPUT UNIT named constant of the ISO FORTRAN ENV intrinsic module (13.8.2). 36 37 · If the parent data transfer statement is a READ statement with an asterisk unit or a READ 38 statement without an io-control-spec-list, the unit argument shall have the same value as the INPUT UNIT named constant of the ISO FORTRAN ENV intrinsic module (13.8.2). 39 40 · Otherwise the parent data transfer statement must access an internal file, in which case the unit 41 argument shall have a processor-dependent negative value. 238 2006/01/05 WORKING DRAFT J3/07-007 NOTE 9.46 The unit argument passed to a user-defined derived-type input/output procedure will be negative when the parent input/output statement specified an internal unit, or specified an external unit that is a NEWUNIT value. When an internal unit is used with the INQUIRE statement, an error condition will occur, and any variable specified in an IOSTAT= specifier will be assigned the value IOSTAT INQUIRE INTERNAL UNIT from the ISO FORTRAN ENV intrinsic module (13.8.2). 1For formatted data transfer, the processor shall pass an iotype argument that has the value 2 · "LISTDIRECTED" if the parent data transfer statement specified list directed formatting, 3 · "NAMELIST" if the parent data transfer statement specified namelist formatting, or 4 · "DT" concatenated with the char-literal-constant, if any, of the edit descriptor, if the parent data 5 transfer statement contained a format specification and the list item's corresponding edit descriptor 6 was a DT edit descriptor. 7If the parent data transfer statement is a READ statement, the dtv dummy argument is argument 8associated with the effective list item that caused the user-defined derived-type input procedure to be invoked, as if the effective list item were an actual argument in this procedure reference (2.5.6). 9 10If the parent data transfer statement is a WRITE or PRINT statement, the processor shall provide the 11value of the effective list item in the dtv dummy argument. 12If the v-list of the edit descriptor appears in the parent data transfer statement, the processor shall 13provide the values from it in the v_list dummy argument, with the same number of elements in the 14same order as v-list. If there is no v-list in the edit descriptor or if the data transfer statement specifies 15list-directed or namelist formatting, the processor shall provide v_list as a zero-sized array. NOTE 9.47 The user's procedure may choose to interpret an element of the v_list argument as a field width, but this is not required. If it does, it would be appropriate to fill an output field with "*"s if the width is too small. 16The iostat argument is used to report whether an error, end-of-record, or end-of-file condition (9.10) 17occurs. If an error condition occurs, the user-defined derived-type input/output procedure shall assign 18a positive value to the iostat argument. Otherwise, if an end-of-file condition occurs, the user-defined 19derived-type input procedure shall assign the value of the named constant IOSTAT END (13.8.2.10) 20to the iostat argument. Otherwise, if an end-of-record condition occurs, the user-defined derived- 21type input procedure shall assign the value of the named constant IOSTAT EOR (13.8.2.11) to iostat. 22Otherwise, the user-defined derived-type input/output procedure shall assign the value zero to the 23iostat argument. 24If the user-defined derived-type input/output procedure returns a nonzero value for the iostat argument, 25the procedure shall also return an explanatory message in the iomsg argument. Otherwise, the procedure 26shall not change the value of the iomsg argument. NOTE 9.48 The values of the iostat and iomsg arguments set in a user-defined derived-type input/output procedure need not be passed to all of the parent data transfer statements. 27If the iostat argument of the user-defined derived-type input/output procedure has a nonzero value 28when that procedure returns, and the processor therefore terminates execution of the program as de- 239 J3/07-007 WORKING DRAFT 2006/01/05 1scribed in 9.10, the processor shall make the value of the iomsg argument available in a processor- 2dependent manner. 3When a parent READ statement is active, an input/output statement shall not read from any external 4unit other than the one specified by the dummy argument unit and shall not perform output to any 5external unit. 6When a parent WRITE or PRINT statement is active, an input/output statement shall not perform 7output to any external unit other than the one specified by the dummy argument unit and shall not 8read from any external unit. 9When a parent data transfer statement is active, a data transfer statement that specifies an internal file 10is permitted. 11OPEN, CLOSE, BACKSPACE, ENDFILE, and REWIND statements shall not be executed while a 12parent data transfer statement is active. 13A user-defined derived-type input/output procedure may use a FORMAT with a DT edit descriptor for 14handling a component of the derived type that is itself of a derived type. A child data transfer statement that is a list directed or namelist input/output statement may contain a list item of derived type. 15 16Because a child data transfer statement does not position the file prior to data transfer, the child data 17transfer statement starts transferring data from where the file was positioned by the parent data transfer 18statement's most recently processed effective list item or record positioning edit descriptor. This is not 19necessarily at the beginning of a record. 20A record positioning edit descriptor, such as TL and TR, used on unit by a child data transfer statement 21shall not cause the record position to be positioned before the record position at the time the user-defined derived-type input/output procedure was invoked. 22 NOTE 9.49 A robust user-defined derived-type input/output procedure may wish to use INQUIRE to deter- mine the settings of BLANK=, PAD=, ROUND=, DECIMAL=, and DELIM= for an external unit. The INQUIRE provides values as specified in 9.9. 23Neither a parent nor child data transfer statement shall be asynchronous. 24A user-defined derived-type input/output procedure, and any procedures invoked therefrom, shall not 25define, nor cause to become undefined, any storage location referenced by any input/output list item, 26the corresponding format, or any specifier in any active parent data transfer statement, except through 27the dtv argument. NOTE 9.50 A child data transfer statement shall not specify the ID=, POS=, or REC= specifiers in an input/output control list. NOTE 9.51 A simple example of derived type formatted output follows. The derived type variable chairman has two components. The type and an associated write formatted procedure are defined in a module so as to be accessible from wherever they might be needed. It would also be possible to check that iotype indeed has the value 'DT' and to set iostat and iomsg accordingly. MODULE p 240 2006/01/05 WORKING DRAFT J3/07-007 NOTE 9.51 (cont.) TYPE :: person CHARACTER (LEN=20) :: name INTEGER :: age CONTAINS PROCEDURE,PRIVATE :: pwf GENERIC :: WRITE(FORMATTED) => pwf END TYPE person CONTAINS SUBROUTINE pwf (dtv,unit,iotype,vlist,iostat,iomsg) ! argument definitions CLASS(person), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER (LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: vlist(:) INTEGER, INTENT(OUT) :: iostat CHARACTER (LEN=*), INTENT(INOUT) :: iomsg ! local variable CHARACTER (LEN=9) :: pfmt ! vlist(1) and (2) are to be used as the field widths of the two ! components of the derived type variable. First set up the format to ! be used for output. WRITE(pfmt,'(A,I2,A,I2,A)' ) '(A', vlist(1), ',I', vlist(2), ')' ! now the basic output statement WRITE(unit, FMT=pfmt, IOSTAT=iostat) dtv%name, dtv%age END SUBROUTINE pwf END MODULE p PROGRAM USE p INTEGER id, members TYPE (person) :: chairman ... WRITE(6, FMT="(I2, DT (15,6), I5)" ) id, chairman, members ! this writes a record with four fields, with lengths 2, 15, 6, 5 ! respectively END PROGRAM NOTE 9.52 In the following example, the variables of the derived type node form a linked list, with a single value at each node. The subroutine pwf is used to write the values in the list, one per line. MODULE p TYPE node 241 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 9.52 (cont.) INTEGER :: value = 0 TYPE (NODE), POINTER :: next_node => NULL ( ) CONTAINS PROCEDURE,PRIVATE :: pwf GENERIC :: WRITE(FORMATTED) => pwf END TYPE node CONTAINS RECURSIVE SUBROUTINE pwf (dtv,unit,iotype,vlist,iostat,iomsg) ! Write the chain of values, each on a separate line in I9 format. CLASS(node), INTENT(IN) :: dtv INTEGER, INTENT(IN) :: unit CHARACTER (LEN=*), INTENT(IN) :: iotype INTEGER, INTENT(IN) :: vlist(:) INTEGER, INTENT(OUT) :: iostat CHARACTER (LEN=*), INTENT(INOUT) :: iomsg WRITE(unit,'(i9 /)', IOSTAT = iostat) dtv%value IF(iostat/=0) RETURN IF(ASSOCIATED(dtv%next_node)) WRITE(unit,'(dt)', IOSTAT=iostat) dtv%next_node END SUBROUTINE pwf END MODULE p 9.5.4.7.3 Resolving derived-type input/output procedure references 1 2A suitable generic interface for user-defined derived-type input/output of an effective item is one that 3has a dtio-generic-spec that is appropriate to the direction (read or write) and form (formatted or 4unformatted) of the data transfer as specified in 9.5.4.7, and has a specific interface whose dtv argument 5is compatible with the effective item according to the rules for argument association in 12.5.2.5. 6When an effective item (9.5.3) that is of derived-type is encountered during a data transfer, user-defined derived-type input/output occurs if both of the following conditions are true. 7 8 (1) The circumstances of the input/output are such that user-defined derived-type input/output 9 is permitted; that is, either 10 (a) the transfer was initiated by a list-directed, namelist, or unformatted input/output 11 statement, or 12 (b) a format specification is supplied for the input/output statement, and the edit de- 13 scriptor corresponding to the effective item is a DT edit descriptor. (2) A suitable user-defined derived-type input/output procedure is available; that is, either 14 15 (a) the declared type of the effective item has a suitable generic type-bound procedure, 16 or (b) a suitable generic interface is accessible. 17 18If (2a) is true, the procedure referenced is determined as for explicit type-bound procedure references 19(12.5); that is, the binding with the appropriate specific interface is located in the declared type of the 20effective item, and the corresponding binding in the dynamic type of the effective item is selected. 21If (2a) is false and (2b) is true, the reference is to the procedure identified by the appropriate specific 242 2006/01/05 WORKING DRAFT J3/07-007 1interface in the interface block. This reference shall not be to a dummy procedure that is not present, 2or to a disassociated procedure pointer. 39.5.5 Termination of data transfer statements Termination of an input/output data transfer statement occurs when 4 5 (1) format processing encounters a data edit descriptor and there are no remaining elements in 6 the input-item-list or output-item-list, (2) unformatted or list-directed data transfer exhausts the input-item-list or output-item-list, 7 (3) namelist output exhausts the namelist-group-object-list, 8 (4) an error condition occurs, 9 (5) an end-of-file condition occurs, 10 11 (6) a slash (/) is encountered as a value separator (10.10, 10.11) in the record being read during 12 list-directed or namelist input, or 13 (7) an end-of-record condition occurs during execution of a nonadvancing input statement (9.10). 14 9.6 Waiting on pending data transfer 15 9.6.1 Wait operation 16 17Execution of an asynchronous data transfer statement in which neither an error, end-of-record, nor end- 18of-file condition occurs initiates a pending data transfer operation. There may be multiple pending data 19transfer operations for the same or multiple units simultaneously. A pending data transfer operation 20remains pending until a corresponding wait operation is performed. A wait operation may be performed 21by a WAIT, INQUIRE, FLUSH, CLOSE, data transfer, or file positioning statement. 22A wait operation completes the processing of a pending data transfer operation. Each wait operation 23completes only a single data transfer operation, although a single statement may perform multiple wait 24operations. 25If the actual data transfer is not yet complete, the wait operation first waits for its completion. If the 26data transfer operation is an input operation that completed without error, the storage units of the input/output storage sequence then become defined with the values as described in 9.5.2.15 and 9.5.4.4. 27 28If any error, end-of-file, or end-of-record conditions occur, the applicable actions specified by the IO- 29STAT=, IOMSG=, ERR=, END=, and EOR= specifiers of the statement that performs the wait oper- 30ation are taken. 31If an error or end-of-file condition occurs during a wait operation for a unit, the processor performs a 32wait operation for all pending data transfer operations for that unit. NOTE 9.53 Error, end-of-file, and end-of-record conditions may be raised either during the data transfer state- ment that initiates asynchronous input/output, a subsequent asynchronous data transfer statement for the same unit, or during the wait operation. If such conditions are raised during a data transfer statement, they trigger actions according to the IOSTAT=, ERR=, END=, and EOR= specifiers of that statement; if they are raised during the wait operation, the actions are in accordance with the specifiers of the statement that performs the wait operation. 33After completion of the wait operation, the data transfer operation and its input/output storage sequence 34are no longer considered to be pending. 243 J3/07-007 WORKING DRAFT 2006/01/05 19.6.2 WAIT statement 2A WAIT statement performs a wait operation for specified pending asynchronous data transfer oper- 3ations. NOTE 9.54 The CLOSE, INQUIRE, and file positioning statements may also perform wait operations. R921 wait-stmt is WAIT (wait-spec-list) 4 5R922 wait-spec is [ UNIT = ] file-unit-number 6 or END = label 7 or EOR = label 8 or ERR = label 9 or ID = scalar-int-expr 10 or IOMSG = iomsg-variable 11 or IOSTAT = scalar-int-variable 12C939 No specifier shall appear more than once in a given wait-spec-list. 13C940 A file-unit-number shall be specified in a wait-spec-list; if the optional characters UNIT= are 14 omitted, the file-unit-number shall be the first item in the wait-spec-list. 15C941 (R922) The label in the ERR=, EOR=, or END= specifier shall be the statement label of a 16 branch target statement that appears in the same scoping unit as the WAIT statement. 17The IOSTAT=, ERR=, EOR=, END=, and IOMSG= specifiers are described in 9.10. 18The value of the expression specified in the ID= specifier shall be the identifier of a pending data transfer 19operation for the specified unit. If the ID= specifier appears, a wait operation for the specified data 20transfer operation is performed. If the ID= specifier is omitted, wait operations for all pending data 21transfers for the specified unit are performed. 22Execution of a WAIT statement specifying a unit that does not exist, has no file connected to it, or is 23not open for asynchronous input/output is permitted, provided that the WAIT statement has no ID= 24specifier; such a WAIT statement does not cause an error or end-of-file condition to occur. NOTE 9.55 An EOR= specifier has no effect if the pending data transfer operation is not a nonadvancing read. And END= specifier has no effect if the pending data transfer operation is not a READ. 9.7 File positioning statements 25 9.7.1 Syntax 26 27R923 backspace-stmt is BACKSPACE file-unit-number or BACKSPACE ( position-spec-list ) 28 29R924 endfile-stmt is ENDFILE file-unit-number or ENDFILE ( position-spec-list ) 30 31R925 rewind-stmt is REWIND file-unit-number or REWIND ( position-spec-list ) 32 33A unit that is connected for direct access shall not be referred to by a BACKSPACE, ENDFILE, or 244 2006/01/05 WORKING DRAFT J3/07-007 1REWIND statement. A unit that is connected for unformatted stream access shall not be referred to 2by a BACKSPACE statement. A unit that is connected with an ACTION= specifier having the value 3READ shall not be referred to by an ENDFILE statement. A unit whose connect team has more than 4one image shall not be referred to by a BACKSPACE, ENDFILE, or REWIND statement. 5R926 position-spec is [ UNIT = ] file-unit-number 6 or IOMSG = iomsg-variable 7 or IOSTAT = scalar-int-variable 8 or ERR = label 9C942 No specifier shall appear more than once in a given position-spec-list. 10C943 A file-unit-number shall be specified in a position-spec-list; if the optional characters UNIT= 11 are omitted, the file-unit-number shall be the first item in the position-spec-list. 12C944 (R926) The label in the ERR= specifier shall be the statement label of a branch target statement 13 that appears in the same scoping unit as the file positioning statement. 14The IOSTAT=, ERR=, and IOMSG= specifiers are described in 9.10. 15Execution of a file positioning statement performs a wait operation for all pending asynchronous data 16transfer operations for the specified unit. 179.7.2 BACKSPACE statement 18Execution of a BACKSPACE statement causes the file connected to the specified unit to be positioned 19before the current record if there is a current record, or before the preceding record if there is no current 20record. If the file is at its initial point, the position of the file is not changed. NOTE 9.56 If the preceding record is an endfile record, the file is positioned before the endfile record. 21If a BACKSPACE statement causes the implicit writing of an endfile record, the file is positioned before 22the record that precedes the endfile record. 23Backspacing a file that is connected but does not exist is prohibited. 24Backspacing over records written using list-directed or namelist formatting is prohibited. NOTE 9.57 An example of a BACKSPACE statement is: BACKSPACE (10, IOSTAT = N) 259.7.3 ENDFILE statement 26Execution of an ENDFILE statement for a file connected for sequential access writes an endfile record 27as the next record of the file. The file is then positioned after the endfile record, which becomes the last 28record of the file. If the file also may be connected for direct access, only those records before the endfile 29record are considered to have been written. Thus, only those records may be read during subsequent 30direct access connections to the file. 31After execution of an ENDFILE statement for a file connected for sequential access, a BACKSPACE 32or REWIND statement shall be used to reposition the file prior to execution of any data transfer input/output statement or ENDFILE statement. 33 245 J3/07-007 WORKING DRAFT 2006/01/05 1Execution of an ENDFILE statement for a file connected for stream access causes the terminal point of 2the file to become equal to the current file position. Only file storage units before the current position are 3considered to have been written; thus only those file storage units may be subsequently read. Subsequent 4stream output statements may be used to write further data to the file. 5Execution of an ENDFILE statement for a file that is connected but does not exist creates the file; if 6the file is connected for sequential access, it is created prior to writing the endfile record. NOTE 9.58 An example of an ENDFILE statement is: ENDFILE K 79.7.4 REWIND statement 8Execution of a REWIND statement causes the specified file to be positioned at its initial point. NOTE 9.59 If the file is already positioned at its initial point, execution of this statement has no effect on the position of the file. 9Execution of a REWIND statement for a file that is connected but does not exist is permitted and has 10no effect on any file. NOTE 9.60 An example of a REWIND statement is: REWIND 10 119.8 FLUSH statement 12R927 flush-stmt is FLUSH file-unit-number or FLUSH ( flush-spec-list ) 13 14R928 flush-spec is [UNIT =] file-unit-number 15 or IOSTAT = scalar-int-variable 16 or IOMSG = iomsg-variable 17 or ERR = label 18C945 No specifier shall appear more than once in a given flush-spec-list. 19C946 A file-unit-number shall be specified in a flush-spec-list; if the optional characters UNIT= are 20 omitted from the unit specifier, the file-unit-number shall be the first item in the flush-spec-list. 21C947 (R928) The label in the ERR= specifier shall be the statement label of a branch target statement 22 that appears in the same scoping unit as the FLUSH statement. 23The IOSTAT=, IOMSG= and ERR= specifiers are described in 9.10. The IOSTAT= variable shall 24be set to a processor-dependent positive value if an error occurs, to zero if the processor-dependent 25flush operation was successful, or to a processor-dependent negative value if the flush operation is not 26supported for the unit specified. 27Execution of a FLUSH statement causes data written to an external unit to be made available to 246 2006/01/05 WORKING DRAFT J3/07-007 1other images of the unit's connect team which execute a FLUSH statement in a subsequent segment for 2that unit. It also causes data written to an external file to be available to other processes, or causes 3data placed in an external file by means other than Fortran to be available to a READ statement. The 4action is processor dependent. J3 internal note Unresolved Technical Issue 106 FLUSH action contradiction. The last sentence contradicts the entire rest of the paragraph it's in. Well, what is it ­ is the action processor-defined, or does it cause data written to an external file to be available to other processors and cause data placed in an external file by means other than Fortran to be available to a READ statement? Hmm, the first half sounds like something outside the scope of the standard anyway, so it could probably be more cautiously worded. 5Execution of a FLUSH statement for a file that is connected but does not exist is permitted and has no 6effect on any file. A FLUSH statement has no effect on file position. 7Execution of a FLUSH statement performs a wait operation for all pending asynchronous data transfer 8operations for the specified unit. NOTE 9.61 Because this standard does not specify the mechanism of file storage, the exact meaning of the flush operation is not precisely defined. The intention is that the flush operation should make all data written to a file available to other processes or devices, or make data recently added to a file by other processes or devices available to the program via a subsequent read operation. This is commonly called "flushing I/O buffers". NOTE 9.62 An example of a FLUSH statement is: FLUSH( 10, IOSTAT=N) 9.9 File inquiry statement 9 109.9.1 Forms of the INQUIRE statement 11The INQUIRE statement may be used to inquire about properties of a particular named file or of 12the connection to a particular unit. There are three forms of the INQUIRE statement: inquire by file, 13which uses the FILE= specifier, inquire by unit, which uses the UNIT= specifier, and inquire by 14output list, which uses only the IOLENGTH= specifier. All specifier value assignments are performed 15according to the rules for assignment statements. 16For inquiry by unit, the unit specified need not exist or be connected to a file. If it is connected to a 17file, the inquiry is being made about the connection and about the file connected. 18An INQUIRE statement may be executed before, while, or after a file is connected to a unit. All values 19assigned by an INQUIRE statement are those that are current at the time the statement is executed. 20R929 inquire-stmt is INQUIRE ( inquire-spec-list ) 21 or INQUIRE ( IOLENGTH = scalar-int-variable ) 22 output-item-list 247 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 9.63 Examples of INQUIRE statements are: INQUIRE (IOLENGTH = IOL) A (1:N) INQUIRE (UNIT = JOAN, OPENED = LOG_01, NAMED = LOG_02, & FORM = CHAR_VAR, IOSTAT = IOS) 9.9.2 Inquiry specifiers 1 2Unless constrained, the following inquiry specifiers may be used in either of the inquire by file or inquire 3by unit forms of the INQUIRE statement: 4R930 inquire-spec is [ UNIT = ] file-unit-number 5 or FILE = file-name-expr 6 or ACCESS = scalar-default-char-variable 7 or ACTION = scalar-default-char-variable 8 or ASYNCHRONOUS = scalar-default-char-variable 9 or BLANK = scalar-default-char-variable 10 or DECIMAL = scalar-default-char-variable 11 or DELIM = scalar-default-char-variable 12 or DIRECT = scalar-default-char-variable 13 or ENCODING = scalar-default-char-variable 14 or ERR = label 15 or EXIST = scalar-default-logical-variable 16 or FORM = scalar-default-char-variable 17 or FORMATTED = scalar-default-char-variable 18 or ID = scalar-int-expr 19 or IOMSG = iomsg-variable 20 or IOSTAT = scalar-int-variable 21 or NAME = scalar-default-char-variable 22 or NAMED = scalar-default-logical-variable 23 or NEXTREC = scalar-int-variable 24 or NUMBER = scalar-int-variable 25 or OPENED = scalar-default-logical-variable 26 or PAD = scalar-default-char-variable 27 or PENDING = scalar-default-logical-variable 28 or POS = scalar-int-variable 29 or POSITION = scalar-default-char-variable 30 or READ = scalar-default-char-variable 31 or READWRITE = scalar-default-char-variable 32 or RECL = scalar-int-variable 33 or ROUND = scalar-default-char-variable 34 or SEQUENTIAL = scalar-default-char-variable 35 or SIGN = scalar-default-char-variable 36 or SIZE = scalar-int-variable 37 or STREAM = scalar-default-char-variable 38 or TEAM = image-team 39 or UNFORMATTED = scalar-default-char-variable 40 or WRITE = scalar-default-char-variable 41C948 No specifier shall appear more than once in a given inquire-spec-list. 42C949 An inquire-spec-list shall contain one FILE= specifier or one UNIT= specifier, but not both. 248 2006/01/05 WORKING DRAFT J3/07-007 1C950 In the inquire by unit form of the INQUIRE statement, if the optional characters UNIT= are 2 omitted, the file-unit-number shall be the first item in the inquire-spec-list. 3C951 If an ID= specifier appears in an inquire-spec-list, a PENDING= specifier shall also appear. 4C952 (R928) The label in the ERR= specifier shall be the statement label of a branch target statement 5 that appears in the same scoping unit as the INQUIRE statement. If file-unit-number identifies an internal unit (9.5.4.7.2), an error condition occurs. 6 7When a returned value of a specifier other than the NAME= specifier is of type character, the value 8returned is in upper case. 9If an error condition occurs during execution of an INQUIRE statement, all of the inquiry specifier variables become undefined, except for variables in the IOSTAT= and IOMSG= specifiers (if any). 10 11The IOSTAT=, ERR=, and IOMSG= specifiers are described in 9.10. 129.9.2.1 FILE= specifier in the INQUIRE statement 13The value of the file-name-expr in the FILE= specifier specifies the name of the file being inquired about. 14The named file need not exist or be connected to a unit. The value of the file-name-expr shall be of a 15form acceptable to the processor as a file name. Any trailing blanks are ignored. The interpretation of 16case is processor dependent. 179.9.2.2 ACCESS= specifier in the INQUIRE statement 18The scalar-default-char-variable in the ACCESS= specifier is assigned the value SEQUENTIAL if the 19connection is for sequential access, DIRECT if the connection is for direct access, or STREAM if the 20connection is for stream access. If there is no connection, it is assigned the value UNDEFINED. 219.9.2.3 ACTION= specifier in the INQUIRE statement 22The scalar-default-char-variable in the ACTION= specifier is assigned the value READ if the connection 23is for input only, WRITE if the connection is for output only, and READWRITE if the connection is for 24both input and output. If there is no connection, the scalar-default-char-variable is assigned the value 25UNDEFINED. 269.9.2.4 ASYNCHRONOUS= specifier in the INQUIRE statement 27The scalar-default-char-variable in the ASYNCHRONOUS= specifier is assigned the value YES if the 28connection allows asynchronous input/output; it is assigned the value NO if the connection does not 29allow asynchronous input/output. If there is no connection, the scalar-default-char-variable is assigned 30the value UNDEFINED. 319.9.2.5 BLANK= specifier in the INQUIRE statement 32The scalar-default-char-variable in the BLANK= specifier is assigned the value ZERO or NULL, corre- 33sponding to the blank interpretation mode in effect for a connection for formatted input/output. If there 34is no connection, or if the connection is not for formatted input/output, the scalar-default-char-variable 35is assigned the value UNDEFINED. 369.9.2.6 DECIMAL= specifier in the INQUIRE statement 37The scalar-default-char-variable in the DECIMAL= specifier is assigned the value COMMA or POINT, 38corresponding to the decimal edit mode in effect for a connection for formatted input/output. If there 249 J3/07-007 WORKING DRAFT 2006/01/05 1is no connection, or if the connection is not for formatted input/output, the scalar-default-char-variable 2is assigned the value UNDEFINED. 39.9.2.7 DELIM= specifier in the INQUIRE statement 4The scalar-default-char-variable in the DELIM= specifier is assigned the value APOSTROPHE, QUOTE, 5or NONE, corresponding to the delimiter mode in effect for a connection for formatted input/output. 6If there is no connection or if the connection is not for formatted input/output, the scalar-default-char- 7variable is assigned the value UNDEFINED. 89.9.2.8 DIRECT= specifier in the INQUIRE statement 9The scalar-default-char-variable in the DIRECT= specifier is assigned the value YES if DIRECT is 10included in the set of allowed access methods for the file, NO if DIRECT is not included in the set of 11allowed access methods for the file, and UNKNOWN if the processor is unable to determine whether 12DIRECT is included in the set of allowed access methods for the file. 139.9.2.9 ENCODING= specifier in the INQUIRE statement 14The scalar-default-char-variable in the ENCODING= specifier is assigned the value UTF-8 if the con- 15nection is for formatted input/output with an encoding form of UTF-8, and is assigned the value UN- 16DEFINED if the connection is for unformatted input/output. If there is no connection, it is assigned 17the value UTF-8 if the processor is able to determine that the encoding form of the file is UTF-8; if 18the processor is unable to determine the encoding form of the file, the variable is assigned the value 19UNKNOWN. NOTE 9.64 The value assigned may be something other than UTF-8, UNDEFINED, or UNKNOWN if the processor supports other specific encoding forms (e.g. UTF-16BE). 209.9.2.10 EXIST= specifier in the INQUIRE statement 21Execution of an INQUIRE by file statement causes the scalar-default-logical-variable in the EXIST= 22specifier to be assigned the value true if there exists a file with the specified name; otherwise, false is 23assigned. Execution of an INQUIRE by unit statement causes true to be assigned if the specified unit 24exists; otherwise, false is assigned. 259.9.2.11 FORM= specifier in the INQUIRE statement 26The scalar-default-char-variable in the FORM= specifier is assigned the value FORMATTED if the 27connection is for formatted input/output, and is assigned the value UNFORMATTED if the connection is for unformatted input/output. If there is no connection, it is assigned the value UNDEFINED. 28 299.9.2.12 FORMATTED= specifier in the INQUIRE statement 30The scalar-default-char-variable in the FORMATTED= specifier is assigned the value YES if FOR- 31MATTED is included in the set of allowed forms for the file, NO if FORMATTED is not included in 32the set of allowed forms for the file, and UNKNOWN if the processor is unable to determine whether 33FORMATTED is included in the set of allowed forms for the file. 349.9.2.13 ID= specifier in the INQUIRE statement 35The value of the expression specified in the ID= specifier shall be the identifier of a pending data transfer operation for the specified unit. This specifier interacts with the PENDING= specifier (9.9.2.20). 36 250 2006/01/05 WORKING DRAFT J3/07-007 19.9.2.14 NAME= specifier in the INQUIRE statement 2The scalar-default-char-variable in the NAME= specifier is assigned the value of the name of the file if 3the file has a name; otherwise, it becomes undefined. NOTE 9.65 If this specifier appears in an INQUIRE by file statement, its value is not necessarily the same as the name given in the FILE= specifier. However, the value returned shall be suitable for use as the value of the file-name-expr in the FILE= specifier in an OPEN statement. The processor may return a file name qualified by a user identification, device, directory, or other relevant information. 4The case of the characters assigned to scalar-default-char-variable is processor dependent. 59.9.2.15 NAMED= specifier in the INQUIRE statement 6The scalar-default-logical-variable in the NAMED= specifier is assigned the value true if the file has a 7name; otherwise, it is assigned the value false. 89.9.2.16 NEXTREC= specifier in the INQUIRE statement 9The scalar-int-variable in the NEXTREC= specifier is assigned the value n + 1, where n is the record 10number of the last record read from or written to the connection for direct access by the executing 11image. If there is a connection but no records have been read or written since the connection, the scalar- 12int-variable is assigned the value 1. If there is no connection, the connection is not for direct access, 13or the position is indeterminate because of a previous error condition, the scalar-int-variable becomes 14undefined. If there are pending data transfer operations for the specified unit, the value assigned is 15computed as if all the pending data transfers had already completed. 169.9.2.17 NUMBER= specifier in the INQUIRE statement 17The scalar-int-variable in the NUMBER= specifier is assigned the value of the external unit number of 18the unit that is connected to the file. If there is no unit connected to the file, the value -1 is assigned. 199.9.2.18 OPENED= specifier in the INQUIRE statement 20Execution of an INQUIRE by file statement causes the scalar-default-logical-variable in the OPENED= 21specifier to be assigned the value true if the file specified is connected to a unit; otherwise, false is 22assigned. Execution of an INQUIRE by unit statement causes the scalar-default-logical-variable to be 23assigned the value true if the specified unit is connected to a file; otherwise, false is assigned. 249.9.2.19 PAD= specifier in the INQUIRE statement 25The scalar-default-char-variable in the PAD= specifier is assigned the value YES or NO, corresponding 26to the pad mode in effect for a connection for formatted input/output. If there is no connection or if 27the connection is not for formatted input/output, the scalar-default-char-variable is assigned the value 28UNDEFINED. 299.9.2.20 PENDING= specifier in the INQUIRE statement 30The PENDING= specifier is used to determine whether previously pending asynchronous data transfers 31are complete. A data transfer operation is previously pending if it is pending at the beginning of 32execution of the INQUIRE statement. 251 J3/07-007 WORKING DRAFT 2006/01/05 1If an ID= specifier appears and the specified data transfer operation is complete, then the variable 2specified in the PENDING= specifier is assigned the value false and the INQUIRE statement performs 3the wait operation for the specified data transfer. 4If the ID= specifier is omitted and all previously pending data transfer operations for the specified unit 5are complete, then the variable specified in the PENDING= specifier is assigned the value false and the 6INQUIRE statement performs wait operations for all previously pending data transfers for the specified 7unit. 8In all other cases, the variable specified in the PENDING= specifier is assigned the value true and no 9wait operations are performed; in this case the previously pending data transfers remain pending after 10the execution of the INQUIRE statement. NOTE 9.66 The processor has considerable flexibility in defining when it considers a transfer to be complete. Any of the following approaches could be used: (1) The INQUIRE statement could consider an asynchronous data transfer to be incom- plete until after the corresponding wait operation. In this case PENDING= would always return true unless there were no previously pending data transfers for the unit. (2) The INQUIRE statement could wait for all specified data transfers to complete and then always return false for PENDING=. (3) The INQUIRE statement could actually test the state of the specified data transfer operations. 119.9.2.21 POS= specifier in the INQUIRE statement 12The scalar-int-variable in the POS= specifier is assigned the number of the file storage unit immediately 13following the current position of a file connected for stream access. If the file is positioned at its terminal 14position, the variable is assigned a value one greater than the number of the highest-numbered file storage 15unit in the file. If the file is not connected for stream access or if the position of the file is indeterminate 16because of previous error conditions, the variable becomes undefined. 179.9.2.22 POSITION= specifier in the INQUIRE statement 18The scalar-default-char-variable in the POSITION= specifier is assigned the value REWIND if the 19connection was opened for positioning at its initial point, APPEND if the connection was opened for 20positioning before its endfile record or at its terminal point, and ASIS if the connection was opened 21without changing its position. If there is no connection or if the file is connected for direct access, the 22scalar-default-char-variable is assigned the value UNDEFINED. If the file has been repositioned since 23the connection, the scalar-default-char-variable is assigned a processor-dependent value, which shall not 24be REWIND unless the file is positioned at its initial point and shall not be APPEND unless the file is 25positioned so that its endfile record is the next record or at its terminal point if it has no endfile record. 269.9.2.23 READ= specifier in the INQUIRE statement 27The scalar-default-char-variable in the READ= specifier is assigned the value YES if READ is included 28in the set of allowed actions for the file, NO if READ is not included in the set of allowed actions for 29the file, and UNKNOWN if the processor is unable to determine whether READ is included in the set 30of allowed actions for the file. 319.9.2.24 READWRITE= specifier in the INQUIRE statement 252 2006/01/05 WORKING DRAFT J3/07-007 1The scalar-default-char-variable in the READWRITE= specifier is assigned the value YES if READ- 2WRITE is included in the set of allowed actions for the file, NO if READWRITE is not included in 3the set of allowed actions for the file, and UNKNOWN if the processor is unable to determine whether 4READWRITE is included in the set of allowed actions for the file. 59.9.2.25 RECL= specifier in the INQUIRE statement 6The scalar-int-variable in the RECL= specifier is assigned the value of the record length of a connection 7for direct access, or the value of the maximum record length of a connection for sequential access. If 8the connection is for formatted input/output, the length is the number of characters for all records that 9contain only characters of type default character. If the connection is for unformatted input/output, 10the length is measured in file storage units. If there is no connection, or if the connection is for stream 11access, the scalar-int-variable becomes undefined. 129.9.2.26 ROUND= specifier in the INQUIRE statement 13The scalar-default-char-variable in the ROUND= specifier is assigned the value UP, DOWN, ZERO, 14NEAREST, COMPATIBLE, or PROCESSOR DEFINED, corresponding to the I/O rounding mode in 15effect for a connection for formatted input/output. If there is no connection or if the connection is not 16for formatted input/output, the scalar-default-char-variable is assigned the value UNDEFINED. The 17processor shall return the value PROCESSOR DEFINED only if the I/O rounding mode currently in 18effect behaves differently than the UP, DOWN, ZERO, NEAREST, and COMPATIBLE modes. 199.9.2.27 SEQUENTIAL= specifier in the INQUIRE statement 20The scalar-default-char-variable in the SEQUENTIAL= specifier is assigned the value YES if SEQUEN- 21TIAL is included in the set of allowed access methods for the file, NO if SEQUENTIAL is not included 22in the set of allowed access methods for the file, and UNKNOWN if the processor is unable to determine 23whether SEQUENTIAL is included in the set of allowed access methods for the file. 249.9.2.28 SIGN= specifier in the INQUIRE statement 25The scalar-default-char-variable in the SIGN= specifier is assigned the value PLUS, SUPPRESS, or 26PROCESSOR DEFINED, corresponding to the sign mode in effect for a connection for formatted in- 27put/output. If there is no connection, or if the connection is not for formatted input/output, the 28scalar-default-char-variable is assigned the value UNDEFINED. 299.9.2.29 SIZE= specifier in the INQUIRE statement 30The scalar-int-variable in the SIZE= specifier is assigned the size of the file in file storage units. If the 31file size cannot be determined, the variable is assigned the value -1. 32For a file that may be connected for stream access, the file size is the number of the highest-numbered 33file storage unit in the file. 34For a file that may be connected for sequential or direct access, the file size may be different from the 35number of storage units implied by the data in the records; the exact relationship is processor-dependent. 369.9.2.30 STREAM= specifier in the INQUIRE statement 37The scalar-default-char-variable in the STREAM= specifier is assigned the value YES if STREAM is 38included in the set of allowed access methods for the file, NO if STREAM is not included in the set of 39allowed access methods for the file, and UNKNOWN if the processor is unable to determine whether 40STREAM is included in the set of allowed access methods for the file. 253 J3/07-007 WORKING DRAFT 2006/01/05 19.9.2.31 TEAM= specifier in the INQUIRE statement 2The image-team in the TEAM= specifier is assigned the value of the connect team if the file or unit is 3connected; otherwise it is assigned a value that identifies an empty image set. NOTE 9.67 The indices of the images in a team may be obtained by using the intrinsic function TEAM - IMAGES (13.7.172). 49.9.2.32 UNFORMATTED= specifier in the INQUIRE statement 5The scalar-default-char-variable in the UNFORMATTED= specifier is assigned the value YES if UN- 6FORMATTED is included in the set of allowed forms for the file, NO if UNFORMATTED is not included 7in the set of allowed forms for the file, and UNKNOWN if the processor is unable to determine whether 8UNFORMATTED is included in the set of allowed forms for the file. 99.9.2.33 WRITE= specifier in the INQUIRE statement 10The scalar-default-char-variable in the WRITE= specifier is assigned the value YES if WRITE is included 11in the set of allowed actions for the file, NO if WRITE is not included in the set of allowed actions for 12the file, and UNKNOWN if the processor is unable to determine whether WRITE is included in the set 13of allowed actions for the file. 9.9.3 Inquire by output list 14 15The scalar-int-variable in the IOLENGTH= specifier is assigned the processor-dependent number of file 16storage units that would be required to store the data of the output list in an unformatted file. The 17value shall be suitable as a RECL= specifier in an OPEN statement that connects a file for unformatted direct access when there are input/output statements with the same input/output list. 18 19The output list in an INQUIRE statement shall not contain any derived-type list items that require 20a user-defined derived-type input/output procedure as described in subclause 9.5.3. If a derived-type 21list item appears in the output list, the value returned for the IOLENGTH= specifier assumes that no user-defined derived-type input/output procedure will be invoked. 22 9.10 Error, end-of-record, and end-of-file conditions 23 The set of input/output error conditions is processor dependent. 24 25An end-of-record condition occurs when a nonadvancing input statement attempts to transfer data 26from a position beyond the end of the current record, unless the file is a stream file and the current record is at the end of the file (an end-of-file condition occurs instead). 27 28An end-of-file condition occurs when (1) an endfile record is encountered during the reading of a file connected for sequential access, 29 (2) an attempt is made to read a record beyond the end of an internal file, or 30 (3) an attempt is made to read beyond the end of a stream file. 31 32An end-of-file condition may occur at the beginning of execution of an input statement. An end-of-file 33condition also may occur during execution of a formatted input statement when more than one record 34is required by the interaction of the input list and the format. An end-of-file condition also may occur 35during execution of a stream input statement. 254 2006/01/05 WORKING DRAFT J3/07-007 9.10.1 Error conditions and the ERR= specifier 1 2If an error condition occurs during execution of an input/output statement, the position of the file 3becomes indeterminate. 4If an error condition occurs during execution of an input/output statement that contains neither an 5ERR= nor IOSTAT= specifier, execution of the program is terminated. If an error condition occurs 6during execution of an input/output statement that contains either an ERR= specifier or an IOSTAT= 7specifier then (1) processing of the input/output list, if any, terminates, 8 9 (2) if the statement is a data transfer statement or the error occurs during a wait operation, all 10 do-variables in the statement that initiated the transfer become undefined, 11 (3) if an IOSTAT= specifier appears, the scalar-int-variable in the IOSTAT= specifier becomes 12 defined as specified in 9.10.4, (4) if an IOMSG= specifier appears, the iomsg-variable becomes defined as specified in 9.10.5, 13 14 (5) if the statement is a READ statement and it contains a SIZE= specifier, the scalar-int- 15 variable in the SIZE= specifier becomes defined as specified in 9.5.2.15, 16 (6) if the statement is a READ statement or the error condition occurs in a wait operation for 17 a transfer initiated by a READ statement, all input items or namelist group objects in the 18 statement that initiated the transfer become undefined, and 19 (7) if an ERR= specifier appears, a branch to the statement labeled by the label in the ERR= 20 specifier occurs. 9.10.2 End-of-file condition and the END= specifier 21 22If an end-of-file condition occurs during execution of an input/output statement that contains neither 23an END= specifier nor an IOSTAT= specifier, execution of the program is terminated. If an end-of-file 24condition occurs during execution of an input/output statement that contains either an END= specifier 25or an IOSTAT= specifier, and an error condition does not occur then (1) processing of the input list, if any, terminates, 26 27 (2) if the statement is a data transfer statement or the error occurs during a wait operation, all 28 do-variables in the statement that initiated the transfer become undefined, 29 (3) if the statement is a READ statement or the end-of-file condition occurs in a wait operation 30 for a transfer initiated by a READ statement, all input list items or namelist group objects 31 in the statement that initiated the transfer become undefined, 32 (4) if the file specified in the input statement is an external record file, it is positioned after the 33 endfile record, 34 (5) if an IOSTAT= specifier appears, the scalar-int-variable in the IOSTAT= specifier becomes 35 defined as specified in 9.10.4, 36 (6) if an IOMSG= specifier appears, the iomsg-variable becomes defined as specified in 9.10.5, 37 and 38 (7) if an END= specifier appears, a branch to the statement labeled by the label in the END= 39 specifier occurs. 9.10.3 End-of-record condition and the EOR= specifier 40 41If an end-of-record condition occurs during execution of an input/output statement that contains neither 42an EOR= specifier nor an IOSTAT= specifier, execution of the program is terminated. If an end-of- 43record condition occurs during execution of an input/output statement that contains either an EOR= 44specifier or an IOSTAT= specifier, and an error condition does not occur then (1) If the pad mode has the value 45 255 J3/07-007 WORKING DRAFT 2006/01/05 1 (a) YES, the record is padded with blanks to satisfy the effective list item (9.5.4.4.2) 2 and corresponding data edit descriptors that require more characters than the record 3 contains, (b) NO, the input list item becomes undefined, 4 (2) processing of the input list, if any, terminates, 5 6 (3) if the statement is a data transfer statement or the end-of-record condition occurs dur- 7 ing a wait operation, all do-variables in the statement that initiated the transfer become 8 undefined, (4) the file specified in the input statement is positioned after the current record, 9 10 (5) if an IOSTAT= specifier appears, the scalar-int-variable in the IOSTAT= specifier becomes 11 defined as specified in 9.10.4, (6) if an IOMSG= specifier appears, the iomsg-variable becomes defined as specified in 9.10.5, 12 13 (7) if a SIZE= specifier appears, the scalar-int-variable in the SIZE= specifier becomes defined as specified in (9.5.2.15), and 14 15 (8) if an EOR= specifier appears, a branch to the statement labeled by the label in the EOR= 16 specifier occurs. 9.10.4 IOSTAT= specifier 17 18Execution of an input/output statement containing the IOSTAT= specifier causes the scalar-int-variable 19in the IOSTAT= specifier to become defined with 20 (1) a zero value if neither an error condition, an end-of-file condition, nor an end-of-record 21 condition occurs, 22 (2) the processor-dependent positive integer value of the constant IOSTAT INQUIRE INTERN- 23 AL UNIT from the ISO FORTRAN ENV intrinsic module (13.8.2) if a unit number in an 24 INQUIRE statement identifies an internal file, 25 (3) a processor-dependent positive integer value different from IOSTAT INQUIRE INTERNAL- 26 UNIT if any other error condition occurs, 27 (4) the processor-dependent negative integer value of the constant IOSTAT END (13.8.2.10) if 28 an end-of-file condition occurs and no error condition occurs, or 29 (5) the processor-dependent negative integer value of the constant IOSTAT EOR (13.8.2.11) if 30 an end-of-record condition occurs and no error condition or end-of-file condition occurs. NOTE 9.68 An end-of-file condition may occur only for sequential or stream input and an end-of-record con- dition may occur only for nonadvancing input. Consider the example: READ (FMT = "(E8.3)", UNIT = 3, IOSTAT = IOSS) X IF (IOSS < 0) THEN ! Perform end-of-file processing on the file connected to unit 3. CALL END_PROCESSING ELSE IF (IOSS > 0) THEN ! Perform error processing CALL ERROR_PROCESSING END IF 9.10.5 IOMSG= specifier 31 256 2006/01/05 WORKING DRAFT J3/07-007 1If an error, end-of-file, or end-of-record condition occurs during execution of an input/output statement, 2the processor shall assign an explanatory message to iomsg-variable. If no such condition occurs, the 3processor shall not change the value of iomsg-variable. 9.11 Restrictions on input/output statements 4 5If a unit, or a file connected to a unit, does not have all of the properties required for the execution of certain input/output statements, those statements shall not refer to the unit. 6 7An input/output statement that is executed while another input/output statement is being executed is called a recursive input/output statement. 8 9A recursive input/output statement shall not identify an external unit that is identified by another 10input/output statement being executed except that a child data transfer statement may identify its 11parent data transfer statement external unit. 12An input/output statement shall not cause the value of any established format specification to be 13modified. 14A recursive input/output statement shall not modify the value of any internal unit except that a recursive 15WRITE statement may modify the internal unit identified by that recursive WRITE statement. 16The value of a specifier in an input/output statement shall not depend on any input-item, io-implied- 17do do-variable, or on the definition or evaluation of any other specifier in the io-control-spec-list or 18inquire-spec-list in that statement. 19The value of any subscript or substring bound of a variable that appears in a specifier in an input/output 20statement shall not depend on any input-item, io-implied-do do-variable, or on the definition or evalua- 21tion of any other specifier in the io-control-spec-list or inquire-spec-list in that statement. 22In a data transfer statement, the variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier, if 23any, shall not be associated with any entity in the data transfer input/output list (9.5.3) or namelist- group-object-list, nor with a do-variable of an io-implied-do in the data transfer input/output list. 24 25In a data transfer statement, if a variable specified in an IOSTAT=, IOMSG=, or SIZE= specifier is an 26array element reference, its subscript values shall not be affected by the data transfer, the io-implied-do 27processing, or the definition or evaluation of any other specifier in the io-control-spec-list. 28A variable that may become defined or undefined as a result of its use in a specifier in an INQUIRE 29statement, or any associated entity, shall not appear in another specifier in the same INQUIRE statement. A STOP statement shall not be executed during execution of an input/output statement. 30 NOTE 9.69 Restrictions on the evaluation of expressions (7.1.4) prohibit certain side effects. 257 J3/07-007 WORKING DRAFT 2006/01/05 258 2006/01/05 WORKING DRAFT J3/07-007 10 Input/output editing 1 10.1 Format specifications 2 3A format used in conjunction with an input/output statement provides information that directs the 4editing between the internal representation of data and the characters of a sequence of formatted records. 5A R914 (9.5.2.2) in an input/output statement may refer to a FORMAT statement or to a character 6expression that contains a format specification. A format specification provides explicit editing infor- 7mation. The R914 alternatively may be an asterisk (*), which indicates list-directed formatting (10.10). Namelist formatting (10.11) may be indicated by specifying a namelist-group-name instead of a format. 8 10.2 Explicit format specification methods 9 1010.2.1 FORMAT statement 11R1001 format-stmt is FORMAT format-specification 12R1002 format-specification is ( [ format-item-list ] ) or ( [ format-item-list, ] unlimited-format-item ) 13 C1001 (R1001) The format-stmt shall be labeled. 14 C1002 (R1002) The comma used to separate format-items in a format-item-list may be omitted 15 16 (1) between a P edit descriptor and an immediately following F, E, EN, ES, D, or G edit descriptor (10.8.5), possibly preceded by a repeat specifier, 17 (2) before a slash edit descriptor when the optional repeat specification is not present (10.8.2), 18 (3) after a slash edit descriptor, or 19 (4) before or after a colon edit descriptor (10.8.3) 20 21Blank characters may precede the initial left parenthesis of the format specification. Additional blank 22characters may appear at any point within the format specification, with no effect on the interpretation of the format specification, except within a character string edit descriptor (10.9). 23 NOTE 10.1 Examples of FORMAT statements are: 5 FORMAT (1PE12.4, I10) 9 FORMAT (I12, /, ' Dates: ', 2 (2I3, I5)) 10.2.2 Character format specification 24 25A character expression used as a format in a formatted input/output statement shall evaluate to a 26character string whose leading part is a valid format specification. NOTE 10.2 The format specification begins with a left parenthesis and ends with a right parenthesis. 259 J3/07-007 WORKING DRAFT 2006/01/05 1All character positions up to and including the final right parenthesis of the format specification shall be 2defined at the time the input/output statement is executed, and shall not become redefined or undefined 3during the execution of the statement. Character positions, if any, following the right parenthesis that 4ends the format specification need not be defined and may contain any character data with no effect on 5the interpretation of the format specification. 6If the format is a character array, it is treated as if all of the elements of the array were specified in array 7element order and were concatenated. However, if a format is a character array element, the format 8specification shall be entirely within that array element. NOTE 10.3 If a character constant is used as a format in an input/output statement, care shall be taken that the value of the character constant is a valid format specification. In particular, if a format specification delimited by apostrophes contains a character constant edit descriptor delimited with apostrophes, two apostrophes shall be written to delimit the edit descriptor and four apostrophes shall be written for each apostrophe that occurs within the edit descriptor. For example, the text: 2 ISN'T 3 may be written by various combinations of output statements and format specifications: WRITE (6, 100) 2, 3 100 FORMAT (1X, I1, 1X, 'ISN''T', 1X, I1) WRITE (6, '(1X, I1, 1X, ''ISN''''T'', 1X, I1)') 2, 3 WRITE (6, '(A)') ' 2 ISN''T 3' Doubling of internal apostrophes usually can be avoided by using quotation marks to delimit the format specification and doubling of internal quotation marks usually can be avoided by using apostrophes as delimiters. 910.3 Form of a format item list 10.3.1 Syntax 10 11R1003 format-item is [ r ] data-edit-desc 12 or control-edit-desc 13 or char-string-edit-desc or [ r ] ( format-item-list ) 14 R1004 unlimited-format-item is * ( format-item-list ) 15 16R1005 r is int-literal-constant C1003 (R1005) r shall be positive. 17 C1004 (R1005) r shall not have a kind parameter specified for it. 18 19The integer literal constant r is called a repeat specification. 10.3.2 Edit descriptors 20 21An edit descriptor is a data edit descriptor, a control edit descriptor, or a character string 22edit descriptor. 260 2006/01/05 WORKING DRAFT J3/07-007 1R1006 data-edit-desc is I w [ . m ] 2 or B w [ . m ] 3 or O w [ . m ] 4 or Z w [ . m ] 5 or F w . d 6 or E w . d [ E e ] 7 or EN w . d [ E e ] 8 or ES w . d [ E e ] 9 or G w [ . d [ E e ] ] 10 or L w 11 or A [ w ] 12 or D w . d or DT [ char-literal-constant ] [ ( v-list ) ] 13 14R1007 w is int-literal-constant 15R1008 m is int-literal-constant 16R1009 d is int-literal-constant 17R1010 e is int-literal-constant 18R1011 v is signed-int-literal-constant C1005 (R1010) e shall be positive. 19 20C1006 (R1007) w shall be zero or positive for the I, B, O, Z, F, and G edit descriptors. w shall be 21 positive for all other edit descriptors. C1007 (R1006) For the G edit descriptor, d shall be specified if and only if w is not zero. 22 C1008 (R1006) w, m, d, e, and v shall not have kind parameters specified for them. 23 24C1009 (R1006) The char-literal-constant in the DT edit descriptor shall not have a kind parameter 25 specified for it. 26I, B, O, Z, F, E, EN, ES, G, L, A, D, and DT indicate the manner of editing. 27R1012 control-edit-desc is position-edit-desc 28 or [ r ] / 29 or : 30 or sign-edit-desc 31 or k P 32 or blank-interp-edit-desc 33 or round-edit-desc 34 or decimal-edit-desc 35R1013 k is signed-int-literal-constant C1010 (R1013) k shall not have a kind parameter specified for it. 36 37In k P, k is called the scale factor. 38R1014 position-edit-desc is T n 39 or TL n 40 or TR n 41 or n X 261 J3/07-007 WORKING DRAFT 2006/01/05 1R1015 n is int-literal-constant C1011 (R1015) n shall be positive. 2 C1012 (R1015) n shall not have a kind parameter specified for it. 3 4R1016 sign-edit-desc is SS 5 or SP 6 or S 7R1017 blank-interp-edit-desc is BN 8 or BZ 9R1018 round-edit-desc is RU 10 or RD 11 or RZ 12 or RN 13 or RC 14 or RP 15R1019 decimal-edit-desc is DC 16 or DP 17T, TL, TR, X, slash, colon, SS, SP, S, P, BN, BZ, RU, RD, RZ, RN, RC, RP, DC, and DP indicate the 18manner of editing. 19R1020 char-string-edit-desc is char-literal-constant C1013 (R1020) The char-literal-constant shall not have a kind parameter specified for it. 20 21Each rep-char in a character string edit descriptor shall be one of the characters capable of representation 22by the processor. 23The character string edit descriptors provide constant data to be output, and are not valid for input. 24The edit descriptors are without regard to case except for the characters in the character constants. 2510.3.3 Fields 26A field is a part of a record that is read on input or written on output when format control encounters 27a data edit descriptor or a character string edit descriptor. The field width is the size in characters of 28the field. 10.4 Interaction between input/output list and format 29 30The start of formatted data transfer using a format specification initiates format control (9.5.4.4.2). 31Each action of format control depends on information jointly provided by the next edit descriptor in the format specification and the next effective item in the input/output list, if one exists. 32 33If an input/output list specifies at least one effective list item, at least one data edit descriptor shall 34exist in the format specification. NOTE 10.4 An empty format specification of the form ( ) may be used only if the input/output list has no effective list items (9.5.4.4). Zero length character items are effective list items, but zero sized arrays and implied DO lists with an iteration count of zero are not. 262 2006/01/05 WORKING DRAFT J3/07-007 1A format specification is interpreted from left to right. The exceptions are format items preceded by a repeat specification r, and format reversion (described below). 2 3A format item preceded by a repeat specification is processed as a list of r items, each identical to the 4format item but without the repeat specification and separated by commas. NOTE 10.5 An omitted repeat specification is treated in the same way as a repeat specification whose value is one. 5To each data edit descriptor interpreted in a format specification, there corresponds one effective item 6specified by the input/output list (9.5.3), except that an input/output list item of type complex requires 7the interpretation of two F, E, EN, ES, D, or G edit descriptors. For each control edit descriptor or 8character edit descriptor, there is no corresponding item specified by the input/output list, and format 9control communicates information directly with the record. 10Whenever format control encounters a data edit descriptor in a format specification, it determines 11whether there is a corresponding effective item specified by the input/output list. If there is such an 12item, it transmits appropriately edited information between the item and the record, and then format 13control proceeds. If there is no such item, format control terminates. 14If format control encounters a colon edit descriptor in a format specification and another effective in- put/output list item is not specified, format control terminates. 15 16If format control encounters the rightmost parenthesis of a complete format specification and another 17effective input/output list item is not specified, format control terminates. However, if another effective 18input/output list item is specified, format control then reverts to the beginning of the format item 19terminated by the last preceding right parenthesis that is not part of a DT edit descriptor. If there 20is no such preceding right parenthesis, format control reverts to the first left parenthesis of the format 21specification. If any reversion occurs, the reused portion of the format specification shall contain at 22least one data edit descriptor. If format control reverts to a parenthesis that is preceded by a repeat 23specification, the repeat specification is reused. Reversion of format control, of itself, has no effect on 24the changeable modes (9.4.1). If format control reverts to a parenthesis that is not the beginning of an 25unlimited-format-item, the file is positioned in a manner identical to the way it is positioned when a slash edit descriptor is processed (10.8.2). 26 NOTE 10.6 Example: The format specification: 10 FORMAT (1X, 2(F10.3, I5)) with an output list of WRITE (10,10) 10.1, 3, 4.7, 1, 12.4, 5, 5.2, 6 produces the same output as the format specification: 10 FORMAT (1X, F10.3, I5, F10.3, I5/F10.3, I5, F10.3, I5) NOTE 10.7 The effect of an unlimited-format-item is as if its enclosed list were preceded by a very large repeat count. There is no file positioning implied by unlimited-format-item reversion. This may be used to write what is commonly called a comma separated value record. 263 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 10.7 (cont.) For example, WRITE( 10, '( "IARRAY =", *( I0, :, ","))') IARRAY produces a single record with a header and a comma separated list of integer values. 10.5 Positioning by format control 1 2After each data edit descriptor or character string edit descriptor is processed, the file is positioned after 3the last character read or written in the current record. 4After each T, TL, TR, or X edit descriptor is processed, the file is positioned as described in 10.8.1. 5After each slash edit descriptor is processed, the file is positioned as described in 10.8.2. 6During formatted stream output, processing of an A edit descriptor can cause file positioning to occur (10.7.4). 7 8If format control reverts as described in 10.4, the file is positioned in a manner identical to the way it is positioned when a slash edit descriptor is processed (10.8.2). 9 10During a read operation, any unprocessed characters of the current record are skipped whenever the 11next record is read. 10.6 Decimal symbol 12 13The decimal symbol is the character that separates the whole and fractional parts in the decimal 14representation of a real number in an internal or external file. When the decimal edit mode is POINT, 15the decimal symbol is a decimal point. When the decimal edit mode is COMMA, the decimal symbol is 16a comma. 10.7 Data edit descriptors 17 1810.7.1 General 19Data edit descriptors cause the conversion of data to or from its internal representation; during formatted 20stream output, the A data edit descriptor may also cause file positioning. On input, the specified variable 21becomes defined unless an error condition, an end-of-file condition, or an end-of-record condition occurs. 22On output, the specified expression is evaluated. 23During input from a Unicode file, 24 (1) characters in the record that correspond to an ASCII character variable shall have a position 25 in the ISO 10646 character type collating sequence of 127 or less, and 26 (2) characters in the record that correspond to a default character variable shall be representable 27 in the default character type. 28During input from a non-Unicode file, 29 (1) characters in the record that correspond to a character variable shall have the kind of the 30 character variable, and 31 (2) characters in the record that correspond to a numeric logical, or bits variable shall be of 32 default character type. 264 2006/01/05 WORKING DRAFT J3/07-007 1During output to a Unicode file, all characters transmitted to the record are of ISO 10646 character 2type. If a character input/output list item or character string edit descriptor contains a character that 3is not representable in the ISO 10646 character type, the result is processor-dependent. 4During output to a non-Unicode file, characters transmitted to the record as a result of processing a 5character string edit descriptor or as a result of evaluating a numeric, logical, bits, or default character 6data entity, are of type default character. 10.7.2 Numeric and bits editing 7 810.7.2.1 General rules 9The I, B, O, Z, F, E, EN, ES, D, and G edit descriptors may be used to specify the input/output of 10integer, real, complex, and bits data. The following general rules apply. 11 (1) On input, leading blanks are not significant. When the input field is not an IEEE excep- 12 tional specification (10.7.2.3.2), the interpretation of blanks, other than leading blanks, is 13 determined by the blank interpretation mode (10.8.6). Plus signs may be omitted. A field 14 containing only blanks is considered to be zero. 15 (2) On input, with F, E, EN, ES, D, and G editing, a decimal symbol appearing in the input 16 field overrides the portion of an edit descriptor that specifies the decimal symbol location. 17 The input field may have more digits than the processor uses to approximate the value of 18 the datum. 19 (3) On output with I, F, E, EN, ES, D, and G editing, the representation of a positive or zero 20 internal value in the field may be prefixed with a plus sign, as controlled by the S, SP, and 21 SS edit descriptors or the processor. The representation of a negative internal value in the 22 field shall be prefixed with a minus sign. 23 (4) On output, the representation is right justified in the field. If the number of characters 24 produced by the editing is smaller than the field width, leading blanks are inserted in the 25 field. 26 (5) On output, if the number of characters produced exceeds the field width or if an exponent 27 exceeds its specified length using the Ew.d Ee, ENw.d Ee, ESw.d Ee, or Gw.d Ee edit 28 descriptor, the processor shall fill the entire field of width w with asterisks. However, 29 the processor shall not produce asterisks if the field width is not exceeded when optional 30 characters are omitted. NOTE 10.8 When an SP edit descriptor is in effect, a plus sign is not optional. 31 (6) On output, with I, B, O, Z, F, and G editing, the specified value of the field width w may 32 be zero. In such cases, the processor selects the smallest positive actual field width that 33 does not result in a field filled with asterisks. The specified value of w shall not be zero on 34 input. 3510.7.2.2 Integer editing 36The Iw and Iw.m, edit descriptors indicate that the field to be edited occupies w positions, except when 37w is zero. When w is zero, the processor selects the field width. On input, w shall not be zero. The 38specified input/output list item shall be of type integer or bits. The G, B, O, and Z edit descriptor also may be used to edit integer data (10.7.5.2.1, 10.7.2.4). 39 40If the input list item is of type bits, the integer value specified by the input field is converted to type 41bits according to the model in 13.3. On input, m has no effect. 265 J3/07-007 WORKING DRAFT 2006/01/05 1In the input field for the I edit descriptor, the character string shall be a signed-digit-string (R409) if 2the list item is of type integer and a digit-string (R410) if it is of type bits, except for the interpretation 3of blanks. 4The output field for the Iw edit descriptor consists of zero or more leading blanks followed by a minus 5sign if the internal value is negative, or an optional plus sign otherwise, followed by the magnitude of 6the internal value as a digit-string without leading zeros. NOTE 10.9 A digit-string always consists of at least one digit. 7The output field for the Iw.m edit descriptor is the same as for the Iw edit descriptor, except that the 8digit-string consists of at least m digits. If necessary, sufficient leading zeros are included to achieve the 9minimum of m digits. The value of m shall not exceed the value of w, except when w is zero. If m is 10zero and the internal value is zero, the output field consists of only blank characters, regardless of the 11sign control in effect. When m and w are both zero, and the internal value is zero, one blank character 12is produced. 1310.7.2.3 Real and complex editing 1410.7.2.3.1 General 15The F, E, EN, ES, and D edit descriptors specify the editing of real and complex data. An input/output 16list item corresponding to an F, E, EN, ES, or D edit descriptor shall be real or complex. The G, B, O, and Z edit descriptors also may be used to edit real and complex data (10.7.5.2.2). 17 1810.7.2.3.2 F editing 19The Fw.d edit descriptor indicates that the field occupies w positions, the fractional part of which 20consists of d digits. When w is zero, the processor selects the field width. On input, w shall not be zero. 21A lower-case letter is equivalent to the corresponding upper-case letter in an IEEE exceptional specifi- 22cation or the exponent in a numeric input field. 23The input field is either an IEEE exceptional specification or consists of an optional sign, followed by a 24string of one or more digits optionally containing a decimal symbol, including any blanks interpreted as 25zeros. The d has no effect on input if the input field contains a decimal symbol. If the decimal symbol 26is omitted, the rightmost d digits of the string, with leading zeros assumed if necessary, are interpreted 27as the fractional part of the value represented. The string of digits may contain more digits than a 28processor uses to approximate the value. The basic form may be followed by an exponent of one of the 29following forms: 30 · a sign followed by a digit-string; 31 · the letter E followed by zero or more blanks, followed by a signed-digit-string; 32 · the letter D followed by zero or more blanks, followed by a signed-digit-string. 33An exponent containing a D is processed identically to an exponent containing an E. NOTE 10.10 If the input field does not contain an exponent, the effect is as if the basic form were followed by an exponent with a value of -k, where k is the established scale factor (10.8.5). 266 2006/01/05 WORKING DRAFT J3/07-007 1An input field that is an IEEE exceptional specification consists of optional blanks, followed by either 2 · an optional sign, followed by the string 'INF' or the string 'INFINITY', or 3 · an optional sign, followed by the string 'NAN', optionally followed by zero or more alphanumeric 4 characters enclosed in parentheses, 5optionally followed by blanks. 6The value specified by form (1) is an IEEE infinity; this form shall not be used if the processor does 7not support IEEE infinities for the input variable. The value specified by form (2) is an IEEE NaN; 8this form shall not be used if the processor does not support IEEE NaNs for the input variable. The 9NaN value is a quiet NaN if the only nonblank characters in the field are 'NAN' or 'NAN()'; otherwise, 10the NaN value is processor-dependent. The interpretation of a sign in a NaN input field is processor 11dependent. 12For an internal value that is an IEEE infinity, the output field consists of blanks, if necessary, followed 13by a minus sign for negative infinity or an optional plus sign otherwise, followed by the letters 'Inf' or 14'Infinity', right justified within the field. If w is less than 3, the field is filled with asterisks; otherwise, 15if w is less than 8, 'Inf' is produced. 16For an internal value that is an IEEE NaN, the output field consists of blanks, if necessary, followed by 17the letters 'NaN' and optionally followed by one to w - 5 alphanumeric processor-dependent characters 18enclosed in parentheses, right justified within the field. If w is less than 3, the field is filled with asterisks. NOTE 10.11 The processor-dependent characters following 'NaN' may convey additional information about that particular NaN. 19For an internal value that is neither an IEEE infinity nor a NaN, the output field consists of blanks, if 20necessary, followed by a minus sign if the internal value is negative, or an optional plus sign otherwise, 21followed by a string of digits that contains a decimal symbol and represents the magnitude of the internal 22value, as modified by the established scale factor and rounded (10.7.2.3.7) to d fractional digits. Leading 23zeros are not permitted except for an optional zero immediately to the left of the decimal symbol if the 24magnitude of the value in the output field is less than one. The optional zero shall appear if there would 25otherwise be no digits in the output field. 2610.7.2.3.3 E and D editing 27The Ew.d, Dw.d, and Ew.d Ee edit descriptors indicate that the external field occupies w positions, the 28fractional part of which consists of d digits, unless a scale factor greater than one is in effect, and the 29exponent part consists of e digits. The e has no effect on input. The form and interpretation of the input field is the same as for Fw.d editing (10.7.2.3.2). 30 31For an internal value that is an IEEE infinity or NaN, the form of the output field is the same as for 32Fw.d. 33For an internal value that is neither an IEEE infinity nor a NaN, the form of the output field for a scale 34factor of zero is 35 [ ± ] [0].x1x2 ...xdexp 36where: 37 · ± signifies a plus sign or a minus sign; 267 J3/07-007 WORKING DRAFT 2006/01/05 · . signifies a decimal symbol (10.6); 1 2 · x1x2 ...xd are the d most significant digits of the internal value after rounding (10.7.2.3.7); 3 · exp is a decimal exponent having one of the forms specified in table 10.1. Table 10.1: E and D exponent forms Edit Absolute Value Form of Descriptor of Exponent Exponent1 Ew.d |exp| 99 E±z1z2 or ±0z1z2 99 < |exp| 999 ±z1z2z3 Ew.d Ee |exp| 10e - 1 E±z1z2 ...ze Dw.d |exp| 99 D±z1z2 or E±z1z2 or ±0z1z2 99 < |exp| 999 ±z1z2z3 (1) where each z is a digit. 4The sign in the exponent is produced. A plus sign is produced if the exponent value is zero. The edit descriptor forms Ew.d and Dw.d shall not be used if |exp| > 999. 5 6The scale factor k controls the decimal normalization (10.3.2, 10.8.5). If -d < k 0, the output field 7contains exactly |k| leading zeros and d-|k| significant digits after the decimal symbol. If 0 < k < d+2, 8the output field contains exactly k significant digits to the left of the decimal symbol and d - k + 1 9significant digits to the right of the decimal symbol. Other values of k are not permitted. 1010.7.2.3.4 EN editing 11The EN edit descriptor produces an output field in the form of a real number in engineering notation 12such that the decimal exponent is divisible by three and the absolute value of the significand (R414) is 13greater than or equal to 1 and less than 1000, except when the output value is zero. The scale factor 14has no effect on output. 15The forms of the edit descriptor are ENw.d and ENw.d Ee indicating that the external field occupies w 16positions, the fractional part of which consists of d digits and the exponent part consists of e digits. The form and interpretation of the input field is the same as for Fw.d editing (10.7.2.3.2). 17 18For an internal value that is an IEEE infinity or NaN, the form of the output field is the same as for 19Fw.d. 20For an internal value that is neither an IEEE infinity nor a NaN, the form of the output field is 21 [ ± ] yyy . x1x2 ...xdexp 22where: 23 · ± signifies a plus sign or a minus sign; 24 · yyy are the 1 to 3 decimal digits representative of the most significant digits of the internal value after rounding (10.7.2.3.7); 25 26 · yyy is an integer such that 1 yyy < 1000 or, if the output value is zero, yyy = 0; · . signifies a decimal symbol (10.6); 27 28 · x1x2 ...xd are the d next most significant digits of the internal value after rounding; 268 2006/01/05 WORKING DRAFT J3/07-007 1 · exp is a decimal exponent, divisible by three, having one of the forms specified in table 10.2. Table 10.2: EN exponent forms Edit Absolute Value Form of Descriptor of Exponent Exponent1 ENw.d |exp| 99 E±z1z2 or ±0z1z2 99 < |exp| 999 ±z1z2z3 ENw.d Ee |exp| 10e - 1 E±z1z2 ...ze (1) where each z is a digit. 2The sign in the exponent is produced. A plus sign is produced if the exponent value is zero. The edit descriptor form ENw.d shall not be used if |exp| > 999. 3 NOTE 10.12 Examples: Internal Value Output field Using SS, EN12.3 6.421 6.421E+00 -.5 -500.000E-03 .00217 2.170E-03 4721.3 4.721E+03 410.7.2.3.5 ES editing 5The ES edit descriptor produces an output field in the form of a real number in scientific notation such 6that the absolute value of the significand (R414) is greater than or equal to 1 and less than 10, except 7when the output value is zero. The scale factor has no effect on output. 8The forms of the edit descriptor are ESw.d and ESw.d Ee indicating that the external field occupies w 9positions, the fractional part of which consists of d digits and the exponent part consists of e digits. The form and interpretation of the input field is the same as for Fw.d editing (10.7.2.3.2). 10 11For an internal value that is an IEEE infinity or NaN, the form of the output field is the same as for 12Fw.d. 13For an internal value that is neither an IEEE infinity nor a NaN, the form of the output field is 14 [ ± ] y . x1x2 ...xdexp 15where: 16 · ± signifies a plus sign or a minus sign; 17 · y is a decimal digit representative of the most significant digit of the internal value after rounding (10.7.2.3.7); 18 · . signifies a decimal symbol (10.6); 19 20 · x1x2 ...xd are the d next most significant digits of the internal value after rounding; 21 · exp is a decimal exponent having one of the forms specified in table 10.3. 269 J3/07-007 WORKING DRAFT 2006/01/05 Table 10.3: ES exponent forms Edit Absolute Value Form of Descriptor of Exponent Exponent1 ESw.d |exp| 99 E±z1z2 or ±0z1z2 99 < |exp| 999 ±z1z2z3 ESw.d Ee |exp| 10e - 1 E±z1z2 ...ze (1) where each z is a digit. 1The sign in the exponent is produced. A plus sign is produced if the exponent value is zero. The edit descriptor form ESw.d shall not be used if |exp| > 999. 2 NOTE 10.13 Examples: Internal Value Output field Using SS, ES12.3 6.421 6.421E+00 -.5 -5.000E-01 .00217 2.170E-03 4721.3 4.721E+03 310.7.2.3.6 Complex editing 4A complex datum consists of a pair of separate real data. The editing of a scalar datum of complex type 5is specified by two edit descriptors each of which specifies the editing of real data. The first of the edit 6descriptors specifies the real part; the second specifies the imaginary part. The two edit descriptors may 7be different. Control and character string edit descriptors may be processed between the edit descriptor 8for the real part and the edit descriptor for the imaginary part. 910.7.2.3.7 Rounding mode 10The rounding mode can be specified by an OPEN statement (9.4.1), a data transfer input/output statement (9.5.2.13), or an edit descriptor (10.8.7). 11 12In what follows, the term "decimal value" means the exact decimal number as given by the character 13string, while the term "internal value" means the number actually stored in the processor. For example, 14in dealing with the decimal constant 0.1, the decimal value is the mathematical quantity 1/10, which 15has no exact representation in binary form. Formatted output of real data involves conversion from an 16internal value to a decimal value; formatted input involves conversion from a decimal value to an internal 17value. 18When the I/O rounding mode is UP, the value resulting from conversion shall be the smallest repre- 19sentable value that is greater than or equal to the original value. When the I/O rounding mode is 20DOWN, the value resulting from conversion shall be the largest representable value that is less than or 21equal to the original value. When the I/O rounding mode is ZERO, the value resulting from conversion 22shall be the value closest to the original value and no greater in magnitude than the original value. When 23the I/O rounding mode is NEAREST, the value resulting from conversion shall be the closer of the two 24nearest representable values if one is closer than the other. If the two nearest representable values are 25equidistant from the original value, it is processor dependent which one of them is chosen. When the 26I/O rounding mode is COMPATIBLE, the value resulting from conversion shall be the closer of the 27two nearest representable values or the value away from zero if halfway between them. When the I/O 28rounding mode is PROCESSOR DEFINED, rounding during conversion shall be a processor-dependent 29default mode, which may correspond to one of the other modes. 30On processors that support IEEE rounding on conversions, NEAREST shall correspond to round to 270 2006/01/05 WORKING DRAFT J3/07-007 1nearest, as specified in the IEEE International Standard. NOTE 10.14 On processors that support IEEE rounding on conversions, the I/O rounding modes COMPATI- BLE and NEAREST will produce the same results except when the datum is halfway between the two representable values. In that case, NEAREST will pick the even value, but COMPATIBLE will pick the value away from zero. The I/O rounding modes UP, DOWN, and ZERO have the same effect as those specified in the IEEE International Standard for round toward +, round toward -, and round toward 0, respectively. 210.7.2.4 Bits editing 3The Bw, Bw.m, Ow, Ow.m, Zw, and Zw.m edit descriptors indicate that the field to be edited occupies 4w positions, except when w is zero. When w is zero, the processor selects the field width. On input, 5w shall not be zero. The input/output list item shall be of type bits, integer, real, complex, or logical. The G edit descriptor (10.7.5.3) or the I edit descriptor (10.7.2.2) also can be used to edit bits data. 6 7If the input list item is not of type bits, the input field is edited as if the input list item were of type bits and bits compatible (12.5.2.4) with the actual list item. 8 9On input, m has no effect. 10In the input field for the B, O, and Z edit descriptors the character string shall consist of binary, octal, 11or hexadecimal digits (as in R426, R427, R428) in the respective input field. The lower-case hexadecimal 12digits a through f in a hexadecimal input field are equivalent to the corresponding upper-case hexadecimal 13digits. 14If the output list item, x, is not of type bits, it is interpreted as if it were of type bits with the value BITS(x). 15 16The output field for the Bw, Ow, and Zw descriptors consists of zero or more leading blanks followed by 17the internal value in a form identical to the digits of a binary, octal, or hexadecimal constant, respectively, 18with the same value and without leading zeros. NOTE 10.15 A binary, octal, or hexadecimal constant always consists of at least one digit or hexadecimal digit. R1021 hex-digit-string is hex-digit [ hex-digit ] ... 19 20The output field for the Bw.m, Ow.m, and Zw.m edit descriptor is the same as for the Bw, Ow, and Zw 21edit descriptor, except that the digit-string or hex-digit-string consists of at least m digits. If necessary, 22sufficient leading zeros are included to achieve the minimum of m digits. The value of m shall not exceed 23the value of w, except when w is zero. If m is zero and the internal value consists of all zero bits, the 24output field consists of only blank characters. When m and w are both zero, and the internal value 25consists of all zero bits, one blank character is produced. 10.7.3 Logical editing 26 27The Lw edit descriptor indicates that the field occupies w positions. The specified input/output list item shall be of type logical. The G edit descriptor also may be used to edit logical data (10.7.5.4). 28 29The input field consists of optional blanks, optionally followed by a period, followed by a T for true or 30F for false. The T or F may be followed by additional characters in the field, which are ignored. 31A lower-case letter is equivalent to the corresponding upper-case letter in a logical input field. 271 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 10.16 The logical constants .TRUE. and .FALSE. are acceptable input forms. 1The output field consists of w - 1 blanks followed by a T or F, depending on whether the internal value 2is true or false, respectively. 10.7.4 Character editing 3 4The A[w] edit descriptor is used with an input/output list item of type character. The G edit descriptor 5also may be used to edit character data (10.7.5.5). The kind type parameter of all characters transferred 6and converted under control of one A or G edit descriptor is implied by the kind of the corresponding 7list item. 8If a field width w is specified with the A edit descriptor, the field consists of w characters. If a field 9width w is not specified with the A edit descriptor, the number of characters in the field is the length of 10the corresponding list item, regardless of the value of the kind type parameter. 11Let len be the length of the input/output list item. If the specified field width w for an A edit descriptor 12corresponding to an input item is greater than or equal to len, the rightmost len characters will be taken 13from the input field. If the specified field width w is less than len, the w characters will appear left 14justified with len-w trailing blanks in the internal value. 15If the specified field width w for an A edit descriptor corresponding to an output item is greater than 16len, the output field will consist of w -len blanks followed by the len characters from the internal value. 17If the specified field width w is less than or equal to len, the output field will consist of the leftmost w 18characters from the internal value. NOTE 10.17 For nondefault character types, the blank padding character is processor dependent. 19If the file is connected for stream access, the output may be split across more than one record if it 20contains newline characters. A newline character is a nonblank character returned by the intrinsic 21function NEW LINE. Beginning with the first character of the output field, each character that is not 22a newline is written to the current record in successive positions; each newline character causes file 23positioning at that point as if by slash editing (the current record is terminated at that point, a new 24empty record is created following the current record, this new record becomes the last and current record of the file, and the file is positioned at the beginning of this new record). 25 NOTE 10.18 If the intrinsic function NEW LINE returns a blank character for a particular character kind, then the processor does not support using a character of that kind to cause record termination in a formatted stream file. 10.7.5 Generalized editing 26 2710.7.5.1 Overview 28The Gw, Gw.d and Gw.d Ee edit descriptors are used with an input/output list item of any intrinsic 29type. When w is nonzero, these edit descriptors indicate that the external field occupies w positions; 30for real or complex data the fractional part consists of a maximum of d digits and the exponent part 31consists of e digits. When these edit descriptors are used to specify the input/output of integer, logical, 32bits, or character data, d and e have no effect. When w is zero the processor selects the field width. On 33input, w shall not be zero. 272 2006/01/05 WORKING DRAFT J3/07-007 110.7.5.2 Generalized numeric editing 2When used to specify the input/output of integer, real, and complex data, the Gw, Gw.d and Gw.d Ee edit descriptors follow the general rules for numeric editing (10.7.2). 3 NOTE 10.19 The Gw.d Ee edit descriptor follows any additional rules for the Ew.d Ee edit descriptor. 410.7.5.2.1 Generalized integer editing 5When used to specify the input/output of integer data, the Gw.d and Gw.d Ee edit descriptors follow 6the rules for the Iw edit descriptor (10.7.2.2), except that w shall not be zero. When used to specify the 7output of integer data, the G0 edit descriptor follows the rules for the I0 edit descriptor. 810.7.5.2.2 Generalized real and complex editing The form and interpretation of the input field is the same as for Fw.d editing (10.7.2.3.2). 9 10When used to specify the output of real or complex data, the G0 edit descriptor follows the rules for 11the ESw.d Ee edit descriptor. Reasonable processor-dependent values of w, d, and e are used with each 12output value. 13For an internal value that is an IEEE infinity or NaN, the form of the output field for the Gw.d and 14Gw.d Ee edit descriptors is the same as for Fw.d. 15Otherwise, the method of representation in the output field depends on the magnitude of the internal 16value being edited. Let N be the magnitude of the internal value and r be the rounding mode value -1 17defined in the table below. If 0 < N < 0.1 - r × 10-d or N 10d - r, or N is identically 0 and 18d is 0, Gw.d output editing is the same as k PEw.d output editing and Gw.d Ee output editing is 19the same as k PEw.d Ee output editing, where k is the scale factor (10.8.5) currently in effect. If -1 200.1 - r × 10-d N < 10d - r or N is identically 0 and d is not zero, the scale factor has no effect, 21and the value of N determines the editing as follows: Magnitude of Internal Value Equivalent Conversion N = 0 F(w - n).(d - 1), n('b') 0.1 - r × 10-d-1 N < 1 - r × 10-d F(w - n).d, n('b') 1 - r × 10-d N < 10 - r × 10-d +1 F(w - n).(d - 1), n('b') 10 - r × 10-d +1 N < 100 - r × 10-d +2 F(w - n).(d - 2), n('b') · · · · · · 10d-2 - r × 10-2 N < 10d -1 - r × 10-1 F(w - n).1, n('b') 10d-1 - r × 10-1 N < 10d - r F(w - n).0, n('b') 22where b is a blank, n is 4 for Gw.d and e + 2 for Gw.d Ee, and r is defined for each rounding mode as 23follows: I/O Rounding Mode r COMPATIBLE 0.5 0.5 if the higher value is even NEAREST -0.5 if the lower value is even UP 1 DOWN 0 273 J3/07-007 WORKING DRAFT 2006/01/05 I/O Rounding Mode r 1 if internal value is negative ZERO 0 if internal value is positive 1The value of w - n shall be positive NOTE 10.20 The scale factor has no effect on output unless the magnitude of the datum to be edited is outside the range that permits effective use of F editing. 210.7.5.3 Generalized bits editing 3When used to specify the input/output of bits data, the Gw.d and Gw.d Ee edit descriptors follow the 4rules for the Zw edit descriptor (10.7.2.4), except that w shall not be zero. When used to specify the 5output of bits data, the G0 edit descriptor follows the rules for the Z0 edit descriptor. 610.7.5.4 Generalized logical editing 7When used to specify the input/output of logical data, the Gw.d and Gw.d Ee edit descriptors follow 8the rules for the Lw edit descriptor (10.7.3). When used to specify the output of logical data, the G0 9edit descriptor follows the rules for the L1 edit descriptor. 1010.7.5.5 Generalized character editing 11When used to specify the input/output of character data, the Gw.d and Gw.d Ee edit descriptors follow 12the rules for the Aw edit descriptor (10.7.4). When used to specify the output of character data, the G0 13edit descriptor follows the rules for the A edit descriptor with no field width. 10.7.6 User-defined derived-type editing 14 15The DT edit descriptor allows a user-provided procedure to be used instead of the processor's default input/output formatting for processing a list item of derived type. 16 17The DT edit descriptor may include a character literal constant. The character value "DT" concatenated 18with the character literal constant is passed to the user-defined derived-type input/output procedure as 19the iotype argument (9.5.4.7). The v values of the edit descriptor are passed to the user-defined 20derived-type input/output procedure as the v_list array argument. NOTE 10.21 For the edit descriptor DT'Link List'(10, 4, 2), iotype is "DTLink List" and v_list is [10, 4, 2]. 21If a derived-type variable or value corresponds to a DT edit descriptor, there shall be an accessible 22interface to a corresponding derived-type input/output procedure for that derived type (9.5.4.7). A DT 23edit descriptor shall not correspond with a list item that is not of a derived type. 10.8 Control edit descriptors 24 25A control edit descriptor does not cause the transfer of data or the conversion of data to or from internal 26representation, but may affect the conversions performed by subsequent data edit descriptors. 274 2006/01/05 WORKING DRAFT J3/07-007 10.8.1 Position editing 1 2The T, TL, TR, and X edit descriptors specify the position at which the next character will be transmitted 3to or from the record. If any character skipped by a T, TL, TR, or X edit descriptor is of type nondefault 4character, and the unit is an internal file of type default character or an external non-Unicode file, the 5result of that position editing is processor dependent. 6The position specified by a T edit descriptor may be in either direction from the current position. On 7input, this allows portions of a record to be processed more than once, possibly with different editing. 8The position specified by an X edit descriptor is forward from the current position. On input, a position 9beyond the last character of the record may be specified if no characters are transmitted from such 10positions. NOTE 10.22 An nX edit descriptor has the same effect as a TRn edit descriptor. 11On output, a T, TL, TR, or X edit descriptor does not by itself cause characters to be transmitted and 12therefore does not by itself affect the length of the record. If characters are transmitted to positions at 13or after the position specified by a T, TL, TR, or X edit descriptor, positions skipped and not previously 14filled are filled with blanks. The result is as if the entire record were initially filled with blanks. 15On output, a character in the record may be replaced. However, a T, TL, TR, or X edit descriptor never 16directly causes a character already placed in the record to be replaced. Such edit descriptors may result 17in positioning such that subsequent editing causes a replacement. 1810.8.1.1 T, TL, and TR editing 19The left tab limit affects file positioning by the T and TL edit descriptors. Immediately prior to 20nonchild data transfer, the left tab limit becomes defined as the character position of the current record 21or the current position of the stream file. If, during data transfer, the file is positioned to another record, 22the left tab limit becomes defined as character position one of that record. 23The Tn edit descriptor indicates that the transmission of the next character to or from a record is to 24occur at the nth character position of the record, relative to the left tab limit. 25The TLn edit descriptor indicates that the transmission of the next character to or from the record is 26to occur at the character position n characters backward from the current position. However, if n is 27greater than the difference between the current position and the left tab limit, the TLn edit descriptor 28indicates that the transmission of the next character to or from the record is to occur at the left tab 29limit. 30The TRn edit descriptor indicates that the transmission of the next character to or from the record is 31to occur at the character position n characters forward from the current position. NOTE 10.23 The n in a Tn, TLn, or TRn edit descriptor shall be specified and shall be greater than zero. 3210.8.1.2 X editing 33The nX edit descriptor indicates that the transmission of the next character to or from a record is to 34occur at the position n characters forward from the current position. 275 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 10.24 The n in an nX edit descriptor shall be specified and shall be greater than zero. 10.8.2 Slash editing 1 2The slash edit descriptor indicates the end of data transfer to or from the current record. 3On input from a file connected for sequential or stream access, the remaining portion of the current 4record is skipped and the file is positioned at the beginning of the next record. This record becomes 5the current record. On output to a file connected for sequential or stream access, a new empty record 6is created following the current record; this new record then becomes the last and current record of the 7file and the file is positioned at the beginning of this new record. 8For a file connected for direct access, the record number is increased by one and the file is positioned 9at the beginning of the record that has that record number, if there is such a record, and this record 10becomes the current record. NOTE 10.25 A record that contains no characters may be written on output. If the file is an internal file or a file connected for direct access, the record is filled with blank characters. An entire record may be skipped on input. 11The repeat specification is optional in the slash edit descriptor. If it is not specified, the default value is 12one. 10.8.3 Colon editing 13 14The colon edit descriptor terminates format control if there are no more effective items in the in- 15put/output list (9.5.3). The colon edit descriptor has no effect if there are more effective items in the input/output list. 16 10.8.4 SS, SP, and S editing 17 18The SS, SP, and S edit descriptors temporarily change (9.4.1) the sign mode (9.4.5.15, 9.5.2.14) for the 19connection. The edit descriptors SS, SP, and S set the sign mode corresponding to the SIGN= specifier 20values SUPPRESS, PLUS, and PROCESSOR DEFINED, respectively. 21The sign mode controls optional plus characters in numeric output fields. When the sign mode is PLUS, 22the processor shall produce a plus sign in any position that normally contains an optional plus sign. 23When the sign mode is SUPPRESS, the processor shall not produce a plus sign in such positions. When 24the sign mode is PROCESSOR DEFINED, the processor has the option of producing a plus sign or not in such positions, subject to 10.7.2(5). 25 26The SS, SP, and S edit descriptors affect only I, F, E, EN, ES, D, and G editing during the execution of 27an output statement. The SS, SP, and S edit descriptors have no effect during the execution of an input 28statement. 10.8.5 P editing 29 30The kP edit descriptor temporarily changes (9.4.1) the scale factor for the connection to k. The scale 31factor affects the editing of F, E, EN, ES, D, and G edit descriptors for numeric quantities. 32The scale factor k affects the appropriate editing in the following manner. 276 2006/01/05 WORKING DRAFT J3/07-007 1 (1) On input, with F, E, EN, ES, D, and G editing (provided that no exponent exists in the 2 field) and F output editing, the scale factor effect is that the externally represented number 3 equals the internally represented number multiplied by 10k. 4 (2) On input, with F, E, EN, ES, D, and G editing, the scale factor has no effect if there is an 5 exponent in the field. 6 (3) On output, with E and D editing, the significand (R414) part of the quantity to be produced 7 is multiplied by 10k and the exponent is reduced by k. 8 (4) On output, with G editing, the effect of the scale factor is suspended unless the magnitude 9 of the datum to be edited is outside the range that permits the use of F editing. If the use 10 of E editing is required, the scale factor has the same effect as with E output editing. (5) On output, with EN and ES editing, the scale factor has no effect. 11 If UP, DOWN, ZERO, or NEAREST I/O rounding mode is in effect, 12 13 (1) on input, the scale factor is applied to the external decimal value and then this is converted using the current I/O rounding mode, and 14 15 (2) on output, the internal value is converted using the current I/O rounding mode and then 16 the scale factor is applied to the converted decimal value. 10.8.6 BN and BZ editing 17 18The BN and BZ edit descriptors temporarily change (9.4.1) the blank interpretation mode (9.4.5.4, 199.5.2.6) for the connection. The edit descriptors BN and BZ set the blank interpretation mode corre- 20sponding to the BLANK= specifier values NULL and ZERO, respectively. 21The blank interpretation mode controls the interpretation of nonleading blanks in numeric and bits 22input fields. Such blank characters are interpreted as zeros when the blank interpretation mode has the 23value ZERO; they are ignored when the blank interpretation mode has the value NULL. The effect of 24ignoring blanks is to treat the input field as if blanks had been removed, the remaining portion of the 25field right justified, and the blanks replaced as leading blanks. However, a field containing only blanks 26has the value zero. 27The blank interpretation mode affects only numeric editing, bits editing, generalized numeric editing, 28and generalized bits editing on input. It has no effect on output. 10.8.7 RU, RD, RZ, RN, RC, and RP editing 29 30The round edit descriptors temporarily change (9.4.1) the connection's I/O rounding mode (9.4.5.14, 319.5.2.13, 10.7.2.3.7). The round edit descriptors RU, RD, RZ, RN, RC, and RP set the I/O rounding 32mode corresponding to the ROUND= specifier values UP, DOWN, ZERO, NEAREST, COMPATIBLE, 33and PROCESSOR DEFINED, respectively. The I/O rounding mode affects the conversion of real and complex values in formatted input/output. It affects only D, E, EN, ES, F, and G editing. 34 10.8.8 DC and DP editing 35 36The decimal edit descriptors temporarily change (9.4.1) the decimal edit mode (9.4.5.5, 9.5.2.7, 10.6) 37for the connection. The edit descriptors DC and DP set the decimal edit mode corresponding to the 38DECIMAL= specifier values COMMA and POINT, respectively. 39The decimal edit mode controls the representation of the decimal symbol (10.6) during conversion of 40real and complex values in formatted input/output. The decimal edit mode affects only D, E, EN, ES, 41F, and G editing. If the mode is COMMA during list-directed input/output, the character used as a 42value separator is a semicolon in place of a comma. 277 J3/07-007 WORKING DRAFT 2006/01/05 10.9 Character string edit descriptors 1 2A character string edit descriptor shall not be used on input. 3The character string edit descriptor causes characters to be written from the enclosed characters of the 4edit descriptor itself, including blanks. For a character string edit descriptor, the width of the field is 5the number of characters between the delimiting characters. Within the field, two consecutive delimiting 6characters are counted as a single character. NOTE 10.26 A delimiter for a character string edit descriptor is either an apostrophe or quote. 10.10 List-directed formatting 7 810.10.1 General 9List-directed input/output allows data editing according to the type of the list item instead of by a 10format specification. It also allows data to be free-field, that is, separated by commas (or semicolons) 11or blanks. 10.10.2 Values and value separators 12 13The characters in one or more list-directed records constitute a sequence of values and value separators. 14The end of a record has the same effect as a blank character, unless it is within a character constant. Any 15sequence of two or more consecutive blanks is treated as a single blank, unless it is within a character 16constant. 17Each value is either a null value, c, r*c, or r*, where c is a literal constant, optionally signed if integer 18or real, or an undelimited character constant and r is an unsigned, nonzero, integer literal constant. 19Neither c nor r shall have kind type parameters specified. The constant c is interpreted as though 20it had the same kind type parameter as the corresponding list item. The r*c form is equivalent to r 21successive appearances of the constant c, and the r* form is equivalent to r successive appearances of 22the null value. Neither of these forms may contain embedded blanks, except where permitted within the 23constant c. 24A value separator is 25 (1) a comma optionally preceded by one or more contiguous blanks and optionally followed by 26 one or more contiguous blanks, unless the decimal edit mode is COMMA, in which case a 27 semicolon is used in place of the comma, 28 (2) a slash optionally preceded by one or more contiguous blanks and optionally followed by 29 one or more contiguous blanks, or 30 (3) one or more contiguous blanks between two nonblank values or following the last nonblank 31 value, where a nonblank value is a constant, an r*c form, or an r* form. NOTE 10.27 Although a slash encountered in an input record is referred to as a separator, it actually causes termination of list-directed and namelist input statements; it does not actually separate two values. NOTE 10.28 If no list items are specified in a list-directed input/output statement, one input record is skipped or one empty output record is written. 278 2006/01/05 WORKING DRAFT J3/07-007 10.10.3 List-directed input 1 2Input forms acceptable to edit descriptors for a given type are acceptable for list-directed formatting, 3except as noted below. The form of the input value shall be acceptable for the type of the next effective 4item in the list. Blanks are never used as zeros, and embedded blanks are not permitted in constants, 5except within character constants and complex constants as specified below. 6For the r*c form of an input value, the constant c is interpreted as an undelimited character constant 7if the first list item corresponding to this value is of type default, ASCII, or ISO 10646 character, there 8is a nonblank character immediately after r*, and that character is not an apostrophe or a quotation 9mark; otherwise, c is interpreted as a literal constant. NOTE 10.29 The end of a record has the effect of a blank, except when it appears within a character constant. 10When the next effective item is of type integer, the value in the input record is interpreted as if an Iw 11edit descriptor with a suitable value of w were used. 12When the next effective item is of type bits, the value in the input record is interpreted as if a Zw edit 13descriptor with a suitable value of w were used. 14When the next effective item is of type real, the input form is that of a numeric input field. A numeric 15input field is a field suitable for F editing (10.7.2.3.2) that is assumed to have no fractional digits unless 16a decimal symbol appears within the field. 17When the next effective item is of type complex, the input form consists of a left parenthesis followed by 18an ordered pair of numeric input fields separated by a comma (if the decimal edit mode is POINT) or 19semicolon (if the decimal edit mode is COMMA), and followed by a right parenthesis. The first numeric 20input field is the real part of the complex constant and the second is the imaginary part. Each of the 21numeric input fields may be preceded or followed by any number of blanks and ends of records. The end 22of a record may occur after the real part or before the imaginary part. 23When the next effective item is of type logical, the input form shall not include value separators among 24the optional characters permitted for L editing. 25When the next effective item is of type character, the input form consists of a possibly delimited sequence 26of zero or more rep-chars whose kind type parameter is implied by the kind of the effective list item. 27Character sequences may be continued from the end of one record to the beginning of the next record, 28but the end of record shall not occur between a doubled apostrophe in an apostrophe-delimited character 29sequence, nor between a doubled quote in a quote-delimited character sequence. The end of the record 30does not cause a blank or any other character to become part of the character sequence. The character 31sequence may be continued on as many records as needed. The characters blank, comma, semicolon, 32and slash may appear in default, ASCII, or ISO 10646 character sequences. 33If the next effective item is of type default, ASCII, or ISO 10646 character and (1) the character sequence does not contain value separators, 34 (2) the character sequence does not cross a record boundary, 35 (3) the first nonblank character is not a quotation mark or an apostrophe, 36 (4) the leading characters are not digits followed by an asterisk, and 37 (5) the character sequence contains at least one character, 38 39the delimiting apostrophes or quotation marks are not required. If the delimiters are omitted, the 40character sequence is terminated by the first blank, comma (if the decimal edit mode is POINT), 41semicolon (if the decimal edit mode is COMMA), slash, or end of record; in this case apostrophes and quotation marks within the datum are not to be doubled. 279 J3/07-007 WORKING DRAFT 2006/01/05 1Let len be the length of the next effective item, and let w be the length of the character sequence. If 2len is less than or equal to w, the leftmost len characters of the sequence are transmitted to the next 3effective item. If len is greater than w, the sequence is transmitted to the leftmost w characters of the 4next effective item and the remaining len-w characters of the next effective item are filled with blanks. 5The effect is as though the sequence were assigned to the next effective item in an intrinsic assignment statement (7.2.1.3). 6 710.10.3.1 Null values 8A null value is specified by (1) the r* form, 9 (2) no characters between consecutive value separators, or 10 11 (3) no characters before the first value separator in the first record read by each execution of a 12 list-directed input statement. NOTE 10.30 The end of a record following any other value separator, with or without separating blanks, does not specify a null value in list-directed input. 13A null value has no effect on the definition status of the next effective item. A null value shall not be 14used for either the real or imaginary part of a complex constant, but a single null value may represent 15an entire complex constant. 16A slash encountered as a value separator during execution of a list-directed input statement causes 17termination of execution of that input statement after the transference of the previous value. Any 18characters remaining in the current record are ignored. If there are additional items in the input list, the 19effect is as if null values had been supplied for them. Any do-variable in the input list becomes defined 20as if enough null values had been supplied for any remaining input list items. NOTE 10.31 All blanks in a list-directed input record are considered to be part of some value separator except for (1) blanks embedded in a character sequence, (2) embedded blanks surrounding the real or imaginary part of a complex constant, and (3) leading blanks in the first record read by each execution of a list-directed input state- ment, unless immediately followed by a slash or comma. NOTE 10.32 List-directed input example: INTEGER I; REAL X (8); CHARACTER (11) P; COMPLEX Z; LOGICAL G ... READ *, I, X, P, Z, G ... The input data records are: 12345,12345,,2*1.5,4* ISN'T_BOB'S,(123,0),.TEXAS$ 280 2006/01/05 WORKING DRAFT J3/07-007 NOTE 10.32 (cont.) The results are: Variable Value I 12345 X (1) 12345.0 X (2) unchanged X (3) 1.5 X (4) 1.5 X (5) ­ X (8) unchanged P ISN'T BOB'S Z (123.0,0.0) G true 10.10.4 List-directed output 1 2The form of the values produced is the same as that required for input, except as noted otherwise. With 3the exception of adjacent undelimited character sequences, the values are separated by one or more 4blanks or by a comma, or a semicolon if the decimal edit mode is comma, optionally preceded by one or 5more blanks and optionally followed by one or more blanks. 6The processor may begin new records as necessary, but the end of record shall not occur within a constant 7except as specified for complex constants and character sequences. The processor shall not insert blanks 8within character sequences or within constants, except as specified for complex constants. 9Logical output values are T for the value true and F for the value false. 10Integer output constants are produced with the effect of an Iw edit descriptor. 11Bits output constants are produced with the effect of a Zw.m edit descriptor with w and m equal to CEILING(k/4.0) where k is the kind type parameter value of the list item. 12 13Real constants are produced with the effect of either an F edit descriptor or an E edit descriptor, 14depending on the magnitude x of the value and a range 10d1 x < 10d2, where d1 and d2 are processor- 15dependent integers. If the magnitude x is within this range or is zero, the constant is produced using 160PFw.d; otherwise, 1PEw.d Ee is used. 17For numeric output, reasonable processor-dependent values of w, d, and e are used for each of the 18numeric constants output. 19Complex constants are enclosed in parentheses with a separator between the real and imaginary parts, 20each produced as defined above for real constants. The separator is a comma if the decimal edit mode is 21POINT; it is a semicolon if the decimal edit mode is COMMA. The end of a record may occur between 22the separator and the imaginary part only if the entire constant is as long as, or longer than, an entire 23record. The only embedded blanks permitted within a complex constant are between the separator and 24the end of a record and one blank at the beginning of the next record. 25Character sequences produced when the delimiter mode has a value of NONE (1) are not delimited by apostrophes or quotation marks, 26 (2) are not separated from each other by value separators, 27 28 (3) have each internal apostrophe or quotation mark represented externally by one apostrophe 29 or quotation mark, and 30 (4) have a blank character inserted by the processor at the beginning of any record that begins 31 with the continuation of a character sequence from the preceding record. 281 J3/07-007 WORKING DRAFT 2006/01/05 1Character sequences produced when the delimiter mode has a value of QUOTE are delimited by quotes, 2are preceded and followed by a value separator, and have each internal quote represented on the external 3medium by two contiguous quotes. 4Character sequences produced when the delimiter mode has a value of APOSTROPHE are delimited 5by apostrophes, are preceded and followed by a value separator, and have each internal apostrophe 6represented on the external medium by two contiguous apostrophes. 7If two or more successive values in an output record have identical values, the processor has the option 8of producing a repeated constant of the form r*c instead of the sequence of identical values. 9Slashes, as value separators, and null values are not produced as output by list-directed formatting. 10Except for continuation of delimited character sequences, each output record begins with a blank char- 11acter. NOTE 10.33 The length of the output records is not specified and may be processor dependent. 10.11 Namelist formatting 12 1310.11.1 General 14Namelist input/output allows data editing with NAME=value subsequences. This facilitates documen- 15tation of input and output files and more flexibility on input. 10.11.2 Name-value subsequences 16 17The characters in one or more namelist records constitute a sequence of name-value subsequences, 18each of which consists of an object designator followed by an equals and followed by one or more values 19and value separators. The equals may optionally be preceded or followed by one or more contiguous 20blanks. The end of a record has the same effect as a blank character, unless it is within a character 21constant. Any sequence of two or more consecutive blanks is treated as a single blank, unless it is within 22a character constant. The name may be any name in the namelist-group-object-list (5.6). 23 A value separator for namelist formatting is the same as for list-directed formatting (10.10). 24 10.11.3 Namelist input 25 26Input for a namelist input statement consists of (1) optional blanks and namelist comments, 27 28 (2) the character & followed immediately by the namelist-group-name as specified in the NAME- 29 LIST statement, (3) one or more blanks, 30 (4) a sequence of zero or more name-value subsequences separated by value separators, and 31 (5) a slash to terminate the namelist input. 32 NOTE 10.34 A slash encountered in a namelist input record causes the input statement to terminate. A slash cannot be used to separate two values in a namelist input statement. 282 2006/01/05 WORKING DRAFT J3/07-007 1In each name-value subsequence, the name shall be the name of a namelist group object list item with 2an optional qualification and the name with the optional qualification shall not be a zero-sized array, a 3zero-sized array section, or a zero-length character string. The optional qualification, if any, shall not 4contain a vector subscript. 5A group name or object name is without regard to case. 610.11.3.1 Namelist group object names 7Within the input data, each name shall correspond to a particular namelist group object name. Sub- 8scripts, strides, and substring range expressions used to qualify group object names shall be optionally 9signed integer literal constants with no kind type parameters specified. If a namelist group object is 10an array, the input record corresponding to it may contain either the array name or the designator of 11a subobject of that array, using the syntax of object designators (R603). If the namelist group object 12name is the name of a variable of derived type, the name in the input record may be either the name of 13the variable or the designator of one of its components, indicated by qualifying the variable name with 14the appropriate component name. Successive qualifications may be applied as appropriate to the shape 15and type of the variable represented. 16The order of names in the input records need not match the order of the namelist group object items. 17The input records need not contain all the names of the namelist group object items. The definition 18status of any names from the namelist-group-object-list that do not occur in the input record remains 19unchanged. In the input record, each object name or subobject designator may be preceded and followed 20by one or more optional blanks but shall not contain embedded blanks. 2110.11.3.2 Namelist group object list items 22The name-value subsequences are evaluated serially, in left-to-right order. A namelist group object 23designator may appear in more than one name-value sequence. 24When the name in the input record represents an array variable or a variable of derived type, the effect 25is as if the variable represented were expanded into a sequence of scalar list items, in the same way that 26formatted input/output list items are expanded (9.5.3). Each input value following the equals shall then 27be acceptable to format specifications for the type of the list item in the corresponding position in the 28expanded sequence, except as noted in this subclause. The number of values following the equals shall 29not exceed the number of list items in the expanded sequence, but may be less; in the latter case, the 30effect is as if sufficient null values had been appended to match any remaining list items in the expanded 31sequence. NOTE 10.35 For example, if the name in the input record is the name of an integer array of size 100, at most 100 values, each of which is either a digit string or a null value, may follow the equals; these values would then be assigned to the elements of the array in array element order. 32A slash encountered as a value separator during the execution of a namelist input statement causes 33termination of execution of that input statement after transference of the previous value. If there are 34additional items in the namelist group object being transferred, the effect is as if null values had been 35supplied for them. 36A namelist comment may appear after any value separator except a slash. A namelist comment is also 37permitted to start in the first nonblank position of an input record except within a character literal 38constant. 39Successive namelist records are read by namelist input until a slash is encountered; the remainder of the 40record is ignored and need not follow the rules for namelist input values. 283 J3/07-007 WORKING DRAFT 2006/01/05 110.11.3.3 Namelist input values 2Each value is either a null value (10.11.3.4), c, r*c, or r*, where c is a literal constant, optionally signed 3if integer or real, and r is an unsigned, nonzero, integer literal constant. A kind type parameter shall not 4be specified for c or r. The constant c is interpreted as though it had the same kind type parameter as 5the corresponding effective item. The r*c form is equivalent to r successive appearances of the constant 6c, and the r* form is equivalent to r successive null values. Neither of these forms may contain embedded 7blanks, except where permitted within the constant c. 8The datum c (10.11) is any input value acceptable to format specifications for a given type, except for 9a restriction on the form of input values corresponding to list items of types logical, integer, bits, and 10character as specified in this subclause. The form of a real or complex value is dependent on the decimal 11edit mode in effect (10.6). The form of an input value shall be acceptable for the type of the namelist 12group object list item. The number and forms of the input values that may follow the equals in a name- 13value subsequence depend on the shape and type of the object represented by the name in the input 14record. When the name in the input record is that of a scalar variable of an intrinsic type, the equals 15shall not be followed by more than one value. Blanks are never used as zeros, and embedded blanks are 16not permitted in constants except within character constants and complex constants as specified in this 17subclause. 18When the next effective namelist group object list item is of type real, the input form of the input value 19is that of a numeric input field. A numeric input field is a field suitable for F editing (10.7.2.3.2) that is 20assumed to have no fractional digits unless a decimal symbol appears within the field. 21When the next effective item is of type complex, the input form of the input value consists of a left 22parenthesis followed by an ordered pair of numeric input fields separated by a comma (if the decimal 23edit mode is POINT) or a semicolon (if the decimal edit mode is COMMA), and followed by a right 24parenthesis. The first numeric input field is the real part of the complex constant and the second part 25is the imaginary part. Each of the numeric input fields may be preceded or followed by any number of 26blanks and ends of records. The end of a record may occur between the real part and the comma or 27semicolon, or between the comma or semicolon and the imaginary part. 28When the next effective item is of type logical, the input form of the input value shall not include equals or value separators among the optional characters permitted for L editing (10.7.3). 29 30When the next effective item is of type integer, the value in the input record is interpreted as if an Iw 31edit descriptor with a suitable value of w were used. 32When the next effective item is of type bits, the value in the input record is interpreted as if a Zw edit 33descriptor with a suitable value of w were used. 34When the next effective item is of type character, the input form consists of a delimited sequence of zero 35or more rep-chars whose kind type parameter is implied by the kind of the corresponding list item. Such 36a sequence may be continued from the end of one record to the beginning of the next record, but the 37end of record shall not occur between a doubled apostrophe in an apostrophe-delimited sequence, nor 38between a doubled quote in a quote-delimited sequence. The end of the record does not cause a blank or 39any other character to become part of the sequence. The sequence may be continued on as many records 40as needed. The characters blank, comma, semicolon, and slash may appear in such character sequences. NOTE 10.36 A character sequence corresponding to a namelist input item of character type shall be delimited either with apostrophes or with quotes. The delimiter is required to avoid ambiguity between undelimited character sequences and object names. The value of the DELIM= specifier, if any, in the OPEN statement for an external file is ignored during namelist input (9.4.5.6). 284 2006/01/05 WORKING DRAFT J3/07-007 1Let len be the length of the next effective item, and let w be the length of the character sequence. If 2len is less than or equal to w, the leftmost len characters of the sequence are transmitted to the next 3effective item. If len is greater than w, the constant is transmitted to the leftmost w characters of the 4next effective item and the remaining len-w characters of the next effective item are filled with blanks. 5The effect is as though the sequence were assigned to the next effective item in an intrinsic assignment statement (7.2.1.3). 6 710.11.3.4 Null values 8A null value is specified by (1) the r* form, 9 (2) blanks between two consecutive nonblank value separators following an equals, 10 (3) zero or more blanks preceding the first value separator and following an equals, or 11 (4) two consecutive nonblank value separators. 12 13A null value has no effect on the definition status of the corresponding input list item. If the namelist 14group object list item is defined, it retains its previous value; if it is undefined, it remains undefined. A 15null value shall not be used as either the real or imaginary part of a complex constant, but a single null 16value may represent an entire complex constant. NOTE 10.37 The end of a record following a value separator, with or without intervening blanks, does not specify a null value in namelist input. 1710.11.3.5 Blanks 18All blanks in a namelist input record are considered to be part of some value separator except for (1) blanks embedded in a character constant, 19 (2) embedded blanks surrounding the real or imaginary part of a complex constant, 20 21 (3) leading blanks following the equals unless followed immediately by a slash or comma, or a 22 semicolon if the decimal edit mode is comma, and (4) blanks between a name and the following equals. 23 2410.11.3.6 Namelist Comments 25Except within a character literal constant, a "!" character after a value separator or in the first nonblank 26position of a namelist input record initiates a comment. The comment extends to the end of the current 27input record and may contain any graphic character in the processor-dependent character set. The 28comment is ignored. A slash within the namelist comment does not terminate execution of the namelist 29input statement. Namelist comments are not allowed in stream input because comments depend on 30record structure. NOTE 10.38 Namelist input example: INTEGER I; REAL X (8); CHARACTER (11) P; COMPLEX Z; LOGICAL G NAMELIST / TODAY / G, I, P, Z, X READ (*, NML = TODAY) The input data records are: 285 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 10.38 (cont.) &TODAY I = 12345, X(1) = 12345, X(3:4) = 2*1.5, I=6, ! This is a comment. P = ''ISN'T_BOB'S'', Z = (123,0)/ The results stored are: Variable Value I 6 X (1) 12345.0 X (2) unchanged X (3) 1.5 X (4) 1.5 X (5) ­ X (8) unchanged P ISN'T BOB'S Z (123.0,0.0) G unchanged 10.11.4 Namelist output 1 2The form of the output produced is the same as that required for input, except for the forms of real, 3character, and logical values. The name in the output is in upper case. With the exception of adjacent 4undelimited character values, the values are separated by one or more blanks or by a comma, or a 5semicolon if the decimal edit mode is COMMA, optionally preceded by one or more blanks and optionally 6followed by one or more blanks. 7Namelist output shall not include namelist comments. 8The processor may begin new records as necessary. However, except for complex constants and character 9values, the end of a record shall not occur within a constant, character value, or name, and blanks shall 10not appear within a constant, character value, or name. NOTE 10.39 The length of the output records is not specified exactly and may be processor dependent. 1110.11.4.1 Namelist output editing Values in namelist output records are edited as for list-directed output (10.10.4). 12 NOTE 10.40 Namelist output records produced with a DELIM= specifier with a value of NONE and which contain a character sequence might not be acceptable as namelist input records. 1310.11.4.2 Namelist output records 14If two or more successive values for the same namelist group item in an output record produced have 15identical values, the processor has the option of producing a repeated constant of the form r*c instead 16of the sequence of identical values. 17The name of each namelist group object list item is placed in the output record followed by an equals 18and a list of values of the namelist group object list item. 19An ampersand character followed immediately by a namelist-group-name will be produced by namelist 20formatting at the start of the first output record to indicate which particular group of data objects is being output. A slash is produced by namelist formatting to indicate the end of the namelist formatting. 286 2006/01/05 WORKING DRAFT J3/07-007 1A null value is not produced by namelist formatting. 2Except for new records created by explicit formatting within a user-defined derived-type output pro- 3cedure or by continuation of delimited character sequences, each output record begins with a blank 4character. 287 J3/07-007 WORKING DRAFT 2006/01/05 288 2006/01/05 WORKING DRAFT J3/07-007 11 Program units 1 11.1 Main program 2 3A Fortran main program is a program unit that does not contain a SUBROUTINE, FUNCTION, 4MODULE, SUBMODULE, or BLOCK DATA statement as its first statement. 5R1101 main-program is [ program-stmt ] 6 [ specification-part ] 7 [ execution-part ] 8 [ internal-subprogram-part ] 9 end-program-stmt 10R1102 program-stmt is PROGRAM program-name R1103 end-program-stmt is END [ PROGRAM [ program-name ] ] 11 12C1101 (R1101) In a main-program, the execution-part shall not contain a RETURN statement or an 13 ENTRY statement. 14C1102 (R1101) The program-name may be included in the end-program-stmt only if the optional 15 program-stmt is used and, if included, shall be identical to the program-name specified in the 16 program-stmt. NOTE 11.1 The program name is global to the program (16.2). For explanatory information about uses for the program name, see subclause C.8.1. NOTE 11.2 An example of a main program is: PROGRAM ANALYZE REAL A, B, C (10,10) ! Specification part CALL FIND ! Execution part CONTAINS SUBROUTINE FIND ! Internal subprogram ... END SUBROUTINE FIND END PROGRAM ANALYZE 17The main program may be defined by means other than Fortran; in that case, the program shall not 18contain a main-program program unit. 19A reference to a Fortran main-program shall not appear in any program unit in the program, including 20itself. 2111.2 Modules 289 J3/07-007 WORKING DRAFT 2006/01/05 111.2.1 General 2A module contains specifications and definitions that are to be accessible to other program units by use 3association. A module that is provided as an inherent part of the processor is an intrinsic module. A 4nonintrinsic module is defined by a module program unit or a means other than Fortran. 5Procedures and types defined in an intrinsic module are not themselves intrinsic. 6R1104 module is module-stmt 7 [ specification-part ] 8 [ module-subprogram-part ] 9 end-module-stmt 10R1105 module-stmt is MODULE module-name R1106 end-module-stmt is END [ MODULE [ module-name ] ] 11 12R1107 module-subprogram-part is contains-stmt [ module-subprogram ] ... 13 14R1108 module-subprogram is function-subprogram 15 or subroutine-subprogram 16 or separate-module-subprogram 17C1103 (R1104) If the module-name is specified in the end-module-stmt, it shall be identical to the 18 module-name specified in the module-stmt. 19C1104 (R1104) A module specification-part shall not contain a stmt-function-stmt, an entry-stmt, or a 20 format-stmt. 21C1105 (R1104) If an object that has a default-initialized direct component is declared in the specifica- 22 tion part of a module it shall have the ALLOCATABLE, POINTER, or SAVE attribute. 23C1106 If an object that has a co-array ultimate component is declared in the specification-part of a 24 module it shall have the SAVE attribute. J3 internal note Unresolved Technical Issue 010 This is better, but still inconsistent. After 06-238r1, top-level allocatable co-arrays are allowed in a module without being SAVEd. Allow that but requiring SAVE for things with co-array components does not make sense. 06-238r1 claims "save is required for a module variable if it has a co-array component. We wish to retain this since otherwise an unexpected implicit synchronization would be needed whenever the module ceases to be active." Why would that be unexpected? I would expect that when the module goes out of scope, the allocatable (co-array thingo) either remains (as is allowed) or is deallocated (as is allowed), with only the latter case requiring (implicit) synchronisation. NOTE 11.3 The module name is global to the program (16.2). NOTE 11.4 Although statement function definitions, ENTRY statements, and FORMAT statements shall not appear in the specification part of a module, they may appear in the specification part of a module subprogram in the module. 290 2006/01/05 WORKING DRAFT J3/07-007 NOTE 11.5 For a discussion of the impact of modules on dependent compilation, see subclause C.8.2. NOTE 11.6 For examples of the use of modules, see subclause C.8.3. 1If a procedure declared in the scoping unit of a module has an implicit interface, it shall be given the 2EXTERNAL attribute in that scoping unit; if it is a function, its type and type parameters shall be 3explicitly declared in a type declaration statement in that scoping unit. 4If an intrinsic procedure is declared in the scoping unit of a module, it shall explicitly be given the 5INTRINSIC attribute in that scoping unit or be used as an intrinsic procedure in that scoping unit. 611.2.2 The USE statement and use association 7The USE statement specifies use association. A USE statement is a reference to the module it 8specifies. At the time a USE statement is processed, the public portions of the specified module shall 9be available. A module shall not reference itself, either directly or indirectly. A submodule shall not 10reference its ancestor module by use association, either directly or indirectly. NOTE 11.7 It is possible for submodules with different ancestor modules to reference each others' ancestor modules by use association. 11The USE statement provides the means by which a scoping unit accesses named data objects, derived 12types, interface blocks, procedures, abstract interfaces, module procedure interfaces, generic identifiers, 13macros, and namelist groups in a module. The entities in the scoping unit are use associated with the 14entities in the module. The accessed entities have the attributes specified in the module, except that an 15entity may have a different accessibility attribute or it may have the ASYNCHRONOUS or VOLATILE 16attribute in the local scoping unit even if the associated module entity does not. The entities made 17accessible are identified by the names or generic identifiers used to identify them in the module. By 18default, they are identified by the same identifiers in the scoping unit containing the USE statement, 19but it is possible to specify that different local identifiers are used. NOTE 11.8 The accessibility of module entities may be controlled by accessibility attributes (4.5.2.2, 5.3.2), and the ONLY option of the USE statement. Definability of module entities can be controlled by the PROTECTED attribute (5.3.14). 20R1109 use-stmt is USE [ [ , module-nature ] :: ] module-name [ , rename-list ] 21 or USE [ [ , module-nature ] :: ] module-name , ONLY : [ only-list ] 22 23R1110 module-nature is INTRINSIC 24 or NON INTRINSIC 25R1111 rename is local-name => use-name 26 or OPERATOR (local-defined-operator) => OPERATOR (use-defined-operator) 27 28R1112 only is generic-spec 29 or only-use-name 291 J3/07-007 WORKING DRAFT 2006/01/05 1 or rename 2R1113 only-use-name is use-name C1107 (R1109) If module-nature is INTRINSIC, module-name shall be the name of an intrinsic module. 3 4C1108 (R1109) If module-nature is NON INTRINSIC, module-name shall be the name of a nonintrinsic 5 module. 6C1109 (R1109) A scoping unit shall not access an intrinsic module and a nonintrinsic module of the 7 same name. C1110 (R1111) OPERATOR(use-defined-operator) shall not identify a type-bound generic interface. 8 C1111 (R1112) The generic-spec shall not identify a type-bound generic interface. 9 NOTE 11.9 The above two constraints do not prevent accessing a generic-spec that is declared by an interface block, even if a type-bound generic interface has the same generic-spec. C1112 (R1112) Each generic-spec shall be a public entity in the module. 10 C1113 (R1113) Each use-name shall be the name of a public entity in the module. 11 12R1114 local-defined-operator is defined-unary-op 13 or defined-binary-op 14R1115 use-defined-operator is defined-unary-op 15 or defined-binary-op C1114 (R1115) Each use-defined-operator shall be a public entity in the module. 16 17A use-stmt without a module-nature provides access either to an intrinsic or to a nonintrinsic module. 18If the module-name is the name of both an intrinsic and a nonintrinsic module, the nonintrinsic module 19is accessed. 20The USE statement without the ONLY option provides access to all public entities in the specified 21module. 22A USE statement with the ONLY option provides access only to those entities that appear as generic- 23specs, use-names, or use-defined-operators in the only-list. 24More than one USE statement for a given module may appear in a scoping unit. If one of the USE 25statements is without an ONLY option, all public entities in the module are accessible. If all the USE 26statements have ONLY options, only those entities in one or more of the only-lists are accessible. 27An accessible entity in the referenced module has one or more local identifiers. These identifiers are 28 (1) the identifier of the entity in the referenced module if that identifier appears as an only-use- 29 name or as the defined-operator of a generic-spec in any only for that module, 30 (2) each of the local-names or local-defined-operators that the entity is given in any rename for 31 that module, and 32 (3) the identifier of the entity in the referenced module if that identifier does not appear as a 33 use-name or use-defined-operator in any rename for that module. 34Two or more accessible entities, other than generic interfaces or defined operators, may have the same 35identifier only if the identifier is not used to refer to an entity in the scoping unit. Generic interfaces 36and defined operators are handled as described in 12.4.3.4 and 12.4.3.4.5. Except for these cases, the 292 2006/01/05 WORKING DRAFT J3/07-007 1local identifier of any entity given accessibility by a USE statement shall differ from the local identifiers 2of all other entities accessible to the scoping unit through USE statements and otherwise. NOTE 11.10 There is no prohibition against a use-name or use-defined-operator appearing multiple times in one USE statement or in multiple USE statements involving the same module. As a result, it is possible for one use-associated entity to be accessible by more than one local identifier. 3The local identifier of an entity made accessible by a USE statement shall not appear in any other 4nonexecutable statement that would cause any attribute (5.3) of the entity to be specified in the scoping 5unit that contains the USE statement, except that it may appear in a PUBLIC or PRIVATE statement 6in the scoping unit of a module and it may be given the ASYNCHRONOUS or VOLATILE attribute. 7The appearance of such a local identifier in a PUBLIC statement in a module causes the entity accessible 8by the USE statement to be a public entity of that module. If the identifier appears in a PRIVATE 9statement in a module, the entity is not a public entity of that module. If the local identifier does not 10appear in either a PUBLIC or PRIVATE statement, it assumes the default accessibility attribute (5.4.1) 11of that scoping unit. NOTE 11.11 The constraints in subclauses 5.7.1, 5.7.2, and 5.6 prohibit the local-name from appearing as a common-block-object in a COMMON statement, an equivalence-object in an EQUIVALENCE statement, or a namelist-group-name in a NAMELIST statement, respectively. There is no prohi- bition against the local-name appearing as a common-block-name or a namelist-group-object. NOTE 11.12 For a discussion of the impact of the ONLY option and renaming on dependent compilation, see subclause C.8.2.1. NOTE 11.13 Examples: USE STATS_LIB provides access to all public entities in the module STATS LIB. USE MATH_LIB; USE STATS_LIB, SPROD => PROD makes all public entities in both MATH LIB and STATS LIB accessible. If MATH LIB contains an entity called PROD, it is accessible by its own name while the entity PROD of STATS LIB is accessible by the name SPROD. USE STATS_LIB, ONLY: YPROD; USE STATS_LIB, ONLY : PROD makes public entities YPROD and PROD in STATS LIB accessible. USE STATS_LIB, ONLY : YPROD; USE STATS_LIB makes all public entities in STATS LIB accessible. 1211.2.3 Submodules 293 J3/07-007 WORKING DRAFT 2006/01/05 1A submodule is a program unit that extends a module or another submodule. The program unit that 2it extends is its parent, and is specified by the parent-identifier in the submodule-stmt. A submodule 3is a child of its parent. An ancestor of a submodule is its parent or an ancestor of its parent. A 4descendant of a module or submodule is one of its children or a descendant of one of its children. The 5submodule identifier is the ordered pair whose first element is the ancestor module name and whose 6second element is the submodule name. NOTE 11.14 A module and its submodules stand in a tree-like relationship one to another, with the module at the root. Therefore, a submodule has exactly one ancestor module and may optionally have one or more ancestor submodules. A submodule accesses the scoping unit of its parent by host association (16.5.1.4). 7 8A submodule may provide implementations for module procedures, each of which is declared by a module 9procedure interface body (12.4.3.2) within that submodule or one of its ancestors, and declarations and 10definitions of other entities that are accessible by host association in its descendants. 11R1116 submodule is submodule-stmt 12 [ specification-part ] 13 [ module-subprogram-part ] 14 end-submodule-stmt R1117 submodule-stmt is SUBMODULE ( parent-identifier ) submodule-name 15 R1118 parent-identifier is ancestor-module-name [ : parent-submodule-name ] 16 R1119 end-submodule-stmt is END [ SUBMODULE [ submodule-name ] ] 17 18C1115 (R1116) A submodule specification-part shall not contain a format-stmt, entry-stmt, or stmt- 19 function-stmt. 20C1116 (R1116) An object with a default-initialized direct component that is declared in the specification 21 part of a submodule shall have the ALLOCATABLE, POINTER, or SAVE attribute. 22C1117 (R1118) The ancestor-module-name shall be the name of a nonintrinsic module; the parent- 23 submodule-name shall be the name of a descendant of that module. 24C1118 (R1116) If a submodule-name appears in the end-submodule-stmt, it shall be identical to the one 25 in the submodule-stmt. 11.3 Block data program units 26 27A block data program unit is used to provide initial values for data objects in named common blocks. 28R1120 block-data is block-data-stmt 29 [ specification-part ] 30 end-block-data-stmt R1121 block-data-stmt is BLOCK DATA [ block-data-name ] 31 R1122 end-block-data-stmt is END [ BLOCK DATA [ block-data-name ] ] 32 33C1119 (R1120) The block-data-name shall be included in the end-block-data-stmt only if it was provided 34 in the block-data-stmt and, if included, shall be identical to the block-data-name in the block- 35 data-stmt. 294 2006/01/05 WORKING DRAFT J3/07-007 1C1120 (R1120) A block-data specification-part shall contain only derived-type definitions and ASYN- 2 CHRONOUS, BIND, COMMON, DATA, DIMENSION, EQUIVALENCE, IMPLICIT, INTRIN- 3 SIC, PARAMETER, POINTER, SAVE, TARGET, USE, VOLATILE, and type declaration 4 statements. 5C1121 (R1120) A type declaration statement in a block-data specification-part shall not contain AL- 6 LOCATABLE, EXTERNAL, or BIND attribute specifiers. NOTE 11.15 For explanatory information about the uses for the block-data-name, see subclause C.8.1. 7If an object in a named common block is initially defined, all storage units in the common block storage 8sequence shall be specified even if they are not all initially defined. More than one named common block 9may have objects initially defined in a single block data program unit. NOTE 11.16 In the example BLOCK DATA INIT REAL A, B, C, D, E, F COMMON /BLOCK1/ A, B, C, D DATA A /1.2/, C /2.3/ COMMON /BLOCK2/ E, F DATA F /6.5/ END BLOCK DATA INIT common blocks BLOCK1 and BLOCK2 both have objects that are being initialized in a single block data program unit. B, D, and E are not initialized but they need to be specified as part of the common blocks. 10Only an object in a named common block may be initially defined in a block data program unit. NOTE 11.17 Objects associated with an object in a common block are considered to be in that common block. 11The same named common block shall not be specified in more than one block data program unit in a 12program. 13There shall not be more than one unnamed block data program unit in a program. NOTE 11.18 An example of a block data program unit is: BLOCK DATA WORK COMMON /WRKCOM/ A, B, C (10, 10) REAL :: A, B, C DATA A /1.0/, B /2.0/, C /100 * 0.0/ END BLOCK DATA WORK 295 J3/07-007 WORKING DRAFT 2006/01/05 296 2006/01/05 WORKING DRAFT J3/07-007 112 Procedures 12.1 Concepts 2 3The concept of a procedure was introduced in 2.2.4. This clause contains a complete description of 4procedures. The actions specified by a procedure are performed when the procedure is invoked by 5execution of a reference to it. 6The sequence of actions encapsulated by a procedure has access to entities in the invoking scoping 7unit by way of argument association (12.5.2). A dummy argument is a name that appears in the 8SUBROUTINE, FUNCTION, or ENTRY statement in the declaration of a procedure (R1235). Dummy 9arguments are also specified for intrinsic procedures and procedures in intrinsic modules in Clauses 13, 1014, and 15. 11The entities in the invoking scoping unit are specified by actual arguments. An actual argument is an entity that appears in a procedure reference (R1223). 12 13A procedure may also have access to entities in other scoping units, not necessarily the invoking scoping 14unit, by use association (16.5.1.3), host association (16.5.1.4), linkage association (16.5.1.5), storage association (16.5.3), or by reference to external procedures (5.3.8). 15 1612.2 Procedure classifications 12.2.1 Procedure classification by reference 17 18The definition of a procedure specifies it to be a function or a subroutine. A reference to a function 19either appears explicitly as a primary within an expression, or is implied by a defined operation (7.1.6) 20within an expression. A reference to a subroutine is a CALL statement, a defined assignment statement 21(7.2.1.4), the appearance of an object processed by user-defined derived-type input/output (9.5.4.7) in an input/output list, or finalization (4.5.6). 22 A procedure is classified as elemental if it is a procedure that may be referenced elementally (12.8). 23 12.2.2 Procedure classification by means of definition 24 2512.2.2.1 Intrinsic procedures 26A procedure that is provided as an inherent part of the processor is an intrinsic procedure. 2712.2.2.2 External, internal, and module procedures 28An external procedure is a procedure that is defined by an external subprogram or by a means other 29than Fortran. 30An internal procedure is a procedure that is defined by an internal subprogram. Internal subprograms 31may appear in the main program, in an external subprogram, or in a module subprogram. Internal 32subprograms shall not appear in other internal subprograms. Internal subprograms are the same as 33external subprograms except that the name of the internal procedure is not a global identifier, an 34internal subprogram shall not contain an ENTRY statement, and the internal subprogram has access to 35host entities by host association. 297 J3/07-007 WORKING DRAFT 2006/01/05 1A module procedure is a procedure that is defined by a module subprogram. 2A subprogram defines a procedure for the SUBROUTINE or FUNCTION statement. If the subprogram 3has one or more ENTRY statements, it also defines a procedure for each of them. 412.2.2.3 Dummy procedures 5A dummy argument that is specified to be a procedure or appears in a procedure reference is a dummy 6procedure. A dummy procedure with the POINTER attribute is a dummy procedure pointer. 712.2.2.4 Procedure pointers 8A procedure pointer is a procedure that has the EXTERNAL and POINTER attributes; it may be 9pointer associated with an external procedure, an internal procedure, an intrinsic procedure, a module 10procedure, or a dummy procedure that is not a procedure pointer. 1112.2.2.5 Statement functions 12 A function that is defined by a single statement is a statement function (12.6.4). 1312.3 Characteristics 12.3.1 Characteristics of procedures 14 15The characteristics of a procedure are the classification of the procedure as a function or subroutine, 16whether it is pure, whether it is elemental, whether it has the BIND attribute, the characteristics of its 17dummy arguments, and the characteristics of its result value if it is a function. 12.3.2 Characteristics of dummy arguments 18 1912.3.2.1 General 20Each dummy argument has the characteristic that it is a dummy data object, a dummy procedure, a 21dummy procedure pointer, or an asterisk (alternate return indicator). A dummy argument other than an asterisk 22may be specified to have the OPTIONAL attribute. This attribute means that the dummy argument 23need not be associated with an actual argument for any particular reference to the procedure. 2412.3.2.2 Characteristics of dummy data objects 25The characteristics of a dummy data object are its type, its type parameters (if any), its shape, its 26co-rank, its co-dimensions, its intent (5.3.9, 5.4.8), whether it is optional (5.3.11, 5.4.9), whether it is 27allocatable (5.3.7.4), whether it has the ASYNCHRONOUS (5.3.4), CONTIGUOUS (5.3.6), VALUE 28(5.3.17), or VOLATILE (5.3.18) attributes, whether it is polymorphic, and whether it is a pointer 29(5.3.13, 5.4.11) or a target (5.3.16, 5.4.14). If a type parameter of an object or a bound of an array is not 30an initialization expression, the exact dependence on the entities in the expression is a characteristic. If 31a shape, size, or type parameter is assumed or deferred, it is a characteristic. 3212.3.2.3 Characteristics of dummy procedures and dummy procedure pointers 33The characteristics of a dummy procedure are the explicitness of its interface (12.4.2), its characteristics as a procedure if the interface is explicit, whether it is a pointer, and whether it is optional (5.3.11, 5.4.9). 34 3512.3.2.4 Characteristics of asterisk dummy arguments 36 An asterisk as a dummy argument has no characteristics. 298 2006/01/05 WORKING DRAFT J3/07-007 112.3.3 Characteristics of function results 2The characteristics of a function result are its type, type parameters (if any), rank, whether it is poly- 3morphic, whether it is allocatable, whether it is a pointer, whether it has the CONTIGUOUS attribute, 4and whether it is a procedure pointer. If a function result is an array that is not allocatable or a pointer, 5its shape is a characteristic. If a type parameter of a function result or a bound of a function result 6array is not an initialization expression, the exact dependence on the entities in the expression is a 7characteristic. If type parameters of a function result are deferred, which parameters are deferred is a 8characteristic. If the length of a character function result is assumed, this is a characteristic. 912.4 Procedure interface 1012.4.1 General 11The interface of a procedure determines the forms of reference through which it may be invoked. 12The procedure's interface consists of its abstract interface, its name, its binding label if any, and the 13procedure's generic identifiers, if any. The characteristics of a procedure are fixed, but the remainder 14of the interface may differ in different scoping units, except that for a separate module procedure body 15(12.6.2.5), the dummy argument names, binding label, and whether it is recursive shall be the same as in its corresponding module procedure interface body (12.4.3.2). 16 17An abstract interface consists of procedure characteristics and the names of dummy arguments. NOTE 12.1 For more explanatory information on procedure interfaces, see C.9.3. 12.4.2 Implicit and explicit interfaces 18 19If a procedure is accessible in a scoping unit, its interface is either explicit or implicit in that scoping 20unit. The interface of an internal procedure, module procedure, or intrinsic procedure is always explicit 21in such a scoping unit. The interface of a subroutine or a function with a separate result name is explicit 22within the subprogram that defines it. The interface of a statement function is always implicit. The interface of 23an external procedure or dummy procedure is explicit in a scoping unit other than its own if an interface body (12.4.3.2) for the procedure is supplied or accessible, and implicit otherwise. 24 NOTE 12.2 For example, the subroutine LLS of C.8.3.5 has an explicit interface. 2512.4.2.1 Explicit interface 26A procedure other than a statement function shall have an explicit interface if it is referenced and (1) a reference to the procedure appears 27 (a) with an argument keyword (12.5.2), 28 (b) in a context that requires it to be pure, or 29 30 (c) with an argument that it not of type bits corresponding to a dummy argument of 31 type bits, (2) the procedure has a dummy argument that 32 33 (a) has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, 34 VALUE, or VOLATILE attribute, (b) is an assumed-shape array, 35 299 J3/07-007 WORKING DRAFT 2006/01/05 (c) is a co-array, 1 (d) is of a parameterized derived type, or 2 (e) is polymorphic, 3 (3) the procedure has a result that 4 (a) is an array, 5 (b) is a pointer or is allocatable, or 6 (c) has a nonassumed type parameter value that is not an initialization expression, 7 (4) the procedure is elemental, or 8 (5) the procedure has the BIND attribute. 9 12.4.3 Specification of the procedure interface 10 1112.4.3.1 General 12The interface for an internal, external, module, or dummy procedure is specified by a FUNCTION, 13SUBROUTINE, or ENTRY statement and by specification statements for the dummy arguments and 14the result of a function. These statements may appear in the procedure definition, in an interface body, 15or both, except that the ENTRY statement shall not appear in an interface body. NOTE 12.3 An interface body cannot be used to describe the interface of an internal procedure, a module procedure that is not a separate module procedure, or an intrinsic procedure because the interfaces of such procedures are already explicit. However, the name of a procedure may appear in a PROCEDURE statement in an interface block (12.4.3.2). 1612.4.3.2 Interface block 17R1201 interface-block is interface-stmt 18 [ interface-specification ] ... 19 end-interface-stmt 20R1202 interface-specification is interface-body 21 or procedure-stmt 22R1203 interface-stmt is INTERFACE [ generic-spec ] 23 or ABSTRACT INTERFACE R1204 end-interface-stmt is END INTERFACE [ generic-spec ] 24 25R1205 interface-body is function-stmt 26 [ specification-part ] 27 end-function-stmt 28 or subroutine-stmt 29 [ specification-part ] 30 end-subroutine-stmt R1206 procedure-stmt is [ MODULE ] PROCEDURE [ :: ] procedure-name-list 31 32R1207 generic-spec is generic-name 33 or OPERATOR ( defined-operator ) 34 or ASSIGNMENT ( = ) 35 or dtio-generic-spec 300 2006/01/05 WORKING DRAFT J3/07-007 1R1208 dtio-generic-spec is READ (FORMATTED) 2 or READ (UNFORMATTED) 3 or WRITE (FORMATTED) or WRITE (UNFORMATTED) 4 5C1201 (R1201) An interface-block in a subprogram shall not contain an interface-body for a procedure 6 defined by that subprogram. 7C1202 (R1201) The generic-spec shall be included in the end-interface-stmt only if it is provided in the 8 interface-stmt. If the end-interface-stmt includes generic-name, the interface-stmt shall specify 9 the same generic-name. If the end-interface-stmt includes ASSIGNMENT(=), the interface- 10 stmt shall specify ASSIGNMENT(=). If the end-interface-stmt includes dtio-generic-spec, the 11 interface-stmt shall specify the same dtio-generic-spec. If the end-interface-stmt includes OP- 12 ERATOR(defined-operator), the interface-stmt shall specify the same defined-operator. If one 13 defined-operator is .LT., .LE., .GT., .GE., .EQ., or .NE., the other is permitted to be the corre- sponding operator <, <=, >, >=, ==, or /=. 14 15C1203 (R1203) If the interface-stmt is ABSTRACT INTERFACE, then the function-name in the 16 function-stmt or the subroutine-name in the subroutine-stmt shall not be the same as a keyword 17 that specifies an intrinsic type. C1204 (R1202) A procedure-stmt is allowed only in an interface block that has a generic-spec. 18 19C1205 (R1205) An interface-body of a pure procedure shall specify the intents of all dummy arguments 20 except pointer, alternate return, and procedure arguments. 21C1206 (R1205) An interface-body shall not contain an entry-stmt, data-stmt, format-stmt, or stmt- 22 function-stmt. 23C1207 (R1206) A procedure-name shall have an explicit interface and shall refer to an accessible pro- 24 cedure pointer, external procedure, dummy procedure, or module procedure. 25C1208 (R1206) If MODULE appears in a procedure-stmt, each procedure-name in that statement shall 26 be accessible in the current scope as a module procedure. 27C1209 (R1206) A procedure-name shall not specify a procedure that is specified previously in any 28 procedure-stmt in any accessible interface with the same generic identifier. 29An external or module subprogram specifies a specific interface for the procedures defined in that 30subprogram. Such a specific interface is explicit for module procedures and implicit for external proce- 31dures. 32An interface block introduced by ABSTRACT INTERFACE is an abstract interface block. An 33interface body in an abstract interface block specifies an abstract interface. An interface block with a 34generic specification is a generic interface block. An interface block with neither ABSTRACT nor a 35generic specification is a specific interface block. 36The name of the entity declared by an interface body is the function-name in the function-stmt or the 37subroutine-name in the subroutine-stmt that begins the interface body. 38A module procedure interface body is an interface body whose initial statement contains the 39keyword MODULE. It defines the module procedure interface for a separate module procedure 40(12.6.2.5). A separate module procedure is accessible by use association if and only if its interface body 41is declared in the specification part of a module and is public. If a corresponding (12.6.2.5) separate 42module procedure is not defined, the interface may be used to specify an explicit specific interface but 43the procedure shall not be used in any other way. 301 J3/07-007 WORKING DRAFT 2006/01/05 C1210 (R1205) A module procedure interface body shall not appear in an abstract interface block. 1 2An interface body in a generic or specific interface block specifies the EXTERNAL attribute and an 3explicit specific interface for an external procedure or a dummy procedure. If the name of the declared 4procedure is that of a dummy argument in the subprogram containing the interface body, the procedure 5is a dummy procedure; otherwise, it is an external procedure. 6An interface body specifies all of the characteristics of the explicit specific interface or abstract interface. 7The specification part of an interface body may specify attributes or define values for data entities that 8do not determine characteristics of the procedure. Such specifications have no effect. 9If an explicit specific interface is specified by an interface body or a procedure declaration statement 10(12.4.3.6) for an external procedure, the characteristics shall be consistent with those specified in the 11procedure definition, except that the interface may specify a procedure that is not pure if the procedure 12is defined to be pure. An interface for a procedure named by an ENTRY statement may be specified by 13using the entry name as the procedure name in the interface body. If an external procedure does not 14exist in the program, an interface body for it may be used to specify an explicit specific interface but 15the procedure shall not be used in any other way. An explicit specific interface may be specified by an 16interface body for an external procedure that does not exist in the program if the procedure is never 17used in any way. A procedure shall not have more than one explicit specific interface in a given scoping 18unit. NOTE 12.4 The dummy argument names in an interface body may be different from the corresponding dummy argument names in the procedure definition because the name of a dummy argument is not a characteristic. NOTE 12.5 An example of a specific interface block is: INTERFACE SUBROUTINE EXT1 (X, Y, Z) REAL, DIMENSION (100, 100) :: X, Y, Z END SUBROUTINE EXT1 SUBROUTINE EXT2 (X, Z) REAL X COMPLEX (KIND = 4) Z (2000) END SUBROUTINE EXT2 FUNCTION EXT3 (P, Q) LOGICAL EXT3 INTEGER P (1000) LOGICAL Q (1000) END FUNCTION EXT3 END INTERFACE This interface block specifies explicit interfaces for the three external procedures EXT1, EXT2, and EXT3. Invocations of these procedures may use argument keywords (12.5.2); for example: PRINT *, EXT3 (Q = P_MASK (N+1 : N+1000), P = ACTUAL_P) 1912.4.3.3 IMPORT statement R1209 import-stmt is IMPORT [[ :: ] import-name-list ] 20 302 2006/01/05 WORKING DRAFT J3/07-007 1C1211 (R1209) The IMPORT statement is allowed only in an interface-body that is not a module 2 procedure interface body. C1212 (R1209) Each import-name shall be the name of an entity in the host scoping unit. 3 4The IMPORT statement specifies that the named entities from the host scoping unit are accessible in 5the interface body by host association. An entity that is imported in this manner and is defined in the 6host scoping unit shall be explicitly declared prior to the interface body. The name of an entity made 7accessible by an IMPORT statement shall not appear in any of the contexts described in 16.5.1.4 that 8cause the host entity of that name to be inaccessible. 9Within an interface body, if an IMPORT statement with no import-name-list appears, each host entity 10not named in an IMPORT statement also is made accessible by host association if its name does not 11appear in any of the contexts described in 16.5.1.4 that cause the host entity of that name to be 12inaccessible. If an entity that is made accessible by this means is accessed by host association and is 13defined in the host scoping unit, it shall be explicitly declared prior to the interface body. NOTE 12.6 The IMPORT statement can be used to allow module procedures to have dummy arguments that are procedures with assumed-shape arguments of an opaque type. For example: MODULE M TYPE T PRIVATE ! T is an opaque type ... END TYPE CONTAINS SUBROUTINE PROCESS(X,Y,RESULT,MONITOR) TYPE(T),INTENT(IN) :: X(:,:),Y(:,:) TYPE(T),INTENT(OUT) :: RESULT(:,:) INTERFACE SUBROUTINE MONITOR(ITERATION_NUMBER,CURRENT_ESTIMATE) IMPORT T INTEGER,INTENT(IN) :: ITERATION_NUMBER TYPE(T),INTENT(IN) :: CURRENT_ESTIMATE(:,:) END SUBROUTINE END INTERFACE ... END SUBROUTINE END MODULE The MONITOR dummy procedure requires an explicit interface because it has an assumed-shape array argument, but TYPE(T) would not be available inside the interface body without the IM- PORT statement. 1412.4.3.4 Generic interfaces 1512.4.3.4.1 Generic identifiers 16A generic interface block specifies a generic interface for each of the procedures in the interface block. 17The PROCEDURE statement lists procedure pointers, external procedures, dummy procedures, or 18module procedures that have this generic interface. A generic interface is always explicit. 19The generic-spec in an interface-stmt is a generic identifier for all the procedures in the interface 20block. The rules specifying how any two procedures with the same generic identifier shall differ are given 303 J3/07-007 WORKING DRAFT 2006/01/05 1 in 12.4.3.4.5. They ensure that any generic invocation applies to at most one specific procedure. 2 A generic name specifies a single name to reference all of the procedure names in the interface block. 3 A generic name may be the same as any one of the procedure names in the interface block, or the same 4 as any accessible generic name. 5 A generic name may be the same as a derived-type name, in which case all of the procedures in the 6 interface block shall be functions. 7 An interface-stmt having a dtio-generic-spec is an interface for a user-defined derived-type input/output procedure (9.5.4.7). 8 NOTE 12.7 An example of a generic procedure interface is: INTERFACE SWITCH SUBROUTINE INT_SWITCH (X, Y) INTEGER, INTENT (INOUT) :: X, Y END SUBROUTINE INT_SWITCH SUBROUTINE REAL_SWITCH (X, Y) REAL, INTENT (INOUT) :: X, Y END SUBROUTINE REAL_SWITCH SUBROUTINE COMPLEX_SWITCH (X, Y) COMPLEX, INTENT (INOUT) :: X, Y END SUBROUTINE COMPLEX_SWITCH END INTERFACE SWITCH Any of these three subroutines (INT SWITCH, REAL SWITCH, COMPLEX SWITCH) may be referenced with the generic name SWITCH, as well as by its specific name. For example, a reference to INT SWITCH could take the form: CALL SWITCH (MAX_VAL, LOC_VAL) ! MAX_VAL and LOC_VAL are of type INTEGER 912.4.3.4.2 Defined operations 10If OPERATOR is specified in a generic specification, all of the procedures specified in the generic 11interface shall be functions that may be referenced as defined operations (7.1.6, 12.5). In the case of 12functions of two arguments, infix binary operator notation is implied. In the case of functions of one 13argument, prefix operator notation is implied. OPERATOR shall not be specified for functions with no 14arguments or for functions with more than two arguments. The dummy arguments shall be nonoptional 15dummy data objects and shall be specified with INTENT (IN). The function result shall not have assumed 16 character length. If the operator is an intrinsic-operator (R310), the number of function arguments shall 17be consistent with the intrinsic uses of that operator, and the types, kind type parameters, or ranks of the dummy arguments shall differ from those required for the intrinsic operation (7.1.5). 18 19A defined operation is treated as a reference to the function. For a unary defined operation, the operand 20corresponds to the function's dummy argument; for a binary operation, the left-hand operand corre- 21sponds to the first dummy argument of the function and the right-hand operand corresponds to the 22second dummy argument. NOTE 12.8 An example of the use of the OPERATOR generic specification is: INTERFACE OPERATOR ( * ) 304 2006/01/05 WORKING DRAFT J3/07-007 NOTE 12.8 (cont.) FUNCTION BOOLEAN_AND (B1, B2) LOGICAL, INTENT (IN) :: B1 (:), B2 (SIZE (B1)) LOGICAL :: BOOLEAN_AND (SIZE (B1)) END FUNCTION BOOLEAN_AND END INTERFACE OPERATOR ( * ) This allows, for example SENSOR (1:N) * ACTION (1:N) as an alternative to the function call BOOLEAN_AND (SENSOR (1:N), ACTION (1:N)) ! SENSOR and ACTION are ! of type LOGICAL 1A given defined operator may, as with generic names, apply to more than one function, in which case 2it is generic in exact analogy to generic procedure names. For intrinsic operator symbols, the generic 3properties include the intrinsic operations they represent. Because both forms of each relational operator 4have the same interpretation (7.1.6.2), extending one form (such as <=) has the effect of defining both forms (<= and .LE.). 5 NOTE 12.9 In Fortran 90 and Fortran 95, it was not possible to define operations on pointers because pointer dummy arguments were disallowed from having an INTENT attribute. The restriction against INTENT for pointer dummy arguments is now lifted, so defined operations on pointers are now possible. However, the POINTER attribute cannot be used to resolve generic procedures (12.4.3.4.5), so it is not possible to define a generic operator that has one procedure for pointers and another procedure for nonpointers. 612.4.3.4.3 Defined assignments 7If ASSIGNMENT ( = ) is specified in a generic specification, all the procedures in the generic interface 8shall be subroutines that may be referenced as defined assignments (7.2.1.4). Defined assignment may, 9as with generic names, apply to more than one subroutine, in which case it is generic in exact analogy 10to generic procedure names. 11Each of these subroutines shall have exactly two dummy arguments. The dummy arguments shall be 12nonoptional dummy data objects. The first argument shall have INTENT (OUT) or INTENT (INOUT) 13and the second argument shall have INTENT (IN). Either the second argument shall be an array whose 14rank differs from that of the first argument, the declared types and kind type parameters of the arguments 15shall not conform as specified in Table 7.12, or the first argument shall be of derived type. A defined 16assignment is treated as a reference to the subroutine, with the left-hand side as the first argument 17and the right-hand side enclosed in parentheses as the second argument. The ASSIGNMENT generic 18specification specifies that assignment is extended or redefined. NOTE 12.10 An example of the use of the ASSIGNMENT generic specification is: INTERFACE ASSIGNMENT ( = ) 305 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 12.10 (cont.) SUBROUTINE LOGICAL_TO_NUMERIC (N, B) INTEGER, INTENT (OUT) :: N LOGICAL, INTENT (IN) :: B END SUBROUTINE LOGICAL_TO_NUMERIC SUBROUTINE CHAR_TO_STRING (S, C) USE STRING_MODULE ! Contains definition of type STRING TYPE (STRING), INTENT (OUT) :: S ! A variable-length string CHARACTER (*), INTENT (IN) :: C END SUBROUTINE CHAR_TO_STRING END INTERFACE ASSIGNMENT ( = ) Example assignments are: KOUNT = SENSOR (J) ! CALL LOGICAL_TO_NUMERIC (KOUNT, (SENSOR (J))) NOTE = '89AB' ! CALL CHAR_TO_STRING (NOTE, ('89AB')) 12.4.3.4.4 User-defined derived-type input/output procedure interfaces 1 2All of the procedures specified in an interface block for a user-defined derived-type input/output proce- 3dure shall be subroutines that have interfaces as described in 9.5.4.7.2. 412.4.3.4.5 Restrictions on generic declarations 5This subclause contains the rules that shall be satisfied by every pair of specific procedures that have 6the same generic identifier within a scoping unit. If a generic procedure is accessed from a module, the 7rules apply to all the specific versions even if some of them are inaccessible by their specific names. NOTE 12.11 In most scoping units, the possible sources of procedures with a particular generic identifier are the accessible interface blocks and the generic bindings other than names for the accessible objects in that scoping unit. In a type definition, they are the generic bindings, including those from a parent type. 8A dummy argument is type, kind, and rank compatible, or TKR compatible, with another dummy 9argument if both have the same rank, and either the first is type compatible with the second and the 10kind type parameters of the first have the same values as the corresponding kind type parameters of the 11second, or the two are bits compatible. 12Two dummy arguments are distinguishable if 13 · one is a procedure and the other is a data object, 14 · they are both data objects or known to be functions, and neither is TKR compatible with the 15 other, 16 · one has the ALLOCATABLE attribute and the other has the POINTER attribute, or 17 · one is a function with nonzero rank and the other is not known to be a function. 18Within a scoping unit, if two procedures have the same generic operator and the same number of 19arguments or both define assignment, one shall have a dummy argument that corresponds by position 20in the argument list to a dummy argument of the other that is distinguishable with it. 306 2006/01/05 WORKING DRAFT J3/07-007 1Within a scoping unit, if two procedures have the same dtio-generic-spec (12.4.3.2), their dtv arguments 2shall be type incompatible or have different kind type parameters. 3Within a scoping unit, two procedures that have the same generic name shall both be subroutines or 4both be functions, and (1) there is a non-passed-object dummy data object in one or the other of them such that 5 6 (a) the number of dummy data objects in one that are nonoptional, are not passed-object, 7 and with which that dummy data object is TKR compatible, possibly including that 8 dummy data object itself, 9 exceeds 10 (b) the number of non-passed-object dummy data objects, both optional and nonoptional, 11 in the other that are not distinguishable with that dummy data object, 12 (2) both have passed-object dummy arguments and the passed-object dummy arguments are 13 distinguishable, or (3) at least one of them shall have both 14 15 (a) a nonoptional non-passed-object dummy argument at an effective position such that 16 either the other procedure has no dummy argument at that effective position or the 17 dummy argument at that position is distinguishable with it, and 18 (b) a nonoptional non-passed-object dummy argument whose name is such that either the 19 other procedure has no dummy argument with that name or the dummy argument 20 with that name is distinguishable with it. 21 and the dummy argument that disambiguates by position shall either be the same as or 22 occur earlier in the argument list than the one that disambiguates by name. 23The effective position of a dummy argument is its position in the argument list after any passed-object 24dummy argument has been removed. 25Within a scoping unit, if a generic name is the same as the name of a generic intrinsic procedure, the 26generic intrinsic procedure is not accessible if the procedures in the interface and the intrinsic procedure 27are not all functions or not all subroutines. If a generic invocation applies to both a specific procedure 28from an interface and an accessible generic intrinsic procedure, it is the specific procedure from the 29interface that is referenced. NOTE 12.12 An extensive explanation of the application of these rules is in C.12.2. 3012.4.3.5 EXTERNAL statement An EXTERNAL statement specifies the EXTERNAL attribute (5.3.8) for a list of names. 31 R1210 external-stmt is EXTERNAL [ :: ] external-name-list 32 33The appearance of the name of a block data program unit in an EXTERNAL statement confirms that 34the block data program unit is a part of the program. NOTE 12.13 For explanatory information on potential portability problems with external procedures, see sub- clause C.9.1. NOTE 12.14 An example of an EXTERNAL statement is: 307 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 12.14 (cont.) EXTERNAL FOCUS 112.4.3.6 Procedure declaration statement 2A procedure declaration statement declares procedure pointers, dummy procedures, and external procedures. It specifies the EXTERNAL attribute (5.3.8) for all entities in the proc-decl-list. 3 4R1211 procedure-declaration-stmt is PROCEDURE ( [ proc-interface ] ) [ [ , proc-attr-spec ] ... :: ] proc-decl-list 5 6R1212 proc-interface is interface-name 7 or declaration-type-spec 8R1213 proc-attr-spec is access-spec 9 or proc-language-binding-spec 10 or INTENT ( intent-spec ) 11 or OPTIONAL 12 or POINTER 13 or SAVE R1214 proc-decl is procedure-entity-name [ => proc-pointer-init ] 14 15R1215 interface-name is name 16R1216 proc-pointer-init is null-init 17 or initial-proc-target 18R1217 initial-proc-target is procedure-name 19 20C1213 (R1215) The name shall be the name of an abstract interface or of a procedure that has an 21 explicit interface. If name is declared by a procedure-declaration-stmt it shall be previously 22 declared. If name denotes an intrinsic procedure it shall be one that is listed in 13.6 and not marked with a bullet (·). 23 C1214 (R1215) The name shall not be the same as a keyword that specifies an intrinsic type. 24 25C1215 If a procedure entity has the INTENT attribute or SAVE attribute, it shall also have the 26 POINTER attribute. 27C1216 (R1211) If a proc-interface describes an elemental procedure, each procedure-entity-name shall 28 specify an external procedure. C1217 (R1214) If => appears in proc-decl, the procedure entity shall have the POINTER attribute. 29 C1218 (R1217) The procedure-name shall be the name of an initialization target. 30 31C1219 (R1211) If proc-language-binding-spec with a NAME= is specified, then proc-decl-list shall con- 32 tain exactly one proc-decl, which shall neither have the POINTER attribute nor be a dummy 33 procedure. 34C1220 (R1211) If proc-language-binding-spec is specified, the proc-interface shall appear, it shall be an 35 interface-name, and interface-name shall be declared with a proc-language-binding-spec. 36If proc-interface appears and consists of interface-name, it specifies an explicit specific interface (12.4.3.2) 37for the declared procedures or procedure pointers. The abstract interface (12.4) is that specified by the 308 2006/01/05 WORKING DRAFT J3/07-007 1interface named by interface-name. 2If proc-interface appears and consists of declaration-type-spec, it specifies that the declared procedures 3or procedure pointers are functions having implicit interfaces and the specified result type. If a type is 4specified for an external function, its function definition (12.6.2.2) shall specify the same result type and 5type parameters. 6If proc-interface does not appear, the procedure declaration statement does not specify whether the 7declared procedures or procedure pointers are subroutines or functions. 8If a proc-attr-spec other than a proc-language-binding-spec appears, it specifies that the declared proce- 9dures or procedure pointers have that attribute. These attributes are described in 5.3. If a proc-language- 10binding-spec with NAME= appears, it specifies a binding label or its absence, as described in 15.5.2. 11A proc-language-binding-spec without a NAME= is allowed, but is redundant with the proc-interface 12required by C1220. 13A procedure is an initialization target if it is a nonelemental external or module procedure, or a specific intrinsic function listed in 13.6 and not marked with a bullet (·). 14 15If => appears in a proc-decl in a procedure-declaration-stmt it specifies the initial association status 16of the corresponding procedure entity, and implies the SAVE attribute, which may be confirmed by 17explicit specification. If => null-init appears, the procedure entity is initially disassociated. If => 18initial-proc-target appears, the procedure entity is initially associated with the target. 19If proc-entity-name has an explicit interface, its characteristics shall be the same as initial-proc-target 20except that initial-proc-target may be pure even if proc-entity-name is not pure and initial-proc-target 21may be an elemental intrinsic procedure. 22If the characteristics of proc-entity-name or initial-proc-target are such that an explicit interface is 23required, both proc-entity-name and initial-proc-target shall have an explicit interface. 24If proc-entity-name has an implicit interface and is explicitly typed or referenced as a function, initial- 25proc-target shall be a function. If proc-entity-name has an implicit interface and is referenced as a 26subroutine, initial-proc-target shall be a subroutine. 27If initial-proc-target and proc-entity-name are functions, they shall have the same type; corresponding 28type parameters shall either both be deferred or both have the same value. NOTE 12.15 In contrast to the EXTERNAL statement, it is not possible to use the PROCEDURE statement to identify a BLOCK DATA subprogram. NOTE 12.16 The following code illustrates PROCEDURE statements. Note 7.48 illustrates the use of the P and BESSEL defined by this code. ABSTRACT INTERFACE FUNCTION REAL_FUNC (X) REAL, INTENT (IN) :: X REAL :: REAL_FUNC END FUNCTION REAL_FUNC END INTERFACE INTERFACE SUBROUTINE SUB (X) 309 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 12.16 (cont.) REAL, INTENT (IN) :: X END SUBROUTINE SUB END INTERFACE !-- Some external or dummy procedures with explicit interface. PROCEDURE (REAL_FUNC) :: BESSEL, GFUN PROCEDURE (SUB) :: PRINT_REAL !-- Some procedure pointers with explicit interface, !-- one initialized to NULL(). PROCEDURE (REAL_FUNC), POINTER :: P, R => NULL() PROCEDURE (REAL_FUNC), POINTER :: PTR_TO_GFUN !-- A derived type with a procedure pointer component ... TYPE STRUCT_TYPE PROCEDURE (REAL_FUNC), POINTER :: COMPONENT END TYPE STRUCT_TYPE !-- ... and a variable of that type. TYPE(STRUCT_TYPE) :: STRUCT !-- An external or dummy function with implicit interface PROCEDURE (REAL) :: PSI 112.4.3.7 INTRINSIC statement An INTRINSIC statement specifies the INTRINSIC attribute (5.3.10) for a list of names. 2 R1218 intrinsic-stmt is INTRINSIC [ :: ] intrinsic-procedure-name-list 3 C1221 (R1218) Each intrinsic-procedure-name shall be the name of an intrinsic procedure. 4 NOTE 12.17 A name shall not be explicitly specified to have both the EXTERNAL and INTRINSIC attributes in the same scoping unit. 512.4.3.8 Implicit interface specification 6In a scoping unit where the interface of a function is implicit, the type and type parameters of the 7function result are specified by an implicit or explicit type specification of the function name. The type, 8type parameters, and shape of dummy arguments of a procedure invoked from a scoping unit where the 9interface of the procedure is implicit shall be such that the actual arguments are consistent with the 10characteristics of the dummy arguments. 1112.5 Procedure reference 12.5.1 Syntax 12 13The form of a procedure reference is dependent on the interface of the procedure or procedure pointer, 14but is independent of the means by which the procedure is defined. The forms of procedure references 15are as follows. R1219 function-reference is procedure-designator ( [ actual-arg-spec-list ] ) 16 C1222 (R1219) The procedure-designator shall designate a function. 17 310 2006/01/05 WORKING DRAFT J3/07-007 1 C1223 (R1219) The actual-arg-spec-list shall not contain an alt-return-spec. R1220 call-stmt is CALL procedure-designator [ ( [ actual-arg-spec-list ] ) ] 2 C1224 (R1220) The procedure-designator shall designate a subroutine. 3 4 R1221 procedure-designator is procedure-name 5 or proc-component-ref 6 or data-ref % binding-name C1225 (R1221) A procedure-name shall be the name of a procedure or procedure pointer. 7 C1226 (R1221) A binding-name shall be a binding name (4.5.5) of the declared type of data-ref . 8 9 C1227 (R1221) If data-ref is an array, the referenced type-bound procedure shall have the PASS at- 10 tribute. 11 Resolving references to type-bound procedures is described in 12.5.6. 12 A function may also be referenced as a defined operation (12.4.3.4.2). A subroutine may also be ref- 13 erenced as a defined assignment (12.4.3.4.3), by user-defined derived-type input/output (9.5.4.7), or by finalization (4.5.6). 14 NOTE 12.18 If image I executes a procedure reference in which the variable of a proc-component-ref specifies a procedure pointer on image J, the procedure pointer association is fetched from image J but the invocation of the associated procedure occurs on image I. R1222 actual-arg-spec is [ keyword = ] actual-arg 15 16 R1223 actual-arg is expr 17 or variable 18 or procedure-name 19 or proc-component-ref 20 or alt-return-spec 21 R1224 alt-return-spec is * label 22C1228 (R1222) The keyword = shall not appear if the interface of the procedure is implicit in the 23 scoping unit. 24C1229 (R1222) The keyword = shall not be omitted from an actual-arg-spec unless it has been omitted 25 from each preceding actual-arg-spec in the argument list. 26C1230 (R1222) Each keyword shall be the name of a dummy argument in the explicit interface of the 27 procedure. C1231 (R1223) A nonintrinsic elemental procedure shall not be used as an actual argument. 28 29C1232 (R1223) A procedure-name shall be the name of an external, internal, module, or dummy proce- 30 dure, a specific intrinsic function listed in 13.6 and not marked with a bullet (·), or a procedure 31 pointer. 32C1233 (R1224) The label shall be the statement label of a branch target statement that appears in the same scoping 33 unit as the call-stmt. 311 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 12.19 Successive commas shall not be used to omit optional arguments. NOTE 12.20 Examples of procedure reference using procedure pointers: P => BESSEL WRITE (*, *) P(2.5) !-- BESSEL(2.5) S => PRINT_REAL CALL S(3.14) NOTE 12.21 An internal procedure cannot be invoked using a procedure pointer from either Fortran or C after the host instance completes execution, because the pointer is then undefined. While the host instance is active, however, the internal procedure may be invoked from outside of the host procedure scoping unit if that internal procedure was passed as an actual argument or is the target of a procedure pointer. b Let us assume there is a procedure with the following interface that calculates f(x)dx. a INTERFACE FUNCTION INTEGRATE(F, A, B) RESULT(INTEGRAL) BIND(C) USE ISO_C_BINDING INTERFACE FUNCTION F(X) BIND(C) ! Integrand USE ISO_C_BINDING REAL(C_FLOAT), VALUE :: X REAL(C_FLOAT) :: F END FUNCTION END INTERFACE REAL(C_FLOAT), VALUE :: A, B ! Bounds REAL(C_FLOAT) :: INTEGRAL END FUNCTION INTEGRATE END INTERFACE This procedure can be called from Fortran or C, and could be written in either Fortran or C. The argument F representing the mathematical function f(x) can be written as an internal procedure; this internal procedure will have access to any host instance local variables necessary to actually calculate f(x). For example: REAL FUNCTION MY_INTEGRATION(N, A, B) RESULT(INTEGRAL) ! Integrate f(x)=x^n over [a,b] USE ISO_C_BINDING INTEGER, INTENT(IN) :: N REAL, INTENT(IN) :: A, B INTEGRAL = INTEGRATE(MY_F, REAL(A, C_FLOAT), REAL(B, C_FLOAT)) ! This will call the internal function MY_F to calculate f(x). ! The above interface of INTEGRATE must be explicit and available. CONTAINS 312 2006/01/05 WORKING DRAFT J3/07-007 NOTE 12.21 (cont.) REAL(C_FLOAT) FUNCTION MY_F(X) BIND(C) ! Integrand REAL(C_FLOAT), VALUE :: X MY_F = X**N ! N is taken from the host instance of MY_INTEGRATION. END FUNCTION END FUNCTION MY_INTEGRATION The function INTEGRATE shall not save a function pointer to MY F and use it after INTEGRATE has finished execution, because the host instance of MY F might no longer exist, making the pointer undefined. If such a pointer is saved, then it can only be used to invoke MY F during the execution of the host instance of MY INTEGRATION called from INTEGRATE. 12.5.2 Actual arguments, dummy arguments, and argument association 1 212.5.2.1 Argument correspondence 3In either a subroutine reference or a function reference, the actual argument list identifies the corre- 4spondence between the actual arguments supplied and the dummy arguments of the procedure. This 5correspondence may be established either by keyword or by position. If an argument keyword appears, 6the actual argument corresponds to the dummy argument whose name is the same as the argument 7keyword (using the dummy argument names from the interface accessible in the scoping unit containing 8the procedure reference). In the absence of an argument keyword, an actual argument corresponds to the 9dummy argument occupying the corresponding position in the reduced dummy argument list; that is, 10the first actual argument corresponds to the first dummy argument in the reduced list, the second actual 11argument corresponds to the second dummy argument in the reduced list, etc. The reduced dummy 12argument list is either the full dummy argument list or, if there is a passed-object dummy argument 13(4.5.4.4), the dummy argument list with the passed object dummy argument omitted. Exactly one 14actual argument shall correspond to each nonoptional dummy argument. At most one actual argument 15shall correspond to each optional dummy argument. Each actual argument shall correspond to a dummy 16argument. NOTE 12.22 For example, the procedure defined by SUBROUTINE SOLVE (FUNCT, SOLUTION, METHOD, STRATEGY, PRINT) INTERFACE FUNCTION FUNCT (X) REAL FUNCT, X END FUNCTION FUNCT END INTERFACE REAL SOLUTION INTEGER, OPTIONAL :: METHOD, STRATEGY, PRINT ... may be invoked with CALL SOLVE (FUN, SOL, PRINT = 6) provided its interface is explicit; if the interface is specified by an interface block, the name of the last argument shall be PRINT. 313 J3/07-007 WORKING DRAFT 2006/01/05 112.5.2.2 The passed-object dummy argument and argument correspondence 2In a reference to a type-bound procedure, or a procedure pointer component, that has a (4.5.4.4), the 3data-ref of the function-reference or call-stmt corresponds, as an actual argument, with the passed-object 4dummy argument. 512.5.2.3 Argument association 6Except in references to intrinsic inquiry functions, a pointer actual argument that corresponds to a 7nonoptional nonpointer dummy argument shall be pointer associated with a target. 8If a nonpointer dummy argument without the VALUE attribute corresponds to a pointer actual argument 9that is pointer associated with a target, the dummy argument becomes argument associated with that 10target. 11If a present nonpointer dummy argument without the VALUE attribute corresponds to a nonpointer 12actual argument it becomes argument associated with that actual argument. 13A present dummy argument with the VALUE attribute becomes argument associated with a definable 14anonymous data object whose initial value is the value of the actual argument. 15A present pointer dummy argument that corresponds to a pointer actual argument becomes argument 16associated with that actual argument. A present pointer dummy argument that does not correspond to 17a pointer actual argument is not argument associated. 18The entity that is argument-associated with a dummy argument is called its effective argument. 1912.5.2.4 Compatibility with bits objects 20An entity is bits compatible with another entity if and only if one is of type bits, the other is of type 21bits, integer, real, complex, or logical, and scalar entities of these types have the same size expressed in 22bits. J3 internal note Unresolved Technical Issue 016 Can "bits compatible" be folded into a new concept of "type and kind compatible"? 2312.5.2.5 Ordinary dummy variables 24The requirements in this subclause apply to actual arguments that correspond to nonallocatable non- 25pointer dummy data objects. 26The dummy argument shall be type compatible with the actual argument or it shall be of type bits and 27bits compatible with the actual argument. 28Unless the actual argument and the corresponding dummy argument are bits compatible, the type 29parameter values of the actual argument shall agree with the corresponding ones of the dummy argument 30that are not assumed, except for the case of the character length parameter of an actual argument of 31type default character associated with a dummy argument that is not assumed shape. 32If a scalar dummy argument is of type default character, the length len of the dummy argument shall 33be less than or equal to the length of the actual argument. The dummy argument becomes associated 34with the leftmost len characters of the actual argument. If an array dummy argument is of type default 35character and is not assumed shape, it becomes associated with the leftmost characters of the actual argument element sequence (12.5.2.12). 36 37The values of assumed type parameters of a dummy argument are assumed from the corresponding type 314 2006/01/05 WORKING DRAFT J3/07-007 1parameters of the actual argument. 2If the actual argument is a co-indexed object with an allocatable ultimate component, the dummy argument shall have the INTENT(IN) or the VALUE attribute. 3 J3 internal note Unresolved Technical Issue 050 Note that this does not match the edit in 06-319r3, but I believe it correctly reflects the technical discussion therein. Remove this UTI if that is correct, and if the requirement is good. NOTE 12.23 If the actual argument is a co-indexed object, a processor that uses distributed memory might create a copy on the executing image of the actual argument, including copies of any allocated allocatable subcomponents, and associate the dummy argument with that copy. If necessary, on return from the procedure, the value of the copy would be copied back to the actual argument. 4Except in references to intrinsic inquiry functions, if the dummy argument is nonoptional and the actual 5argument is allocatable, the corresponding actual argument shall be allocated. NOTE 12.24 Fortran argument association is usually similar to call by reference and call by value-result. If the VALUE attribute is specified, the effect is as if the actual argument is assigned to a temporary, and the temporary is then argument associated with the dummy argument. Subsequent changes to the value or definition status of the dummy argument do not affect the actual argument. The actual mechanism by which this happens is determined by the processor. 6If the dummy argument does not have the TARGET attribute, or is not type-compatible with the 7actual argument, any pointers associated with the effective argument do not become associated with the 8corresponding dummy argument on invocation of the procedure. If such a dummy argument is used as 9an actual argument that corresponds to a dummy argument with the TARGET attribute, whether any 10pointers associated with the original effective argument become associated with the dummy argument 11with the TARGET attribute is processor dependent. 12If the dummy argument has the TARGET attribute, is type-compatible with the actual argument, does 13not have the VALUE attribute, and is either a scalar or an assumed-shape array that does not have the 14CONTIGUOUS attribute, and the effective argument has the TARGET attribute but is not a co-indexed 15object or an array section with a vector subscript then 16 (1) any pointers associated with the effective argument become associated with the correspond- 17 ing dummy argument on invocation of the procedure, and 18 (2) when execution of the procedure completes, any pointers that do not become undefined 19 (16.5.2.2.3) and are associated with the dummy argument remain associated with the effec- 20 tive argument. 21If the dummy argument has the TARGET attribute and is an explicit-shape array, an assumed-shape 22array with the CONTIGUOUS attribute, or an assumed-size array, and the effective argument has the 23TARGET attribute but is not an array section with a vector subscript then 24 (1) on invocation of the procedure, whether any pointers associated with the effective argument 25 become associated with the corresponding dummy argument is processor dependent, and 26 (2) when execution of the procedure completes, the pointer association status of any pointer 27 that is pointer associated with the dummy argument is processor dependent. 28If the dummy argument has the TARGET attribute and the effective argument does not have the 315 J3/07-007 WORKING DRAFT 2006/01/05 1TARGET attribute or is an array section with a vector subscript, or the dummy argument is not 2type-compatible with the actual argument, any pointers associated with the dummy argument become 3undefined when execution of the procedure completes. 4If the dummy argument has the TARGET attribute and the VALUE attribute, any pointers associated 5with the dummy argument become undefined when execution of the procedure completes. 6If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual 7argument is of type default character, of type character with the C character kind (15.2), or is an element 8or substring of an element of an array that is not an assumed-shape, pointer, or polymorphic array. If 9the procedure is nonelemental and is referenced by a generic name or as a defined operator or defined 10assignment, the ranks of the actual arguments and corresponding dummy arguments shall agree. 11If a dummy argument is an assumed-shape array, the rank of the actual argument shall be the same as 12the rank of the dummy argument; the actual argument shall not be an assumed-size array (including an array element designator or an array element substring designator). 13 14Except when a procedure reference is elemental (12.8), each element of an array actual argument or of 15a sequence in a sequence association (12.5.2.12) is associated with the element of the dummy array that has the same position in array element order (6.2.2.1). 16 NOTE 12.25 For type default character sequence associations, the interpretation of element is provided in 12.5.2.12. 17A scalar dummy argument of a nonelemental procedure shall be associated only with a scalar actual 18argument. 19If a dummy argument has INTENT (OUT) or INTENT (INOUT), the actual argument shall be definable. 20If a dummy argument has INTENT (OUT), the actual argument becomes undefined at the time the 21association is established, except for direct components of an object of derived type for which default 22initialization has been specified. If the dummy argument is not polymorphic and the type of the effective 23argument is an extension type of the type of the dummy argument, only the part of the effective argument 24that is of the same type as the dummy argument becomes undefined. 25If the actual argument is an array section having a vector subscript, the dummy argument is not defin- 26able and shall not have the ASYNCHRONOUS, INTENT (OUT), INTENT (INOUT), or VOLATILE 27attributes. NOTE 12.26 Argument intent specifications serve several purposes. See Note 5.16. NOTE 12.27 For more explanatory information on argument association and evaluation, see subclause C.9.5. For more explanatory information on targets as dummy arguments, see subclause C.9.6. 28C1234 An actual argument that is a co-indexed object shall not correspond to a dummy argument that 29 has either the ASYNCHRONOUS or VOLATILE attribute. 30C1235 (R1223) If an actual argument is an array section or an assumed-shape array, and the corre- 31 sponding dummy argument has either the VOLATILE or ASYNCHRONOUS attribute, that 32 dummy argument shall be an assumed-shape array that does not have the CONTIGUOUS 33 attribute. 316 2006/01/05 WORKING DRAFT J3/07-007 1C1236 (R1223) If an actual argument is a pointer array, and the corresponding dummy argument 2 has either the VOLATILE or ASYNCHRONOUS attribute, that dummy argument shall be an 3 assumed-shape array that does not have the CONTIGUOUS attribute or a pointer array. J3 internal note Unresolved Technical Issue 097 So, consider this example. INTERFACE ASSIGNMENT(=) SUBROUTINE s(a,b) REAL,INTENT(OUT),VOLATILE :: a(*) REAL,INTENT(IN) :: b(:) END SUBROUTINE END REAL,POINTER :: p(:),q(:) ... CALL s(p,q) ! Constraint violation associating P with A p = q ! No constraint violation because ! syntax is not being used. Hmm, maybe this should be an interp? Is there any doubt as to our intention? Is there any doubt the standard does not reflect that intention? NOTE 12.28 The constraints on actual arguments that correspond to a dummy argument with either the ASYN- CHRONOUS or VOLATILE attribute are designed to avoid forcing a processor to use the so-called copy-in/copy-out argument passing mechanism. Making a copy of actual arguments whose values are likely to change due to an asynchronous I/O operation completing or in some unpredictable manner will cause those new values to be lost when a called procedure returns and the copy-out overwrites the actual argument. 412.5.2.6 Allocatable and pointer dummy variables 5The requirements in this subclause apply to actual arguments that correspond to either allocatable or 6pointer dummy data objects. 7The actual argument shall be polymorphic if and only if the associated dummy argument is polymorphic, 8and either both the actual and dummy arguments shall be unlimited polymorphic, or the declared type 9of the actual argument shall be the same as the declared type of the dummy argument. NOTE 12.29 The dynamic type of a polymorphic allocatable or pointer dummy argument may change as a result of execution of an allocate statement or pointer assignment in the subprogram. Because of this the corresponding actual argument needs to be polymorphic and have a declared type that is the same as the declared type of the dummy argument or an extension of that type. However, type compatibility requires that the declared type of the dummy argument be the same as, or an extension of, the type of the actual argument. Therefore, the dummy and actual arguments need to have the same declared type. Dynamic type information is not maintained for a nonpolymorphic allocatable or pointer dummy argument. However, allocating or pointer assigning such a dummy argument would require main- tenance of this information if the corresponding actual argument is polymorphic. Therefore, the corresponding actual argument needs to be nonpolymorphic. 317 J3/07-007 WORKING DRAFT 2006/01/05 1The rank of the actual argument shall be the same as that of the dummy argument. The type parameter 2values of the actual argument shall agree with the corresponding ones of the dummy argument that are 3not assumed or deferred. 4The values of assumed type parameters of a dummy argument are assumed from the corresponding type 5parameters of the associated actual argument. 6The actual argument shall have deferred the same type parameters as the dummy argument. 7If the actual argument is a co-indexed object, the dummy argument shall have the INTENT(IN) at- 8tribute. J3 internal note Unresolved Technical Issue 096 Co-indexed actual to pointer/allocatable dummy. In the interests of preventing remote allocation/deallocation or remote pointer assignment, in accordance with the reasoning in 06-319r3, it would seem necessary to have the above requirement specified somewhere. This seems like the obvious place to have it: this subclause contains those requirements which apply both to allocatable dummies and to pointer dummies. It's possible that the requirement already exists somewhere else, in which case it's superfluous here ... but the authors of 06-319r3 clearly didn't think so, at least in the allocatable case. If this requirement is too onerous for the pointer case, just move the above sentence to the next subclause, which applies only to the allocatable case. Note that this might have some "consistency" interaction with what is left of UTI 050. 912.5.2.7 Allocatable dummy variables 10The requirements in this subclause apply to actual arguments that correspond to allocatable dummy 11data objects. 12The actual argument shall be allocatable. It is permissible for the actual argument to have an allocation 13status of unallocated. 14If the dummy argument does not have the TARGET attribute, any pointers associated with the ac- 15tual argument do not become associated with the corresponding dummy argument on invocation of the 16procedure. If such a dummy argument is used as an actual argument that is associated with a dummy ar- 17gument with the TARGET attribute, whether any pointers associated with the original actual argument 18become associated with the dummy argument with the TARGET attribute is processor dependent. 19If the dummy argument has the TARGET attribute, does not have the INTENT(OUT) or VALUE 20attribute, and the corresponding actual argument has the TARGET attribute then 21 (1) any pointers associated with the actual argument become associated with the corresponding 22 dummy argument on invocation of the procedure, and 23 (2) when execution of the procedure completes, any pointers that do not become undefined 24 (16.5.2.2.3) and are associated with the dummy argument remain associated with the actual 25 argument. 26If a dummy argument has INTENT (OUT) or INTENT (INOUT), the actual argument shall be definable. 27If a dummy argument has INTENT (OUT), an allocated actual argument is deallocated on procedure invocation (6.3.3.1). 28 2912.5.2.8 Pointer dummy variables 30The requirements in this subclause apply to actual arguments that correspond to dummy data pointers. 31If the dummy argument does not have the INTENT(IN) attribute, the actual argument shall be a 318 2006/01/05 WORKING DRAFT J3/07-007 1pointer. Otherwise, the actual argument shall be a pointer or a valid target for the dummy pointer in 2a pointer assignment statement. If the actual argument is not a pointer, the dummy pointer becomes 3pointer-associated with the actual argument. 4The nondeferred type parameters and ranks shall agree. 5If the dummy pointer has the CONTIGUOUS attribute and the actual argument does not have the 6CONTIGUOUS attribute, the actual argument shall satisfy the following conditions. 7 · Its base object shall either have the CONTIGUOUS attribute or shall not be a pointer or assumed- 8 shape array. 9 · It shall not be the real or imaginary part of an array of type complex. 10 · Its designator shall not contain a substring-range. 11 · It shall not have a vector subscript. 12 · Only its final part-ref shall have nonzero rank. 13 · If that part-ref has a section-subscript-list, the section-subscript-list shall satisfy these conditions: 14 ­ no stride shall appear; 15 ­ if any section-subscript is a subscript, it shall not be followed by a subscript-triplet; 16 ­ all but the last subscript-triplet shall consist of a single colon with no subscript. NOTE 12.30 This requires that the actual argument be obviously contiguous at compile time. Columns, planes, cubes and hypercubes of contiguous base objects can be passed, for example: ARRAY1 (10:20, 3) ! passes part of the third column of ARRAY1. X3D (:, i:j, 2) ! passes part of the second plane of X3D (or the whole ! plane if i==LBOUND(X3D,2) and j==UBOUND(X3D,2). Y5D (:, :, :, :, 7) ! passes the seventh hypercube of Y5D. 17If the dummy argument has INTENT(OUT), the pointer association status of the actual argument 18becomes undefined on invocation of the procedure. 19If the dummy argument is nonoptional and the actual argument is allocatable, the actual argument shall 20be allocated. NOTE 12.31 For more explanatory information on pointers as dummy arguments, see subclause C.9.6. 2112.5.2.9 Co-array arguments 22If the dummy argument is an allocatable co-array, the actual argument shall be an allocatable co-array 23with the same rank and co-rank. 24If a dummy argument is a nonallocatable co-array, the co-rank and co-bounds are specified by the local 25declaration and are independent of those of the actual argument. The actual argument shall be a co-array 26or a subobject of a co-array without any co-subscripts, vector-valued subscripts, non-co-array allocatable 27component selection, or pointer component selection. 319 J3/07-007 WORKING DRAFT 2006/01/05 NOTE 12.32 The co-array on the executing image is specified as the actual argument and this is associated with the dummy co-array argument on the same image. There are corresponding co-arrays on the other images. For example: INTERFACE SUBROUTINE SUB(X, Y) REAL :: X(:)[*], Y(:)[*] END SUBROUTINE SUB END INTERFACE ... REAL, ALLOCATABLE :: A(:)[:], B(:,:)[:] ... CALL SUB(A(:), B(1,:)) NOTE 12.33 The bounds and co-bounds of a dummy co-array may differ on each image executing a reference to the procedure. A co-indexed data-ref always uses the bounds and co-bounds on the executing image. 1If the dummy argument is a co-array that has the CONTIGUOUS attribute or is not of assumed shape, 2the actual argument shall be compile-time contiguous. J3 internal note Unresolved Technical Issue 101 Use of undefined term "compile-time contiguous". This term has not been defined. According to a straw vote taken at meeting 178, it ought to be. NOTE 12.34 The requirements on an actual argument that corresponds to a dummy co-array that is not of assumed-shape or has the CONTIGUOUS attribute are designed to avoid forcing a processor to use the so-called copy-in/copy-out