From owner-sc22wg5@open-std.org Wed Jul 16 22:37:23 2008 Return-Path: X-Original-To: sc22wg5-dom6 Delivered-To: sc22wg5-dom6@open-std.org Received: by open-std.org (Postfix, from userid 521) id DA818DDAFB; Wed, 16 Jul 2008 22:37:23 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mail1.cray.com (mail1.cray.com [136.162.0.111]) by open-std.org (Postfix) with ESMTP id 20ED0D6BA8 for ; Wed, 16 Jul 2008 22:37:05 +0200 (CET DST) 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 m6GKacBt011777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Jul 2008 15:36:42 -0500 (CDT) Received: from CFEXFE01.us.cray.com (cfexfe01.us.cray.com [172.30.74.93]) by beaver.us.cray.com (8.13.8/8.13.3/hub-5273) with ESMTP id m6GKabH0017395; Wed, 16 Jul 2008 15:36:37 -0500 Received: from mh-dhcp-172-31-20-57.us.cray.com ([172.31.20.57]) by CFEXFE01.us.cray.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jul 2008 15:36:36 -0500 Message-ID: <487E5BD4.6010605@cray.com> Date: Wed, 16 Jul 2008 15:36:36 -0500 From: Bill Long Reply-To: longb@cray.com Organization: Cray Inc. User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jim Xia CC: sc22wg5@open-std.org Subject: Re: (j3.2006) (SC22WG5.3584) OPTIONAL arguments and C interop References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2008 20:36:36.0374 (UTC) FILETIME=[A453B360:01C8E783] X-Cray-VirusStatus: clean Sender: owner-sc22wg5@open-std.org Precedence: bulk Jim Xia wrote: > > j3-bounces@j3-fortran.org wrote on 07/16/2008 10:47:44 AM: > > > > a) Change the specification to require an extra argument that would > > indicate whether an optional argument was present. This extra argument > > would be hidden in the Fortran interface, but be explicit in the > > corresponding C prototype. (This matches that vendor's Fortran > > convention.) > > > > b) Delete the capability of OPTIONAL arguments in BIND(C) interfaces > > entirely. > > > > > > In the discussion so far, alternative (a) was viewed unfavorably for > > multiple reasons. > > Choice (a) is in no way worse than the original design. I don't > understand why a statement like "alternative (a) was viewed > unfavorably" can be made based on one vendor's implementation vs. > another's. How many Fortran vendors are there in the world at this > point? The reasons for disliking alternative (a) were not based on which compiler vendors would need to do work. The amount of work involved is not great. Its it's a case of one vendor having someone spend a day or so implementing this, or N-1 other vendors doing a similar amount of work each. Rather the objections were, roughly, these two: 1) The current convention used in C matches the original proposal and would hence seem the most natural for C users. 2) The idea of specifying extra hidden arguments for any reason is abhorrent. You end up with a situation where the Fortran interface and the C prototype do not correspond even in the number of arguments. Further, if you have an interface with many optional arguments, intermixed with hundreds of nonoptional arguments, keeping track of which flags go with which arguments (which the C user has to do manually) becomes unmaintainable. Hidden arguments are fine as long as they are always hidden. When you have to expose them, they are a bad idea. > > > However, the choice between keeping the current > > proposal and removing it (alternative b) was not fully discussed. > > Neither were any other alternatives. > > > > Editorial comments on alternative (b): The discussion of OPTIONAL > > arguments in the TR, and associated edits, are a very small fraction of > > the text involved, so removing it is editorially easy. On the other > > hand, this feature was explicitly included in the original mandate for > > the TR, so there should be a significant technical reason for change at > > this point. > > Not able to support OPTIOANL with VALUE attribute is a significant > technical reason. > Part of the goal of the discussion is to get more opinions on whether that is the case or not. We now have your vote. Thanks. Cheers, Bill > > Cheers, > > Jim Xia > > RL Fortran Compiler Test > IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7 > Phone (905) 413-3444 Tie-line 313-3444 > email: jimxia@ca.ibm.com > D2/YF7/8200 /MKM -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120