[MPI3 Fortran] Proposing changes to Fortran 2008
steve.lionel at intel.com
Tue Mar 18 13:44:14 CDT 2008
Please keep me involved in this discussion. I don't care if it's done
in this list or through direct email.
Developer Products Division
From: mpi3-fortran-bounces at lists.mpi-forum.org
[mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Craig
Sent: Tuesday, March 18, 2008 11:04 AM
To: MPI-3 Fortran working group
Subject: Re: [MPI3 Fortran] Proposing changes to Fortran 2008
I'm going to take this offline as it probably involves more technical
Fortran discussion that this group wants. If anyone disagrees, we
can keep in online.
On Mar 18, 2008, at 11:18 AM, Aleksandar Donev wrote:
> On Tuesday 18 March 2008 06:56, Craig Rasmussen wrote:
>> Why can't c_void be used like c_ptr is now so that the interface is
>> bi-directional (implementable in either C or Fortran)?
> Because entities in Fortran must have a type----the standard
> literally breaks
> down otherwise. CLASS(*) is the Fortran (2003) "equivalent" to
> void*, but it
> does have a (dynamic) type. The type is passed in a "type
> descriptor". If
> there is no type info, but rather just an address, you can't do
> anything to
> it in Fortran and you cannot interpret the meaning of the standard.
> And the
> committee will never go along with changing the standard to allow
> such a
> thing and thus make Fortran look like C :-)
>> Unfortunately the integer declaration is just for show also. What is
>> really meant in
>> void :: buffer
>> and everything else is just to get around the fact we can't have a
>> void type in Fortran.
> You are agreeing with me that one should not be specifying false
> and fake types and then ignoring them. It is a hack unsuitable for
> But, the problem I see with the above declaration (which I find
> very nice) is
> that it requires (significantly) more work to add to the standard.
> One has to
> specify a whole new section about argument matching for such "void"
> arguments. This includes issues such as what the dummy is actually
> with (the whole of the actual in array-element order?), whether the
> needs to be an array or scalar or either, what type it may have,
> whether it
> has to be contiguous, whether copy in/out is ever allowed or not,
> etc., etc.
> I can help you write a draft of such rules. But, it won't be easy
> to push it
> through the committee, especially at this stage.
> My idea is to only allow type mismatch, much like we do for CLASS
> (*) dummies
> but just passing an address without a type descriptor. This is a
> much more
> localized change. Dealing with multiple ranks is also useful but
> IMO not
> crucial and requires more work.
> Or, one can propose both during the comment period and let J3 make
> an opinion.
> In any case, I strongly urge the MPI Forum Fortran group to come up
> with a
> proposal for the May J3 meeting to get the ball rolling early.
> Aleksandar Donev, Ph.D.
> Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory
> 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
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
mpi3-fortran mailing list
mpi3-fortran at lists.mpi-forum.org
More information about the mpiwg-fortran