(j3.2006) (SC22WG5.3814) [ukfortran] Ballot on the technical content of the TR

Jim Xia jimxia
Wed Dec 10 15:13:38 EST 2008


> (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 at ca.ibm.com
D2/YF7/8200 /MKM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3-fortran.org/pipermail/j3/attachments/20081210/d4fbe242/attachment.html 



More information about the J3 mailing list