(j3.2006) derived types with type parameters are different
Tue Jul 29 13:00:03 EDT 2008
On Monday 28 July 2008 19:59, Jim Xia wrote:
> I don't fully understand what your intention is in this thread of
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.
Where does the standard say this?
What rule can we give in a textbook to determine the answer of "equivalent or
No, an answer such as IBM does this, Cray does this, and Sun does this, is not
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.
> > 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
More information about the J3