(j3.2006) (SC22WG5.3814) [ukfortran] Ballot on the technical content of the TR
Wed Dec 10 15:13:38 EST 2008
> (j3.2006) (SC22WG5.3813) [ukfortran] Ballot on the technical contentof
> Aleksandar Donev
> 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.
> 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
> 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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the J3