J3/98-153 Date: 26 May 1998 To: J3 From: R. Maine Subject: More edits for R.5, PDTs Syntax for PDTs was approved as 97-104r2. Partial edits, up through section 4, were approved as 98-122R1. The following is proposed as further edits. These edits are all relative to 98-007r1. The following 6 edits remove the definitions and uses of the terms numeric sequence structure and character sequence structure. These terms are used only in one note and one sentence of normative text. All uses are pretty easily rewritten to use the previously defined terms character sequence type and numeric sequence type. These edits have little to do with pdts, except that I was editing the pertinent areas and noticed the definitions of these seldom-used terms. [55:10-12] Delete the last 2 sentences of the para "A scalar entity of numeric...character sequence structure." [75:14] "Structures" -> "A structure"; "appear" -> "appears"; "be" -> "be a" [75:17] "numeric sequence structure" -> "structure of a numeric sequence type" (twice) [75:21-22] "chararacter sequence structure" -> "structure of a character sequence type" (twice) [75:23] "Other objects" -> "An object of intrinsic type with non-default kind type parameters" (Incorrectly stated in f90/f95 - but its in a note). [317:31] Change "numeric sequence structure or character sequence structure" to "structure of a numeric sequence type or character sequence type". Now on to the real pdt edits. Section 4 [41:24-25] Delete the J3 note and insert "If a derived type has a component that is a pointer to a (possibly different) derived type, the appearance of a type parameter of the parent type in an expressions for a kind type parameter values of the component implicitly declares it to be a kind type parameter of the parent type only if the type definition for the component precedes that of the parent type. Begin note This rule is to avoid indeterminacy caused by mutually recursive derived type definitions. For example TYPE type_1(a) INTEGER, KIND :: a !-- required because we don't yet know !-- whether type_2 has a kind type parameter. TYPE(type_2(a)), POINTER :: comp END TYPE TYPE type_2(b) !-- No explicit declaration of b needed here. TYPE(type_1(b)), POINTER :: comp END TYPE This is never at issue except with pointer components because a non-pointer component is never allowed to be of subsequently defined type. End note" [44:5+] Add new para "Type parameters are not components. They may be used in a (4.5.4) anywhere that the type name is accessible. They may be used in a for any accessible data object of the type. Section 5 [51:25] "" -> "" [53:37+] Add in shaded note "TYPE (matrix (kind=8, dim=1000)) :: mat" [52:48] "The" -> "A"; "of" -> "in" (There can be more than one). [52:48] " or" -> "," [52:48] "may" -> ", or a for a nonkind type parameter in a may" [56:2] "." -> " of the ." [75:2], [75:16], [78:16] "." -> " with the same type parameter values." Section 6 [84:7+] Insert new subsection "6.1.3 Type parameter inquiry A <> is used to inquire about a type parameter of a data object. It applies to both intrinsic and derived data types. R621.1 <> % Constraint: The shall be the name of a type parameter of the object designated by the . Begin note A has a syntax like that of a structure component reference, but it does not have the same semantics. It is not a variable and can never be assigned to. It may be used only as a primary in an expression. The intrinsic type parameters can also be inquired about by using the intrinsic functions KIND and LEN. End note Begin note The following are examples of type parameter inquiries: a%kind !-- A is real. Equivalent to KIND(A). s%len !-- S is character. Equivalent to LEN(S). b(10)%kind !-- Inquiry about an array component. p%dim !-- P is of the derived type general_point !-- defined in note 4.20. End note" Section 7 [96:6+] Add " <> " Exchange sections 7.1.6.1 and 7.1.6.2 (because we want to introduce the term specification inquiry and use it in both sections). [105:28-29] Move the sentence "A constant specification ..." to a new para at [103:41+]. [106:1-7] Replace these lines by "(7) A specification inquiry where each designator or function argument is" [106:21+] Insert new para "A specification inquiry is a reference to [copy the old 106:2-6 to here, renumbering as 1-5] , or (6) a type parameter inquiry (6.1.3). [103:21-27] Replace these lines by "(7) A specification inquiry where each designator or function argument is" [104:30-36] Replace these lines by "(7) A specification inquiry where each designator or function argument is" [105:8], [106:41] "reference to an inquiry function" -> "specification inquiry" (twice) [106:44] "inquiry function reference" -> "specification inquiry" [118:32], [118:39] "type" - > "type, have the same type parameter values, " [118:33], [118:40] "type" -> "type and type parameters" [119:8] "type as" -> "type and type parameters as" Section 9 [168:1] "type" -> "type and kind type parameters" [168:35] "type" -> "type and a particular set of kind type parameter values". [168:37] Delete "for a particular type". Its already implied, and it gets pretty wordy to add on the kind type param stuff. [170:2] [170:4] "type" -> "type and kind type parameters" Section 12 [221:35] "type" -> "type and kind type parameters" [222:16] "derived type" -> "derived type and set of kind type parameter values" [222:16-20] "procedure for that type" -> "corresponding procedure" 4 times. [225:42-226:3] "The kind ... argument." -> "The type parameter values of the actual argument shall agree with those of the dummy argument, except for the character length parameter of an actual argument of type default character associated with a dummy argument that is not assumed shape." Section 14 [305:10], [305:18], [305:22], [305:23] "kind type parameter" -> "kind type parameters" three times [305:27], [305:31] "a different kind type parameter" -> "different kind type parameters" two times [308:23] "Components" -> "Components and type parameters" [308:28+] Add new para "A type parameter name has the same scope as the type of which it is a parameter. Outside the type definition, it may appear only as a keyword in a for the type or as the of a . If the type is accessible in another scoping unit by use association or host association, the type parameter name is accessible for use in s in that scoping unit. A is accessible anywhere that the data object being inquired about is accessible. [310:35+] Add item and renumber "(3) A in a ;" [314:5] "or" -> "parameterized derived type, or" [314:6] ";" -> "and each set of type parameter values;" [314:7] Delete "of intrinsic type or sequence derived type" and interchange items (6) and (7) Note: The only thing relevant to this item is that we have a non-pointer array. This list is not the place to define what variables can be in a storage association context; that is done separately. For example, we don't say non-dummy here. The words deleted above just left me wondering how the other cases were covered until it was explained to me that the other cases can't come up. This seems like an unnecessary distraction. [314:10] "sequence type" -> "a sequence type with no type parameters"