Problems with records

Although the second interpretation for record constructors (amounting to name-equivalence) has been dubbed sensible in section 4, it does not seem sensible to adopt this convention in a language where types are regarded merely as sets, since the obvious interpretations of the sets of values generated by the other type constructors all amount to structural equivalence.

Structural equivalence, however, creates problems when records are used as the ``concrete'' representations of abstract types. For example, if

type Stack =
record
Top : range 0..100;
Elems : array 1..100 of Int;
end record

and

type Funny-rec =
record
Top : range 0..100;
Elems : array 1..100 of Int;
end record

then types Stack and Funny-rec represent the same set of values if structural equivalence is used.

Given assignment compatibility as outlined in the previous section, this means that a client programmer can always make the ``hidden'' representation of abstract types visible by providing alternative type definitions that happen to describe the same sets of values as the abstract types. Thus, abstract types have to be handled in non-traditional ways if types are to intersect freely.