(j3.2006) derived types with type parameters are different
Thu Jul 24 20:43:00 EDT 2008
Bill Long wrote:
> Aleksandar Donev wrote:
>>Jim Xia wrote:
>>>For two sequence types to be the same type, they
>>>must have the same memory layout for any pair of objects that having the
>>>same type parameter values.
>>Wow, are you serious. Does the IBM compiler now implement a Maple
>>symbolic algebra proof (reduction) system???
> Even 40 years ago the IBM compiler supported symbolic algebra (I think
> the extension was called FORMAC). It would even let you convert the
> resulting expression into a function, compile it, and dynamically relink
> it into your program so you could get numerical values out.
> More to the point, most compilers have some level of internal symbolic
> algebra capability for the interpretation and simplification of
> expressions. At least at the level of knowing that N and N+0 are the
> same. Not quite as clear for Andy's example of N*(N-1) and N*N-N.
>>Seriously, we cannot possibly add ANY burden on compilers due to this
>>"over-integration". The equivalence of SEQUENCE types is an old
>>"feature" which has little to no place in modern programming. Using it
>>with derived type parameters should certainly not be encouraged, yet
>>alone glorified by forcing any compiler to do more work than necessary.
>>If there is no words in the standard, Robert should submit an interp.
> The words I see require that the corresponding components have the same
> attributes. That boils down to whether A(N) and A(N+0) have the same
> dimension attribute. I suspect the answer is yes, whether that's what
> we intended or not.
>>I would say that two separate derived types with parameters are never
>>equivalent even if they are SEQUENCE, even if they are cut-and-pasted.
> At least for the cut-and-paste case, that horse / warthog left the barn
> 5 years ago. To late to change it now.
Are there any compilers that implement parameterized derived types
yet? If so, how do they handle type equivalence? Interpretations
that change the way programs work have been issued before.
Interpretations 90/000082 and 90/000086 are going to force many
vendors, including Sun, to change the way their compilers work.
More information about the J3