[MPI3 Fortran] Deprecate mpif.h?

[N.M. Maclaren]

On Mar 5 2010, Bill Long wrote:
>> 
>> I.e., in the long term, all programmers and all programs should convert
>> to MPI3.  But, given that the TR which it will depend on is still under
>> development, "in the long term" means decades.  But there really is no
>> alternative, because the language infrastructure on which the existing
>> MPI interfaces depend is getting increasingly unreliable.
>
>I agree with this, but think it is worth noting that there are two time 
>scales involved.  The long horizon is getting user codes migrated to the 
>new module. This one is the "decades" referred to above.

Yes, that is what I meant.

> There will no 
>doubt be a very long tail.  The shorter time scale is for availability 
>of compilers that incorporate the features of the TR. Although it is 
>still under development, it is pretty far along.  Recent changes will 
>make the implementation more work,  but I still expect to see compilers 
>that support the TR in 2011 (as opposed to my previous expectation of 
>the end of this year).

Perhaps.  There is still a great deal of work to do on it, and we didn't
even address all of the comments on the ISO Email ballot in Las Vegas,
and some of those are very fundamental.

> The TR features can be implemented on top of an 
>existing Fortran 2003 compiler - it is not necessary for the vendor to 
>implement the new features of Fortran 2008 first.  It is not even 
>required that all of Fortran 2003 be implemented before the TR.  You 
>really just need the support for C interoperability and allocatable 
>dummy arguments from Fortran 2003, and most compilers already support 
>those features.

Yes.  That's not the problem.

A bigger one is how to bind the various models together.  For example,
with the current TR's approach, you cannot have a single MPI function
that takes both assumed-size array arguments (which are heavily used)
and assumed-shape/assumed-rank ones.  MPI is going to have to decide
how to handle that one.

Similarly, MPI is going to have to address the fact that the TR doesn't
help with using Fortran derived types on heterogeneous clusters.  And
what to do about one-sided transfers (ugh) - actually, those are going
to be a BIG semantic problem with the forthcoming C++ and C standards
as well.

Regards,
Nick Maclaren.