[MPI3 Fortran] Proposing changes to Fortran 2008

[Lionel, Steve]

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: mpi3-fortran-bounces at lists.mpi-forum.org
[mailto:mpi3-fortran-bounces at lists.mpi-forum.org] 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: 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
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

_______________________________________________
mpi3-fortran mailing list
mpi3-fortran at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran