(j3.2006) derived types with type parameters are different

[Bill Long]

Aleksandar Donev wrote:
> On Monday 28 July 2008 19:59, Jim Xia wrote:
>
>   
>> To answer your technical questions, IBM's compiler
>> accepts 2*N vs. N+N case, regardless KIND or LEN type parameters,  For your
>> 3 examples (with syntax fixes of course), we diagnose the first two
>> examples because generic name S is ambiguous (we treat N*2 the same as N+N,
>>     

So, the next question is whether N+N and 2*int(sqrt(N*N + epsilon(0.0))) 
are treated as the same?  In other words, is there a limit on the 
complexity of the expression?  In the standard we some times use 
"attributes" as an English word (in which case it means what Malcolm 
says it means), and at other times it means what it is defined to mean.  
That does leave open opportunities for interpretation.   Bob can 
certainly ask for one.



>> also I assume the 2nd example is testing LEN instead of KIND).  For the
>> last example we compiles without a problem.
>>     
>
> For example:
>   
>>> This one compiled and output:
>>>
>>> CALLED S1
>>> CALLED S2
>>>       
>> So your compiler decides that the attributes of the components
>> REAL A(N+N) and REAL A(2*N) are different.
>>     
> I read the standard to say the opposite. The array dimension attributes are 
> constants, and are the same. There is absolutely no need to decide 
> equivalence between symbolic expressions. I see no support in the standard 
> for this. As I said, it is like having an INTEGER(4) and an INTEGER(8) in a 
> generic interface. At least I see nothing in the standard contradicting my 
> interpretation???
>
>   

If it is the case that the code is illegal (as it seems the IBM compiler 
contends), then some other compiler can produce the above output, or do 
most anything else.  In this case, neither compiler is required to 
change, though one might want to improve the quality of its 
implementation.  If the code is decided to be legal, then IBM would need 
to make some adjustment.  Fixing something like this would be a tiny 
amount of work in the context of the work needed to implement 
parameterized types in the first place.  There is a valid interest in 
getting a ruling here.  I don't think the situation rises nearly to the 
level of being so hopeless that the feature has to be removed. 

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