From owner-sc22wg5@open-std.org Wed Dec 10 20:08:33 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 DACD7CA3439; Wed, 10 Dec 2008 20:08:33 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from smtp.llnl.gov (nspiron-3.llnl.gov [128.115.41.83]) by www2.open-std.org (Postfix) with ESMTP id E4D0CC178E6 for ; Wed, 10 Dec 2008 20:08:32 +0100 (CET) X-Attachments: None Received: from cyrus2.llnl.gov ([128.15.97.105]) by smtp.llnl.gov with ESMTP; 10 Dec 2008 11:08:30 -0800 From: Aleksandar Donev Organization: LLNL To: sc22wg5@open-std.org Subject: Re: (j3.2006) (SC22WG5.3812) [ukfortran] Ballot on the =?iso-8859-1?q?technical=09content_of_the?= TR Date: Wed, 10 Dec 2008 11:08:30 -0800 User-Agent: KMail/1.9.4 References: <20081127193527.EF00DC178D9@www2.open-std.org> <4A7809D4-58F0-45CA-8AEC-9520DD4A2666@lanl.gov> <20081210175242.6DC96C178E6@www2.open-std.org> In-Reply-To: <20081210175242.6DC96C178E6@www2.open-std.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200812101108.30420.donev1@llnl.gov> Sender: owner-sc22wg5@open-std.org Precedence: bulk Hi Jim, > Last thing I'd like to mention is in N1761 assumed-rank arrays are > always passed using a Fortran descriptor. =A0This was a big change from > the original response to MPI forum that Fortran standardize > IGNORE_TKR. The thinking (at least mine) was that "TYPE(*), DIMENSION(*)" already=20 provides a kind of IGNORE_TKR since the actual can be of any type and=20 even rank, by virtue of the long-existing practice of sequence=20 association. However, Reinhold has pointed out recently that sequence=20 association does not work with generic resolution, nor does it work=20 with a scalar actual that is not an array element. He has=20 proposed "DIMENSION(**)" to specify a dummy that is passed by address=20 and can be matched by an actual of any rank (including scalar), even in=20 generic resolution. Would that help? DIMENSION(..) was meant to be used in new, "modern" interfaces, where=20 descriptors are passed. They add a lot of power to the descriptor TR,=20 coming from a user perspective. They won't help the old "F77" folks,=20 but, I can assure you, there are scientific programmers that know F90=20 and onward and can and will use them. >=A0I believe this was caused by tangling the MPI > request with TR 29113. As I explained above there was no "tangling". These are separate pieces=20 of an effort to "improve interoperability with C" for types of dummy=20 arguments that do not exist in both languages, so one language needs to=20 do something new (C has to construct descriptors, and Fortran needs to=20 learn how "void*" works). > To me we shouldn't do that and we'd better=20 > leave them separate, i.e. response to MPI folks with something else, > and remove the assumed-type and assumed-rank features from TR 29113. I am very opposed to further delays by a needless wasted effort to go=20 backwards. Let's make something work and publish the damn TR. We could=20 even make it a two-part document, so that vendors can only implement=20 one and say so. The first part would be the "void*" part (allowing type=20 and some kind of rank mismatch between actual and dummy), and the=20 second the descriptor part. Best, Aleks =2D-=20 Aleksandar Donev, Ph.D. Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory High Performance Computational Materials Science and Chemistry E-mail: donev1@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