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

[Robert Corbett]

Jim Xia wrote:
> 
> I don't fully understand what your intention is in this thread of 
> discussions.  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, and we wouldn't 
> want to see the investment go wasted.  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.
> 
> Again, I don't see much of the point to keep discussing this.  Sequence 
> type with type parameter is one of the easiest fraction in the entire 
> parameterized derived type feature.  You barely scratched the surface on 
> this monstrous feature yet.  If you can not overcome the sequence type, 
> then I don't know when or ever you'll be able to get the whole thing done.

Section 4.5.1.3 of the Fortran 2003 gives a rule for determining
when the types defined by two derived-type definitions are the
same type.  The rule is incomplete.  Based on your response here
and on Bill Long's response earlier today, IBM's implementation
and Cray's produce different results for my first example.  I
would like an interpretation which lets me determine which of
the two implementations is correct, or a ruling that both are
correct (in which case users will suffer the consequences of the
ambiguity) or neither is correct.  The solution I am advocating
is to drop the feature from the standard, which, given the
permissive nature of the standard, makes any implementation
correct.

Bob Corbett