J3/97-264 Date: 10 Nov 1997 To: J3 From: R. Maine Subject: Partial edits for R.5, PDTs This paper is not particularly close to complete. Nor has it been reviewed by subgroup. It is being put out just to save the progress to date. Syntax for PDTs was approved as 97-104r2. The following is proposed as edits. These edits are all relative to 97-007R1. Intro [xv:13] "predefined" -> "defined by the language" The term "predefined" is used only in 4 sentences in section 4.0 and in this 1 sentence describing section 4. One of the uses in section 4.0 is in a sentence that just explains that different terminology will be used in the rest of the section. That leaves three real uses, all of which are on the same page say almost the same thing. One of these isn't phrased quite like the other two and seems a bit out of place anyway. I propose expurgating the term completely instead of introducing it for just long enough to say that we aren't going to use it. Section 2 [15:9] "way to denote" -> "syntax for denoting" [15:9] "collection" -> "set" For consistency of terminology here and in section 4. [15:10+] Add new para A type may be parameterized, in which case the set of data values, the syntax for denoting them, and the set of operations depend on the values of the parameters. Such a parameter is called a <> (4.3). [15:13] and [15:23] "implicitly" -> "by the language" These 2 sentences are the only places in the document where the term "implicitly" was used in this sense. The simillar statements in section 4 use the "by the language" terminology, (with some inconsistent variations that I fixed) which seems much better (and avoids the confusing possibility of talking about names that implicitly have types that are not implicitly defined). [15:15-17] Delete "An intrinsic...<> (4.3)." [15:17] Add " intrinsic" after "The". [15:25] After "(5.1.1.7). " add "Derived types may be parameterized. " [15:25-26] "type agreement" -> "agreement of type and type parameters." [15:32] After "take" add ", depending on the values of the values of the type parameters" [15:35] After "definition" add ", type parameter values, " [15:38-39] "(either...may have," -> "and type parameters; it may have" [16:3] "type" -> "type and type parameters" [16:38] After "type" add ", type parameters" [17:3] After "type" add ", type parameters," Section 4 Much of the material in section 4.0 seems to be said in three places: First in section 2.4, again in 4.0, and a third time in section 4.1. At first, I found myself making similar edits in all three sections. I decided to cut this to two by merging most of the material from 4.0 into 4.1, making section 4.0 shorter. [29:3-7] Delete "Each..interpret the values." [29:8-14] Move note 4.1 to [29:38+] [29:15-16] "The means...that type." -> "The syntax for denoting a value indicates both the type and the particular value." and move this sentence to a separate paragraph at [30:7+]. The above change isn't directly related to pdts, but there were other pdt edits in this same area, and I noticed this one sentence, the original of which threatened my sanity. [29:16-19] Delete "Intrinsic...of the parameter." [29:20] "predefined" -> "defined" [29:21-22] Delete "The phrase...this sense." We now avoid introducing the term "predefined" in the first place, so we don't need this sentence to explain that, having itroduced it, we aren't going to use it. Section 2.5.7 does a better job of defining the term "intrinsic" anyway. [29:23] "In addition...be derived." -> "A derived type is one that is defined by the program." [29:31-33] Delete "Means are...predefined." [30:2-3] Delete "For parameterized...of the parameters." [30:17] after "assignment" add "with agreement of type and type parameters" [30:18+] Add new section as follows: "4.2 Type parameters A data type may be parameterized. In this case, the set of values, the syntax for denoting the values, and the set of operations on the values of the type depend on the values of the parameters. The intrinsic data types are all parameterized. Derived types may be defined to be parameterized. A type parameter is either a kind type parameter or a nonkind type parameter. The value of a kind type parameter shall be specified by an initialization expression (7.1.6.1). A kind type parameter may in turn be be used in initialization expressions and specification expressions; it participates in generic overload resolution (14.1.2.3). Each of the intrinsic types has a kind type parameter named kind, which is used to distinguish multiple representations of the intrinsic type. BEGIN NOTE By design, the value of a kind type parameter is known at compile time. Parameterizations that involve multiple representation forms need to be distingushed 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 user may also specify a type parameter to be a kind type parameter in order to allow generic overload resolution based on the parameter; that is, to allow a single generic overload to include two specific procedures that have interfaces distinguished only by the value of a kind type parameter of a dummy argument. Generic overloads are designed to be resolvable at compile time. END NOTE The value of a nonkind type parameter shall either be specified by a specification expression (7.1.6.2) or assumed. A nonkind type parameter may in turn be used in specification expressions, but not in initialization expressions. The intrinsic character type has a nonkind type parameter, which is the length of the string. BEGIN NOTE A typical use of a nonkind type parameter is to specify a size. An example is the length of an entity of intrinsic character type. END NOTE ..." [30:28-29] Delete "The components...subobjects." This isn't necessary to say here. And its done much better (and correctly) in section 6. This is really an addition to my subobject cleanup paper, but maybe if I bury it here, nobody will notice. I was reviewing this area for pdt stuff anyway. [30:30] "type" -> "type and type parameters" and "determines" -> "determine" [30:40] "type" -> "type and type parameters" and "determines" -> "determine" [31:5-7] Delete note 4.4. This note seems singularly useless. It just repeats in a note something discussed quite a bit in the normative text of the preceding few pages. [31:22] "is" -> "uses" The type specifier also includes the optional kind-spec. [33:25-26] "is" -> "uses" (twice) [34:27] "is the keyword" -> "uses the keyword" [35:22] "is" -> "uses" and move this para to [35:19+] [37:36] "is" -> "uses" and move this para to [37:22+] [37:39] Add a paragraph break after "its components." Add the following new paragraph between the two. "A derived type may be parameterized by multiple type parameters, each of which is defined to be either a kind or nokind type parameter. There is no concept of a default value for a type parameter of a derived type; it is required to explicitly specify the values of all type parameters of a derived type entity. [38:21] "is" -> "uses" And move this para to precede the para inserted at [37:39] by the edit above. [38:29] after "" add " [()] [38:26-27] "" -> "" twice. [38:39+] Insert new bnf rules R424.1 <> <> R424.2 <> INTEGER [ ] [[, ] :: ] R424.3 <> KIND <> NONKIND Constraint: A in a in a shall be one of the s in the of that . Constraint: The same shall not appear more than once in all of the s of a . [39:22+] Insert new constraint (part of this is an omission from f95) Constraint: A shall not be the same as another or in the same . [39:37+] Add section 4.1.1.1 Derived type parameters The derived type is parameterized if the has any s. Each type parameter is itself integer. This may be confirmed by a . A type parameter is default integer unless its kind is explicitly specified in a . A type parameter is either a kind type parameter or a nonkind type parameter (4.2). If it is a kind parameter it is said to have the KIND attribute. A explicitly specifies whether a type parameter is kind nonkind. The KIND attribute may also be implicitly conferred as described below. If a type parameter is not given the KIND attribute, either explicitly or implicitly, it is a nonkind type parameter. It is never required to explicitly specify a type parameter to be a nonkind parameter, but such specification is allowed. A type parameter may be used as a primary in a specification expression (7.1.6.2) in the . A kind type parameter may also be used as a primary in an initialization expression (7.1.6.1) in the . With the exception stated below, a type parameter is implicitly given the KIND attribute if it appears in the as a primary in an expression that is required to be an initialization expression. BEGIN NOTE In most cases, it is not necessary to explicitly declare anything about a type parameter; it is implicitly default integer and will implicitly get the KIND attribute if needed. For example, consider TYPE matrix(k, d) REAL(k) :: element(d,d) END TYPE Both k and d are default integer. The parameter k implicitly has the KIND attribute because it is used as a context that requires it to. The following example uses explicit type parameter declarations. TYPE humongous_matrix(k, d) INTEGER, KIND :: k INTEGER(selected_int_kind(12)), NONKIND :: d !-- Specify a non-default kind for d. REAL(k) :: element(d,d) END TYPE In the following example, dim is explicitly declared to be a kind parameter, even though it is not required by anything shown here. This would allow generic overloading of procedures distinguished only by dim. TYPE point(dim) INTEGER, KIND :: dim REAL :: coordinates(dim) END TYPE END NOTE -----the exception for the recursive case still needs to be added here. [39:38-40:13] Move paragraph and note to [40:48+] and add heading "4.4.1.5 Sequence type" [39:38] before "all" add "there are no type parameters and " [39:40] before "all" add "there are no type parameters and " [40:14-23] Add heading "4.4.1.2 Component initialization" [40:24-] Add heading "4.4.1.3 Array components" [40:33-] Add heading "4.4.1.4 Pointer components" [40:44-] Add heading "4.4.1.5 Accessibility" [41:1-43:20] Move note 4.20 to [39:37+] (before the new section 4.1.1.1). Move note 4.21 to [40:28+] (in array component section) Move notes 4.22,4.23 to [40:48+] (end of accessibility section) Move note 4.24 to end of sequence section Move notes 4.25,4.26 to [40:38+] (end of pointer section) Move notes 4.27,4.28,4.29 to [40:23+] (end of init section) Section 14 [281:38] Before "components" add "parameters and " --lots more needed starting at 4.4.2.