From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Thu Oct 11 12:15:12 2012 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id CBF6B35693E; Thu, 11 Oct 2012 12:15:12 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mk-filter-2-a-1.mail.uk.tiscali.com (mk-filter-2-a-1.mail.tiscali.co.uk [212.74.100.53]) by www.open-std.org (Postfix) with ESMTP id D451A35692B for ; Thu, 11 Oct 2012 12:15:09 +0200 (CEST) X-Trace: 819806265/mk-filter-2.mail.uk.tiscali.com/B2C/$THROTTLED_STATIC/TalkTalk_Customer/92.21.160.188/None/John.Reid@stfc.ac.uk X-SBRS: None X-RemoteIP: 92.21.160.188 X-IP-MAIL-FROM: John.Reid@stfc.ac.uk X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120909 Firefox/15.0.1 SeaMonkey/2.12.1 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBANaadlBcFaC8/2dsb2JhbAANN4txsBqHOyUGNxYYAwIBAgFLDQgCrVWKaYkIi0iGHwOSPIMxhU+NT4Fi X-IronPort-AV: E=Sophos;i="4.80,571,1344207600"; d="txt'?scan'208";a="819806265" Received: from host-92-21-160-188.as13285.net (HELO [127.0.0.1]) ([92.21.160.188]) by smtp.tiscali.co.uk with ESMTP; 11 Oct 2012 11:12:28 +0100 Message-ID: <50769B97.5060502@stfc.ac.uk> Date: Thu, 11 Oct 2012 11:12:39 +0100 From: John Reid User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120909 Firefox/15.0.1 SeaMonkey/2.12.1 MIME-Version: 1.0 To: WG5 Subject: Result of the interpretations ballot 4 Content-Type: multipart/mixed; boundary="------------090506090606050504040204" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------090506090606050504040204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit WG5, Here is the latest draft result of interpretations ballot 4. The only changes since the previous version come from Malcolm. I had included as "Responses from the editor" comments that were intended only as email. He has provided revised comments. There remains the task of choosing the result of all the ? items. I propose that they all be C, so that J3 decides what to do about them at its meeting next week. What does \interp think about this? Cheers, John. --------------090506090606050504040204 Content-Type: text/plain; charset=windows-1252; name="N1944-3.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="N1944-3.txt" ISO/IEC JTC1/SC22/WG5 N1944-3 Result of the interpretations ballot 4, N1934 Key for the Result line: Y vote passes unconditionally. C vote passes, subject to J3 considering the comments and reasons and making no change that alters the technical content. N vote fails. Returned to J3 for further work. ? result will be decided by the Convener and /INTERP. The comments are given in alphabetic order, which sometimes causes forward references to later comments. F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ 0043 0048 0054 0055 0056 0057 0058 0059 0060 0061 Chen Y Y Y Y Y Y Y Y Y Y Cohen Y N Y C Y Y Y Y Y Y Corbett Y C N Y N Y N Y Y Y Long Y C Y C Y Y Y C Y Y Maclaren - Y Y - - Y Y - Y Y Muxworthy C Y C C Y C Y Y Y Y Reid Y Y Y Y Y Y Y Y Y Y Snyder Y Y Y Y Y C C Y Y Y Whitlock Y Y Y Y Y Y Y Y Y Y Result C ? ? C ? C ? C Y Y F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ 0062 0063 0064 0065 0066 0067 0068 0069 0070 0072 0073 Chen Y Y Y Y Y Y Y Y Y Y Y Cohen Y Y Y Y Y Y Y Y Y Y C Corbett Y N C Y Y C Y Y Y Y Y Long Y Y C Y Y Y C Y Y C Y Maclaren Y C Y C - - - - - Y - Muxworthy Y Y Y Y Y Y Y Y Y Y Y Reid Y Y Y Y Y Y Y Y Y Y C Snyder Y Y Y Y Y C Y Y Y Y Y Whitlock Y Y Y Y Y Y Y Y Y Y Y Result Y ? C C Y C C Y Y C C Comments and reasons for NO votes F08/0043 Muxworthy comment: Why not remove C1229 now? It takes only three small edits. Reply from the editor: Because there is no defect in the standard so it would be an unnecessary edit. Editorial fixes like removing redundant text is more efficiently done via the editorial process for the next revision. (It might not necessarily be best to remove the specific redundancy identified by the interp question.) .................................................................... F08/0048 Cohen reason for NO vote: Bill Long writes: "Does the interp open the door to a whole room full of "clever programming" opportunities? For example, you can pass a different element on each image." Yes, that is precisely why I voted against this interp at every previous opportunity. I think it is a bad idea to provide such a confusing feature with so few redeeming qualities. Corbett comment: While I see no problem with implementing the feature as described in the proposed interpretation, I would agree to defer approval of the interpretation until after further consideration of Malcolm's objections. Long comment: I think it would be clearer if the last word of the edit were changed from "array" to "coarray". I know that further restriction could be deduced from 12.5.2.8p1, but why be unnecessarily obscure? Does the interp open the door to a whole room full of "clever programming" opportunities? For example, you can pass a different element on each image. An only slightly more complicated example than the outline in the interp is: program test interface subroutine sub (x) real x(10)[*] end subroutine end interface real :: x(100)[*] integer :: ti ti = this_image() x = 666 call sub (x(ti)) print *, "For image ", ti, "x(1:15) = ", x(1:15) end program test subroutine sub(y) real y(10)[*] y = 999 end subroutine sub Testing this out does lead to the expected results: > aprun -n4 ./a.out For image 3 x(1:15) = 2*666., 10*999., 3*666. For image 4 x(1:15) = 3*666., 10*999., 2*666. For image 2 x(1:15) = 666., 10*999., 4*666. For image 1 x(1:15) = 10*999., 5*666. > If sub contained coindexed references to y, it could get confusing about what elements of x you are really accessing on the remote images. In principle this is OK, but I wanted to be sure we were all agreeing to the same consequences for this interp. Reply from the editor re: Changing "contiguous array" to "contiguous coarray": The editor will change it back, since that would make this sentence confusing and at the same time partially duplicate the technical content of the previous sentence. It is ALWAYS a bad idea to duplicate requirements! There is no obscurity, the previous sentence is perfectly clear. It does not have to be stated again. .................................................................... F08/0054 Corbett reason for NO vote: I think that the proposed interpretation is a misinterpretation of what was intended by paper 02-144. As I have said before, I think that the paper was sloppy in that it did not mean a procedure reference when it used the term "referenced." I think that by "referenced," it meant any use other than a declaration. Nonetheless, I think the difference between the proposed interpretation and what I think was intended in the paper is small enough that I would not vote "no" on this interpretation for that reason. The reason I am voting "no" on this interpretation is that the proposed edits are incorrect. The text of the relevant portion of the standard is also erroneous. I assume that the term "procedure identifier" is meant to include operators and the names of procedures and procedure pointers. The problem is that a generic identifier appears to fall under this definition. A generic identifier does not have either implicit or explicit interface. I do not see how the proposed edits apply in the case of a generic identifier. As I thought about the issue, I convinced myself that the property of having implicit or explicit interface should apply only to the names of procedures and procedure pointers, and not to procedures themselves. Because of renaming, a single procedure can have more than one name in a given scoping unit. The properties of each name might be different. For example, a function F might be identified by the names G and H in a scoping unit. The names of the dummy arguments of G and H might be different. Reply from the editor: > > I think that the proposed interpretation is a misinterpretation of > what was intended by paper 02-144. Paper 02-144 ***DID NOT INTEND TO MAKE A TECHNICAL CHANGE*** Not even a small one. (Either that or the authors secretly wanted a technical change and got it past the committee by subterfuge. I do not believe that is the case.) ... > The reason I am voting "no" on this interpretation is that the > proposed edits are incorrect. The text of the relevant portion of > the standard is also erroneous. > > I assume that the term "procedure identifier" is meant to include > operators and the names of procedures and procedure pointers. The > problem is that a generic identifier appears to fall under this > definition. A generic identifier does not have either implicit or > explicit interface. Huh? The edit says "Within the scope of a procedure identifier, THE PROCEDURE shall have an explicit interface" Nothing about generic identifiers having an explicit interface. > I do not see how the proposed edits apply in > the case of a generic identifier. Seems clear enough to me. > As I thought about the issue, I convinced myself that the property > of having implicit or explicit interface should apply only to the > names of procedures and procedure pointers, and not to procedures > themselves. Because of renaming, a single procedure can have more > than one name in a given scoping unit. The properties of each name > might be different. For example, a function F might be identified > by the names G and H in a scoping unit. The names of the dummy > arguments of G and H might be different. They would still both have explicit interfaces though... I am reluctant to completely rewrite the way the standard describes interfaces to procedures along the lines suggested, in an interp. I agree that the language could be better, but apart from not being entirely convinced that the suggested approach would actually be an improvement, I think that the right time for rewriting the whole method of description must be in a revision, not an interp. Muxworthy comment: In the first edit shift 'only' four words to the right? Reply from the editor: ok (the original is also ok, but this is marginally nicer). .................................................................... F08/0055 Cohen comment: In the edits, change "with d==0" to "with d equal to 0", twice. Long comment: Particularly for an interp about G output formatting, it would be very helpful to actually display the expected output. [Generally, when there is example code that has output, it would be helpful to state the correct output if the code is claimed to be conforming.] Muxworthy comment: Is it preferred style to use 'd==0' in narrative English in the edits (twice), rather than d=0? d is not a variable (although it could be represented by a character variable). Reply from the editor: I take your point, but actually I don't like "[with] d=0" much either; "[with] d equal to zero" would be better I think, and matches the wording in the later clause better. .................................................................... F08/0056 Corbett reason for NO vote: I continue to oppose this interpretation. I think the functionality it provides is too little to be worth the risk of misuse. I have yet to think of a case where I would want use the functionality provided. I can easily imagine cases where the wrong variable is used in the SOURCE= specifier and the error goes undetected. .................................................................... F08/0057 Muxworthy comment: It would be more in accordance with previous practice to number the new constraint C1504a. [Corrigendum 1 uses both upper and lower case suffices for new constraints. Presumably lower case is preferred.] Reply from the editor: I agree. I think we should use lower case for the suffices. Snyder comment: Does this need a compatibility caveat in 1.6? .................................................................... F08/0058 Corbett reason for NO vote: I continue to believe that removal of this restriction in Fortran 90 was deliberate. The restriction in FORTRAN 77 was intended to make it easier to write one-pass compilers. Many such restrictions were removed in Fortran 90. The restriction serves no purpose now. The restriction in the FORTRAN 77 standard is in paragraph 2 of Section 15.7.4. Snyder comment: Replace "program" in the first paragraph of the answer with "module". .................................................................... F08/0059 Long comment: The last sentence of the Answer should begin "Edits are" instead of "An edit is". There are two edits. .................................................................... F08/0063 Cohen comment on Corbett NO vote: > This interpretation upends the meaning of item (5) in Clause 10.7.2.1. > A similar argument could be made against any application of item (5). I disagree. F6.1 makes sense and according to item (5) will produce asterisks for large values e.g. 1e8. E10.2E2 makes sense and according to item (5) will produce asterisks for large enough values e.g. 1d200. F4.5 does not make sense. The standard does not make sense of F4.5, so it does not say *anything*. It would be a good idea to require F4.5 to produce 4 asterisks in the next revision, sure looks like a wart to me. Corbett reason for NO vote: This interpretation upends the meaning of item (5) in Clause 10.7.2.1. A similar argument could be made against any application of item (5). I am surprised anyone thinks that editing under an F4.5 edit descriptor should be permitted to produce anything other than four asterisks. Under the proposed interpretation, I have no idea what should be expected as a result of editing under an F4.4 edit descriptor. Maclaren comment: This is a good candidate for improvement in a future revision. .................................................................... F08/0064 Corbett comment: There should be no "their" in the sentence This relies on their being a difference between "no value" and "zero-length value". Long comment: Perhaps the original should have been "there". .................................................................... F08/0065 Maclaren comment: Upon checking on what this meant, I believe that the lists in tables 14.1 and 14.2 contain some errors. Specifically, I can see no reason for IEEE_GET_ROUNDING MODE and IEEE_GET_UNDERFLOW MODE not to be pure (but they aren't), but I can see good reasons for IEEE_SET_FLAG and IEEE_SET_HALTING_MODE not to be (and they are). However, even if true, that is a matter for a future revision. .................................................................... F08/0067 Corbett comment: I agree that the program should not be standard conforming, and I agree that the edit provided ensures that it is not. I do not agree with the rationale given for the answer. Whether the invocation of SUB2 in SUB1 does or does not require the shape of A depends on the argument passing conventions used by the processor. While all or almost all existing Fortran processors use copy-in/copy-out to pass the array argument to SUB2, the Fortran standard does not require a conforming processor to use copy-in/copy-out. Other argument passing conventions exist that do not require making a copy in this case. Those conventions do not require the shape or size of A to be known. Snyder comment: To clarify the answer, it would be helpful to replace ", and therefore the" by "because, in the absense of an explicit interface, the corresponding dummy argument is assumed to be nonpolymorphic, and therefore a copy consisting only of the declared type part of the actual argument is required. The" .................................................................... F08/0068 Long comment: I think that the second bullets in each of the two edits is trying to say that the dummy argument becomes associated with the part of the actual argument (target) with the declared type of the dummy argument. The current "declared type part of that actual argument (target)" could be confused to refer to the declared type of the actual argument. .................................................................... F08/0072 Long comment: It would be helpful to supply more explanation than just "No." for the answer. Specification of rank is allowed for a FINAL subroutine dummy argument. Why should corank be different? Reply from the editor: Because we did not intend it to do that, and it would not make any sense. We don't need to write a treatise on language design, we just need to answer the question. "No" conveys the entirety of "we did not intend to do that", which is the only thing we can easily agree on. Doing anything more would not only be difficult to craft all those language-design- principlely words and getting agreement all the way up and down the committees, but would delay answering the actual question and fixing the standard. (Actually rank specification would not have made a lot of sense either if F2003 had had impure elemental procedures... it was merely papering over that particular deficiency in the language.) .................................................................... F08/0073 Cohen comment: The note about the edit being unnecessary if F08/0059 passes should be an instruction not to make the edit in that case. Reid comment: I hope we pass F08/0059 and do not make the edit in F08/0073. .................................................................... --------------090506090606050504040204--