Hi,

Thanks Greg for the insightful question.

> You can't write a general interface to MPI using C interop
There are two kinds of implementation-dependence: dependence on the MPI 
implementation, and dependence on the Fortran compiler used. It is the 
second which I seek to avoid as much as possible, by using *standard* 
features of both Fortran and C, rather than hacks or compiler-specific 
C code. The first cannot be completely avoided, of course. For example, 
the values of all the MPI_??? constants are implementation-dependent. 
In the OpenGL example I provided, there was a little C file that 
printed the values of the OpenGL constants in the C header files. These 
are then used in the Fortran module. I am hoping this process can be 
automated using Perl scripts and such. The *majority* of the Fortran 
"binding" is just interfaces and such, which *are* completely 
implementation-dependent, in both meanings of the phrase.

> the types are not specified in the standard, but are
> implementation-dependent. 
What types are you talking about? You mean things like MPI_Datatype? The 
present Fortran "binding" makes them integers. This is *horrible*, 
non-standard, and simply *bad*. So clearly one needs to do better. If 
MPI_Datatype is a C struct in the C header files, the above Perl script 
could make an equivalent Fortran TYPE (with BIND(C)) declaration. If it 
is a typedef, sadly, there is no standard-conforming way to do it at 
present. We had TYPEALIAS in Fortran in drafts but then it was pulled 
out just before the standard got finalized, despite my best attempts to 
keep it in for purposes of C interop. If users actually care(d) and 
show interest in these things then maybe they would be easier to do. If 
user say "Oh, I don't care, the FORTRAN 77 interface is just fine with 
me, it works great [you said it!]", then J3 is of course not going to 
care enough to actually think about something like MPI bindings.

> The existing Fortran77 MPI interface works great 
I would contest "great", see points above. First, it is non-conforming, 
second, it uses INTEGER handles in completely inappropriate ways, 
third, it has several known "Fortran issues", actually mandating a 
separate chapter of the MPI-2 standard.

> why would you throw away working code?
This was/is a very important point to me, and I have spent considerable 
time arguing for it in J3. First of all, I am not proposing that code 
be thrown away. It is *possible* to change the binding (the interfaces) 
yet not affect at all the working of code that uses those interfaces. A 
typical example is adding the VALUE attribute. You can add it to the 
dummy but the way you actually pass the actual is unaffected almost 
always.

Sadly, this kind of "backward-compatible" binding can be done relatively 
easily with OpenGL, but much harder to do with MPI. Let me give a 
(fake) example:

int MPISend(void *buffer);

The official Fortran "binding" lies and makes one pass arrays of 
arbitrary type in non-conforming ways:

real :: x(100)
integer :: y(100)
call MPISend(x)
call MPISend(y)

In Fortran 2003, for *strict* conformance, one has to do:

interface
	subroutine MPISend(buffer) bind(C,name="MPISend")
		type(c_ptr), value :: buffer
	end subroutine
end interface

real, target :: x(100)
integer, target :: y(100)
call MPISend(c_loc(x))
call MPISend(c_loc(y))

I wrote proposals to J3 about a feature that would allow the code to be 
the same as with the old "FORTRAN 77" binding, using a new attribute 
called ADDRESS:

interface
	subroutine MPISend(buffer) bind(C,name="MPISend")
		type(c_ptr), address :: buffer
	end subroutine
end interface

This is similar to the way VALUE attribute is much better than the old 
%VAL in compilers---put it in the interface instead of the caller. The 
TARGET attribute is a little trickier due to historical complexities 
with it, but IMO it is not impossible to eliminate the need for target 
on the actual arguments...

Sadly, this was not accepted for inclusion in Fortran 2008. Few seemed 
to actually care... Again, if users show interest and contribute to the 
discussion than maybe something can be done to convince the Fortran 
committee and also to make sure that better solutions are found.

Best,
Aleks
(both a user and a committee member)