From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Oct 19 05:54:27 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 D369E356906; Wed, 19 Oct 2011 05:54:27 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from ns.nag-j.co.jp (218-42-159-107.cust.bit-drive.ne.jp [218.42.159.107]) by www.open-std.org (Postfix) with ESMTP id D4EFB3568E1 for ; Wed, 19 Oct 2011 05:54:26 +0200 (CEST) Received: from 218-42-159-108.cust.bit-drive.ne.jp ([218.42.159.108] helo=Maru6) by ns.nag-j.co.jp with smtp (Exim 4.50) id 1RGNEW-0007GU-7E for sc22wg5@open-std.org; Wed, 19 Oct 2011 12:54:24 +0900 Message-ID: <0ADDF006C3EE42A081C8151E7A705693@Maru6> From: "Malcolm Cohen" To: "WG5" References: <20110907091150.AA67F3568C0@www.open-std.org> In-Reply-To: <20110907091150.AA67F3568C0@www.open-std.org> Subject: Re: [ukfortran] (SC22WG5.4522) Second WG5 ballot on interpretations Date: Wed, 19 Oct 2011 12:54:26 +0900 Organization: =?UTF-8?B?5pel5pysTkFH?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0208_01CC8E5E.3BDA8B30" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0208_01CC8E5E.3BDA8B30 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit Attached is my vote on the interpretations. May I bring people's attention to my comments on F08/0038. My feeling is that this has not had adequate informed discussion... Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo. ------=_NextPart_000_0208_01CC8E5E.3BDA8B30 Content-Type: text/plain; format=flowed; name="ballot2.txt"; reply-type=original Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ballot2.txt" he following Fortran 2003 interpretations are being balloted: Yes No Number Title -Y- --- F08/0021 STORAGE_SIZE and unlimited polymorphic -Y- --- F08/0022 DO CONCURRENT and file i/o -Y- --- F08/0023 DO CONCURRENT and POINTER -Y- --- F08/0024 Dummy arguments of impure elemental procedures -Y- --- F08/0025 DO CONCURRENT and ALLOCATABLE -Y- --- F08/0026 DO CONCURRENT and output interleaving -Y- --- F08/0027 ATOMIC_REF example -Y- --- F08/0028 Does a procedure reference cause loop termination? -Y- --- F08/0029 G0 edit descriptor and floating-point output -Y- --- F08/0030 Unlimited format repeat effects -C- --- F08/0031 PURE INTENT(OUT) finalization -Y- --- F08/0032 PURE FUNCTION result finalization -Y- --- F08/0033 PURE polymorphic finalization -Y- --- F08/0034 ELEMENTAL INTENT(OUT) finalization -Y- --- F08/0035 Maximum value for SHIFT argument to SHIFTL and SHIFTR -Y- --- F08/0036 NORM2 example in Annex C -Y- --- F08/0037 PROCEDURE POINTER vs PROTECTED --- -N- F08/0038 Are pointless restrictions on DIM arguments intended? -Y- --- F08/0039 Many-one vector subscript usage --- -N- F08/0040 MOVE_ALLOC for coarrays --- -N- F08/0042 SOURCE= questions -Y- --- F08/0043 Executing a type-bound procedure on a coindexed object -Y- --- F08/0044 Resolving the type of a coarray or coindexed object -Y- --- F08/0046 VALUE attribute restrictions -Y- --- F08/0047 public generic with same name as private type -Y- --- F08/0049 ELEMENTAL functions with nonconstant type parameters -Y- --- F08/0050 Ordering requirements on definition of specification functions -Y- --- F08/0051 Pure procedure arguments with VALUE -Y- --- F08/0052 Private type-bound procedures -Y- --- F08/0053 Restrictions on generic declarations, generic resolution --- -N- F08/0054 Requirements for needing an explicit interface F08/0031 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. F08/0038 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. F08/0040 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. F08/0042 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 ". F08/0054 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." ------=_NextPart_000_0208_01CC8E5E.3BDA8B30--