J3/05-146 To: J3 Members Date: 24-Jan-2005 From: /interp/Stan Whitlock Subj: Results of the J3 interp letter ballot #10 Here are the results of J3 letter ballot #10 on Fortran 2003 interpretations that closed on 22-Dec-2004. The ballot is in J3 paper 05-101 for meeting #171. 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 8 12 17 18 19 20 21 22 23 24 25 26 Rich Bleikamp Y Y Y Y Y Y Y Y Y Y Y Y Dick Hendrickson Y Y Y Y Y Y Y N Y N Y Y Michael Ingrassia Y N N Y Y Y Y Y Y Y Y Y Rob James Y Y Y Y Y Y N Y Y Y Y Y Bill Long Y Y Y Y Y Y Y Y Y Y Y Y Jeanne Martin Y Y Y Y Y Y N N Y N Y Y 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 C Y Y Matthijs (Toon) 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 F03 F03 27 28 29 Rich Bleikamp Y N Y Dick Hendrickson Y Y Y Michael Ingrassia Y Y Y Rob James Y Y Y Bill Long Y Y Y Jeanne Martin Y Y Y Dan Nagle Y Y Y Craig Rasmussen Y Y Y Van Snyder Y Y Y Matthijs (Toon) Y Y Y Stan Whitlock 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 8 12 17 18 19 20 21 22 23 24 25 26 27 28 29 P P F P P P F F P F P P P F P The interps marked "C" pass with some minor typo fixes, as noted below. The interps marked "F" will be reconsidered at J3 meeting #171 by the /interp committee who will decide if the status becomes "withdraw for more work", "passed as amended", or "passed as printed". /Stan ************************************************************************ F03/0001 Generic type-bound procedures Rob James' YES comment for F03/0001: While there is no technical problem, the different uses of are confusing, and should be changed in the next revision of the standard. F03/0012 Procedure pointers and the EXTERNAL attribute Michael Ingrassia's NO comment for F03/0012: The language is confusing. Asking reader to follow along that "A conspiracy of [thing 1] [thing 2] [thing 3] [thing 4] appears to completely wipe out procedure pointers (PPP because of [thing 5] )" is insufficiently kind to the reader, and too many different points are made. Split into separate interps please. F03/0017 Dummy procedure pointers and PRESENT Michael Ingrassia's NO comment for F03/0017: The statement "It is not clear in 13.7.91 whether the argument of PRESENT has or has not the POINTER attribute" seems to me to be wrong. In the fragment subroutine S(I) integer, optional :: I if (present(I)) then the argument of present does not have the POINTER attribute, but in the fragment subroutine S(I) integer, pointer, optional :: I if (present(I)) then it does, and the language of 13.7.91 is clear enough "[the argument to PRESENT] may be a pointer". Delete the statement ("It is not clear..."). Since that removes justification for the edits submitted, change the answer to read "The program does not conform to the 2003 standard. This is because the pointer F is not associated in subroutine S, which is not one of the possibilities permitted by 12.4.1.3 [271:16]." F03/0021 What kind of token is a stop code? Rob James' NO comment for F03/0021: The last edit does not make sense for an that does not have a . [36:37-38] explicitly states that such an is of type default integer. The last edit, however, says that the value of this constant does not have to be representable in the default integer type. How can a default integer not contain a value representable in the default integer type? Jeanne Martin's NO comment for F03/0021: 21, 22, and 24 need more work. The answers seem incomplete. F03/0022 Coexistence of IEEE and non-IEEE kinds Dick Hendrickson's NO comment on F03/0022: The answer doesn't appear to answer the details of the question. Saying that IEEE and non-IEEE reals are both allowed is not an answer the question about REQUIRING overflow and divide by zero for the NON-IEEE reals in the second paragraph. What practical use is there in requiring a processor to support overflow and divide-by-zero for NON-IEEE reals in a subroutine that uses both kinds of reals? Surely the purpose of NON-IEEE reals is that they are not bound by the same rules as the IEEE reals are. Why was it intentional to bind at least some of the IEEE rules to them? The answer should be reversed to state that the speculation in the last paragrpah of the question is correct, and edits provided. Jeanne Martin's NO comment for F03/0022: 21, 22, and 24 need more work. The answers seem incomplete. F03/0024 DEALLOCATE and array pointers Dick Hendrickson's NO comment for F03/0024: The answer appears to be incomplete. The question is "What exactly does "whole" mean in this rule", but the answer appears to be limited just to the specific example given. We also need to consider things like b=>a(10:1:-1) Also, pining the answer to ASSOCIATED is risky for understanding other cases. ASSOCIATED is true for zero sized things. Given ALLOCATE(A(0),C(0)) b=>C then ASSOCIATED(B,A) is true, yet A isn't deallocated. Jeanne Martin's NO comment for F03/0024: 21, 22, and 24 need more work. The answers seem incomplete. Van Snyder's YES comment for F03/0024: I'm holding my nose and voting "Yes with comment" on F03/0024. It's OK as far as it goes, and the questions it doesn't answer weren't asked. But I expect there will be another interp along the lines of "Is this OK: ALLOCATE(A(N)); B => A(N:1:-1); DEALLOCATE(B)?" I don't really care about the outcome of the vote on that interp, if it does come up; I just think the standard should be clear. F03/0028 Commas in complex namelist output Rich Bleikamp's NO vote for F03/0028: For historically perverse reasons, a '/' is listed as a value separator in list item 2 on page 239 (04-007). Because of this perversity, whereever a 'real' value separator is required, the text of F90 and F95 have to specifically call out a comma or period, as appropriate. See 04-007 239:27-29. A similar sentence is needed in section 10.10.1.3 when describing acceptable input forms for the complex datatype. I would note that fixing the standard so '/' does not need to be value separator is a better solution, and was proposed by Walt B in the last days of F90 processing, but that is a much harder fix than my suggestion above.