From owner-sc22wg5@open-std.org Wed Jul 16 22:01:01 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 51BBFDDAFB; Wed, 16 Jul 2008 22:01:01 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 2104 seconds by postgrey-1.18 at pingo.cv.ihk.dk; Wed, 16 Jul 2008 20:00:59 UTC Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.150]) by open-std.org (Postfix) with ESMTP id 87EA6393D9 for ; Wed, 16 Jul 2008 22:00:47 +0200 (CET DST) Received: from e1.ny.us.ibm.com ([192.168.1.101]) by pokfb.esmtp.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6GJPuFb015771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 16 Jul 2008 15:25:56 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6GJPeum013925 for ; Wed, 16 Jul 2008 15:25:40 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6GJPe9E231434 for ; Wed, 16 Jul 2008 15:25:40 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6GJPdlX000624 for ; Wed, 16 Jul 2008 15:25:39 -0400 Received: from d25ml04.torolab.ibm.com (d25ml04.torolab.ibm.com [9.26.6.105]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6GJPd6Q000599; Wed, 16 Jul 2008 15:25:39 -0400 In-Reply-To: <20080716151703.5BDC9D9F76@open-std.org> To: longb@cray.com Cc: sc22wg5@open-std.org MIME-Version: 1.0 Subject: Re: (j3.2006) (SC22WG5.3584) OPTIONAL arguments and C interop X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 Message-ID: From: Jim Xia Date: Wed, 16 Jul 2008 15:25:37 -0400 X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 07/16/2008 15:25:39, Serialize complete at 07/16/2008 15:25:39 Content-Type: multipart/alternative; boundary="=_alternative 006AB77A85257488_=" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 006AB77A85257488_= Content-Type: text/plain; charset="US-ASCII" 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? 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. 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 --=_alternative 006AB77A85257488_= Content-Type: text/html; charset="US-ASCII"
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?


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.


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
--=_alternative 006AB77A85257488_=--