[J3] sequence type equality
malcolm at nag-j.co.jp
Thu Oct 15 20:10:53 EDT 2020
> The idea of SEQUENCE was that without it, compilers were free to reorder derived type components - I am not aware of any that did.
The NAG compiler has optimised the storage of non-sequence types, to improve alignment and remove padding (and potentially decreasing the total size), for more than two decades.
Most programmers try not to write the component sequence in suboptimal order, but with non-sequence types that can be handled by the compiler.
>>the ordering problem
There’s no “ordering problem” unless you want to communicate with C. For which we have BIND(C).
We only have BIND(C) because some compilers did incompatible layout for SEQUENCE compared with the C compiler. Otherwise we would have used SEQUENCE for C interoperability.
>not support deleting features
I support deleting harmful features. For example, I’m sure they are still out there, but it is a long time since I’ve run into a program with a floating-point DO.
>Can we delete SEQUENCE?
No. Not according to the informal rules we’ve all promised to obey (though few on the committee now were around at that time?). That is, we promised only to delete Obsolescent features, and we promised to make features only Obsolescent when better methods existed in the previous standard. I think there are enough public statements of this policy that we should adhere to it.
The bigger the feature the longer it should stay Obsolescent. SEQUENCE types is not a huge feature, especially given we have BIND(C) to solve the interoperation problem. We could Obsolescence them in F202x, and delete them in F202y. That would be “WG5 could ...”, if a country comment at the CD stage said the country wanted them to be Obsolescent. It’s not something J3 can do blithely itself.
..............Malcolm Cohen, NAG Oxford/Tokyo.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the J3