[J3] sequence type equality

[Bill Long]

> On Oct 15, 2020, at 9:13 AM, Steve Lionel via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> On 10/15/2020 8:22 AM, Bill Long via J3 wrote:
>> BIND(C) types solve the problem of interacting with C.   Modules solve he problem of “same type as”.  COMMON is obsolescent and better replaced by modules.   I don’t see any ue for SEQEUNCE types any more, except that really old codes might have them (as well as arithmetic IF and a lot of other ancient junk).   Is there any use for SEQUENCE that does not already have a batter alternative?
> 
> The idea of SEQUENCE was that without it, compilers were free to reorder derived type components - I am not aware of any that did. SEQUENCE did not specify whether or not components could have padding added (for data alignment). Some compilers (and many users) assumed that SEQUENCE meant no padding, and some compilers naturally align SEQUENCE type components. It's a mess.
> 
> Indeed, BIND(C) solves the ordering problem. It doesn't completely solve the padding problem, but at least any padding must be consistent with the companion C processor which is what most care about.

Right. The whole point of BIND(C) for a type is to ensure the memory is set up the same way as is expected by the companion C compiler. 

> 
> I have always disliked the carve-out for SEQUENCE (and BIND(C)) in the test for "same type", but I don't see how we can get rid of it. Could we make that aspect obsolescent? Deleting SEQUENCE would not accomplish anything useful, so at most I'd support making it obsolescent for 202Y. I do not support deleting features.

I agree that deleting features typically is unhelpful.  (There are exceptions.  For example, IF(E) 10,20,30 has no sensible interpretation when E is a NaN value.)   However, making SEQUENCE obsolescent does lead to a compiler message for its use which might encourage cleanup of rusty code.  And the  \obs{} font in the standard should be a big hint to users about what to avoid. 

Cheers,
Bill

> 
> Steve
> 

Bill Long                                                                       longb at hpe.com
Engineer/Master , Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Hewlett Packard Enterprise/ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425