(j3.2006) TKR for C Interop

[Aleksandar Donev]

On Tuesday 27 February 2007 09:09, Michael Ingrassia wrote:

> interface
> subroutine s(buffer)
> !$pragma ignore_tkr buffer
> end subroutine
> end interface
If the procedure s is written in C, we have a mechanism for doing this 
already:

subroutine s(buffer)
   type(c_ptr), value :: buffer
end subroutine

What the real issue is for the Interop TR is what to do when the dummy is 
assumed-shape, pointer or allocatable. If the routine is written in Fortran, 
it has a single TKR signature so there is nothing to be done. But if it is 
written in C it could easily operate on arrays of different types and ranks. 
At present however, Ch 16 makes it so that it can only be given a single 
Fortran interface, and thus, each C routine must choose a priory what TKR to 
operate on. Combinatorial explosion of wrappers ensues!

On Monday 26 February 2007 17:12, Bill Long wrote:
> As said earlier, the idea of forcing the Fortran programmer to write (I
> believe Craig was claiming ) thousands of interfaces to use this feature is
> just not reasonable.? This is the WRONG solution to this problem.

This is an important issue. The argument for combinatorial explosions is that 
a separate interface is needed for each of the pieces T, K  and R. The only 
way around it is if we have some ability to pass actuals of different TKRs.

Well, in Fortran 2003+, we have the TK part already done via CLASS(*) dummy 
arguments. The actual can be of any type. What we can do in the Interop TR is 
allow the following:

interface
 subroutine process(array) bind(c)
  class(*), dimension(:), intent(in) :: array
 end subroutine
end interface

The assumption here is that the descriptor that is used to pass array contains 
TKR information inside it. If the routine process is written in C, then it 
can use this information. When called from Fortran, the compiler will 
automatically construct the needed descriptor, including TKR *and* bounds 
information for the actual. A PERFECT Fortran->C INTERFACE! This is the RIGHT 
solution, IMNSHO.

I can hear Bill asking already what happens if the routine process is written 
in Fortran. There are two options:

1) We only allow class(*) dummies inside BIND(C) interfaces. I see no reason 
in the world why this is a problem other than the fact some stuff in Ch. 16 
needs to be modified to realize that there is a difference between an 
interface and a procedure specification.

2) We allow class(*) dummies for BIND(C) Fortran procedures. There needs to be 
a mechanism for C callers to construct the appropriate type descriptors. This 
may be too complicated to work out now, especially since vendors are still 
implementing CLASS(*) and there is no "agreed" way of how to pass type 
signatures. On the other hand, maybe it is better to prevent wildly diverging 
implementations by standardizing this now. I am not sure.

Saying that this is is beyond the scope of the TR is simply manipulation. The 
TR was delayed for inclusion in the standard because it was claimed we need 
more time to work things out and it made sense as a TR (so do macros, BTW). 
It makes no sense to me to now go back and simply publish the same old design 
we had 10 meetings ago as a TR, without considering carefully some important 
design decisions.

Best,
Aleks

-- 
Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ LLNL
High Performance Computational Materials Science and Chemistry
E-mail: donev1 at llnl.gov
Phone: (925) 424-6816  Fax: (925) 423-0785
Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
Web: http://cherrypit.princeton.edu/donev