(j3.2006) request for interpretation
Wed Apr 2 19:38:59 EDT 2008
Aleksandar Donev wrote:
> On Wednesday 02 April 2008 12:33, Bill Long wrote:
>> rules that require distinguishable specifics have been converted into
>> Constraints. Thus, while some lax compliers can argue conformance now,
>> the new standard will require that they diagnose the error in the
>> example code you posted.
> Bill, did you read Kurt's post? The essential point he made is that those
> rules specifically do not apply to specifics that come in through a generic
> identifier via host association. What are you citing as a counter-argument?
I guess I'm not seeing a conflict here.
The first part of 12.4.4, items (1)(a)..(1)(d) explain how you get the
list of specifics for a generic.
16.2.3 explains the rules that constrain that list based on argument
188.8.131.52 is effectively six steps you go through to determine which
specific is referenced by a particular reference using the generic name.
It is focused on differences based on characteristics among the specific
interfaces that are orthogonal to the ones in 16.2.3, such as whether it
is elemental or not. In particular,
1) Look at non-elemental specifics from the local scoping unit or USE
2) Look at elemental specifics from the local scoping unit or USE
3) Look at INTRINSIC specifics from the local scoping unit or USE
4) Same as 1 for host associated.
5) Same as 2 for host associated.
6) Same as 3 for host associated.
Suppose you have a set of subroutines that have one argument, and they
are specifics in a generic interface. One could have a rank 2 dummy and
the other a scalar argument, but be elemental. The arguments are TKR
distinguishable because of the rank difference. If you have an actual
reference with a rank 2 actual argument, the 6-step plan tells you which
one to pick. For example, if the specific with the rank 2 dummy came
from host association, and the elemental one is local, the 6-step rules
seem to say you pick the elemental one. It would seem simpler to me to
have merged all the access methods together and have just the three
steps. but there must have been some issue at the time that favored this
order. Maybe they did not anticipate vendors constructing the
interfaces fully before doing the searches, but rather iterating through
local first and then going to host. Whatever the reason, that's the
However, the basic point remains that the search order in 184.108.40.206 in no
way relieves the user from conforming to the rules in 16.2.3.
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
More information about the J3