J3/03-227r1 Date: 18-Aug-2003 To: J3 From: Toon Moene Subject: Partial response to 03-201/N1524. -------- Xrefs: 03-227/N1571 is the WG5 response to part of 03-201/N1524. Page and line references are to 03-007. ===================================================================== Part I (reply to comments in 03-201/N1524 on 03-173) [271:7-9] currently states : "If a dummy argument is allocatable or a pointer, the associated actual argument shall be polymorphic if and only if the dummy argument is polymorphic, and the declared type of the actual argument shall be the same as the declared type of the dummy argument." The original 03-173 responded to a Japanese comment that this restriction was surprising. However, an allocatable or pointer polymorphic argument may have its type defined by an allocate statement or by pointer assignment [76:11-12]. If that type is defined in either the caller or callee, the corresponding argument in the other program unit must have a compatible type. This is not generally possible unless both the actual and dummy arguments are polymorphic. A Note was suggested to clarify this section. Edit: [271:9+] Add Note 12.21+ "An allocatable or pointer polymorphic argument may have its type defined by an allocate statement or by pointer assignment. If that type is defined in either the caller or callee, the corresponding argument in the other program unit must have a compatible type. This is not generally possible unless both the actual and dummy arguments are polymorphic." ================================================================= Part II (reply to comments in 03-201/N1524 on 03-180) The first sentence of 12.4.3, [278:10-11], which discusses subroutine invocation, mentions "finalization", but the sentence in [278:13-14], which discusses subroutine completion, does not. Finalization is sufficiently different from the other mechanisms listed in [278:13-14] that it should not be included in that list. The structure of the list in [278:14] makes the meaning unclear, and the use of articles in the list is inconsistent. Clarifying edits are supplied. Edits: [278:13] Insert "the" before "execution". [278:14] Insert "the execution of the" before "defined". ===================================================================== Part III (reply to comments in 03-201/N1524 on 03-183) The sentence structure in [371:6-9] in 03-007 is ambiguous and the use of the term "operators for" is confusing. Edits are supplied to fix this. The final part of the sentence, "or valid and within range (if another type)" refers to operands or arguments that are not floating point. The current structure could be read to allow the IEEE result to be a non-floating point. An edit rearranges the sentence to avoid this misinterpretation. Edits: [371:1] Replace "operators" by "operations" [371:6-7] Replace "operators for" by "operations of" [371:8-9] Replace by "whenever the operands or arguments are normalized (if floating point) or are valid and within range (if another type), and the IEEE result is normalized." ======================================================================= Part IV (reply to comments in 03-201/N1524 on 03-186) The current text in section 2.4.6 [18:22-31] does not discuss the pointer association status of undefined. This is parallel to section 2.4.3.1.1 which does not discuss undefined variables. It is sufficient to leave the discussion of undefined status to section 16.4.2.1.3, so no edits are proposed for section 2.4.6. The sections 4.5.3.1 and 4.5.3.2 are short, but this does not seem to be a problem. However, three of the Notes in these sections begin with effective restatements of the normative text just above. This is unnecessary. The notes are just examples and the text should read that way. Edits are supplied to fix the Notes. Edits: [50:15+2] Replace first line of Note 4.29 by "An example of a derived type with an array component is:" [50:15+20] Replace first line of Note 4.30 by "An example of a derived type with an allocatable component is:" [51:3+2] Replace first line of Note 4.32 with "An example of a derived type with a pointer component is:" ======================================================================= Part V (reply to comments in 03-201/N1524 on 03-188r1) Section 12.4.5 contains 3 references to "binding with that name in the ... type". Papers 03-101 and 03-188r1 propose to change "in" to "declared in or inherited into". The syntax for procedure declaration is different from that for , so a better wording is "specified in or inherited into". One, could, alternatively say that "in" implies the inherited parts, and that text is OK as is. Edits to make the change are supplied. Edits: [280:33] Replace "in" by "specified in or inherited into". [280:36] Before "in" insert "specified". [281:4] Replace "in" by "specified in or inherited into". ========================================================================= Part VI (reply to Miscellany at the end of 03-201/N1524) Two lines [220:27,29] extend over into the margin by two characters. Paper 03-212, in the section referring to N1543 (which is 03-205), recommends that one layer of section headings in 13.8.2.x.x be removed. This will reduce the length of lines [220:27,29] by 2 characters each and solve the problem. No additional edits are required. ====================================================================