Type compatibility: Difference between revisions

m
Some grammar, a link
(Created)
 
m (Some grammar, a link)
Line 1:
[[Category:Encyclopedia]]'''TypesType equivalence''' describes the way types are considered equivalent when matched. Types can be equivalent:
 
* by name (nominal equivalence);
* by structure (structural equivalence).
 
In a more general context typestype matching considers not only the relation of typestype equivalence (T<sub>1</sub>=T<sub>2</sub>), but also the relations of subsumption (T<sub>1</sub><:T<sub>2</sub>), subtyping, [[inheritance|subclassing]] etc. These also can be nominal or structural.
 
A structural matching is necessarily based on typestype inference. In presence of user-defined abstract data types, it is in general casegenerally undecidable whether two types are semantically equivalent to each other. Even if equivalence is decidable, in complicated cases it might be very difficult for the code maintainer to determine if two types in question are indeed equivalent or not. It is also incompatible with the ''information hiding principle'', because hidden implementation details might prevent the reader to see types equivalent. For these reasons modern typed languages with elaborated typestype systems tend totowards nominal typestype equivalence. At the same time for many standard types, and especially for subtypes, it becomes very tedious to use nominal equivalence. Therefore, programming languages have some pragmatic mixture of structural and nominal equivalences.
==Nominal equivalence example (in [[Ada]])==
<ada>
Line 21:
Y : not null access String := X; -- This is OK
</ada>
The anonymous type of X matches the anonymous type of Y. The structure of both types is the same: "a pointer to String". Further, the constraint ''not null'' put on the type of Y does not effect equivalence because it is also structural.
Anonymous user