J3/06-133r1 To: J3 Members Date: 16-Feb-2006 From: /interp/Stan Whitlock Subj: Results of the J3 interp letter ballot #12 Here are the results of J3 letter ballot #12 on Fortran interpretations that closed on 3-Feb-2006. The ballot is in J3 paper 06-111 for meeting #175. If I have transcribed a vote or a comment incorrectly, please let me know. At J3 meeting #175, /interp decided to accept Rob James' suggestion in his YES vote; therefore, F03/0063 passes J3 letter ballot #12 with that change. J3 rep F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 F03 28 45 56 57 58 59 60 61 62 63 64 66 Rich Bleikamp Y Y Y Y Y N Y Y Y Y Y Y Dick Hendrickson Y Y Y Y Y Y Y Y Y Y Y Y Michael Ingrassia Y Y Y Y Y Y Y Y Y Y Y Y Rob James Y Y Y Y Y C Y Y N C N Y Bill Long Y Y Y Y Y Y Y Y Y Y Y Y Jeanne Martin no ballot received Dan Nagle Y Y Y Y Y Y Y Y Y Y Y Y Craig Rasmussen Y Y Y Y Y Y Y Y Y Y Y Y Van Snyder Y Y Y Y Y Y Y Y Y Y Y Y Matthijs van Waveren no ballot received Stan Whitlock Y Y Y Y Y Y Y Y Y Y Y Y J3 rep F03 F03 F03 F03 F03 67 68 69 70 72 Rich Bleikamp Y Y Y Y Y Dick Hendrickson Y Y Y Y Y Michael Ingrassia Y Y Y Y Y Rob James Y Y Y C Y Bill Long Y Y Y Y C Jeanne Martin no ballot received Dan Nagle Y Y Y Y Y Craig Rasmussen Y Y Y Y Y Van Snyder Y Y Y Y Y Matthijs van Waveren no ballot received Stan Whitlock Y Y Y Y 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 45 56 57 58 59 60 61 62 63 64 66 67 68 69 70 72 P P P P P F P P C C F P P P P C c The interps marked "C" pass with some minor typo fixes, as noted below. The interps marked "F" will be reconsidered at J3 meeting #175 by the /interp committee who will decide if the status becomes "withdraw for more work", "passed as amended", or "passed as printed". /Stan ********************************************************************** F03/0059 Structure components in namelist input Rich Bleikamp's NO comment for F03/0059: The replacement text reads "if the variable would not be processed by a UDDTIO ...", but I think the presence of an object designator might actually determine whether or not the object designator is processed by a UDDTIO routine (sort of the reverse decision process than what is being suggested, where being processed by a UDDTIO routine precludes the use of a non-simple variable name in the input record). Second, the sentence immediately after the replaced text talks about "Successive qualifications" being applied to the name. I think this reads awkwardly with the suggested edit. Third, I think the answer may be wrong. For namelist input, we should allow (perhaps we already do) object designators all the time, and just not invoke the UDDTIO routine if the object designator is not a simple variable name, or if the resulting objects datatype/shape do not match an existing interface for a UDDTIO routine. Also, its not clear to me (its too late in the day), but perhaps we really want to allow an object designator that's an array element reference to invoke a UDDTIO routine. We could use the datatype and shape of the object designator to determine whether or not a UDDTIO routine should be invoked (still a compile time decision). I'm not at all sure we'd want to allow component references in such a case, or perhaps a component reference in the input record just precludes the possibility of invoking a UDDTIO routine for that input value. The tradeoffs here are: 1) allow some more functionality (which we may already allow), such as array element references appearing in a namelist input record (as a namelist group object name, possibly qualified), and still cause a UDDTIO routine to be invoked, and 2) keep the rules simple enough that the user and compiler's I/O library can easily agree on what's supposed to happen, and what input values are therefore allowed. I was going to suggest a replacement edit, but my head hurts too much :). Rob James' YES comment for F03/0059: In the input for the program (question 1), "b1" should be "x". Conclusion on F03/0059: Has not yet passed J3 letter ballot #12 - /interp will consider the above comment from Rich Bleikamp at meeting #175; the correction suggested by Rob James will be made F03/0062 Finalization of array constructors Rob James' NO comment for F03/0062: For both edits, it is not enough just to change the first occurrence of "structure". Both occurrences of "structure" on these lines should be changed to "structure or array". Conclusion on F03/0062: Passed J3 letter ballot #12 with the above change F03/0063 Procedure pointers in BLOCK DATA program units Rob James' YES comment for F03/0063: I'm not sure that the line number is right for the last edit. It seems to me that this would go better at [254:3]. Conclusion on F03/0063: /interp decided at meeting #175 to accept the above suggestion; therefore, F03/0063 passes J3 letter ballot #12 with the above change F03/0064 Recursive declaration of procedure interfaces Rob James' NO comment for F03/0064: There are some cases of this kind of thing that don't seem to be caught by this interpretation response. In particular, these cases don't seem to be prohibited: MODULE m1 CONTAINS SUBROUTINE s(p) PROCEDURE(s) :: p END SUBROUTINE END MODULE MODULE m2 CONTAINS SUBROUTINE s1(a) PROCEDURE(s2) :: a END SUBROUTINE SUBROUTINE s2(b) PROCEDURE(s1) :: b END SUBROUTINE END MODULE Maybe some sort of statement would cover all of these cases if it is along the lines that a dummy procedure's characteristics can't depend on the characteristics of the procedure or interface body in which it is declared. Conclusion on F03/0064: Has not yet passed J3 letter ballot #12 - /interp will consider the above comment at meeting #175 F03/0070 Can child I/O statements be advancing I/O statements? Rob James' YES comment for F03/0070: The words "nonadvancing" and "nonchild" should not be hyphenated. Conclusion on F03/0070: Passed J3 letter ballot #12 with the above changes F03/0072 Default initialization for "automatic" components Bill Long's YES Comment for F03/0072: Was it intended that the constraint include a rule reference? Perhaps beginning with "C447a (R440) If". Conclusion on F03/0072: Passed J3 letter ballot #12 with the above change