(j3.2006) Interesting F2003-ism

[Craig Rasmussen]

On Feb 23, 2007, at 8:59 AM, Bill Long wrote:

> Just curious, since I don't that often see C libraries used in  
> scientific codes, what types of libraries are you talking about  
> that someone might in the future write to handle these new types of  
> arguments?   Most of the rank-independent arguments I see in C  
> libraries are typeless buffers in routines used to just move data  
> from one place to another. Given that Fortran has intrinsic  
> assignment for arrays, libraries like these seem irrelevant to a  
> Fortran programmer.

Bill,

I don't see why C libraries with typeless buffers (e.g., MPI) are  
irrelevant to a Fortran programmer.  I know you aren't saying that  
MPI is irrelevant, therefore my confusion.  I'm attaching a paper I  
wrote with an OpenMPI developer that illustrates the combinatorial  
explosion problem.  It seems to me we've only made the TKR problem  
worse with an upper limit of 15 for rank.

Suppose I am required to allocate array memory using a C library.   
There will certainly be only one C routine/interface to do this.   
Even with the interop TR, is there anyway to do this without writing  
many separate interfaces/procedures and mindless wrapper code?  It  
seems to me that this is a large hole in interop that should be fixed  
in the TR.

You mentioned that some (most?) vendors have an IGNORE_TKR  
directive?  Could you give an example of how this is used?  You seem  
to want this "conceptially trivial" feature in a later version of  
Fortran, but since we are doing an interop TR, why isn't it  
appropriate to fix it now?  When I made the pitch for the interop  
changes to WG5, I explicitly stated that it would be useful to  
library writers, but not absolutely critical, as you can do the same  
thing with the current interop and wrapper code in Fortran.  In my  
mind, the TKR difficulty is a bigger problem than what we want to do  
in the TR.

Just to be explicit, here is a program:

program main
   interface
     subroutine c_malloc(a, rank) bind(C)
         real, allocatable, dimension(rank=*/IGNORE_R/whatever) :: a
         integer :: rank
     end subroutine
   end interface

     real, allocatable :: a(:,:)
     call c_malloc(a, 2)		! actually, I suppose we don't even need  
the rank parameter, it's in the descriptor

end program

Now it seems to me that we've given the programmer all of the tools  
to do the job in the interop TR, except dimension(rank=*), and  
currently vendors have directives to do this anyway, but we don't  
actually want to put standard practice into the standard, because  
why?  I'm very happy to limit this to bind(C) interfaces.

Currently we are fixing a minor problem and leaving behind a huge  
hole.  If we are going to fix interop, let's fix interop.

Regards,
Craig

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3.scs.gmu.edu/pipermail/j3/attachments/20070223/75aee6d8/attachment-0002.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pvmmpi-paper81.pdf
Type: application/pdf
Size: 324412 bytes
Desc: not available
Url : http://j3.scs.gmu.edu/pipermail/j3/attachments/20070223/75aee6d8/attachment-0001.pdf 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3.scs.gmu.edu/pipermail/j3/attachments/20070223/75aee6d8/attachment-0003.html