From owner-sc22wg5@open-std.org Wed Dec 10 18:52:42 2008 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 4EFD1CA3439; Wed, 10 Dec 2008 18:52:42 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by www2.open-std.org (Postfix) with ESMTP id 7453EC178E6 for ; Wed, 10 Dec 2008 18:52:40 +0100 (CET) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mBAHqFCF012623 for ; Wed, 10 Dec 2008 12:52:15 -0500 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mBAHqcoo173990 for ; Wed, 10 Dec 2008 12:52:39 -0500 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id mBAHqcEp030795 for ; Wed, 10 Dec 2008 12:52:38 -0500 Received: from d25ml04.torolab.ibm.com (d25ml04.torolab.ibm.com [9.26.6.105]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id mBAHqcFV030788 for ; Wed, 10 Dec 2008 12:52:38 -0500 In-Reply-To: <4A7809D4-58F0-45CA-8AEC-9520DD4A2666@lanl.gov> References: <20081127193527.EF00DC178D9@www2.open-std.org> <20081208024650.76234C4596C@www2.open-std.org> <20081208154207.B50ABC178E0@www2.open-std.org> <493DDCA3.3050104@sun.com> <20081209044540.E9F0AC178E5@www2.open-std.org> <493E0084.1020206@sun.com> <20081209063036.65499CA343D@www2.open-std.org> <20081209114032.1E486C178D6@www2.open-std.org> <4A7809D4-58F0-45CA-8AEC-9520DD4A2666@lanl.gov> To: sc22wg5@open-std.org MIME-Version: 1.0 Subject: Re: (j3.2006) (SC22WG5.3786) [ukfortran] Ballot on the technical content of the TR X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 Message-ID: From: Jim Xia Date: Wed, 10 Dec 2008 12:52:36 -0500 X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 12/10/2008 12:52:38, Serialize complete at 12/10/2008 12:52:38 Content-Type: multipart/alternative; boundary="=_alternative 006232938525751B_=" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 006232938525751B_= Content-Type: text/plain; charset="US-ASCII" > Re: (j3.2006) (SC22WG5.3786) [ukfortran] Ballot on the technical > content of the TR > > Craig Rasmussen > > to: > > fortran standards email list for J3 > > 12/10/2008 11:12 AM However, the assumed-shape dummy portion of > N1761 would allow "real" (i.e., much better) Fortran interfaces to be > developed (as I discuss further below). So how about limiting Fortran descriptors to assumed-shape arrays only? I'm mostly worried about the safety issues of allowing C programmers to create or update POINTER and ALLOCATABLE arrays for Fortran. > I don't want to put words in your mouth but it sounds like you are in > favor of the vast majority of parallel Fortran programmers using the > old unsafe Fortran 77 interfaces. The problem does not only exist in MPI community. If you read the OpenMP specification, nearly ALL the Fortran examples in it are using either explicit shape or assumed-size arrays, or COMMON blocks in passing data. In fact I can NOT find a single example in the OpenMP 3.0 standard that uses assumed-shape array, pointer array or allocatable array in their function calls. Should we also standardize their specification for putting some "modern" Fortran in their examples? Most people I know of who still use Fortran (mostly scientists and engineers including my dad) know virtually nothing beyond Fortran 77. To them Fortran is Fortran 77. They keep writing Fortran 77 code and call it a Fortran 90 program. And they're not interested in learning new features in the language -- if they know something works, why bother changing it. So I think we must address this issue. If you deliver something to the MPI forum ultimately new and suspicious to them, how big a chance you think we can succeed in convincing them to adopting it? Last thing I'd like to mention is in N1761 assumed-rank arrays are always passed using a Fortran descriptor. This was a big change from the original response to MPI forum that Fortran standardize IGNORE_TKR. This was rather a big change in calling convention that I'm not happy about. I believe this was caused by tangling the MPI request with TR 29113. To me we shouldn't do that and we'd better leave them separate, i.e. response to MPI folks with something else, and remove the assumed-type and assumed-rank features from TR 29113. Cheers, Jim Xia RL Fortran Compiler Test IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7 Phone (905) 413-3444 Tie-line 313-3444 email: jimxia@ca.ibm.com D2/YF7/8200 /MKM --=_alternative 006232938525751B_= Content-Type: text/html; charset="US-ASCII"
> Re: (j3.2006) (SC22WG5.3786) [ukfortran] Ballot on the technical
> content of the TR
>
> Craig Rasmussen
>
> to:
>
> fortran standards email list for J3
>
> 12/10/2008 11:12 AM

                            However, the assumed-shape dummy portion of  
> N1761 would allow "real" (i.e., much better) Fortran interfaces to be  
> developed (as I discuss further below).

So how about limiting Fortran descriptors to assumed-shape arrays only?  I'm mostly worried about the safety issues of allowing C programmers to create or update POINTER and ALLOCATABLE arrays for Fortran.


> I don't want to put words in your mouth but it sounds like you are in  
> favor of the vast majority of parallel Fortran programmers using the  
> old unsafe Fortran 77 interfaces.


The problem does not only exist in MPI community.  If you read the OpenMP specification, nearly ALL the Fortran examples in it are using either explicit shape or assumed-size arrays, or COMMON blocks in passing data.  In fact I can NOT find a single example in the OpenMP 3.0 standard that uses assumed-shape array, pointer array or allocatable array in their function calls.  Should we also standardize their specification for putting some "modern" Fortran in their examples?

Most people I know of who still use Fortran (mostly scientists and engineers including my dad) know virtually nothing beyond Fortran 77.  To them Fortran is Fortran 77.  They keep writing Fortran 77 code and call it a Fortran 90 program.  And they're not interested in learning new features in the language -- if they know something works, why bother changing it.  So I think we must address this issue.  If you deliver something to the MPI forum ultimately new and suspicious to them, how big a chance you think we can succeed in convincing them to adopting it?


Last thing I'd like to mention is in N1761 assumed-rank arrays are always passed using a Fortran descriptor.  This was a big change from the original response to MPI forum that Fortran standardize IGNORE_TKR.  This was rather a big change in calling convention that I'm not happy about.  I believe this was caused by tangling the MPI request with TR 29113.  To me we shouldn't do that and we'd better leave them separate, i.e. response to MPI folks with something else, and remove the assumed-type and assumed-rank features from TR 29113.

Cheers,

Jim Xia

RL Fortran Compiler Test
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7
Phone (905) 413-3444  Tie-line 313-3444
email: jimxia@ca.ibm.com
D2/YF7/8200 /MKM
--=_alternative 006232938525751B_=--