From owner-sc22wg5@open-std.org Wed Mar 17 15:58:21 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 3C8DDC178DF; Wed, 17 Mar 2010 15:58:21 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 493 seconds by postgrey-1.18 at www2.open-std.org; Wed, 17 Mar 2010 15:58:20 CET Received: from outbound003.roc2.bluetie.com (outbound003.roc2.bluetie.com [208.89.132.143]) by www2.open-std.org (Postfix) with ESMTP id 508F7C178D9 for ; Wed, 17 Mar 2010 15:58:19 +0100 (CET) Received: by outbound003.roc2.bluetie.com (Postfix, from userid 8) id 30C5F618005; Wed, 17 Mar 2010 10:50:11 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on outbound003.roc2.bluetie.com Received: from emta003.roc2.bluetie.com (emta003.roc2.bluetie.com [10.200.2.133]) by outbound003.roc2.bluetie.com (Postfix) with ESMTP id F0989618005 for ; Wed, 17 Mar 2010 10:50:10 -0400 (EDT) Received: from Elrond (CPE-75-86-190-39.wi.res.rr.com [75.86.190.39]) (Authenticated sender: craig@ctdedo.com) by emta003.roc2.bluetie.com (Postfix) with ESMTP id C50AE11D0146 for ; Wed, 17 Mar 2010 10:50:10 -0400 (EDT) From: "Craig Dedo" To: "WG5 Mailing List" References: <20100317081909.9DEC5C178D9@www2.open-std.org> <11AB08DC-17EE-49C3-8BEF-546B80E2B908@verizon.net> In-Reply-To: <11AB08DC-17EE-49C3-8BEF-546B80E2B908@verizon.net> Subject: RE: (j3.2006) (SC22WG5.4222) What shall we do with the broken feature? Date: Wed, 17 Mar 2010 09:49:37 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrF2QERoVjQKBhxTbWGmJzXE51KyAABuK8w Content-Language: en-us x-cr-hashedpuzzle: pyM= AKzz Axqo BF64 BLIr B949 FEUl F0Va GMFj Gi5c HRs5 H45J IJ9M JWYl JZGj KtSc;1;cwBjADIAMgB3AGcANQBAAG8AcABlAG4ALQBzAHQAZAAuAG8AcgBnAA==;Sosha1_v1;7;{BA650675-8BC1-422D-A6D0-95191B0431DD};YwByAGEAaQBnAEAAYwB0AGQAZQBkAG8ALgBjAG8AbQA=;Wed, 17 Mar 2010 14:49:35 GMT;UgBFADoAIAAoAGoAMwAuADIAMAAwADYAKQAgACgAUwBDADIAMgBXAEcANQAuADQAMgAyADIAKQAgAFcAaABhAHQAIABzAGgAYQBsAGwAIAB3AGUAIABkAG8AIAB3AGkAdABoACAAdABoAGUAIABiAHIAbwBrAGUAbgAJAGYAZQBhAHQAdQByAGUAPwA= x-cr-puzzleid: {BA650675-8BC1-422D-A6D0-95191B0431DD} Sender: owner-sc22wg5@open-std.org Precedence: bulk Hi Everyone, FWIW, I agree with Bill and Dan. Given the schedule for Fortran 2008 and the complexity of this particular issue, I would STRONGLY argue for fixing via the Interpretations process for all of the mentioned reasons. I would argue strongly AGAINST any kind of quick fix. That said, I would encourage WG5 and PL22.3 to open up the Fortran 2008 Interpretations list immediately and make this issue Fortran 2008 Interpretation #000001. One of the people who discovered or analyzed this issue in depth should write it up and submit it at their earliest convenience. Sincerely, Craig T. Dedo 17130 W. Burleigh Place P. O. Box 423 Mobile Phone: (414) 412-5869 Brookfield, WI 53008-0423 E-mail: USA Linked-In: http://www.linkedin.com/in/craigdedo -----Original Message----- From: j3-bounces@j3-fortran.org [mailto:j3-bounces@j3-fortran.org] On Behalf Of Dan Nagle Sent: Wednesday, March 17, 2010 08:49 To: fortran standards email list for J3 Subject: Re: (j3.2006) (SC22WG5.4222) What shall we do with the broken feature? Hi, I vote with Bill. Quick fixes chance errors, processing an Interp allows time for more in-depth thought. No one is implementing this today, we can take the time to do it right. On Mar 17, 2010, at 4:19 AM, 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? > > Cheers, > -- > ................................Malcolm Cohen, Nihon NAG, Tokyo. > > _______________________________________________ > J3 mailing list > J3@j3-fortran.org > http://j3-fortran.org/mailman/listinfo/j3 -- Cheers! Dan Nagle _______________________________________________ J3 mailing list J3@j3-fortran.org http://j3-fortran.org/mailman/listinfo/j3