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

[Supalov, Alexander]

Thanks. I said "certain" rather than "eternal" beauty, so I'm for changing the interface if necessary in a controlled manner. "Controlled" here means that while chasing the ever evolving Fortran standard, we should not lose valuable aspects of the earlier MPI Fortran interface, or at least lose it without due consideration and ROI analysis.

One of those virtues was an essential ABI compatibility by design within the Fortran interface of any particular MPI. As soon as anything but a pointer to the object internals creeps into the handle, this virtue will be gone. Maybe a corresponding advice to impelementors would be appropriate here.

-----Original Message-----
From: mpi3-fortran-bounces at lists.mpi-forum.org [mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Jeff Squyres
Sent: Wednesday, June 03, 2009 3:21 PM
To: MPI-3 Fortran working group
Cc: Underwood, Keith D
Subject: Re: [MPI3 Fortran] Agenda for MPI3 Fortran Working group next week

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

_______________________________________________
mpi3-fortran mailing list
mpi3-fortran at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.