From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Sep 28 09:02:55 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 24C863569B0; Fri, 28 Sep 2012 09:02:55 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by www.open-std.org (Postfix) with ESMTP id 4C7353569AF for ; Fri, 28 Sep 2012 09:02:51 +0200 (CEST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8S72nJ4020696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 28 Sep 2012 07:02:50 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8S72mPL025353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Sep 2012 07:02:49 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8S72mFq029147 for ; Fri, 28 Sep 2012 02:02:48 -0500 Received: from [10.132.140.77] (/10.132.140.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 Sep 2012 00:02:48 -0700 Message-ID: <50654B2D.30802@oracle.com> Date: Fri, 28 Sep 2012 00:01:01 -0700 From: Robert Corbett Reply-To: robert.corbett@oracle.com Organization: Oracle America User-Agent: Mozilla/5.0 (X11; SunOS sun4u; rv:6.0) Gecko/20110814 Thunderbird/6.0 MIME-Version: 1.0 To: WG5 Subject: Re: (j3.2006) (SC22WG5.4799) WG5 letter ballot 4 on Fortran 2008 interpretations References: <20120914232724.BB7E5356938@www.open-std.org> <20120925194814.26C3D356934@www.open-std.org> In-Reply-To: <20120925194814.26C3D356934@www.open-std.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Sender: owner-sc22wg5@open-std.org Precedence: bulk The following Fortran 2008 interpretations are being balloted: Yes No Number Title -Y- --- F08/0043 Executing a type-bound procedure on a coindexed object -C- --- F08/0048 Sequence association for coarrays --- -N- F08/0054 Requirements for needing an explicit interface -Y- --- F08/0055 G editing for reals --- -N- F08/0056 Non-polymorphic ALLOCATE with polymorphic SOURCE= -Y- --- F08/0057 Interoperability with empty types --- -N- F08/0058 ENTRY point RESULT variable -Y- --- F08/0059 Auto-targetting requirements -Y- --- F08/0060 Procedure pointer assignment with an EXTERNAL target -Y- --- F08/0061 Description of the CONTIGUOUS attribute misworded? -Y- --- F08/0062 Mixing default initialization with DATA initialization --- -N- F08/0063 G editing to a narrow output field -C- --- F08/0064 STATUS of GET_ENVIRONMENT_VARIABLE -Y- --- F08/0065 Should certain procedures in intrinsic modules be pure? -Y- --- F08/0066 Are certain expressions with pointer initialization constant? -C- --- F08/0067 Passing arrays of extended type objects -Y- --- F08/0068 Pointer association and extended type arrays -Y- --- F08/0069 Which part of an effective argument becomes undefined? -Y- --- F08/0070 Finalization of INTENT(OUT) arguments -Y- --- F08/0072 Final subroutines with corank -Y- --- F08/0073 Polymorphic auto-targetting ------------------------- F08/0048 C 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. ------------------------- F08/0054 N 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. ------------------------- F08/0056 N 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/0058 N 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. ------------------------- F08/0063 N 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. ------------------------- F08/0064 C There should be no "their" in the sentence This relies on their being a difference between "no value" and "zero-length value". ------------------------- F08/0067 C 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.