(j3.2006) Paper submission

Bill Long longb
Mon Jun 13 07:50:48 EDT 2011

On 6/12/11 11:16 PM, Malcolm Cohen wrote:
> Bill Long wrote:
>> Just as a general policy, it is not acceptable to try to edit 10-007r1 by
>> slipping edits into Clause 6 of the N1854 that are not related to the TR.

I stand by my  objection.  There is nothing in the TR text (Clauses 1-5) 
related to this, and Craig's paper did not include edits to insert 
anything there.   The point of Clause 6 is to provide the edits that 
incorporate the rest of the TR into 10-007r1.  Edits that have no 
reference to anything in the TR are not acceptable.

>> This should be modified to be a paper with edits to 10-007r1 and go into the
>> pool of proposals for the next revision.
> I think this is a spectacularly unhelpful response to a proposal to handle a
> real problem with interoperating with companion processors, viz the asynchronous
> updating of Fortran entities caused by the companion processor.
> This possibility is not limited to MPI or new things like OpenCL but includes
> the asynchronous i/o primitives found in most operating systems and available
> through most C compilers.  Such primitives have even been available in ordinary
> retail operating systems like *BSD, Linux and Windows for well over a decade.
> In fact IIRC we already debated this in the context of how can we support MPI,
> and decided at that to handle this in the TR.

My recollection is that the MPI group specifically withdrew this 
request, and decided to not use ASYNCHRONOUS in the new MPI interface. 
So, the urgency is no longer there.

> So I strongly disagree that this is a priori off the table.  On the contrary, we
> have already been dinged on our apparent lack of action to support our earlier
> decision and communication with the MPI community!  We would do ourselves no
> favour by continuing to take no action on this issue.

I am not a priori opposed to considering this.  However, it is a new 
feature that is not related to the purpose of the TR (interoperability 
of interfaces with assumed-shape. allocatable, pointer, and optional 
arguments).  At some point we have to stop adding new features and 
finish the TR. I think this should be considered as part of the next 
standard - it even fits well into the idea of a "corrections" proposal.

This topic is squarely in the /Data bin.  If the /Data subgroup can come 
up with an acceptable rewrite of the paper within the first couple of 
days of the meeting, I may soften my procedural objection.


> Cheers,

Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

More information about the J3 mailing list