Please keep me involved in this discussion. I don't care if it's done in this list or through direct email. Steve Lionel Developer Products Division Intel Corporation Nashua, NH -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Craig Rasmussen Sent: Tuesday, March 18, 2008 11:04 AM To: MPI-3 Fortran working group Subject: Re: [MPI3 Fortran] Proposing changes to Fortran 2008 Importance: Low 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. Cheers, Craig 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 attributes and fake types and then ignoring them. It is a hack unsuitable for standardization.

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 associated with (the whole of the actual in array-element order?), whether the actual 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.

Best, Aleks

-- Aleksandar Donev, Ph.D. Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory High Performance Computational Materials Science and Chemistry E-mail: [email protected] 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 [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

_______________________________________________ mpi3-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran