(j3.2006) request for interpretation

[Bill Long]

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?
> Best,
> Aleks
>
>   
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 
differences.

12.4.4.1 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 
associated.
2) Look at elemental specifics from the local scoping unit or USE 
associated.
3) Look at INTRINSIC specifics from the local scoping unit or USE 
associated.
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 
order specified.

However, the basic point remains that the search order in 12.4.4.1 in no 
way relieves the user from conforming to the rules in 16.2.3. 

Cheers,
Bill





-- 
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