(j3.2006) (SC22WG5.3588) OPTIONAL arguments and C interop

[Bill Long]

Jim Xia wrote:
>
> j3-bounces at 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 at ca.ibm.com
> D2/YF7/8200 /MKM

-- 
Bill Long                                   longb at 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