(j3.2006) TKR for C Interop

[Bill Long]

Aleksandar Donev wrote:

>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.
>

Since class(*) is already allowed in interfaces without bind(c) in f03, 
I see option 1 as a non-starter.  The CLASS declaration is designed for 
dummy arguments.


>
>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.
>

Involving all the overhead of polymorphic calling seems like unnecessary 
and undesirable overkill for interoperating with C.  Also, as Aleks 
predicted, this overhead makes writing the subroutine in Fortran so 
inefficient that it is effectively prohibited. And it does not address 
the rank part of the problem.   We've discussed before, and rejected, 
the CLASS(*) scheme for argument passing to C routines.  I think the 
hacks / warts required in the standard are not the right way to go.


>
>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.
>  
>
In a separate posting Aleks sent an example of the contortions people go 
to now to deal with dope vector style actual arguments.  It was, for my 
taste, so bad as to be unusable.  Of course, this was one of the 
problems the TR was aimed at solving.

In terms of dealing with turning off TKR checking in an interface, if 
that's what we want, then we should be up front about it.  I believe 
that schemes that try to overload some existing language syntax, such as 
modified forms of dimension() or class() are off the mark.  The 
interface should still make sense independent of whether the actual 
procedure is written in Fortran or C.  I am increasingly convinced that 
the best approach proposed so far is a new attribute:

    IGNORE([<ignore-mode-list>])

    <ignore-mode> is TYPE or
                                 KIND or
                                 RANK

If no list is specified, all three are assumed.  The items begin 
declared shall be dummy data arguments.  The only effect is to disable 
the required matching of the specified characteristics in interface 
checking or in generic resolution.  The other attributes in the 
declaration determine the actual characteristics of the declared 
object.  Thus, the new attribute can be added without messing up the 
current standard.  I suppose for consistency, a corresponding statement 
form is required.  Given that there already exists a time-tested 
directive in at least some compilers that provides the same 
functionality, I see this as a low risk option.  I see no reason, on the 
surface, to limit this attribute to interfaces that have bind(c). The 
current directive has no such restriction, and, if I recall, was added 
in our compiler to support extra-standard wanderings of an earlier 
generation of DOE lab programmers.


The questions I have are:

1) Is the problem posed by Aleks and Craig serious enough to warrant a 
change?   (I assume Aleks and Craig already voted yes.)

2) Does the IGNORE attribute solve the problem?

If yes to 1 and 2 then:

3) Should this feature be added into the f08 draft, or into the TR?

4) If it should be added into the TR, should it be done in a draft 
before the WG5 meeting (effectively expanding the scope of the TR 
compared to what was voted so far)?

Cheers,
Bill

-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120