J3/00-151r1 JOR Responses to Proposed Edits in 00-103r1 Chapters 7, 8, 9 To: J3 From: Craig Dedo Subject: JOR Responses to Proposed Edits in 00-103r1 - Chapters 7, 8, 9 Date: March 2, 2000 JOR has considered the editorial changes proposed in paper 00-103r1. Following are the responses that JOR is recommending that J3 adopt. These responses are limited to the editorial changes proposed for Chapters 7, 8, and 9. Due to time constraints, JOR is only answering Chapter 9 issues up through page 190. There are 4 categories of action: Deferred JOR decided to defer any recommendation until a future meeting. Yes JOR decided to accept the proposed change and recommends that J3 accept it. No JOR decided to decline the proposed change and recommends that J3 decline it. Not JOR JOR decided that this proposed change does not belong in the jurisdiction of JOR. Chapter 7 JOR is referring all of the recommendations for Chapter 7 to the Data Subgroup except for the following items. [116:18]Add "intrinsic" before "operation" because the section doesn't address defined operations. JOR Response: No. [116:23]Would be clearer as "The result of an intrinsic operation has a kind type parameter. The result of an intrinsic character operation also...". JOR Response: No. [120:17]I'm curious why "properties" instead of the more precise "type parameters and bounds" is used here. JOR Response: No. [121:19]After "defined" add a new sentence "If the operand is allocatable it shall be allocated and defined." JOR Response: Yes. [134:29-35]Are the normative text and note inconsistent, or does the note imply construction of a temp? JOR Response: No. [135:43+]I wrote a note to myself "It should be explicitly spelled out what happens if variable and expr overlap." I think this was intended to apply to assignment in general, not just to defined assignment. JOR Response: No. Any assignment is processed as if the expression is fully evaluated before its value is assigned to the variable. [136:45](1) I didn't know that expressions "delivered" anything. Replace by "The result of expr shall have the POINTER attribute." (2) After the pointer assignment takes place, does the pointer result of the target get deallocated? Pointer results of functions can get deallocated "after use" (but note 12.36 appears to be the only place to say so). Should there be an exception for the case when a function with a pointer result is used as the target in a pointer assignment, or if it's an actual argument associated with a dummy argument that has the POINTER or TARGET attribute? JOR Response: Item (1) is Yes. Item (2) is referred to the Data Subgroup. [140:43]Should be a constraint. JOR Response: Yes. Move the first sentence to [139:20+] and make it into a constraint. [141:2 ]Add "other than restoring the control mask and pending control mask of an enclosing WHERE construct." JOR Response: Yes. But, instead, delete the sentence in [141:1-2]. "Execution of an END WHERE has no effect." Chapter 8 [148:9]Replace "usually" by "may be". Asserting "usually" implies some foreknowledge of the program. (At least the "usually" shouldn't be normative.) JOR Response: Yes. Instead, move the last two sentences [148:8-10] into a note. [149:27-28]This constraint could be done with syntax rules. JOR Response: No. [149:31 ]The phrase "and execution continues as though a CONTINUE statement (8.3) were executed" contributes nothing, since a CONTINUE statement does nothing. JOR Response: No. This text has been in the standard for a very long time and explains exactly what is going on. [152:29-30](This is the same area at which 00-105 proposes changes. This should maybe be in 00-105.) Add "or is a variable that has a vector subscript" after variable. Add "within the SELECT TYPE construct" at the end of the constraint. Add another constraint: Constraint: If the selector is a variable that is a dummy argument with the INTENT(IN) attribute, associate-name shall not appear in a variable definition context (14.7.7) within the SELECT TYPE construct. JOR Response: Referred to Data Subgroup. [154:36]Add "within the ASSOCIATE construct" at the end of the constraint. Add another constraint: Constraint: If the selector is a variable that is a dummy argument with the INTENT(IN) attribute, associate-name shall not appear in a variable definition context (14.7.7) within the ASSOCIATE construct. (00-105 does this.) JOR Response: Referred to Data Subgroup. [155:2-8]The rules concerning attributes of the associate-name should be the same for SELECT TYPE and ASSOCIATE constructs. If the ASYNCHRONOUS, VOLATILE and INTENT attributes of the selector apply to the associate-name (at least when the selector is a variable), then the POINTER and ALLOCATABLE attributes, and pointer association or allocation status, should apply as well. Then, it wouldn't be necessary for the selector to be associated or allocated, and the two constraints above about INTENT(IN) wouldn't be needed. (00-105 does this.) JOR Response: Referred to Data Subgroup. [156:39]This constraint could be done with syntax rules. JOR Response: No. [156:39]Long ago, in a galaxy far, far away, the do-term-action-stmt couldn't be a logical IF statement if its consequent couldn't be a do-term-action-stmt on its own. Has this requirement intentionally vanished? JOR Response: No. This requirement was never there in the first place. The text of Fortran 95 is the same. [157:7]Same two remarks as for [156:39] above. JOR Response: No. [161:20 ]Given that we now have the concept of ERROR UNIT, it would be better to issue the warning on it than on the unit identified by *. Change "* in a WRITE statement" to "the named constant ERROR_UNIT from the ISO_FORTRAN_ENV intrinsic module (13.17.1.3)". JOR Response: Yes. Chapter 9 [163:12-15]Some discussion in section 9 refers to statements by their categories defined in this paragraph. In what category is the WAIT statement? JOR Response: No. The WAIT statement does not need a category. [164:31]Add "processor-dependent" before "restriction". JOR Response: No. This is not needed. [166:10]Add ", assuming a READ statement for this connection is allowed" (compare to [166:27-28]). JOR Response: Yes. But add ", and if a READ statement for this connection is allowed." at this position. At [166:27]. Change "assuming" to ", and if". [167:19, 25, 31]Does the "position just after the last record" mean that it's just after the last data record, or just after the endfile record? (See [164:17].) JOR Response: Deferred. This issues needs much more thought. [168:2]Does the "otherwise" refer to direct access, stream access, or output? JOR Response: No. "Other wise" refers to the when there is no current record. [168:8]Does the "otherwise" refer to direct access, stream access, or input? JOR Response: No. "Other wise" refers to the when there is no current record. [169:41-42]The phrase "that is not..." duplicates the constraint on R903, and as such is not needed. JOR Response: No. This is a desirable redundancy. [170:41-42]The syntax rules already say this. It's not necessary to say it with text. If it is necessary, at least add the WAIT statement here, and at [170:25]. JOR Response: Yes. Delete lines [170:41-42]. [172:7-8 ]"of default character type" is said thrice already, once in a constraint. Is it necessary to say it again? JOR Response: Yes. Strike the text, "of default character type" in the sentence. [172:31]Are the ERR= and IOSTAT= specifiers "in effect"? I am confused by this sentence because I think they're not. JOR Response: Yes. This was done in paper 00-137r2. [172:41-44]Belongs in 9.4.4.2. JOR Response: No. This text deals with re-open issues. [173:3-4]Belongs in 9.4.4.2. JOR Response: Deferred. [173:27-28]Add something to require that the branch target could be accessed by a GO TO statement from the point of the OPEN statement. JOR Response: No. The branch control restrictions are already well explained in sections 8.1.1.2 and 8.2. [173:29-31]Should perhaps be in 9.4.4.1. JOR Response: No. [173:43-46]The sentence "The file-name shall be a name that is allowed by the processor" is repeated at [200:18-19], but more precisely. Is it needed here, too? The sentence "If this specifier ... processor-dependent file" and the material at [173:29-31] should be together. JOR Response: No. [175:5-6]Would be clearer if "... the endfile record is the next record, if it has one" were "... the endfile record, if it has one, is the next record." (Upon first reading, I thought "one" referred to "the next record," not "the endfile record.") JOR Response: Deferred. [176:17-177:26]Belongs in 10.7.7. JOR Response: Yes. This was done in paper 00-109. [176:29-33]Rounding needs to be defined in terms of the external (decimal) representation. I don't think anything else can work. JOR Response: No. [177:29, 31]The external-file-unit isn't optional in the CLOSE statement. What does "that refers to a unit" mean? Remove it, and replace "that unit" at [177:31] by "the unit specified in the CLOSE statement." JOR Response: Yes. But, change "that refers to" to "for" after "Execution of a CLOSE statement" in [177:29]. [177:41-44]"with status ... DELETE" duplicates 9.4.5.1. Delete it, and "Note 9.20 The effect is" (making the rest of the note normative). JOR Response: No. [178:12]Add something to require that the branch target could be accessed by a GO TO statement from the point of the CLOSE statement. JOR Response: No. [179:17-18]The "exactly one" constraint is done di erently for data transfer statements, as compared to the OPEN statement (see [173:26]). The constraint at [179:26-27] implies at least one. Replace this constraint by Constraint: Each specifier shall not appear more than once in a given data transfer statement. JOR Response: Yes. Delete the constraints in [179:17-18, 26-27]. [179:17] Add these two constraints. "Constraint: An io-unit shall be specified; if the optional characters UNIT= are omitted from the unit specifier, the unit specifier shall be the first item in the io-control-spec-list. Constraint: Each specifier shall not appear more than once in a given io-control-spec-list. [179:20-22 ]Add something to require that the branch target could be accessed by a GO TO statement from the point of the data transfer statement. JOR Response: No. [185:29]What happens during namelist input? JOR Response: Yes. Add "or namelist-group-object-list items" before "becomes undefined" in the sentence. [186:27]Is it possible to define the variable specified in a SIZE= specifier if an error occurs? JOR Response: Yes. Fortran 90 already defines the SIZE= specifier in this case. [187:5]Is it possible to define the variable specified in a SIZE= specifier if an error occurs? JOR Response: Yes. Fortran 90 already defines the SIZE= specifier in this case. [187:32-33]This sentence seems to have little or no relation to establishing the direction of data transfer. It should be step (1.5) or (2.5) in 9.5.4.0. JOR Response: Yes. Move the sentence to [186:1+]. [188:5-6]Is it necessary to repeat "If the format..." here? It's already at [180:38-39] in the definition of the format specifier. JOR Response: Yes. Delete the sentence, "If the format is an array ...". [190:8-9]Appears to be inconsistent with the requirement for a REC= specifier in data transfer statements that refer to units connected for direct access. (See [166:3-4].) JOR Response: No. [End of J3 / 00-151]