From owner-sc22wg5@open-std.org Wed Dec 10 21:13:43 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 B1295CA3439; Wed, 10 Dec 2008 21:13:43 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by www2.open-std.org (Postfix) with ESMTP id DF0F2C178E6 for ; Wed, 10 Dec 2008 21:13:41 +0100 (CET) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mBAKD2MU008776 for ; Wed, 10 Dec 2008 15:13:02 -0500 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mBAKDe9j198902 for ; Wed, 10 Dec 2008 15:13:40 -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 mBAKDdh2002629 for ; Wed, 10 Dec 2008 15:13:40 -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 mBAKDdMZ002624 for ; Wed, 10 Dec 2008 15:13:39 -0500 In-Reply-To: <20081210190834.04BE0C178E6@www2.open-std.org> References: <20081127193527.EF00DC178D9@www2.open-std.org> <4A7809D4-58F0-45CA-8AEC-9520DD4A2666@lanl.gov> <20081210175242.6DC96C178E6@www2.open-std.org> <20081210190834.04BE0C178E6@www2.open-std.org> To: sc22wg5@open-std.org MIME-Version: 1.0 Subject: Re: (j3.2006) (SC22WG5.3813) [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 15:13:38 -0500 X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 12/10/2008 15:13:38, Serialize complete at 12/10/2008 15:13:38 Content-Type: multipart/alternative; boundary="=_alternative 006F1BCB8525751B_=" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 006F1BCB8525751B_= Content-Type: text/plain; charset="US-ASCII" > (j3.2006) (SC22WG5.3813) [ukfortran] Ballot on the technical contentof the TR > > Aleksandar Donev > > to: > > sc22wg5 > > 12/10/2008 02:09 PM > The thinking (at least mine) was that "TYPE(*), DIMENSION(*)" already > provides a kind of IGNORE_TKR since the actual can be of any type and > even rank, by virtue of the long-existing practice of sequence > association. However, Reinhold has pointed out recently that sequence > association does not work with generic resolution, nor does it work > with a scalar actual that is not an array element. I was originally concerned about the scalar case, but not the generic resolution: if you choose to ignore the rank for a procedure call, should we allow that procedure to participate the generic resolution at all? Note the generic resolution rule pretty much says TKR conformance. It seems this proposal also changes that rule. He has > proposed "DIMENSION(**)" to specify a dummy that is passed by address > and can be matched by an actual of any rank (including scalar), even in > generic resolution. Would that help? That'll solve the IGNORE_TKR problem. I'll have to think about the generic resolution issue. > DIMENSION(..) was meant to be used in new, "modern" interfaces, where > descriptors are passed. They add a lot of power to the descriptor TR, > coming from a user perspective. They won't help the old "F77" folks, > but, I can assure you, there are scientific programmers that know F90 > and onward and can and will use them. I'm not comfortable allowing dimension(..) to be specified for assumed-shape arrays. This may sound like arguing for some other vendors, but Sun just said they don't have the rank information in their descriptors. Is there any evidence this assumed-rank is needed beyond IGNORE_TKR? We could > even make it a two-part document, so that vendors can only implement > one and say so. The first part would be the "void*" part (allowing type > and some kind of rank mismatch between actual and dummy), and the > second the descriptor part. A TR with two optional parts works for me. 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 006F1BCB8525751B_= Content-Type: text/html; charset="US-ASCII"
> (j3.2006) (SC22WG5.3813) [ukfortran] Ballot on the technical contentof the TR
>
> Aleksandar Donev
>
> to:
>
> sc22wg5
>
> 12/10/2008 02:09 PM


> The thinking (at least mine) was that "TYPE(*), DIMENSION(*)" already
> provides a kind of IGNORE_TKR since the actual can be of any type and
> even rank, by virtue of the long-existing practice of sequence
> association. However, Reinhold has pointed out recently that sequence
> association does not work with generic resolution, nor does it work
> with a scalar actual that is not an array element.


I was originally concerned about the scalar case, but not the generic resolution: if you choose to ignore the rank for a procedure call, should we allow that procedure to participate the generic resolution at all?  Note the generic resolution rule pretty much says TKR conformance.  It seems this proposal also changes that rule.


                                                                  He has
> proposed "DIMENSION(**)" to specify a dummy that is passed by address
> and can be matched by an actual of any rank (including scalar), even in
> generic resolution. Would that help?
That'll solve the IGNORE_TKR problem.  I'll have to think about the generic resolution issue.



> DIMENSION(..) was meant to be used in new, "modern" interfaces, where
> descriptors are passed. They add a lot of power to the descriptor TR,
> coming from a user perspective. They won't help the old "F77" folks,
> but, I can assure you, there are scientific programmers that know F90
> and onward and can and will use them.

I'm not comfortable allowing dimension(..) to be specified for assumed-shape arrays.  This may sound like arguing for some other vendors, but Sun just said they don't have the rank information in their descriptors.  Is there any evidence this assumed-rank is needed beyond IGNORE_TKR?


                                                              We could
> even make it a two-part document, so that vendors can only implement
> one and say so. The first part would be the "void*" part (allowing type
> and some kind of rank mismatch between actual and dummy), and the
> second the descriptor part.

A TR with two optional parts works for me.


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 006F1BCB8525751B_=--