[MPI3 Fortran] Agenda for MPI3 Fortran Working group next week

[Jeff Squyres]

On Jun 3, 2009, at 7:35 AM, Supalov, Alexander wrote:

> 1. Use of intent(IN/OUT/INOUT) for parameters.
>
> AS> Note also a possible bizzare connection to the const buffer  
> modifier matter (#140, https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/140) 
>  that has been pushed back on by most MPI implementors and is likely  
> to become an MPI-3 rather than MPI-2.2 topic. I don't think it would  
> be good if different language bindings were to allow syntactically  
> different things to happen.
>

I don't think there's a danger of that happening here.

> 2. Review of new MPI derived types to be used, for example,
> type(MPI_Comm).
>
> AS> There's certain beauty in the integer handle approach of the  
> current Fortran interface. It specifies pretty clearly that the meat  
> of the object lives outside of the application. With the derived  
> type, implementors might be tempted to put more than a handle into  
> the application space, and then we may have issues with tools,  
> compatibility between different MPI versions, etc.
>

Before the Fortran guys storm in with their replies ;-), I'll mention  
that I think that using integer handles is a horrid idea for Fortran.   
It was done with good reason back in the 90s, but the language has  
evolved such that we can give much better type safety these days.   
I've seen too many customers accidentally use the wrong handle type  
for a parameter and didn't know it because the compiler didn't  
(couldn't) tell them.  C and C++ give this protection -- Fortran can  
too, now, so we should allow, nay, *encourage*, that.

I don't see the problem of allowing an MPI implementation to put more  
information in a language handle (this is already allowed in the C++  
bindings).  Can you explain more specifically what you mean?

> 3. How to handle MPI attributes and extra state variables.  This can
> be done in a very Fortran way as it doesn't have to look the MPI C.
>
> AS> It would be better if the solution resembled C in some way.  
> Having language bindings diverge too far from each other may not be  
> good for usability, after all.
>

Note that INTEGER is already a divergence from C's (void*) arguments  
in this case.

As Bill Gropp clearly stated, the intent for the Fortran bindings here  
is to allow passing a reference to some other, potentially larger,  
data.  Again, INTEGER was used in the 90's because there was no other  
good option.  Now there are better options.  My $0.20: we should  
express this in the language-natural fashion, not fall back to archaic  
INTEGER representation.

> 5. Review what integer kind should be used for things like tags.
> We've previously decided to use default integer kinds except for
> possibly for counts, in which case we would specify a specific kind,
> MPI_COUNT.
>
> AS> Please look into #117 that already proposes MPI_COUNT_KIND (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/117 
> ).
>

Yes, this is exactly what Craig is referring to.  We think that  
MPI_COUNT_KIND is probably the only new INTEGER kind that is  
necessary, but it's worth a closer look to be sure.

-- 
Jeff Squyres
Cisco Systems