<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>We just had a productive teleconference regarding Fortran MPI 3.0 bindings. I summarize the discussion below.</div><div><br></div><div>Cheers,</div><div>Craig</div><div><br></div><br><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>Agenda:<br><br>1. Implications of new TYPE(*) and DIMENSION(..) syntax in Fortran.</div></blockquote><div><br></div><div>TYPE(*), DIMENSION(*) will be used for array actual arguments to C void* and TYPE(*) will be used for scalar actual arguments. Many compilers have compiler directives to achieve this now so there may not be an excessively long wait for this syntax to appear in compilers. It shouldn't make a difference to the users as they won't have to change their codes in any case, this will only appear in the interface definition.</div><br><blockquote type="cite"><div><br>2. What KIND parameter to use for integer arguments.</div></blockquote><div><br></div><div>This topic took up most of the discussion.</div><div><br></div><div>There are two sides to this:</div><div>1. From a users perspective it would be very convenient to use default integers, especially for constants.</div><div>2. However from an implementation perspective, this becomes tricky because it would require many more interfaces to be defined to handle all of the different potential kind values.</div><div><br></div><div>I think the resolution of this needs wider participation. I was persuaded that we should explicitly specify a kind value, C_INT, in most cases. This will work in most cases for default integer actual arguments unless the user specifies compiler options to change the default size. When the user does this he/she should expect some things to break and take the steps to correct the problem.</div><div><br></div><div>Some arguments, for example, the count argument in MPI_Send should require a kind large enough to store a pointer.</div><br><blockquote type="cite"><div><br>3. Multiple Fortran interfaces? Subroutine and function interfaces (since we have to have wrappers for subroutines anyway...)</div></blockquote><div><br></div><div>The Fortran standard says that generic resolution shall be used either for subroutines or functions but not for both. Therefore, we will specify only subroutine interfaces.</div><br><blockquote type="cite"><div><br>4. What to do about a high-level interface that is truly Fortran and not low-level C?</div></blockquote><div><br></div><div>I was the only one really in favor of this. This option would use the DIMENSION(..) syntax and would require a lot of work on the implementers part.</div><br><blockquote type="cite"><div><br>5. Optional arguments?</div></blockquote><div><br></div><div>Yes, the error status parameter should be optional. If other parameters were made optional (e.g. MPI_COMM) the user may be required to supply the argument name in the call, depending on what arguments were left out.</div><div><br></div><div>The decision was that ONLY the error status be optional. However, is it a bad think to allow the user to drop some arguments and specify others by name?</div><div><br></div></div></body></html>