J3/98-122r1 Date: 19 Feb 1998 To: J3 From: R. Maine Subject: Partial edits for R.5, PDTs Syntax for PDTs was approved as 97-104r2. The following is proposed as partial edits. These edits are all relative to 98-007. This paper is a revised version of 97-264. The revisions are as follows 1. Make the page:line refs relative to 98-007 2. Fix the bnf edits to 4.4.1 to reflect the requirement that "Any explicit declarations of type parameters shall precede any component declarations for the derived type." as passed in 97-104r2. 3. Added some of the material not yet done in 97-264, specifically the edits to define (the new 4.4.4 section) and the edits to constructors. This should complete the edits required up through section 4. I would like to pass these edits now instead of waiting for the complete set. Otherwise, I'd have to write (and you'd feel obligated to read) a new version of this paper for the next meeting, changed to be relative to the presumed 98-007r1. Intro [xv:14] "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 one or more 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 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 introduced 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 derived by composition of other types." [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 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. Some 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 to include two specific procedures that have interfaces distinguished only by the value of a kind type parameter of a dummy argument. Generics 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 nonkind 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:27] "is" -> "uses" And move this para to precede the para inserted at [37:39] by the edit above. [38:35] after "" add " [()] [38:31+] Insert after the private-sequence-stmt line "[ ] ..." [38:45+] Insert new bnf rules R424.2 <> INTEGER [ ] [[, ] :: ] R424.3 <> KIND <> NONKIND Constraint: A in a in a shall be one of the s in the of that . (The previous version of this paper included two other constraints; those constraints were aimed at precluding multiple uses of a single name. A comment noted that these constraints were incomplete. On restudy, and in particular on comparison with how the same question is handled for dummy arguments, it appears that the constraints are not needed here at all; in fact, putting them here would be inconsistent in style. The constraints are already implied by the general prohibition of multiple entities with the same name in the same scope.) [39:42+] Add section 4.4.1.1 Derived type parameters The derived type is parameterized if the has any s. Each type parameter is itself of type 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 or 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 4.new1 In most cases, it is not necessary to explicitly declare anything about a type parameter; it is implicitly of type 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 in 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:40-40:15] Move paragraph and note to [40:50+] and add heading "4.4.1.5 Sequence type" [39:46] before "all" add "there are no type parameters and " [40:1] before "all" add "there are no type parameters and " [40:16-] Add heading "4.4.1.2 Component initialization" [40:26-] Add heading "4.4.1.3 Array components" [40:35-] Add heading "4.4.1.4 Pointer components" [40:41-] Add heading "4.4.1.5 Accessibility" [41:1-43:31] Move note 4.20 to [39:39+] (before the new section 4.1.1.1). Move note 4.21,4.26 to [40:30+] (in array component section) Move notes 4.22,4.23 to [40:50+] (end of accessibility section) Move note 4.24 to end of sequence section Move notes 4.25,4.27 to [40:40+] (end of pointer section) Move notes 4.28,4.29,4.30 to [40:25+] (end of init section) [43:40] before "components" add "type parameters and" [45:3] after "type" add "and the type parameters" [45:3+] Add new section as follows " 4.4.4 Derived-type specifier A derived-type specifier is used in several contexts to specify a particular derived type and type parameters. R430.1 <> [ ( ) ] R430.2 <> [ = ] R430.3 <> <> * Constraint: shall be the name of an accessible derived type. Constraint: shall appear if and only if the type is parameterized. Constraint: There shall be exactly one corresponding to each parameter of the type. Constraint: the = may be omitted from a only if the = has been omitted from each preceding in the . Constraint: Each shall be the name of a parameter of the type. Constraint: The for a kind type parameter shall be an initialization expression. Constraint: The for a nonkind type parameter shall be a specification expression or an asterisk. Constraint: An asterisk may be used as a only in the declaration of a dummy argument. In the absence of a type parameter keyword, a type parameter value is assigned to the type parameter occupying the corresponding position in the type parameter list of the derived type definition; that is the first type parameter value is assigned to the first type parameter, the second type parameter value is assigned to the second type parameter, etc. If a type parameter keyword is present, the value is assigned to the type parameter named by the keyword. A type parameter value is not required to be of the same integer kind as the corresponding type parameter. If an asterisk is specified for a of a nonkind type parameter of a dummy argument, the value of the type parameter is assumed from the corresponding actual argument." [45:8] Replace R431 with "R431 <> ( ) R431.1 <> [ = ] Constraint: There shall be at most one corresponding to each component of the type. Constraint: There shall be exactly one corresponding to each component that does not have a default initialization. Constraint: the = may be omitted from a only if the = has been omitted from each preceding in the constructor. Constraint: Each shall be the name of a component of the type." [45:9-10] Replace the sentence spanning these lines with the following. "In the absence of a component name keyword, the is assigned to the sequentially corresponding component of the derived type definition; that is the first is assigned to the first component, the second is assigned to the second component, etc. If a component name keyword is present, the is assigned to the component named by the keyword." [45:13] Break the paragraph before the "A" and add the following new paragraph between. "If a component with default initialization has no corresponding , then the default iitialization is applied to that component." *******STRAW VOTE**** Allow this? If not, then "at most one" becomes "exactly one" in the first constraint after R431.1, and the second constraint goes away. [45:19+] Add as part of the note "This could also be written as PERSON (NAME = 'JOHN SMITH', AGE = 21)" [45:21+] Add new note "BEGIN NOTE An example constructor using the derived type POINT defined in note 4.new1 is point(dim=3) ( (/ 1., 2., 3. /) ) END NOTE" Section 14 [287:38] Before "components" add "parameters and " --lots more needed starting at section 5.