Comments on F2008 circular sequence derived-type equivalences.

[joseph-krahn]

I read the F2008 committee responses to public comments. One comment was on the difficulties of establishing the equivalence of sequence derived types defined in different source code files. It becomes quite complex when there are circular references. The F2008 response didn't really provide a good explanation of how to deal with this issue. There seems to be no official approach for public comments on those responses.

I have not spent time trying to understand all of the relevant details. So, I may be compeltely wrong here, but I hope there are at least a few useful ideas.

Robert Corbett commented on difficulties of type equivalences for SEQUENCE derived types defined in separate sources, such as:

       module mod
         type t1
           sequence
           integer i
           type(t2), pointer :: p
         end type
         type t2
           sequence
           integer i
           type(t1), pointer :: p
         end type
       end

My suggestion to help resolve ambiguities is that type considerations can use the idea of an "incomplete type" similar to typedefs in C, but without depending on the type's name. So, when t1 is initially defined, "type(t2)" can be thought of as "type(*)", and remains that way until after type t2 is defined. For sequence-type equivalence, the t1 "signature" retains the "incomplete type" which was present when t1 was initially defined.

This seems to be the most practical and straight-forward approach without using complicated type recursion analysis. However, I don't know if this would violate the equivalent type rules, because it would depend on the order in which types are defined. In the above example, t1 and t2 would not be equivalent for the purposed of sequence-type matching. Likewise, the initial definition of t1 could be equivalent in two separate cases, followed by completely different t2 definitions. In the scheme I propose here, t1 would still be equivalent sequence types because the t2 pointer is considered an incomplete type reference at the time it is defined.

Joe Krahn

[Steven_L_Intel1]

I was at the committee meeting and voted on the response to this comment. Most of the committee does not agree with Corbett that there are ambiguities. A lot depends on what algorithm a compiler uses to determine whether two types are "the same type".

In the case you show, there is no ambiguity at all. Corbett's example involved renaming which complicates processing, but does not prevent resolution. As it happens, ifort gets Corbett's original example wrong and I have filed a bug report about that.

Discussion has continued in the J3 mailing list after the meeting and I have not seen anything to suggest that there is a problem to be solved.

[jimdempseyatthecove]

Steve,

Why would Joe's example be any different from

module mod

 type t1
 sequence
 integer i
 real A
 end type t1

 type t2
 sequence
 integer i
 real A
 end type t2

end module

Although the layouts are identical these are not "the same type".

Is F2003 spec saying that these are the same type?

Jim Dempsey

[Steven_L_Intel1]

Here is what F2003 has to say, with bolding added by me.

1 4.5.1.3 Determination of derived types
2 Derived-type definitions with the same type name may appear in different scoping units, in which case
3 they may be independent and describe different derived types or they may describe the same type.
4 Two data entities have the same type if they are declared with reference to the same derived-type
5 definition. The definition may be accessed from a module or from a host scoping unit. Data entities in
6 different scoping units also have the same type if they are declared with reference to different derived-type
7 definitions that specify the same type name, all have the SEQUENCE property or all have the BIND
8 attribute, have no components with PRIVATE accessibility, and have type parameters and components
9 that agree in order, name, and attributes. Otherwise, they are of different derived types. A data entity
10 declared using a type with the SEQUENCE property or with the BIND attribute is not of the same type
11 as an entity of a type declared to be PRIVATE or that has any components that are PRIVATE.

In both your case and Joe's, T1 and T2 are not the same type because they have different names. All I said above is that there is no ambiguity.

If you want to see the original comment, you can find it here. The example contained is quite different from either yours or Joe's. The commenter wanted the standard to specify an algorithm for determining whether two types were the same - the committee declined to do so.

[joseph-krahn]

No. I just got confused by reading Corbett's comments, without taking the time to go over the specs. It states that sequence types include the original name as part of their signature.

Corbett was mainly pointing out that circular references can make it difficult to decide if two types are identical when you cannot rely on just the type's name. He included an example with module renaming, which made it look more complicated than it is. But, the spec explicitly says that the use-renamed labels are not siginficant for comparison.

[joseph-krahn]

Oops, that NO was in refernce to Jim Dempsey. Steve posted while I was typing.

[jimdempseyatthecove]

>> In both your case and Joe's, T1 and T2 are not the same type because they have different names. All I said above is that there is no ambiguity

That is how it should be. Otherwise you could not distinguish one enum type from another (C/C++ or Fortran equivilent use of type for argument matching).

Section 6 is (initially) confusing to the C++ programmer. Whereby if module A is compiled with somewhereFOO.H and module B is compiled with somewhereelseFOO.H but where FOO.H are copies of each other, the assumption being the same type names (class/struct) , (with the same signatures) describe the same class/struct . The Fortran committee went a bit further (as I think they should have) in trying to tie the declaration to the actual file with the declaration but left some wiggle room to fall back on signatures. File+declaration would work on a monolithic application but would not necessarily work on a distributed library as placement varies(unless you fall back on the MS CLSID or say MD5 type of identification). But then this would prevent patches (bugfixes) from being issued to the library header files. You win some you loose some.

Jim Dempsey