J3/01-307

Date:    6 August 2001
To:      J3
From:    WG5 Members
Subject: Interp F90/000212 (EQUIVALENCE of Data Objects of
         Different Types or Kinds)

WG5 members in London considered Interp F90/000212 and recommend as
follows. The HISTORY mentions the action recommended by WG5.

----------------------------------------------------------------------

NUMBER: F90/000212
TITLE: EQUIVALENCE of Data Objects of Different Types or Kinds
KEYWORDS: EQUIVALENCE limitations
DEFECT TYPE:
STATUS: J3 consideration in progress

    Section 5.5.1 acknowledges that it is possible to construct equivalences
    between data objects of different types or kinds:
    "If equivalenced objects have differing type or type parameters, the
     EQUIVALENCE statement does not cause type conversion or imply
mathematical
     equivalence."

    However, section 5.5.1 also has severe restrictions on equivalences
between
    data objects of differing types and kinds.  Following rule R547, there
are
    a series of constraints.  Constraints 3 through 6 read:

    Constraint:  If an <equivalence-object> is of type default integer,
default
    real, double precision real, default complex, default logical, or
numeric
    sequence type, all of the objects in the equivalence set must be these
    types.

    Constraint:  If an <equivalence-object> is of type default character or
    character sequence type, all of the objects in the equivalence set must
be
    of these types.

    Constraint:  If an <equivalence-object> is of a derived type that is not
    a numeric sequence or character sequence type, all of the objects in the
    equivalence set must be of the same type.

    Constraint:  If an <equivalence-object> is of an intrinsic type other
than
    default integer, default real, double precision real, default complex,
    default logical, or default character, all of the objects in the
    equivalence set must be of the same type with the same kind type
parameter
    value.

    Question 1) Why are these constraints in the standard?  What useful
                purpose do they serve?  What problems do they prevent or
solve?

    Question 2) Could a standard-conforming processor relax or eliminate one
                or more of these constraints, as an extension, without
                sacrificing full conformance to the standard?

    Question 3) Can a data object of sequence derived type be equivalenced
to
                another data object of a different sequence derived type?

    Question 4) Assume that a processor has among its intrinsic types
INTEGER (1)
                (8 bits), INTEGER (2) (16 bits), and INTEGER (4) (32 bits).
                Given the following definitions, is the EQUIVALENCE
statement
                standard-conforming?

TYPE T1
    SEQUENCE
    INTEGER (1) I1_ARRAY (36)
END TYPE

TYPE T4
    SEQUENCE
    INTEGER (4) I4_ARRAY (9)
END TYPE

TYPE (T1) OBJECT_1
TYPE (T4) OBJECT_4

EQUIVALENCE (OBJECT_1, OBJECT_4)

    Question 5) Can an object of sequence derived type be equivalenced to an
                array of intrinsic type?

    Question 5a) Assume the definitions of question 4. Is the following
                 EQUIVALENCE statement standard conforming?

INTEGER (4) :: I4_ARRAY_9 (9)

EQUIVALENCE (OBJECT_1, I4_ARRAY_9)

    Question 6) Can an object of sequence derived type be equivalenced to a
                scalar of intrinsic type?

ANSWER:

Question 1: The constraints are there for portability (section 1.1) since
different implementations may use different amounts of storage for these
objects.

Question 2: Such an extension is permitted, but the processor must provide
the capability to detect this (see section 1.5).

Question 3: Yes, a numeric sequence structure may be equivalenced to another
numeric sequence structure and a character sequence structure may be
equivalenced to another character sequence structure (see note 5.28).

Question 4: No, this is not standard-conforming, because either INTEGER(1)
or INTEGER(4) or both are non-default integers (see fourth constraint
above).

Question 5: Yes, a numeric sequence structure may be equivalenced to an
array of default integer type, default real type, double precision real
type,
default complex type, or default logical type, and a character sequence
structure may be equivalenced to an array of default character type
(see note 5.28).

Question 5a: No, this is not standard-conforming, because either INTEGER(1)
or INTEGER(4) or both are non-default integers (see fourth constraint
above).

Question 6: Yes, a numeric sequence structure may be equivalenced to a
scalar
of default integer type, default real type, double precision real type,
default complex type, or default logical type, and a character sequence
structure may be equivalenced to a scalar of default character type
(see note 5.28).

EDIT: None

SUBMITTED BY: Craig Dedo (Craig.Dedo@mixcom.com)
HISTORY: submitted Jan. 23, 1996 (first appeared in 96-006r2)
         WG5-N1456   draft answer