(j3.2006) MPI usage problems in Fortran

[Bill Long]

Lionel, Steve wrote:
>
> It seems oddly redundant to me to add a LANG= keyword to BIND where the
> first "parameter" to BIND is already a language name. 

The current bind(c) semantics just says to use the C calling 
conventions.  The routine itself may very well be written in Fortran - 
the usual case where you have a Fortran library that you want to make 
accessible to C programmers.  The bind(c) by itself makes no implication 
that the routine is written in C.  The intent of the lang="C" specifier 
is to say the routine is, indeed, written in C.  This allows you to make 
rules for the interface that would have no semantics if the routine were 
written in Fortran.


> I also have
> difficulty with the concept of a specifically named derived type
> (C_VOID) that has special properties and that cannot be otherwise
> expressed in Fortran.
>
> I had earlier proposed to the MPI-3 list a VOID attribute that would be
> allowed to appear only in an dummy argument declaration in an interface
> body, but I was told that this approach had been rejected earlier by the
> Fortran committee (or perhaps that it "would not fly"). 

Same issue as above. Without the lang= specifier, you have to assume the 
function is written in Fortran, and the VOID attribute would be usable 
there.  My initial impression is that adding an attribute to the Fortran 
base language that cannot be used in a Fortran program would be more 
disruptive that defining a specific derived type.  The later does not 
change anything in the base language syntax, and thus is easier to 
implement in the standard.

If you had a VOID attribute, what type declarations could it be used 
with?  What are the semantics?


> I did not
> understand the objections - it seemed to me a much cleaner approach than
> what is effectively a new intrinsic data type.  It is also the semantics
> already implemented as extensions by several vendors (with varying
> syntax.)
>   

I know of multiple vendors that have a directive that will cause the 
interface to ignore type/kind/rank mismatches.  Is this what you are 
talking about?  One of the options we did discuss was to make this 
directive into an attribute, in which case it would be valid for both 
Fortran and C callees.  The details got messy, though.  The directive 
version is useful, though.  We use it for MPI interfaces, as I suspect 
others do.


> Whatever happens, C interop needs to deal with the "void" concept in
> some form or other, or else a large class of C code cannot be cleanly
> used from Fortran.
>   

Agreed.

Cheers,
Bill

> Steve Lionel
> Developer Products Division
> Intel Corporation
> Nashua, NH 
>
>
>
>   

-- 
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