Sequence Types and Type Equivalence

The question of whether two entities are of the same type arises in many contexts, such as the association of actual and dummy arguments. There are two ways for entities to be declared to be of the same type. The simplest way is for them to be declared with reference to the same derived-type definition. If the two objects are in different scoping units, the only ways to declare them with reference to the same derived-type definition are by using host association (16.2.1.3) or use association (16.2.1.2). Except in some spe-cial cases of sequence and bind types, each derived-type definition defines a distinct type; if two entities are declared with reference to two distinct derived-type defini-tions, those entities are of different type, even if the derived-type definitions are textu-ally identical.

Example:

MODULE SHOP TYPE COMPONENT

CHARACTER(LEN=20) NAME INTEGER CATALOG_NO REAL WEIGHT

END TYPE COMPONENT

TYPE(COMPONENT) PARTS(100) CONTAINS

PRINT *, "Part not available"

PART%NAME = "none"

PART%CATALOG_NO = 0 PART%WEIGHT = 0.0 END SUBROUTINE GET_PART ...

CALL GET_PART(MOTOR(1), "VALVE")

TOTAL_WEIGHT = TOTAL_WEIGHT + MOTOR(1)%WEIGHT ...

END PROGRAM BUILD_MACHINE

Data Types 93 Module procedure GET_PART has access to the type COMPONENT because the type definition appears in its host. Program BUILD_MACHINE has access to the same type because it uses module SHOP. This allows a variable of the type, such as MO-TOR(1), to be passed as an actual argument.

The other way to declare entities to be of the same derived type involves sequence and bind types. A sequence type is a derived type whose type definition has a SE-QUENCE statement. Details of bind types are in 15.4.4. Bind types share many of the features of sequence types and might have been more clearly categorized as a special case of sequence types, but the standard does not categorize them that way; as a result, there are several places in the standard where material about sequence and bind types is nearly identical.

Rules and restrictions:

1. A sequence type must not have the EXTENDS, ABSTRACT, or BIND attributes.

2. A sequence type is not extensible.

3. The type definition for a sequence type must not have a procedure binding part.

4. Each data component of a sequence type must be declared to be of an intrinsic or sequence type.

Entities declared with reference to two distinct derived-type definitions are of the same type if both type definitions specify SEQUENCE or both specify BIND; they spec-ify the same type name; they have no PRIVATE components; and they have type pa-rameters and components that agree in order, name, and attributes. The example for program BUILD_MACHINE above is restated to illustrate the differences between the two ways:

PROGRAM BUILD_MACHINE TYPE COMPONENT SEQUENCE

CHARACTER(LEN=20) NAME INTEGER CATALOG_NO REAL WEIGHT

END TYPE COMPONENT

TYPE(COMPONENT) PARTS, MOTOR(20) COMMON /WAREHOUSE/ PARTS(100) TOTAL_WEIGHT=0.0

CALL GET_PART(MOTOR(1), "VALVE")

TOTAL_WEIGHT = TOTAL_WEIGH + MOTOR(1)%WEIGHT ...

END PROGRAM BUILD_MACHINE

94 Chapter 4 SUBROUTINE GET_PART(PART, NAME)

TYPE COMPONENT SEQUENCE

CHARACTER(LEN=20) NAME INTEGER CATALOG_NO REAL WEIGHT

END TYPE COMPONENT

TYPE(COMPONENT) PART, PARTS CHARACTER(LEN=*) NAME

COMMON /WAREHOUSE/ PARTS(100) DO I = 1, 100

IF (NAME .EQ. PARTS(I)%NAME) THEN PART = PARTS(I)

RETURN END IF END DO

PART%NAME = "none"

PART%CATALOG_NO = 0 PART%WEIGHT = 0.0

PRINT *, "Part not available"

END SUBROUTINE GET_PART ...

In this example, type COMPONENT in program BUILD_MACHINE and type COMPONENT in subroutine GET_PART are the same because they are sequence types with the same name; have no private components; and have type parameters and com-ponents that agree in order, name, and attributes. This example is less concise, particu-larly if there are more procedures that need access to the type definition. The necessity to replicate the type definition also introduces extra chances for errors, which might not be caught by the compiler.

In addition to their role in type equivalence, sequence types also play a role in stor-age association; a derived-type object in COMMON or EQUIVALENCE must be of a sequence type. Additional forms of COMMON and EQUIVALENCE association are al-lowed if the sequence type meets the extra conditions required to be a numeric se-quence type or character sese-quence type, as follows:

1. A numeric or character sequence type must not have type parameters. It must not have allocatable or pointer components.

2. Each component of a numeric sequence type must be of type default integer, de-fault real, double precision real, dede-fault complex, dede-fault logical, or a numeric se-quence type.

3. Each component of a character sequence type must be of type default character or a character sequence type.

There is no way to explicitly declare that something is a numeric or character sequence type; the terms just categorize sequence types that meet the extra conditions.

Data Types 95 Storage sequences for sequence types are described in 16.2.3.1. For numeric and character sequence types, the allowed storage associations essentially require that the components of objects of the type be stored in the specified order with no padding. For other sequence types, although the standard does specify a sequence of storage units for the components, this specification has no practical effect because it cannot be de-tected by a standard-conforming program; therefore, the compiler is free in practice to rearrange the internal storage of such types as long as it is done consistently so that the rules of type equivalence still work. For nonsequence types, no internal storage order is even implied by the standard.