Introduction to Programming Languages/Type Equivalence Issues

Motivating Example (Type Equivalence Context) var Counts1: array['a'..'z'] of Integer; Counts2: array['a'..'z'] of Integer;In this example, two arrays with identical structure are declared. This raises the following question: Is the assignment Counts1 := Counts2 allowed? The answer depends on the type equivalence rule adopted by the language: Name equivalence → not allowed Structural equivalence → allowed This example introduces a broader issue in type systems. Central Question in Type Systems How much of a type’s internal representation should be exposed to the programmer? This is a fundamental design decision in programming languages, as it directly impacts safety, flexibility, and expressiveness. Languages that expose representation In these languages, programmers have direct access to the internal structure of types. Python class Complex: def __init__(self, rp, ip): self.rp = rp self.ip = ip c = Complex(1.0, 2.0) c.rp = "abc" # allowed, even if conceptually incorrect ttributes are directly accessible No strict encapsulation by default Structure can be freely modified Prolog X = complex(1.0, 2.0). X = complex(R, I). Data structure is fully visible Terms can be directly decomposed No traditional encapsulation Languages that hide representation In these languages, types are treated as abstractions, and their internal representation is hidden. SML abstype complex = C of real * real with fun make (r, i) = C(r, i) fun real (C(r, _)) = r end The constructor C is not externally accessible Data can only be accessed through defined functions Internal representation is protected Java class Complex { private double rp; private double ip; public double getRp() { return rp; } } Use of access modifiers (private) Representation is encapsulated Interaction occurs via methods Impact on Type Systems The decision to expose or hide representation directly affects: Encapsulation Maintenance of invariants Program safety Maintainability Optimization opportunities