J3/98-168 Date: 11 Jun 1998 To: J3 From: Richard Maine Subject: Edits incorporated in 98-007R2 This paper describes the changes in J3/98-007R2 relative to the previous f2k draft, J3/98-007R1. All page/line references are to J3/98-007R1 unless otherwise noted. I have flagged several items as needing further attention in my opinion. For convenience in future citation, I have numbered these. They are all flagged with ***ACTION ITEM xx. In all of these cases I have also put a J3 note into the document as a reminder. Ths change bars in 98-007r2 are relative to 98-007r1 misc edits 4.5 [38:11] typo "my" -> "by" 4.5.1.3 section header typo "cpmponents" -> "components" 4.5.5 [47:33] "the " -> "each " 4.5.5 [47:41] typo "iitialitation" -> "initialization". 12.3.2.2 [222:41] add xref to 5.1.2.10 after "external attribute". 15.9.17 typo "to" -> "is" Changed all 3 occurances of the term "legal" in the document. 1.6.3 [5:32] Just delete the word. 15.9.5, note 15.5 "legally" -> "validly" C.6.4 [371:32] "illegal" -> "invalid" *****ACTION FLAG 1 My attention being drawn to the 6th para C.6.4, I see that the whole paragraph is completely wrong anyway - or anyway, it directly contradicts what we said in the normative part of the standard. The edits for named scratch files evidently missed this section. I'll leave the fixup to those concerned with named scratch files. Added a J3 note. ****END ACTION FLAG paper 98-145r2, inheritance, with the following changes [39:13+] Add an "A" to avoid starting sentence with an bnf term. [46:36+] "attributes" -> "attribute". In the definition of "extension type", deleted ", its parent type," both in the glossary and in the new section 4.5.3. (And then added "type" after "its parent" in the following phrase). Since we just finished saying that either a base type or an extended type is an extension type of itself, it is redundant to say both that a type is an extension type of its parent and also of all types for which its parent is an extension. So I deleted the redundant phrase to simplify the wording (and to avoid the questions from those assuming that the phrase wouldn't be there if it was redundant). Moved the note about the possibility of base types having no components and extended types possibly adding no components down to right after the para that first mentions components of extensible types. It seems a little out of place right after the definition of base/extended/parent type where we haven't yet even mentioned components. Don't generally begin notes with "Note:". The ending points of some of the notes weren't explicitly marked, but I think ther were all fairly obvious anyway. Added "in the derived type definition of the extended type" after "additional components may be declared" just to make it a bit more explicit. I assume that the xref in the new 4.5.3 to "existing section 4.5.4" should really have been to existing section 4.5.5 (which is the new section 4.5.6) on "Construction of derived type values". This is probably an unfixed reference to a previous version with different section numbers. In the definition of the component order, changed "components of the extended type" to "components declared in the derived type definition of the extended type". The inherited components are also components of the extended type (as we just finished saying), and we don't mean to include those here. Deleted a comma. ***ACTION FLAG The words in the extensible type section say that every extended type has an additional component name that is the same name and has the same type as its parent type. How about its "grandparent" etc.? If we have an object obj of type x extended from y, which was extended from type z, can we say obj%z or do we have to write that as obj%y%z? Note that cannot automatically deduce that this name is inherited because it is components that are inherited and we explicitly say that this extra name is not a component. I assume that we want to be able to use the simple form, but this is a technical rather than an editorial question. So I've just added a J3 note. While on the subject, a matter that is more editorial. I'm slightly bothered by refering to something as a component name when it is not the name of a component. I think we should use a different terminology here. Perhaps that it is a subobject name or something of the sort. Added that thought to the J3 note also. ***END ACTION FLAG It was not clear to me whether the paragraph about the accessibility of the subobject with the parent type name was intended to be a note or not. The para began with "note:", so at first I made it a note. But I couldn't find any normative text to support it, so I made it normative and removed the "Note:" prefix. Changed ",even if the components of the parent type are not accessible" to "; this is independent of the accessibility of the components of the parent type". I found the original wording confusing in telling only half of the story. The point, I presume, is complete independence. If the new components are public, then so is the subobject, even if the components of the subobject are private. But likewise, if the new components are private, then so is the subobject, even if the components of the subobject are public. ***ACTION FLAG Couldn't we make the restriction about component names not conflicting with parent component or type names a constraint? (After fixup to include grandparent type names if we decide to do that). I added a J3 note. ***END ACTION FLAG "same name as the parent type name" -> "same name as the parent type". I don't think a name has a name. Changed "list form" to "flattened form" (expanded form would be another possibility if people dislike "flattened"). I don't think that "list form" is a good contrast with "nested form". Lists are involved in both forms. Indeed, what we are describing is the syntax of a . Hmm, while on the subject, I changed it more specifically to say that a of a for an extended type may use either of these forms (original words omitted " of a"). ***ACTION FLAG The description of the nested form of the structure constructor refers to the "component" that has the same name as the parent type. This contradicts the definition of that name, which says that it is not a component. And this just reinforces my concern about how confusing it is to have a "component name" that is not the name of a component. Perhaps we mean subobject name here? Added a J3 note. ***END ACTION FLAG In note 4.4.4a, change "(see note 4.5.3a)" to "using types defined in note 4.5.3a". Use "=" instead of "==" in the first comment in note 4.4.4a. "must be" -> "need to be" twice in note 4.4.4a. [51:25+] Added "The" to avoid starting sentence with bnf. [52:1+] "The CLASS" -> "A CLASS" (just like for TYPE in the preceding subsection). I assume that the para "Note: Only components of the declared type of a polymorphic object may be referenced by component selection (6.1.2)" is intended to be a shaded note. It does appear that 6.1.2 has a normative edit to support this note. Changed "referenced" to "designated" in that note. It applies even when the designation is not a "reference". I assume that the para beginning "Note:" at [91:8+] is intended to be a shaded note because it does appear to be deducable from normative text (namely the statement that the dynamic type of a disassociated pointer is its declared type). [118:32-33], [118:39] Small word changes to merge overlapping edits from papers 98-145r2 and 98-153. Eliminated a few unneeded "the"s before bnf terms in section 7.5.2. Also, changed a redundant phrase to "it" in a place where the antecedant was clear and unambiguous. [122:14-15] Simplified "the rank and corresponding kind type parameters" to "those". The only possible difference I can see here is the omission of the word "corresponding", but we don't use that word in numerous other comparable contexts. If we needed it, we have lots of places that need fixing (I don't think we do). ***ACTION FLAG I don't think that the constraint on kind type parameters for pointer assignment (7.5.3) is compile-time checkable in polymorphic cases. The constraint probably needs to be split into those things checkable at compile time (as a constraint) and those things checkable only at run time (as a restriction). Also, I'm surprised that there are no compile-time constraints at all on type when target is polymorphic. We don't even demand compile-time checking that the target and pointer have the same base type. Added a J3 note. As a general problem in several places I'm concerned about the integration of pdts with inheritance. Looks to me like we didn't catch nearly all of the areas. I think that to integrate them properly, we are going to have to talk about "type and type parameters" together, rather than writing one set of requirements about types and then a separate set of requirements about the type parameters. It has been suggested elsewhere that we come up with terms to describe "type and type parameters" or "type and kind type parameters". It might simplify wording some of these things. Perhaps we might just suitably modify the definitions of declared type and dynamic type. We may need to modify them a little anyway. I don't think we ever quite explicitly said that the declared type of a non-polymorphic object type means (though its fairly obvious). ***END ACTION FLAG [226:10] I added this sentence at [226:20] instead of [226:10]. I suspect this as being a typo, as [226:10] is in the middle of an apparently unrelated paragraph. [227:24+] I deleted the "Note:". Put this as normative text rather than as a note because I can't find any other normative text that says this. Deleted "The result is of type" from the result characteristics of both function descriptions. The other functions in c13 use the short form when it completely describes the result characteristics (with 2 exceptions which I just fixed). The complete sentence form is used only when multiple sentences are needed to describe the result characteristics. Delete "actual" from the glossary definition of "dynamic type". We already say "during execution". I don't think "actual" adds anything (since we haven't defined the term "actual type") and it invites confusion with actual arguments. The proposed glossary entry for "inherit" doesn't define the term inherit. It just makes a statement without bothering to say how the term "inherit" relates to it. I reworded it majorly. In the glossary entry for polymorphic, change "Denotes the ability" to "Able" to be in the right form for a definition of an adjective. Throughout the new glossary entries, italicized lots of stuff per the style used in the glossary. (A style that I'm not sure I like - italicizing half the words in the section seems to make it a bit pointless, but I'm not prepared to unilaterally change that now). [361:43+] Deleted commas around "as a whole". [386:23+] I don't understand what the "Given" is supposed to be about; deleted it. And the example could use at least a brief introduction. I wrote a one-sentence one: "The following example illustrates polymorphic argument association rules using the derived types defined in Note 4.39" Yes, I know the section title implies this, but I was always taught that titles are not considered as part of the text of a document. Also, this provided me an excuse for removing the xref from the actual code sample. paper 98-153, more pdt edits, with the following changes The edit labelled as [55:10-12] is really [56:10-12]. The edits only half-singularized [75:14]. Finished doing so. In the first sentence added at [41:24-25] "expressions" -> "expression" and "values" -> "value". In the last sentence added at [41:24-25] Add "a" before "subsequently". [225:42-226:3] "except for" -> "except for the case of". [52:48] Added "in" twice to avoid ambiguity. Added a "thus" in the first note in the new 6.1.3. [226:3-4] Move the sentence on these 2 lines down to a separate para at [226:12+] so that the stuff about arrays is together and particularly so that this unrelated sentence doesn't come between the statement about character len parameters being an exception and the following paragraph, which elaborates the rules for the character len parameter. [308:25] before "." insert "or as a keyword in a structure constructor of the type". [308:28+] Change "the same scope as the type of which it is a parameter" to "the scope of a derived type definition". ***ACTION FLAG In paper 98-153, I had made the description of the scoping of type parameters almost identical to that of components. But I see that this doesn't quite hold together consistently. On studying 14.0, 14.1.2, 14.1.2.5, and 14.1.3, it seems to me that components and type parameters are better described as having a scope of the derived type definition instead of saying that they have "the same scope as the derived type". I'd then interpret parts of section 14.1.2.5 as describing (quite adequately, I think) the limited contexts in which these names can be used outside of the derived type definition (that is, outside of their scope). In fact, I think we are forced to do type parameters this way because we need to have them included in the list (14.6.1.3) of things that block host association of host entities of the same name. The edits of paper 98-153 added type parameters to that list, but that only makes sense if type parameters have a scope of the derived type definition. So I've redescribed the scope of type parameters in that manner. If I've messed this up, let me know. I have not changed anything about the way the scoping of components is described. My inclination is that they should indeed be described much like I now have type parameters - as having a scope of the derived type definition, with limited contexts where they can be used outside of this scope. But simple though this change seems in some ways, I'm concerned that there might be subtleties that I'm missing, so I'm not going to try to do it without J3 guidance. My proposal is just to change "the same scope as the type of which it is a parameter" to "the scope of a derived type definition" in the first para of 14.1.2.5. Added a J3 note. ***END ACTION FLAG paper 98-154, command-line argument fixes. Entered as is. Also deleted the J3 note from 11.1.1. These edits answer it. paper 98-156, recursive internal i/o. Entered as is (for now). ****ACTION FLAG 2 I think that the 3rd para of 9.9 needs to specify that there is an exception for derived type i/o. Ref 9.4.4.4.3. We specifically do allow some forms of recursive i/o to an external unit. I don't see anything in 9.9 that keeps its prohibition from applying to the derived type i/o case. I haven't done anything about this yet. I might fix it up later. Someone needs to anyway. Added a J3 note. ****END ACTION FLAG paper 98-159r1, async and host association, with the following changes Delete the "Note:" at the beginning of the note. "When" -> "If". (Avoid "when" unless time is involved.) Also deleted the J3 note in 5.3.10 because these edits address it.