J3/00-329 Date: 04-Dec-2000 To: J3 From: interp/Stan Whitlock Subj: Results of the F95 interp letter ballot #3 Here are the results of J3 letter ballot #3 on Fortran 95 interpretations that closed on 3-Nov-2000. If I have transcribed a vote or a comment incorrectly, please let me know. F90 F90 J3 rep 14 15 24 31 32 73 74 75 85 86 197 205 Rich Bleikamp Y Y N N Y Y Y Y Y Y Y Y Malcolm Cohen Y Y N C Y Y Y Y C Y Y Y Craig Dedo Y Y N N Y Y N Y Y Y Y Y Dick Hendrickson C C N Y Y C N Y Y Y Y C Kurt Hirchert Y Y N N Y C N Y N C Y Y Larry Meadows Y C C Y Y Y Y Y Y Y Y Y Dan Nagle Y Y Y Y Y Y Y Y Y Y Y Y Mallory North Y Y Y Y Y Y Y Y Y Y Y Y Mike Ross Y Y Y Y Y Y Y Y Y Y Y Y Jeanne Martin for B Smith Y Y Y Y Y Y Y Y Y Y Y Y Van Snyder Y Y C N Y Y N Y Y Y Y Y Jon Steidel C C N Y C C Y Y Y N Y Y Toon Moene for M van Waveren Y Y Y Y Y Y Y Y Y Y Y Y Tony Warnock Y Y Y Y Y Y Y Y Y Y Y Y Stan Whitlock Y Y Y Y Y Y Y Y Y Y Y Y Henry Zongaro Y Y N N Y Y N Y N N Y N F90 F90 F90 F90 JP JP JP JP JP JP JP J3 rep 206 207 208 210 04 05 08 12 16 17 31 Rich Bleikamp Y Y N N Y Y Y Y Y N Y Malcolm Cohen Y C Y Y Y Y Y Y Y Y Y Craig Dedo N Y N Y Y Y Y Y Y Y Y Dick Hendrickson N Y N Y Y Y Y Y Y Y Y Kurt Hirchert C N N C N Y Y Y C N C Larry Meadows Y Y Y Y Y Y Y Y Y Y Y Dan Nagle Y Y Y Y Y Y Y Y Y Y Y Mallory North Y Y Y Y Y Y Y Y Y Y Y Mike Ross Y N Y Y Y Y Y Y Y Y Y Jeanne Martin for BSmith Y Y Y Y Y Y Y Y Y Y Y Van Snyder Y Y Y Y Y Y Y Y Y Y C Jon Steidel Y N N N N N Y Y Y N N Toon Moene for Mvan Waveren Y Y Y Y Y Y Y Y Y Y Y Tony Warnock Y Y Y Y Y Y Y Y Y Y Y Stan Whitlock Y Y Y Y Y Y Y Y Y Y Y Henry Zongaro C N N N N N C Y Y N Y where Y means "yes" C "yes with comment" N "no with comment" The comments are attached below in the same order as the table above. The summary of DRAFT results is as follows: P = passed C = passed as amended F = further consideration F90 F90 F90 F90 F90 F90 14 15 24 31 32 73 74 75 85 86 197 205 206 207 208 210 C C F F C C F P F F P F F F F F JP JP JP JP JP JP JP 04 05 08 12 16 17 31 F F F P F F F The interps marked "P" can be considered by WG5 at John Reid's convenience. The interps marked "F" will be reconsidered at or before J3 meeting #155 by the /interp committee who will decide if the status becomes "withdraw for more work", "passed as amended", or "passed as printed". /Stan ********************************************************************** Status Number Title 000014 Format of complex numbers in list-directed and namelist output Dickh's YES comment on 000014 COMMENT: The interp refers to Fortran 90; not 95. Jon's YES comment on 000014 Nit: Fortran 90 in the question should be Fortran 95. 000015 Commas in list-directed output Dickh's YES comment on 000015 COMMENT: The interp refers to Fortran 90; not 95. Larry's YES comment on 000015 The discussion about item 000015 says it is not clear if the comma which is output is the optional separator or is the character constant from the list. In all cases, it is the character constant. The only implementation I know that ever writes the optional comma, does not in this case. [Bob Corbett] Jon's YES comment on 000015 Nit: Fortran 90 in the question should be Fortran 95. 000024 Termination of a partial record by a CLOSE, BACKSPACE, ENDFILE, or REWIND statement RichB's NO vote on 000024 I agree with Dick Hendrickson/Henry/... that the text of the standard should be altered to explicitly require the partial record to be considered to be a complete record. Malcolm's NO vote on 000024 I concur with the other comments that further specification would be helpful. Craig's NO vote on 000024 I generally agree with the comments of Van Snyder and Dick Hendrickson. I beleive that the proper solution is to add text saying what the processor is required to do if an I/O operation is terminated by something other than an I/O statement with ADVANCE="YES". We should ensure that the standard requires that anything written by a non-advancing WRITE statement ends up in the file REGARDLESS of what happens later. DickH's NO vote on 000024 The proposed answer says in part "However, a 'partial' record that has been written by a Fortran program ought to be readable by a Fortran ^^^^^ program." Nothing in the standard says this! It sounds like a darn good idea, but I don't see how we can deduce it from what is said in REWIND, etc. I think we need to add text something like "execution of this statement on a file which is in the midst of a nonadvancing I/O operation acts as if an advancing I/O operation with a null list was performed just prior to the execution of the statement" to CLOSE, REWIND, ENDFILE, and BACKSPACE. Alternatively we should add general text saying just what the processor is REQUIRED to do when a nonadvancing I/O is "terminated" by something other than an I/O with advance="YES". Things like divide by zero and allocation failure also "terminate" nonadvancing I/O. Ought a subsequent program be able to read those records? Kurt's NO vote on 000024 Minor nit: At a minimum, the "EDIT:" header should either be removed or filled in with "None." I believe I agree with the thrust of this interpretation, but I am unhappy with the justification given. I agree that the standard does not have the concept of 'terminating' a record. It seems to me that the nonadvancing WRITE has conceptually already created a record, but left the file positioned within that record, rather than after it, so additional data may be transferred into that record. The hole in the standard appears to be that it does not state what happens if you attempt to write an endfile record when the file is positioned within a record rather than between two records. I see three obvious possibilities: 1) The endfile record overwrites the current record. 2) The endfile record is written following the current record. 3) Such an attempt is invalid. I have been unable to identify text in the standard to support one of these options over the others. [As a matter of personal preference, I find 1) unacceptable, and I prefer 2) to 3).] If option 2) is chosen, I agree that, for example, a processor could either write NL to the file to maintain the discipline that text records are terminated by NL characters or not write NL and treat the record as being terminated by the end of file. In either case, what was written by that Fortran program would be readable by another Fortran program. [Last minute addition -- Larry Meadows' example illustrates the fact that the convention of terminating a record by the end of file without NL is problematic if the record has zero length.] At this point, it appears to me that this item needs an edit to clarify what should occur when a file is positioned within a record and an endfile record it to be written. Larry's YES comment on 000024 The answer given for item 000024 is misleading for one special case. Consider the program PROGRAM TEST OPEN (10, FILE='XXX') WRITE (10, '()', ADVANCE='NO') ENDFILE (10) END In this case, there must be some indication that a record was written. Since in this case the partial record contains no characters, there must be some indication that a formatted record has been written. Having the capability to read unterminated records is not sufficient for this example. [Bob Corbett] Van's YES comment on 000024 I agree with the spirit of the interpretation, but the wording troubles me. I think the question Corbett is trying to ask is whether the processor has the option to discard part of a record that it may have in a buffer if an advancing WRITE has not occurred prior to closing a file, or doing a BACKSPACE, ENDFILE, or REWIND operation on it. The answer should make it clear that anything written ends up in the file, even if the last WRITE was a nondavancing WRITE. The "terminating a record" question was not, in my opinion, the real question. Jon's NO vote on 000024 Annex C for informative notes contains Section C.6.1.5 Nonadvancing Input/output(9.2.1.3.1) which states the intentions of the developers of the nonadvancing feature: If the last data transfer statement was WRITE and the file is currently positioned within a record, the file will be positioned implicitly after the current record before an ENDFILE record is written to the file, that is, a REWIND, BACKSPACE, or ENDFILE statement following a nonadvancing WRITE statement causes the file to be positioned at the end of the current output record before the endfile record is written to the file. Given this intent, the positioning of the file at the end of the current record is assumed for BACKSPACE, REWIND, ENDFILE, and CLOSE statements after a nonadvancing WRITE statement. To Robert Corbett from Joanne Brixius: The statement from section C states that the file will be positioned implicitly after the current record before an ENDFILE record is written to the file. This means that the program in the Larry Meadows email with the small case: ------------------------------------------begin inclusion > > -C- --- 000024 Termination of a partial record > by a CLOSE, BACKSPACE, ENDFILE, > or REWIND statement The answer given for item 000024 is misleading for one special case. Consider the program PROGRAM TEST OPEN (10, FILE='XXX') WRITE (10, '()', ADVANCE='NO') ENDFILE (10) END In this case, there must be some indication that a record was written. Since in this case the partial record contains no characters, there must be some indication that a formatted record has been written. Having the capability to read unterminated records is not sufficient for this example. [Bob Corbett] --------------------------------------------end inclusion will actually cause an empty record to be completed on output. The Cray implementation creates an empty record in file XXX for the WRITE(10..) followed by the ENDFILE(10). Given the comments, I assumed that there was a question about where the file was positioned and what happened to the file before the ENDFILE, REWIND, BACKSPACE, or CLOSE. Henry's NO vote on 000024 We agree with Dick Hendrickson that the text of the standard should be altered to explicitly require the partial record to be considered to be a complete record. We'd also like to see the behaviour in cases like that described by Larry Meadows need to be made clear. We also feel the implementation-specific details discussed in the response do not really belong there. 000031 Association of pointer function result with INTENT(OUT) dummy argument RichB's NO vote on 000031 See IBM's comments. Malcolm's YES comment on 000031 I disagree with the other comments that the dummy argument is argument-associated with something that is not an actual argument. The dummy argument is associated with the (value of) the actual argument expression. Craig's NO vote on 000031 I agree with Van's comments. Kurt's NO vote on 000031 I agree with Van. The pointer that is the function result is not definable, but the target identified by that pointer (in this case, T) _is_ definable. In the example given, the dummy argument is associated with the target, not the pointer. [The prohibition against a function reference appearing on the left hand side of an assignment statement is syntactic in nature and has no bearing on this semantic question.] Van's NO vote on 000031 I don't know the intent of the committee, but my experience in reading the standard is that the area of argument association of pointers is murky. It is my preference that a non-pointer dummy argument is considered to be associated with a definable actual argument if the actual argument is a pointer that is associated with a definable target. The glossary entry for "definable" is not normative, and, like Henry, I could not find a normative definition for it. I prefer not to depend on non-normative text to resolve an interpretation. Henry's arguments concerning the relation between the passages he cites from 5.1.2.3 and 12.4.1 convince me that the example he provides should be standard-conforming. If the dummy argument had the pointer attribute, I would accept a conclusion that its pointer association status could not be changed, because in that case, the actual argument would be a function result. Henry's NO vote on 000031 We are inclined to agree with Van Snyder on this question. It is clear that the standard treats specially pointers that appear as actual arguments when the associated dummy is not a pointer: the dummy becomes argument associated with the target of the pointer, not with the actual argument itself. We agree the actual argument is not definable, but that seems irrelevant because the entity that is argument associated with the target is not the actual argument in this case. It seems far more likely that the drafters of the standard failed to take into account the case of a pointer actual argument that corresponds to a nonpointer dummy argument when they required that the "actual argument shall be definable" in [201:19-21] and [53:29-31]. In fact, the text cited at 5.1.2.3 [53:29-31] is particularly troublesome. To repeat, it states that: The INTENT(OUT) attribute specifies that. . . any actual argument that becomes associated with such a dummy argument shall be definable. But in the case of a pointer actual argument that corresponds to a nonpointer dummy, there is no actual argument associated with the dummy. The target of the pointer is associated with the dummy, but the target is not the actual argument. We also feel that a normative definition of the term "definable" is required. 000032 Is the TRANSFER function result undefined? Jon's YES comment on 000032 Nit: First sentence of second paragraph of the question should end with a question mark. 000073 Is padding allowed in storage sequences? DickH's YES comment on 000073 The third paragraph of the answer says "Note 5.33 does not prohibit padding between sequences of storage units, but any such padding is required to be consistent between scoping units." This needs to be reworded to "5.5.2.1 and 5.5.2.3 do not prohibit" Since the Note is non-normative it obviously doesn't prohibit anything. Kurt's YES comment on 000073 I agree with Dick Hendrickson's comment. Additionally, it might be appropriate to note that the size of a common block doesn't have much significance in Fortran 90, 95, ... (as opposed to FORTRAN 77, where size was all that had to match), and that there is no requirement that two common blocks whose size is the same actually occupy the same amount of memory. Jon's YES comment on 000073 We agree with Dick Hendrickson's observation that the note is not considered part of the standard, and the response should point to 5.5.2.1 and 5.5.2.3. 000074 TARGET dummy arguments and POINTER expressions Craig's NO vote on 000074 I agree with Van Snyder and Dick Hendrickson. DickH's NO vote on 000074 I don't understand the answer to part 3. It says "'If the dummy argument has the TARGET attribute and is either scalar or is an assumed-shape array, and the corresponding actual argument has the TARGET attribute ^^^^^^^^^^^^^^^^ but is not an array section with a vector subscript (1) Any pointers associated with the actual argument become associated with the corresponding dummy argument on invocation of the procedure ...'" But the corresponding actual argument has the POINTER attribute. I think the discussion also needs to include 200 [30-32] Kurt's NO vote on 000074 This has the same problem as 000031 above. Van's NO vote on 000074 I disagree with the reasoning here for the same reason that I disagree with the reasoning for interpretation 31. The assertion that the actual argument is not definable because it is a function result doesn't convince me. The actual argument is not a function result. It is a target of a function result. The standard is presently silent about whether the target of a function result is definable (at least partly because there is no normative definition of "definable"). It is my preference that a non-pointer dummy argument is considered to be associated with a definable actual argument if the actual argument is a pointer that is associated with a definable target. If the dummy argument had the pointer attribute, I would accept a conclusion that its pointer association status could not be changed, because in that case, the actual argument would be a function result. Jon's YES vote note to DickH on 000074 Note to Dick Hendrickson: In answer three, the POINTER attribute implies the TARGET attribute; POINTERs have the TARGET attribute implicitly. Henry's NO vote on 000074 We disagree with the responses to the first and second questions for the same reasons cited in our objections to the response to Interpretation 31. We concur with the response to the third question. 000075 Defined assignment and INTENT(IN) dummy arguments in PURE procedures For the record, Jon's NO vote changed to YES 000085 Public components of private types Malcolm's YES comment on 000085 The comment in the discussion about not deleting the referenced text was because the submitter of the interpretation request has not only proposed deleting this text but has actually done so in F2000. Thus the comment is intended to bring this to his attention. Kurt's NO vote on 000085 I find the Discussion confusing. The first paragraph appears to be true, but bears no obvious relationship to the question asked. Similarly, the second paragraph explains why the text in 14.1.2.5 should not be deleted, but the question does not propose its deletion, merely that it be edited to clarify the issue. While the text in 14.1.2.5 is literally consistent with the text added to 12.1.2.2.1, it could easily be misinterpreted, so I agree that a clarifying edit is desirable. (I am having trouble devising a "small" edit, so that might require a complete rewrite of the sentence in question.) Henry's NO vote on 000085 We agree with Kurt Hirchert that the discussion is confusing and an edit to clarify things would probably be appropriate. 000086 Definition status requirements for defined operations Kurt's YES comment on 000086 Please add "Not applicable." answers to questions (2) and (4). Jon's NO vote on 000086 We concur with the IBM response. (Yeah, like Henry said.) Henry's NO vote on 000086 We concur with the responses to questions (1) and (3), but we do not believe that the edits are sufficient to resolve the issue. According to 14.7.1 [288:17], "(1) An object is defined if and only if all of its subobjects are defined." If [97:5] is changed to read, "When a structure is referenced, it shall be defined," that leads one to the text cited in 14.7.1, which will lead one to conclude that the variable A in the example for question (3) is undefined, since its component A%PTR is undefined. Interpretation 81 asks the same question about the definition status of a structure that has a pointer component that is disassociated. We feel the responses to 81 and 86 should be considered together. F90/000197 Relationship of NEAREST and SPACING F90/000205 Restrictions on EXTERNAL DickH's YES comment on F90/000205 COMMENT: First line of Question 1 refers to F90, we should change to F95 Henry's NO vote on F90/000205 Although we agree that it should not be possible to specify the EXTERNAL attribute for an external procedure in the scope of the subprogram that defines that procedure, we do not agree that the existing text of the standard makes that clear. In particular, the response suggests that appearance of a name as the in the or in the of a external subprogram causes the name to be considered to be the name of an external procedure, and gives it the external attribute. We agree that the name is considered to be an external procedure, but that does not imply that it has the external attribute. For example, the following program unit is not standard conforming. It is clear in this example that SUB1 is an external procedure, but it does not have the external attribute (or an explicit interface), so it cannot appear as an actual argument. CALL SUB1 CALL SUB2(SUB1) END There is evidence that it was not the intent of the committee to permit the external attribute to be specified for an external procedure in the scope that defines the procedure. Consider 12.5.2.2 [206:41-42], which states: Constraint: If RESULT is specified, the function-name shall not appear in any specification statement in the scoping unit of the function subprogram. When a result clause appears on a function statement, there is no way for the user to specify the external attribute for the function name, even though the name is unambiguously the name of the function in that case, and not the name of the result variable. However, there does not appear to be a general prohibition. F90/000206 Collating sequence inconsistencies Craig's NO vote on F90/000206 The definitions listed in questions 1 and 2 are mutually contradictory. We need to resolve this contradiction one way or another before we can provide a definite answer to this interpretation. I believe that the original intent was that the standard would allow a character mapping with holes in the mapping sequence, e.g., to allow for control characters which are not supported or mappings such as EBCDIC. If this is correct, it appears that the definitions for the CHAR() and ICHAR() intrinsics need some work. DickH's NO vote on F90/000206 I just don't understand this one; I must be missing something simple. Question 1 asks "[F95 CD 36:28+] says that "A <> is a one-to-one mapping of the characters into the nonnegative integers such that each character corresponds to a different nonnegative integer." QUESTION 1: Does this definition imply that the one-to-one mapping is dense? That is, is there a requirement that if the default CHARACTER type has characters, the corresponding collating sequence maps to 0..-1 ?" And the answer is "(1) No, the definition in isolation would not require a "dense" mapping. However, in conjunction with the requirements on the CHAR and ICHAR intrinsic functions, the mapping is required to be "dense"." I thought the intent of 3.1.5 was to allow a processor to "support" e. g., the ASCII set, yet NOT support a few characters. For example not allow carriage return or line feed in a character constant. I thought this was a fairly common thing. In effect a processor supports characters with a collating sequence from 1 to 256 and with a few holes for the control characters. This interp response appears to me to prohibit this. Do we intend to require processors to support CR-LF in character constants and comments or do we intend to require them to renumber the characters from their natural ASCII sequence? Kurt's YES comment on F90/000206 The requirement that the CHAR/ICHAR collating sequence be dense dates back for FORTRAN 77. There is a problem that many (most? all?) compilers can't really allow all supported characters in character literal constants because they use characters to denote end of record. In the free-form source form, we accommodated this by requiring only graphic characters to be supported in character constants, but in fixed-source, we have simply ignored the problem. Perhaps we should address this issue somewhere, but this interpretation doesn't appear to be the right place. Henry's YES comment on F90/000206 We don't have any serious objection to the response, but we would like to comment on some other ballot comments. We don't feel that there is a problem with requiring the mapping to be dense. The standard already appears to provide a processor enough leeway to place restrictions on the usage of control characters, while still permitting the mapping to be dense. In particular, 4.3.2.1 [32-35], in describing the characters permitted in a states: . . . , is one of the following: (1) Any character in the processor-dependent character set in fixed source form. A processor may restrict the occurrence of some or all of the control characters. (2) Any graphic character in the processor-dependent character set in free source form. So in fixed source form, a processor is permitted to prohibit and , for instance, from appearing in a character literal constant, while the standard itself already protects the processor in free source form. According to 3.3, a comment may contain those characters that are permitted in a , so comments pose no additional problems. Similarly, 9.1.1 [133:28-29] states, "a processor may prohibit some control characters (3.1) from appearing in a formatted record." We don't see a need for a processor to prohibit the values 10 and 13, say, from appearing as arguments to CHAR or ACHAR; the fact that a processor can prohibit the corresponding characters in the character sequence from appearing in character literal constants, comments and formatted records seems sufficient protection. F90/000207 Integer bit-model inconsistency Malcolm's YES comment on F90/000207 As written, F90 and F95 make contradictory statements about the bit intrinsics for non-binary machines. Thus the proposed edit does not make an incompatible change. One cannot conserve both the efficiency of the bit intrinsics and the bit-integer mapping; I believe that the efficiency of the intrinsics is more important. Kurt's NO! vote on F90/000207 This is just plain wrong. The original spec for the bit manipulation functions was that they operate as though the underlying representation were binary, regardless of the actual integer radix. (I think this requirement may have been in the original ISA standard, but it might have been in Mil-Std 1753 or IRTF.) The proposed edit is an incompatible _change_ to the language. Mike's NO vote on F90/000207 Agree with IBM's comments Jon's NO vote on F90/000207 The edit is unnecessary. BIT stands for Binary digIT, which implies r==2. Webster defines BIT as a choice between two alternatives, such as yes or no, on or off. Henry's NO vote on F90/000207 We agree with Kurt Hirchert that the proposed edit will yield an incompatible change. The suggested edit would make the results of bit manipulation no longer portable when is not equal to 2. F90/000208 nonadvancing output followed by list directed output RichB's NO vote on F90/000208 I agree with Dick/Kurt/IBM that a specific behavior should be specified by the standard in this case. I think I disagree with IBM's recomendation to continue the current record, but thats a separate issue. Craig's NO vote on F90/000208 I agree with Dick Hendrickson. DickH's NO vote on F90/000208 The answer says "If the first character of the current record is not a blank, the processor must ensure that compliance with [178:24] is achieved by beginning a new record before the output of any list item." The standard doesn't say that. A processor could equally well go back and prepend a blank on the existing partial line couldn't it? If the standard prohibits that we should cite a reference. I would have preferred to say "You can't do list directed or namelist I/O in the middle of nonadvancing I/O". But it's probably a little late for that. My second choice would be to say list directed and namelist start where they are and ignore the leading blank requirement for the current line. Kurt's NO vote on F90/000208 The proposed interpretation is silly. It makes much more sense to admit that this is a case we failed to cover and define an appropriate rule. I could live with any of the following: 1) This is not allowed. (I.e., you can't mix user-formatted and processor-formatted text in the same record.) 2) This is allowed, the processor is not responsible carriage control if it doesn't fill column 1, and the processor must supply separation (blank or comma?) between the user-formatted text and the processor-formatted text. 3) This is allowed, the processor is not responsible carriage control if it doesn't fill column 1, and the processor need not (must not?) supply separation between the user-formatted text and the processor-formatted text. 4) This is allowed. The processor-formatted text must begin in a new record. There are probably other rules that I would find rational. However, the proposed rule in this interpretation is not one of them. Jon's NO vote on F90/000208 The F95 standard does not state that list-directed I/O may or may not continue in an existing nonadvancing record. It simply states that the ADVANCE= specifier is allowed only in formatted sequential I/O statements that contain a control-information list. Since the current position in the record may be beyond the beginning of the record, the list-directed write cannot in general go back to store a blank for carriage control. The use of list-directed input/output following a nonadvancing data transfer statement is undefined in F95. Henry's NO vote on F90/000208 We agree with Dick Hendrickson and Kurt Hirchert that the committee obviously neglected to deal with this case and that the behaviour needs to be specified. Our preference would be that list-directed output continue any record that was begun using nonadvancing output. F90/000210 nonadvancing write followed by list directed write RichB's NO vote on F90/000210 See 208. Kurt's YES Comment on F90/000210 I am satisfied with the thrust of this interpretation, but I am uncomfortable with its expression. In particular, I am uncomfortable with "The processor may start a new record whenever it deems necessary,". At a minimum, I would probably change that to "In producing list-directed output, the processor ...". Were I writing this text from scratch, I would probably say something to the effect that conceptually the list directed output begins on the same record, but that 10.8.2 gives the processor wide latitude for beginning new records _within_ the processor-formatted text, including the possibility of going to a new record before the representation of the first output-list item, so the cited implementation is conforming in this regard. In any case, I would hold this item until F90/000208 is also completed, as the rule we adopt to answer F90/000208 might affect the answer we give here. (E.g., if we say that following nonadvancing output with list-directed output is not permitted, this question becomes moot.) Jon's NO vote on F90/000210 Interp 208 needs to get fixed before this can be answered. Having voted no to 208, we must vote no to this until 208 is fixed. Note to Bob Corbett: Cray, Inc. allows list-directed I/O after a nonadvancing I/O statement. An environment variable allows a user to force a new record for list-directed I/O after a nonadvancing I/O statement. Henry's NO vote on F90/000210 We agree with Kurt Hirchert that the response to this question needs to wait for the response to F90/000208. Having voted NO to 208, we must vote NO to this. JP-04 Construction of derived-type values Kurt's NO vote on JP-04 The replacement text appears to be as bad (in a different way) as the text being replaced. (The right hand side of a pointer assignment statement isn't "a result value".) A simple fix that might be acceptable would be to change "evaluate to" to "identify". A slightly more involved solution might be to delete "evaluate to ... that would" so the resulting text reads "... constructor expression shall be an allowable target ..." Otherwise, we may need to state that in this case, the expression is constrained either to be a variable with the TARGET attribute or to return a pointer result. (I.e., copy more of the requirements from the description of pointer assignment.) Jon's NO vote on JP-04 A better edit, perhaps, would be after ", the" add "result of evaluating the" and delete "evaluate to an object that would" to yield "Where a component in the derived type is a pointer, the result of evaluating the corresponding constructor expression shall be an allowable target for such a pointer in a pointer assignment statement (7.5.2)". Henry's NO vote on JP-04 A pointer might not have a value - it could be associated with an undefined target or it could be disassociated. For this reason, we don't feel that the term "result value" is the best replacement. So perhaps something like the following would be a preferable edit: [45:7-8] Replace "evaluate to an object" with "be a data entity" JP-05 Construction of array values Jon's NO vote on JP-05 The sentence could have been a constraint, perhaps should have been a restraint, and probably should be made a constraint in F2000, but it does not and should not be changed to a constraint in F95. Nothing is clarified or corrected by making processors issue a diagnostic for the error, which most processors probably already diagnose. Henry's NO vote on JP-05 Although we agree that the text cited at [46:3-5] could be made into a constraint, we don't see a need to make this change. Making this change could render conforming Fortran 95 processors nonconforming. There may be many other examples of normative text that are not currently written as constraints, but could be. We feel it would be worth considering in each case whether it would be beneficial to create such new constraints in Fortran 200x, but that such changes are nearly always undesirable in Fortran 95. JP-08 Type declaration statements Henry's YES comment on JP-08 Although we have no serious objection to applying the edit described, we have a suggestion for an alternative edit. [49:5] Replace "" by "" The nonterminal is either a in parentheses or a . The latter form cannot be a nonconstant expression, which means that the cases of and both reduce to whether is a nonconstant expression. JP-12 Bounds of each dimension of an array pointer JP-16 Multiple occurrence of namelist-group-name in NAMELIST statement Kurt's YES comment on JP-16 I agree with the thrust of this response, but I find the phrasing awkward in the edit. I suggest that the first edit be to replace "in one or more" by "more than once in the". (A perverse reading of the current replacement text would be that a namelist-group-name can appear in more than one statement only if it appears more than once in each statement where it appears.) JP-17 Multiple occurrence of namelist group object in namelist group RichB's NO vote on JP-17 IBM's arguments make sense to me. Prohibiting the same name variable seems ok, prohibiting storage associated different named variables does not seem ok. Kurt's NO vote on JP-17 I believe this requirement should be a constraint. Accordingly, I suggest it be added at [66:8+] with the word "Constraint:" prepended. Jon's NO vote on JP-17 We disagree with the response. There is no statement that the namelist must follow the rules of COMMON in the F95 standard and there is no reason to disallow it. There is no storage association to cause problems. The program may get two copies written by a namelist WRITE statement but only the last assignment by the namelist READ statement is kept. Henry's NO vote on JP-17 We have a mild objection to this change. So far as we know, the standard does not currently prohibit variables that are storage associated (or associated in some other way) from appearing in the same namelist group, so might there be a reason a user would want to specify the same variable twice? For example, the following appears to be standard conforming. program p x = 13.0 call sub(x,x) end program p subroutine sub(y,z) equivalence(i,j) namelist /nl/ i, j, y, z i = 17 write(*, nml=nl) end subroutine sub We couldn't think of any reason a user would want to specify the same variable twice, but we were worried about introducing an irregularity. JP-31 Signs of literal constants Kurt's YES comment on JP-31 There appears to be confusion about the "Note for F2000". I am voting in favor of this item on the assumption that it is _not_ part of what we are approving. Van's YES comment on JP-31 Shouldn't the note for F2000 say "The phrase ... is NOW the ..."? Jon's NO vote on JP-31 The second edit it incorrect. It should be [178:40] Replace "c is a literal contant and" by "c is a literal constant, optionally signed if integer or real, and".