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

[Aleksandar Donev]

On Monday 28 July 2008 19:59, Jim Xia wrote:

> I don't fully understand what your intention is in this thread of
> discussions.
It is very simple: Clarify what the standard says.

> If the goal is to remove type parameter feature for sequence 
> type, then I'm afraid to say it's too late. ?At least IBM has invested a
> great amount in implementing this feature
It is not a feature if no user can use it reproducibly and no user can even 
understand what it is the standard says! You've wasted the effort anyway!

> 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,
> also I assume the 2nd example is testing LEN instead of KIND). ?For the
> last example we compiles without a problem.
WHY???
Where does the standard say this?
What rule can we give in a textbook to determine the answer of "equivalent or 
not"???
No, an answer such as IBM does this, Cray does this, and Sun does this, is not 
OK.

I cannot even imagine giving a mathematically-consistent answer to the 
question, yet alone an implementation that actually implements such a 
consistent answer. Maybe you can, but you have not given it.

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

Best,
Aleks