To: J3 J3/21-190 From: Malcolm Cohen Subject: Editorial/technical fixes, mostly for enum types Date: 2021-October-18 Reference: 21-110r1, 21-121 1. Introduction This paper contains possible editorial improvements, and also some editorial/technical fixes. These are split into edits to make our rather handwavy i/o for enums more rigorous, and other edits. We don't really need to do the i/o edits, but we do need the other edits. 2. Edits to change i/o exposition Our description of how i/o is done for interoperable enums has been criticised as being too vague. This completely replaces the current description with a more rigorous one. [244:3-4] 12.6.3 Data transfer input/output list, p6, Delete whole p6 "A list item that is of an interoperable...". {Replaced by the multitudinous edits below.} [276:4-5] 13.7.2.1 General rules (in 13.7.2 Numeric editing), p1, Change "As interoperable... (12.6.3), the" -> "The", and in the same sentence, "can also" -> "can". {There is no "as" any more.} [276:32] 13.7.2.2 Integer editing, para 1, penultimate sentence, before "enumeration" insert "enum or", making that sentence read "The corresponding effective item shall be of type integer or of enum or enumeration type." {Permit enum type for I edit descriptor.} [277:8] Same subclause, p6, "item item" -> "item". {Fix typoo.} [277:9+] Same subclause, p6+, append new para to subclause, "If the effective item for output is of enum type, the value output is its corresponding integer value. If the effective item for input is of enum type, the value assigned is the enum value corresponding to the value of the input field." {Semantics.} [282:25] 13.7.2.4 B, O, and Z editing, para 1, final sentence, before "enumeration" insert "enum or", making that sentence read "The corresponding effective item shall be of type integer, real, or complex, or of enum or enumeration type." {Permit enum type for BOZ edit descriptors.} [282:34] 13.7.2.4 B, O, and Z editing, para 4, final sentence, before "enumeration" insert "enum or", making that sentence read "If the effective item is of enum or enumeration type ET, the value is ET (INT (X))." {Input semantics. Output needs no extra semantics.} [284:17] 13.7.5.2.1 Overview (in 13.7.5.2 Generalized numeric editing), p1, "and complex" -> "complex, and enum", making the whole paragraph (excluding the NOTE) read "When used to specify the input/output of integer, real, complex, and enum data, the Gw, Gw.d and Gw.d Ee edit descriptors follow the general rules for numeric editing (13.7.2)." {Apply the general rules to enum data too.} [284:19] 13.7.5.2.2 Generalized integer editing, heading, -> "13.7.5.2.2 Generalized integer and enum editing". [284:20] p1, "integer" -> "integer or enum", making that whole paragraph read "When used to specify the input/output of integer or enum data, the Gw, Gw.d, and Gw.d Ee edit descriptors follow the rules for the Iw edit descriptor (13.7.2.2). Note that w cannot be zero for input editing (13.7.5.1)." {Semantics. It doesn't seem worth creating a whole new subclause just to say that enum is handled as by the I edit descriptor.} 3. Other edits [9:21] 3.57 definition, qualification part, "enumeration (7.6.1)" -> "interoperable enumeration (7.6.1), enumeration type (7.6.2)" making the whole definition read "3.57 definition specification of the type, enumeration, or procedure" {Editorial fix: include enumeration type definitions in the definition of definition.} [21:13] 3.147.3, derived type change "defined by a type definition" to "defined by a derived-type definition" {Slightly less misleading.} [36:17+9-14] 5.3.2 Statement order, Table 5.1, Change text block "Derived-type definitions, ... and statement function statements" to "Specification constructs \obs{and statement function statements}". {Was missing GENERIC statements and enumeration type definitions. Although PARAMETER is included in specification constructs, there is no ambiguity with it being permitted twice in the same place. There is a nice symmetry with "Specification constructs" here and "Executable constructs" in the next lower text block.} ALTERNATIVE [same place] change "enumeration definitions" to "GENERIC statements, enumeration type definitions, interoperable enumeration definitions" {Make the wall of text more opaque.} [39:27] 5.4.1.1 General (in 5.4.1 Type), p2, "derived" -> "nonintrinsic". Append sentence "A nonintrinsic type is defined by the program or by an intrinsic module." making that whole paragraph read "A type is either an intrinsic type or a nonintrinsic type. A nonintrinsic type is defined by the program or by an intrinsic module." {Rewrite and future-proof. Note that nonintrinsic modules are part of the program.} [40:12] 5.4.2 Data value, p1, append "The values that an object of a nonderived nonintrinsic type can assume are determined by the type definition." {Add our new types here, and attempt to future-proof.} [44:4] 5.5.1 Names and designators, p1, "derived" -> "nonintrinsic", making the whole paragraph read "A name is used to identify a program constituent, such as a program unit, named variable, named constant, dummy argument, or nonintrinsic type." {Technically wasn't wrong because of "such as", only misleading. Actually is also omits construct names, external procedure names, internal procedure names... it was just the specific calling out of *derived* that seems misleading.} [47:13] 6.2.2 Names, p1 "derived" -> "nonintrinsic", making that whole sentence "Names are used for various entities such as variables, program units, dummy arguments, named constants, and nonintrinsic types." {Why do we keep repeating the same partial list?} [54:9] 7.1.2 Type classification, p1, "derived" -> "nonintrinsic", making that whole paragraph read "A type is either an intrinsic type or a nonintrinsic type." {Another duplicate paragraph. Correct it and future-proof it.} [54:11-12] Same subclause, p3, after "or by an intrinsic module.", insert new sentences "An enum type is one that is defined by an enum type definition (7.6.1) or by an intrinsic module. An enumeration type is one that is defined by an enumeration type definition (7.6.2) or by an intrinsic module." Change "It shall be" to "A nonintrinsic type name shall be", making that sentence read "A nonintrinsic type name shall be used only where it is accessible (7.5.2.2)." {Add missing cases to type classification. Explicitly mention that an intrinsic module can provide enum/enumeration type. Also, change "type can be used" to "type name can be used", because other uses of a type that do not need its name can be done without access to the name.} [54:17] 7.1.3 Set of values, p1, append "The set of valid values for an enum type is as defined in 7.6.1. The set of valid values for an enumeration type is as defined in 7.6.2." {More missing text.} [54:21-23] 7.1.4 Constants, p3, Before "An array constructor" insert new sentences "An enum constructor (7.6.1) that is a constant expression denotes a scalar constant value of enum type. An enumeration constructor (7.6.2) that is a constant expression denotes a scalar constant value of enumeration type." At the end of the paragraph, "or derived type" -> "or nonintrinsic type". {More missing duplicative text. Maybe we should be trying harder to say these things only once? But right now, we don't.} [54:30+] 7.1.5 Operations, append new paragraph to subclause "For an enum or enumeration type, a set of intrinsic operations is defined intrinsically as described in Clause 10. The intrinsic set can be augmented with operations and operators defined by the program." {More blather.} [56:3] 7.3.1 Relationship of types and values to objects, p2, "derived" -> "nonintrinsic", making the whole paragraph read "An array is formed of scalar data of an intrinsic or nonintrinsic type, and has the same type and type parameters as its elements." {More blather.} [57:10-11] 7.3.2.2 TYPE type specifier, p1, ", derived, or other user-defined" -> "or nonintrinsic", making the whole paragraph read "A TYPE type specifier is used to declare entities that are assumed- type, or of an intrinsic or nonintrinsic type." {Simplify wording, don't claim enum/enumeration have to be "user-defined".} [57:12-17] Same subclause, p2, After "derived-type-spec" insert ", enum-type-spec, or enumeration-type-spec", change every "derived type" -> "type" within the paragraph, and change "derived-type-def" -> "definition", making the whole paragraph read "A derived-type-spec, enum-type-spec, or enumeration-type-spec in a TYPE type specifier in a type declaration statement shall specify a previously defined type. If the data entity is a function result, the type may be specified in the FUNCTION statement provided the type is defined within the body of the function or is accessible there by use or host association. If the type is specified in the FUNCTION statement and is defined within the body of the function, it is as if the function result were declared with that type immediately following the definition of the specified type." {Promulgate requirements and abilities of TYPE(derived) to TYPE(enum) and TYPE(enumeration).} [88:7] 7.6 Other user-defined types, heading, "user-defined" -> "nonintrinsic". [88:12] Same subclause, p1, "user-defined" -> "nonintrinsic". {Avoid saying these are necessarily user-defined.} [88:12] 7.6.1 Interoperable enumerations and enum types, p1, "user-defined type" -> "nonintrinsic type". {Technical fix: Allow in intrinsic modules.} [88:25] Same subclause, p2 "C enumeration type" -> "C enumerated type", twice. {Wrong terminology.} [89:1+] After p3, insert new paragraph "An enum type specifier specifiers the type. Two data entities of enum type have the same type if they are declared with reference to the same enum type definition." {Dot the eyes and cross the tees.} [89:4+] Same subclause, NOTE 1, "enumeration type" -> "C enumerated type" (line 1 of NOTE 1), and in NOTE 3, "enumeration types" -> "C enumerated types", twice (lines 1 and 4 of NOTE 3). {Wrong terminology.} [89:13-16] Same subclause, R765 enum-constructor, the following constraint C7113 "The expr...", and para 6, change "expr" to "scalar-expr" thrice. This makes that rule, constraint, and paragraph read "R765 enum-constructor is enum-type-spec ( scalar-expr ) C7113 The scalar-expr in an enum-constructor shall be of type integer or be a boz-literal-constant. An enum constructor produces a scalar value of the specified type, with the specified internal representation. The value of scalar-expr shall be representable in objects of that type." {Technical fix: Enforce argument of the enum constructor being scalar.} [90:2] 7.6.2 Enumeration types, p1, "user-defined type" -> "nonintrinsic type". {Technical fix: Allow in intrinsic modules.} [100:8] 8.5.2 Accessibility attribute, p2, After "of the derived type name." insert new sentence "An in an specifies the accessibility of the enumeration type name, and the default accessibility of its enumerators." {Missing waffle.} [114:29] 8.6 Attribute specification statements, C874 "(R832) Each access-name shall be...", Change "derived type" to "nonintrinsic type". {Fix obvious oversight. Actually we don't even need "nonintrinsic" here, as intrinsic types don't have names, only keywords.} [117:23-24] 8.6.7 DATA statement, C887, After "If a DATA statement constant value is a named constant," delete "or a", after "structure constructor" insert ", enum constructor, or enumeration constructor", after "the named constant or" delete "derived", making the whole constraint read "C887 (R849) If a DATA statement constant value is a named constant, structure constructor, enum constructor, or enumeration constructor, the named constant or type shall have been defined previously." {Technical fix: Require previous definition for DATA.} [127:3] 8.10.1.1 General (in 8.10.1 EQUIVALENCE statement), C8110, After "nonsequence derived type," insert "an object of enumeration type," {Don't extend enumeration type to EQUIVALENCE. Do allow enum type though (by not saying anything).} [128:20] 8.10.2.1 General (in 8.10.2 COMMON statement), After "ultimate component that is allocatable," insert "an object of enumeration type,". {Don't extend enumeration type to COMMON. Do allow enum type though (by not saying anything).} [129:24+] 8.10.2.4 Common association, p4+ After p4 "A nonpointer object of a derived..." insert new paragraph "A nonpointer object of an enum type shall be associated only with nonpointer objects of the same type." {Require type conformance for enums in common.} ALTERNATIVE As above, but at the end of the sentence insert "or with nonpointer objects of integer type with the same kind as its enumerators". {So someone can give an existing ENUM,BIND(C) a name and start to change the COMMON blocks, but not required to change them all. Is this worth it?} [164:18] 10.1.9.1 General (in 10.1.9 Type, type parameters, and shape of an expression), p1, in the last sentence, "derived type (7.5)" -> "nonintrinsic type (7.5, 7.6)", making that sentence read "The type of an expression is one of the intrinsic types (7.4) or a nonintrinsic type (7.5, 7.6)." {Technical fix. Moderately future-proof.} [299:24] 14.2.2 The USE statement and use association, p2, 1st sentence, "derived types" -> "nonintrinsic types". {Actually just "types" would be sufficient.} [506:5-] 18.3.3 Interoperability of derived types and C structure types, immediately before that subclause insert new subclause "18.3.3- Interoperability of enum types An enum type interoperates with its corresponding C enumerated type. It also interoperates with the C integer type that interoperates with its enumerators." {Not totally sure we need this, but it's pretty vague if we don't say anything at all.} [529:6] 19.3.1 Classes of local identifiers, p1, item (1), "derived types" -> "nonintrinsic types". {Add enum and enumeration type names to class (1) names.} [533:13] 19.5.1.4 Host association, p1, "derived types" -> "nonintrinsic types". {Allow host association for enum and enumeration type names.} 4. Edits not done Currently, defined input/output is not available for enum or enumeration type. That stands. For enum type it is not really workable at all, because the enumerators are of integer type so would not be subject to defined input/output. We don't allow generic names to be the same as an enum or enumeration type name. (15.4.3.4.1 Generic identifiers, p4 allows derived type names.) ===END===