(j3.2006) MPI usage problems in Fortran

[Craig Rasmussen]

On Mar 21, 2008, at 11:13 AM, Bill Long wrote:

> A couple of comments on the ideas below.
>
> 1) The ASYNCHRONOUS FUNCTION scheme is basically what some people call
> 'futures'.  If we (WG5) want to go that direction, we should consider
> how to do it in general.
>
> 2) Either the async functions, or the proposal to change the rules for
> C_LOC() take the proposal out of conformance with f03.  If the idea is
> to provide a facility that is usable with f03, then those options are
> out.  If the idea is to make an interface for f08, for which we  
> (barely)
> have time for changes, or for a future f1x standard, then it would be
> better, in my opinion, to directly address the root problem rather  
> than
> trying to twist existing syntax.  For example, we could add a type
> C_VOID to the ISO_C_BINDING module, say that any data type can match
> this in an interface, and that variables declared that way shall not
> appear in a definition context, shall not be referenced, and shall not
> be allocatable, pointer, or assumed-shape.  In other words, can't be
> used outside an interface, and are pass by address, and not dope
> vector.  Alternatives, like type(*), have been proposed in the past to
> serve a similar function, though experience suggests that messing with
> the basic typing syntax is unpopular.
>
> Another variation that has been discussed (and I would prefer) is  
> to add
> a LANG= spec to the BIND( ) syntax, which would enable you to specify
> that an interface was for a function written in C and that type 
> (C_VOID)
> would be allowed only in such an interface, and disallow allocatable,
> pointer, and assumed-shape for type(C_VOID) dummies.  You enforce  
> the C
> nature (or , at least non-Fortran nature) of the function by requiring
> that the LANG= spec on the interface and the actual function  
> definition
> has to match , and that LANG="C"  is allowed only in an interface  
> body.
> Some of these ideas COULD be added into the C interop TR, which  
> would be
> better than messing with the base f08 document.  And it would allow  
> the
> MPI crowd to require f03 + TR rather than all of f08.

I think the LANG=spec proposal would be widely welcomed by the MPI  
community as they really want something to put in the MPI 3.0 spec  
and so this would fit the f03 + TR time frame.

Would this require something like C_LOC?

Thanks,
Craig