From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Oct 19 14:43:36 2011 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 5DE36356914; Wed, 19 Oct 2011 14:43:36 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from engine19-1277-1.icritical.com (engine19-1277-1.icritical.com [93.95.13.253]) by www.open-std.org (Postfix) with SMTP id 92159356911 for ; Wed, 19 Oct 2011 14:43:33 +0200 (CEST) Received: (qmail 16156 invoked from network); 19 Oct 2011 12:43:32 -0000 Received: from localhost (127.0.0.1) by engine19-1277-1.icritical.com with SMTP; 19 Oct 2011 12:43:32 -0000 Received: from engine19-1277-1.icritical.com ([127.0.0.1]) by localhost (engine19-1277-1.icritical.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 16126-01 for ; Wed, 19 Oct 2011 13:43:30 +0100 (BST) Received: (qmail 16138 invoked by uid 599); 19 Oct 2011 12:43:30 -0000 Received: from unknown (HELO exchhub03.rl.ac.uk) (130.246.236.11) by engine19-1277-1.icritical.com (qpsmtpd/0.28) with ESMTP; Wed, 19 Oct 2011 13:43:30 +0100 Received: from jkr.cse.rl.ac.uk (130.246.9.202) by exchsmtp.stfc.ac.uk (130.246.236.18) with Microsoft SMTP Server id 14.1.289.1; Wed, 19 Oct 2011 13:43:28 +0100 Received: from jkr.cse.rl.ac.uk (localhost.localdomain [127.0.0.1]) by jkr.cse.rl.ac.uk (Postfix) with ESMTP id 0918E560D5; Wed, 19 Oct 2011 13:43:29 +0100 (BST) Message-ID: <4E9EC5F0.70902@stfc.ac.uk> Date: Wed, 19 Oct 2011 13:43:28 +0100 From: John Reid Reply-To: Organization: Rutherford Appleton Laboratory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090908 Fedora/1.1.18-1.fc10 SeaMonkey/1.1.18 MIME-Version: 1.0 To: WG5 Subject: Interps ballot 2 References: <4E8C2654.7080606@stfc.ac.uk> In-Reply-To: <4E8C2654.7080606@stfc.ac.uk> Content-Type: multipart/mixed; boundary="------------070807070302060003000908" Received-SPF: None (EXCHHUB03.fed.cclrc.ac.uk: John.Reid@stfc.ac.uk does not designate permitted sender hosts) X-Virus-Scanned: by iCritical at engine19-1277-1.icritical.com Sender: owner-sc22wg5@open-std.org Precedence: bulk --------------070807070302060003000908 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit WG5, Here is a draft of the result of the result of the second interps ballot. Please let me know ASAP if you have any comments, particularly if you find any errors in the records of your views. Best wishes, John. -- Scanned by iCritical. --------------070807070302060003000908 Content-Type: text/plain; name="N1889-1.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="N1889-1.txt" ISO/IEC JTC1/SC22/WG5 N1889-1 Result of the interpretations ballot 2, N1877 The result in N1878 for F08/003 is changed to C, in view of the comment from Reid, see below. 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. F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ 0021 0022 0023 0024 0025 0026 0027 0028 0029 0030 Bader Y Y C Y Y Y Y Y Y Cohen Y Y Y Y Y Y Y Y Y Y Corbett C Y Y Y Y C Y Y N Y Long Y Y Y Y Y N Y Y Y Y Muxworthy Y Y Y Y Y Y Y Y Y Y Reid Y Y Y Y Y Y Y Y Y C Snyder Y Y Y Y Y Y Y Y Y Y Result C Y C Y Y C Y Y N C F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ 0031 0032 0033 0034 0035 0036 0037 0038 0039 0040 Bader Y Y Y Y Cohen C Y Y Y Y Y Y N Y N Corbett N N Y Y Y Y Y N Y Y Long N C Y Y Y Y Y N Y Y Muxworthy Y Y Y Y Y C Y C Y Y Reid Y Y Y Y Y Y Y Y Y Y Snyder N Y Y Y Y Y Y Y Y N Result N N Y Y Y C Y N Y N F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ 0042 0043 0044 0046 0047 0049 0050 0051 0052 0053 0054 Bader N Y Y Y Y Cohen N Y Y Y Y Y Y Y Y Y N Corbett N Y Y Y Y C Y Y Y Y N Long N Y Y Y Y Y Y Y Y Y C Muxworthy Y Y Y C Y Y Y Y Y C Y Reid N Y Y C Y C Y Y Y C Y Snyder N Y Y Y Y Y Y Y Y C Y Result N N Y C Y C Y Y Y C N Comments and reasons for NO votes .................................................................... F08/0003 Reid comment: Considering F08/0038 has made me aware of the merit of rewriting intrinsics with an optional DIM argument as a pair of overloaded procedures. I am therefore no longer opposed to the acceptance of F08/003, though I would like to suggest adding this to the ANSWER. "This is done as far as possible by rewriting each procedure as a pair of overloaded procedures, but this cannot be done for COUNT, LBOUND, LCOBOUND, UBOUND, or UCOBOND because calls to them might become ambiguous." .................................................................... F08/0021 Corbett comment: I agree that a comma should be added after "type parameters" in the edited form of the third sentence of 13.7.16p3. A comma should also be added following "polymorphic" in the second sentence. .................................................................... F08/0023 Bader comment: The wording for the suggested replacement text appears a bit strange to me. It is maybe more complicated than necessary. Would not "A pointer that is used in any iteration either shall be previously pointer-assigned, allocated, or nullified in the same iteration or shall not have its pointer association changed during any other iteration." be sufficient? Cohen email response to Bader: The answer is no, unless you are mentally excluding a set of uses from "used" - and in that case it is not clear which uses you are excluding! That's why the edit spells out the exclusions. I will agree the words are a bit clunky, but making them more vague in the hope that everyone agrees on the unstated assumptions is not an improvement. .................................................................... F08/0026 Corbett comment: The conditional clause at the start of the new paragraph added by the second edit contributes nothing. The simple sentence "The ordering between records written by different iterations is indeterminate." has the same meaning and is easier to understand. Long NO vote: The example for Q1 shows output in the other order from what would occur for sequential execution of the loop. Q1 asks if allowing this was intentional. A1 says No, it was not intentional. Yet, the edit supplied says that the output is, in fact, allowed. I think that the answer A1 should be Yes. The edit is still desirable as a response to Q2/A2. .................................................................... F08/0029 Corbett NO vote: I agree that the word "reasonable" should not appear in the Fortran standard. The first two proposed edits should be incorporated. The third edit should not be adopted. I object to the third edit on general grounds. The issues dealt with in the third edit should be matters of "quality of implementation." I see no reason for the Fortran standard to restrict implementors' choices in this area. I also object to the third edit on specific grounds. The proposed edit makes no provision for nonzero scale factors. If a nonzero scale factor is in effect, an implementation might reasonably choose a value of d that is outside the range specified by the edit, if only to avoid the scale factor being outside the allowed range of values. The phrase and shall not be no more than two larger than the maximum number of digits that might be required to distinguish between two different machine numbers of the kind of the internal value. should say either "any" between "between" and "two", or should say "all pairs of" instead of "two." .................................................................... F08/0030 Reid comment: The final edit is in 10.4 p8. .................................................................... F08/0031 Cohen comment: I cannot understand Bill Long's NO vote. The proposed constraint is on the pure procedure - of course the INTENT(OUT) attribute on its own dummy argument is visible. His proposed wording improvement is too strict: if there is only a FINAL subroutine with a scalar argument but the dummy argument is rank 3, there is no problem with the pure procedure. In any case, he is wrong about "such that" is vague - it is very precise and in fact that wording is already in use throughout the standard. Van points out that if F08/0033 fails, then F08/0031 will also have to fail. This does not seem to be a problem since no-one is voting against F08/0033. Corbett NO vote: I agree with Van that the constraint cannot be a constraint unless F08/0033 (or something else like it) passes. My vote also should be changed to "Y" if F08/0033 passes. Long NO vote: The proposed constraint requires that the INTENT(OUT) attribute on the dummy argument be visible to the code that would perform the finalization. This requires that the "as a matter of practicality" condition in the second paragraph of the DISCUSSION in fact always be true. This seems a bit weak for a constraint in the standard. A non-constraint would be better. I also found the wording of the proposed constraint, "shall not be such that..." unnecessarily vague. Something more direct would seem preferred, such as "The type of an INTENT(OUT) argument of a pure procedure shall not specify an impure final subroutine." Snyder NO vote: If a procedure has a polymorphic intent(out) dummy argument, the processor can't know if an impure final procedure would be invoked. Therefore, the specified new constraint (C1277a) can't be a constraint. My answer would be yes if F08/0033 passes. .................................................................... F08/0032 Corbett NO vote: I did not find a prohibition against a PURE function returning a polymorphic result. If there is one that I missed, please change my vote to "Y". Otherwise, the new constraint added by the final edit cannot be a constraint. Long comment: I found the wording of the proposed constraint, "shall not be such that..." unnecessarily vague. Something more direct would seem preferred, such as "The type of the result value of a pure function shall not specify an impure final subroutine." .................................................................... F08/0036 Muxworthy comment: The edit draws attention to the definition of NORM2. This contains a recommendation on computation, at [375:4], which is the only 'recommendation' in subclause 13. Should it not be a Note, or be omitted altogether? .................................................................... F08/0037 Reid comment: The final edit is in 10.4 p8. .................................................................... F08/0038 Cohen NO vote: This interp adds a new feature to the language. This feature was not approved by WG5 or J3 prior to publication. In fact it was not even considered for action as far as I can recall. The pointless restrictions have been pointless since F95, so we have known about them for a long time. Users have no difficulty writing "(od_dim)" or "od_dim+0" to pass an optional dummy DIM to these functions. The standard is not ambiguous or in error. It is completely inappropriate to add new features to the language by stealth in between revisions. Much though I am in favour of this feature in itself as a feature, it should be a candidate for the next revision, not an interp. If the will of WG5 is to add this new feature to the language by interp, there needs to be an edit to add it to the new feature list in the introduction. Something like "Intrinsic reduction functions now accept, for the DIM argument that specifies which dimension to reduce, an optional dummy argument as the actual argument." would suffice. Corbett NO vote: I do not agree that the restrictions on DIM arguments are pointless. While they are not necessary to permit conforming implementations, they simplify code generation and allow more efficient code to be generated in some cases. Cohen email response to Corbett: No they don't. Appearance of a previously-prohibited optional dummy with this interp has precisely the same meaning as it appearing parenthesised would, i.e. there is no passing-on of the optionality. Since there is no passing-on of the optionality (an absent one is not permitted), you will need a concrete counter-example to demonstrate different semantics. Long NO vote: The text in 13.2.4, on which the subsequent edits depend, relies on a poorly defined concept of "reduction". In particular, some of the "reductions" that are cited in the edits are not what people normally think of as reductions (i.e. ones that return a result that is the same type as the input). It might be better in 13.2.4 to refer to Transformational functions that have a DIM argument. That is unambiguous. It would also cover the cases that currently would not be considered "reductions": FINDLOC, MAXLOC, MINLOC, ALL, ANY, PARITY, and THIS_IMAGE. Also, the COUNT intrinsic [338:31] seems to be missing from the list. Seems like an oversight. Muxworthy comment: Yes to the principle. I have not checked the edits pending the outcome of F08/0003. .................................................................... F08/0040 Cohen NO vote: I agree with Van. The functionality of MOVE_ALLOC was provided by an intrinsic procedure rather than a statement because it seemed like a good idea at the time not to add new statements when not necessary. There was no intention of making it a "second-class citizen". If ALLOCATE and DEALLOCATE of coarrays can be image control statements, then CALL MOVE_ALLOC can be, just as it would be if we had called it the "move allocation statement", e.g. MOVE ALLOCATION FROM(a) TO (b). If MOVE_ALLOC cannot accept coarrays, then ALLOCATE and DEALLOCATE similarly should not accept coarrays for consistency. Snyder NO vote We agreed that MOVE_ALLOC is useful, else we wouldn't have added it. I prefer that a call to it be an image-control statement. .................................................................... F08/0042 Cohen NO vote: The example given in Q2 has a mistake: Change "allocate(x)" to "allocate(x[*])". The proposed change to C633 is defective. In the new C633, After "" insert a comma; after "statement" insert "and have the same rank as the ". Corbett NO vote: I agree with the comments of Long, Reid, and Snyder. Long NO vote The example for Q2: program example2 real,allocatable :: x[:] allocate(x) x = 3 end says that it does not conform to the standard because of 6.7.1.1p4. This is irrelevant. It fails to conform to the standard because it violates C634. The allocate statement is required to be allocate(x[*]) at which point there is no SOURCE= issue involved. At a minimum, the example needs to be replaced with one that illustrates something related to SOURCE=. Reid NO vote I think the new C633 should have the words "and have the same rank as " added at the end, as in the old C633. Snyder NO vote The revised C633 allows the possibility that an that is an array can be allocated without an and a scalar . My vote would be yes if there were an additional sentence something like "If does not appear, shall not be a scalar." .................................................................... F08/0043 Bader NO vote A1 states that the restriction 12.5.2.4p2 [293] is necessary because "the call to the type-bound procedure cannot be resolved without enquiring the type of o_foo%badcomponent on image 2 (because it needs to know how much to copy, and how); this type is not necessarily the same type as that of o_foo%badcomponent on image 1." While true, the same undesirable situation would appear to pertain if the type bound procedure is invoked on an object declared type(badfoo) :: o_foo[*] : ! allocate type components to different dynamic type : ! on different images if (me == 1) call o_foo[2]%op(1) which in turn does not fall under the restriction. This seems to indicate that the restriction (a) does not cover all problematic cases (and I think I'd actually like to see a more precise definition of what is considered problematic) (b) precludes some cases which are harmless At least (a) should be fixed. (b) could be considered as a candidate for the loosening of restrictions planned for within the coarray TS. .................................................................... F08/0046 Muxworthy comment: The edit should be to page xv. Reid comment: The edit is on page xv. .................................................................... F08/0049 Corbett comment: The word "enquiry" in the second edit should be "inquiry". Reid comment: In the first edit, add "constant" before "expression" to avoid ambiguity. .................................................................... F08/0053 Muxworthy comment: In the edit, the reference to (9.6.4.8.3) should immediately follow "arguments". Reid comment: In the edits, remove "Editor:" twice (not our style for corrigendum edits). At the end of the first edit, add "(9.6.4.8.3)" and delete the sentence "Insert ...". Snyder comment: The word "nvocation" in Question (2) should be "invocation". .................................................................... F08/0054 Cohen NO vote: I agree with Bill Long that there needs to be text in 1.6.x to explain the incompatibility with F2003 (even though no processor actually implemented the mistake in F2003). Maybe something like: [24:9-10] 1.6.2p1 "This" -> "Except as identified in this subclause, this"; ". Any" -> "and any". {Makes it a run-on sentence, but avoids repeating "Except as...".} [24:11+] Insert new paragraph "Fortran 2003 only required an explicit interface for a procedure that was actually referenced in the scope, not merely passed as an actual argument. This part of ISO/IEC 1539 requires an explicit interface for a procedure under the conditions listed in 12.4.2.2, regardless of whether the procedure is referenced in the scope." Corbett NO vote: I read paper 02-144, and I agree that it does not provide a justification for adding the phrase "it is referenced and" to the text of 12.4.2.2p1 [279:19]. However, it is not hard to see why Subgroup C chose to add that phrase. Without it, a strict reading of Clause 12.4.2.2 would say that every procedure that meets the conditions of items (2) through (5) must have an interface that is explicit in every scoping unit in the program. I suspect that Subgroup C meant that if a procedure name that satisfies an item in the list in 12.4.2.2 appears in a scoping unit, it shall have an interface that is explicit in the scoping unit. Long comment: This proposes a fix to something that is broken in both F2003 and F2008. Since the change is only in F2008, it then a change from F2003 that should be listed in 1.6.2? --------------070807070302060003000908--