[MPI3 Fortran] Deprecate mpif.h?

[N.M. Maclaren]

On Mar 7 2010, Bill Long wrote:
>
>Removing the requirement that types of actual and dummy arguments match 
>is the sole purpose of type(*).   I'm not sure what Nick means by 'the 
>actual type will still have to be passed'.  There is no requirement or 
>intention that some extra information indicating the type of the actual 
>argument be passed to the subprogram.  If an actual argument of type X 
>is passed to a subprogram that has an interface where the corresponding 
>dummy argument is specified type(*), and the subprogram is a function 
>written in C, then the interpretation of the argument in the function 
>should be as if it were declared type X.

This is in the context of MPI choice arguments, where the information is
provided by the MPI datatype argument.

However, in general (i.e. not just MPI), TYPE(*) isn't useful unless you
pass the type some other way - because, except in a few cases, C needs to
know the actual type X to make use of the argument.  And, if an interface
is used only for a single type, why use TYPE(*)?

>Fortran provides various argument passing semantics, which are most 
>often implemented in these three ways [noting that Fortran character 
>arguments are often an exception, and that none of these implementations 
>is specified in the standard]:

Those ARE specified for BIND(C), which is what C people need to know
about.  Fortran's internal mechanisms are quite likely to be different,
in at least some cases, but it would be unnecessarily confusing to
discuss the possibilities.

>1) Call by value.   The actual value of the argument is passed - a 
>concept very much like the same in C, and designed for interoperability 
>with C.

Unlike in C, it's a true read-only value, and not the initial value of
an updatable variable.  C people need to note that.

There are also some arcane properties of C arguments that Fortran does
NOT share.  Specifically, Fortran has no concept of argument promotion,
which could be 'interesting' for REAL/float and sub-INTEGER/int integers.

>> They will be be able to have the ASYNCHRONOUS attribute, which will be
>> extended to support non-Fortran I/O (such as MPI non-blocking
>> transfers).  
>
>Such an "extension" is not in any draft or accepted proposal, and 
>suffers from some technical issues.  However, a program is permitted to 
>imply, via an interface, that an MPI routine is actually implemented 
>using asynchronous I/O, and the compiler will act accordingly, even if 
>no I/O of any kind is involved.

Ah.  I misunderstood the decision, then.  It was a very confused debate.
 
>Specifying an allocatable dummy argument is only interesting if there is 
>some reason to allocate or deallocate memory for it. For the usual 
>send/receive routines this is not an issue.  An actual argument with the 
>allocatable attribute can be associated with an assumed-size dummy (i.e. 
>what is currently done in f77-style interfaces).

Yes, but MPI_Recv could specify that it would allocate or reallocate the
buffer to the appropriate size.  As I said, I don't like this, but some
people do.  MPI needs to consider it, though I would recommend NOT doing
it, on the grounds of least confusion.


Regards,
Nick Maclaren.