(j3.2006) (SC22WG5.3588) OPTIONAL arguments and C interop
Wed Jul 16 16:36:36 EDT 2008
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
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.
> 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
More information about the J3