From owner-sc22wg5@open-std.org Wed Mar 17 14:04:22 2010 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 5DA23C178DF; Wed, 17 Mar 2010 14:04:22 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mail1.cray.com (mail1.cray.com [136.162.62.100]) by www2.open-std.org (Postfix) with ESMTP id 52B80C178D9 for ; Wed, 17 Mar 2010 14:04:18 +0100 (CET) Received: from beaver.us.cray.com (beaver.us.cray.com [172.30.74.51]) by mail1.cray.com (8.13.6/8.13.3/gw-5323) with ESMTP id o2HD4Esp023866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Mar 2010 08:04:14 -0500 (CDT) Received: from cfexcas01.americas.cray.com (cfexcas01-2.us.cray.com [172.30.74.227]) by beaver.us.cray.com (8.13.8/8.13.3/hub-5273) with ESMTP id o2HD4Dje001995; Wed, 17 Mar 2010 08:04:13 -0500 Received: from cf-vpn-192-168-239-48.us.cray.com (192.168.239.48) by cfexcas01.americas.cray.com (172.30.74.226) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 17 Mar 2010 08:04:12 -0500 Message-ID: <4BA0D355.6000502@cray.com> Date: Wed, 17 Mar 2010 08:04:21 -0500 From: Bill Long Reply-To: Organization: Cray Inc. User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: fortran standards email list for J3 Cc: WG5 Subject: Re: (j3.2006) (SC22WG5.4222) What shall we do with the broken feature? References: <20100317081909.9DEC5C178D9@www2.open-std.org> In-Reply-To: <20100317081909.9DEC5C178D9@www2.open-std.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Cray-VirusStatus: clean Sender: owner-sc22wg5@open-std.org Precedence: bulk Malcolm Cohen wrote: > The facility of being able to pass a null pointer or unallocated allocatable to > an optional nonpointer nonallocatable dummy argument and have that treated as > being an absent dummy argument is broken as follows. > > (i) All of the optional DIM arguments to the intrinsic functions that change the > rank are qualified with "The corresponding actual argument shall not be an > optional dummy argument.". Previously it was not permitted to pass a null > pointer here, now it is permitted and gives a runtime-varying rank depending on > the association status of the pointer. E.g. PRODUCT(matrix,pointer_to_dim) is > rank 1 if pointer_to_dim is associated and rank 0 if it is not. 20 functions > have a prohibition against optional dummy arguments, but in several of those it > is an unnecessary prohibition so fewer than 20 would be necessarily affected. > > (ii) This feature appears to change the results of ASSOCIATED when TARGET is a > null pointer. This does not appear on the surface to be fixable other than by > specifying that the feature does not apply to this particular intrinsic > function, which might be confusing. > > (iii) Minor: The performance of a few intrinsic functions such as MAX when some > arguments are pointers is adversely affected. > > (iv) Nitpick: the description in the Introduction omits the unallocated > allocatable case. > > How should we address the problem? > (1) fix the DIS by deleting the feature (I don't think we have a mandate for > that though); > (2) fix the DIS by changing the wording; > (2) leave it to be fixed later via interpretation processing (other than the > nitpick which should be done anyway). > > Comments? Given the stage of the standard, I'd put my preference in the reverse of the order above. Using the interp process will give more time to review a solution - there is risk in quick fixes, even ones that seem obvious at the time. We can start processing the interp at the June meeting, to ensure that vendors who are starting implementations get this clarified. As this is a non-trivial feature, we're very late in the schedule, and there are known solutions to the problems noted, I do not think we should delete the feature. As Van has noted, there are some positive uses for it. I agree that the nitpick should be done. The 'new features' list in this standard is, by far, the most useful among recent editions. Cheers, Bill > > Cheers, -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101