From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Oct 7 11:22:23 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 E1FE63568F3; Fri, 7 Oct 2011 11:22:22 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mk-filter-4-a-1.mail.uk.tiscali.com (mk-filter-4-a-1.mail.tiscali.co.uk [212.74.100.55]) by www.open-std.org (Postfix) with ESMTP id 5902C3567FE for ; Fri, 7 Oct 2011 11:22:21 +0200 (CEST) X-Trace: 673548184/mk-filter-4.mail.uk.tiscali.com/B2C/$b2c-THROTTLED/TalkTalk_Customer/92.21.171.120/None/John.Reid@stfc.ac.uk X-SBRS: None X-RemoteIP: 92.21.171.120 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:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIBAH7Djk5cFat4/2dsb2JhbAAMOA6mMYRUAQEEUyURLBYPCQMCAQIBRQYBDAgCwCGHMgSOUIUfhRaLejg X-IronPort-AV: E=Sophos;i="4.68,501,1312153200"; d="txt'?scan'208";a="673548184" Received: from host-92-21-171-120.as13285.net (HELO [127.0.0.1]) ([92.21.171.120]) by smtp.tiscali.co.uk with ESMTP; 07 Oct 2011 10:22:20 +0100 Message-ID: <4E8EC4CB.9060608@stfc.ac.uk> Date: Fri, 07 Oct 2011 10:22:19 +0100 From: John Reid User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1 MIME-Version: 1.0 To: John.Reid@stfc.ac.uk, WG5 Subject: WG5 letter ballot 2 on Fortran 2008 interpretations References: <20111004153447.406F03568EB@www.open-std.org> <20111004153917.DC4653568F7@www.open-std.org> <20111004160122.69DAE3568FB@www.open-std.org> <20111004162557.A588735690A@www.open-std.org> <20111004165020.0B17135690A@www.open-std.org> In-Reply-To: <20111004165020.0B17135690A@www.open-std.org> Content-Type: multipart/mixed; boundary="------------070107050406050809040603" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------070107050406050809040603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit WG5, Here is the preliminary result of the second WG5 interps ballot. However many yes votes we get subsequently, those with the preliminary result N are likely to be N in the final rssult, too, so it would be helpful if J3 works on them next week. Malcolm says he is desperately busy with a work deadline and has asked for a longer extension. I am hoping to interact with him by email re the interop TS next week and do not want the interps to be competing for his time. I have therefore decided to extend the vote by another week to make the new deadline 0900 UK time on Wednesday, 19 October 2011 This is definitely the last extension. Cheers, John. --------------070107050406050809040603 Content-Type: text/plain; name="N1884.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="N1884.txt" ISO/IEC JTC1/SC22/WG5 N1884 Preliminary result of the interpretations ballot 2, N1877 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 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 Y Y Y Y Y Y Y Y Y C F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ 0031 0032 0033 0034 0035 0036 0037 0038 0039 0040 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 N Y Y Snyder N Y Y Y Y Y Y Y Y N Result N C Y Y Y C Y N Y Y F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ 0042 0043 0044 0046 0047 0049 0050 0051 0052 0053 0054 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 Y Y C Y C Y Y Y C C Comments and reasons for NO votes .................................................................... F08/0026 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/0030 Reid comment: The final edit is in 10.4 p8. .................................................................... F08/0031 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 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 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. Reid NO vote I agree that it is desirable to describe all the functions with optional DIM arguments as a pair of specifics, one with the argument and one without. Doing this comprehensively makes F08/0003 redundant. It would be better to declare F08/0003 redundant and include all the edits here. There is no need for many of the edits in F08/0003. A bigger change in 13.2.4 p1 is needed. I suggest: [13.2.4p1 316:24-26] Replace the two sentences "These functions ... dummy arguments" by "An added DIM argument specifies the dimension to be reduced." .................................................................... F08/0040 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 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/0046 Muxworthy comment: The edit should be to page xv. Reid comment: The edit is on page xv. .................................................................... F08/0049 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 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? --------------070107050406050809040603--