J3/05-170 To: J3 Members Date: 7-Apr-2005 From: /interp/Stan Whitlock Subj: Results of the J3 interp letter ballot #11 Here are the results of J3 letter ballot #11 on Fortran 2003 interpretations that closed on 31-Mar-2005. The ballot is in J3 paper 05-167 for meeting #172. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 28 30 31 32 33 34 35 36 37 38 39 40 Rich Bleikamp N Y Y Y Y Y Y Y Y Y Y Y Dick Hendrickson N Y Y Y Y Y Y Y Y Y Y Y Michael Ingrassia N Y Y Y Y Y Y Y Y Y Y Y Rob James N Y Y Y C Y Y Y Y Y Y Y Bill Long N Y Y Y Y Y Y Y Y Y Y Y Jeanne Martin N Y Y Y Y Y Y Y Y Y Y Y Dan Nagle Y Y Y Y Y Y Y Y Y Y Y Y Craig Rasmussen no ballot received Van Snyder N Y Y Y Y Y Y Y Y Y Y Y Matthijs van Waveren N Y Y Y Y Y Y Y Y Y Y Y Stan Whitlock N Y Y Y Y Y Y Y Y Y Y Y J3 rep F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 41 43 44 45 46 47 48 49 51 52 53 54 Rich Bleikamp Y Y Y Y Y Y Y Y Y Y Y Y Dick Hendrickson Y Y Y Y Y Y N N Y Y Y Y Michael Ingrassia Y Y Y Y Y Y Y Y N Y Y Y Rob James Y Y Y Y Y Y Y Y C Y Y Y Bill Long Y Y Y Y Y Y N Y Y Y Y Y Jeanne Martin Y Y Y Y Y Y N C N Y Y Y Dan Nagle Y Y Y Y Y Y Y Y Y Y Y Y Craig Rasmussen no ballot received Van Snyder Y Y Y Y Y Y N N Y Y Y Y Matthijs van Waveren 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 J3 rep F03 55 Rich Bleikamp Y Dick Hendrickson Y Michael Ingrassia Y Rob James Y Bill Long Y Jeanne Martin Y Dan Nagle Y Craig Rasmussen no ballot received Van Snyder Y Matthijs van Waveen Y Stan Whitlock Y where Y means "yes" C "yes with comment" N "no with comment" The comments for each interp 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 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 28 30 31 32 33 34 35 36 37 38 39 40 41 43 44 45 46 F P P P P P P P P P P P P P P P P F03 F03 F03 F03 F03 F03 F03 F03 47 48 49 51 52 53 54 55 P F F F P P P P The interps marked "C" pass with some minor typo fixes, as noted below. The interps marked "F" will be reconsidered at J3 meeting #172 by the /interp committee who will decide if the status becomes "withdraw for more work", "passed as amended", or "passed as printed". /Stan ********************************************************************** F03/0028 Commas in complex namelist output Rich Bleikamp's NO comment for F03/0028: I agree with Rob: the first edit needs to be reworked. Dick Hendrickson's NO comment for F03/0028: I agree with Rob James, the first edit is awkward. Perhaps something like ", comma or semicolon depending on the decimal edit mode, " could be made to work. Michael Ingrassia's NO comment for F03/0028: Just piling on, the edit needs work as Rob James has pointed out. Rob James' NO comment for F03/0028: The first edit doesn't work. The resulting sentence reads: If the delimiters are omitted, the character sequence is terminated by the first blank, comma, or semicolon if the decimal edit mode is decimal, slash, or end of record; in this case apostrophes and quotation marks within the datum are not to be doubled. This appears to say that the decimal edit mode can be decimal, slash, or end of record. Bill Long's NO comment for F03/0028: I agree with Rob that the wording resulting from the first edit is confusing, and needs to be redone. Jeanne Martin's NO comment for F03/0028: The edit is unclear, perhaps rearranging the list or making the sentence into two would clarify it. Van Snyder's NO comment for F03/0028: I agree with Rob. The first edit is defective. Matthijs van Waveren's NO comment for F03/0028: The first edit is incorrect. Stan Whitlock's NO comment for F03/0028: I agree with RobJ: the first edit needs to be reworked. Conclusion on F03/0028: Failed J3 letter ballot #11 F03/0033 IEEE_VALUE() Rob James' YES comment for F03/0033: It might be nice to add a sentence like the following to the answer: The specification for IEEE_VALUE appears in 14.10.36. Conclusion on F03/0033: Comment not accepted Passed J3 letter ballot #11 F03/0047 Polymorphic arguments to intrinsic procedures Rob James' NO comment for F03/0047 that changed to YES: The answer fails to account for type parameters. After looking again, it seems that the descriptions for the affected intrinsic procedures already account for type parameters. I'd like to change my vote for F03/0047 to YES. F03/0048 Control edit descriptors in UDDTIO Dick Hendrickson's NO comment for F03/0048: Where does it say that "record position" means the same as "file position". Does the standard actually say that, or is that just our intent? If it's our intent, we should actually define record position. Bill Long's NO comment for F03/0048: I agree with the conclusion (that the program is conforming) but not with the first sentence of the Answer. The terms "record position" and "file position" do not mean the same thing. We've even had previous interps where the difference was the core of the answer to the question. Record position is the character position within the current record, as used in 10.7.1. File position specifies which record (if any) is the current record, as used in 10.7.2 and 9.7. I believe that the originally cited text: 9.5.3.7.2 states: A record positioning edit descriptor, such as TL and TR, used on unit by a child data transfer statement shall not cause the record position to be positioned before the record position at the time the user-defined derived-type input/output procedure was invoked. was intended to say that "...shall not be positioned before the record position within the record that was current at the time the user-defined...". The intent is to prevent the child data transfer from positioning the record position to the left of where it was when the child was called, so to prevent the parent from unknowingly overwriting the characters it had previously written. If the child starts a new record, as is the case in the example, then this protection is no longer an issue. I would suggest deleting the first sentence of the Answer (because it is wrong), keeping the second sentence, and perhaps adding a clarifying edit to the 9.5.3.7.2 text. Jeanne Martin's NO comment for F03/0048: I agree with Bill Long's comment - record position and file position are not the same. Van Snyder's NO comment for F03/0048: I agree with Dick. I couldn't find any support for the assertion that "The term 'record position' means the same as the term 'file position.'" Conclusion on F03/0048: Failed J3 letter ballot #11 F03/0049 Separators in list-directed output involving UDDTIO Dick Hendrickson's NO comment for F03/0049: The answers to both 1 and 2 say "It is the intent of the standard..." How do we know this? There should be a reference to the section that says this, or the words that say it should be added to the standard. Jeanne Martin's YES comment for F03/0049: Perhaps a reference to 9.5.3.7.2 might be helpful in answers 1 and 2, but it is a long subsection and the relevant information is near the middle. Van Snyder's NO comment for F03/0049: I thought about voting "yes with comment," but upon reflection concluded that the standard ought to say what its intent is, rather than relying on an interp answer that doesn't result in any words in a corrigendum. Conclusion on F03/0049: Failed J3 letter ballot #11 F03/0051 Repeat specifiers and UDDTIO Michael Ingrassia's NO comment for F03/0051: John Reid has raised the issue of whether it requires all r values c in r*c to be transferred to effective list items; I am willing to change to YES after hearing a satisfactory answer. Rob James' YES comment for F03/0051: The end of the answer should read "in this case", not "is this case". Also, in the edit, "list directed" should be "list-directed". Jeanne Martin's NO comment for F03/0051: Vote will change to yes if edits mentioned by Rob James are applied. John Reid's comment on F03/0051: I do not have a vote, but if I did, I would comment on the edit in f03/0051. It uses the term 'consume', which is not used anywhere else in the standard and whose meaning I can only guess. Also, it suggests that it is obligatory for all r values c to be transferred to effective list items. Here is a possible alternative edit for the same place: "If the form appears in a list-directed record, all the processing of the constants that occurs shall be performed during the execution of a non-child list-directed input statement or a single execution of the whole of a chain of parent-child input statements." Conclusion on F03/0051: Failed J3 letter ballot #11