[MPI3 Fortran] Proposing changes to Fortran 2008

[Aleksandar Donev]

Hi,

> Aleksandar Donev wrote:
>> interface
>> subroutine mpi_send(buffer...) bind(c)
>>     type(c_void), dimension(*) :: buffer
>> end subroutine
>> end interface

Lionel, Steve wrote:
> My opinion on this is that "type(c_void)" is not consistent with the
> Fortran language.  I'd propose instead that a new VOID attribute be
> allowed in declarations of dummy arguments.
OK, that's fair enough. Maybe the best way to think of what I proposed 
is to think of it as if the buffer array were declared as:

CLASS(C_INTEROPERABLE), DIMENSION(*) :: buffer

where the type C_INTEROPERABLE is a "base class" for all interoperable 
types. The special thing about it would be that no type descriptor would 
be passed as it is for CLASS, since the C side expects a plain address. 
In Fortran we also have CLASS(*), but again that is passed by a 
type-descriptor. This is why I thought of TYPE(C_VOID) or some such.

I am somewhat confident that a "TKR ignore"-type solution will not be 
accepted by the committee (it's been done before). I understand that 
some vendors have implemented it, but that is not really an argument 
that they did it "right"---especially concerning integration with the 
*whole* of the rest of the language. It does show the need for the 
feature, which is the important thing.

>  The argument could be
> declared as having any type (INTEGER would do) - but a dummy with the
> VOID attribute would match any actual argument TKR (Type, Kind, Rank).
I find this incompatible with the Fortran language.
If you want to omit all form of information about an argument, just omit 
it, rather than specifying something and then ignoring it, or even 
worse, over-riding it.

 > I think this
> would also be easy for programmers to understand the correspondence with
> C's void (un)type.
Not really, that is done already by TYPE(C_PTR)---a simple scalar 
containing a C address. We are trying here to improve on the usability 
of this, not to provide an equivalent to C's void.

> So with my proposal, the interface above would be written:
> 
> interface
>  subroutine mpi_send(buffer...) bind(c)
>      integer, dimension(*), void :: buffer
>  end subroutine
> end interface
> 
> In this case, the dimension(*) is really there for the reader - the
> compiler ignores it.
No, this is not acceptable and won't fly through the committee. One 
attribute cannot wipe out other attributes.

Note that I specifically proposed that the information in the dimension 
attribute not be ignored, in fact, I want it to be taken into account. 
For example, dimension(*) is different from dimension(N) in important 
ways (the later will only copy N of the elements if a copy in/out 
occurs, for example).

In fact, what I proposed was only to allow type/kind mismatch, not 
*rank*. As you pointed out yourself, we already have sequence 
association to deal with passing higher-dimensional arrays. Granted, 
this is an old and archaic mechanism, but you are in fact relying on 
sequence association and so better state that rather than ignoring the 
rank declaration.

In Fortran 2008 (and to some extent 2003), you can make an array pointer 
that is CONTIGUOUS and rank-1 and point it to a higher rank array. There 
are rules that ensure you won't shoot yourself in the foot, notably, 
they insure that the target is in fact contiguous so that you can 
reshape the array as expected.

> When used in a generic procedure declaration, VOID arguments match any
> TKR.
Let's think about generic complications once we have a basic design :-)

Thanks,
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