Outline of Class 12: Type Equivalence and Coercion

Held: Friday, February 13, 1998

Administrivia

• Don't forget Monday's brown-bag lunch. It's on multimedia on the ethernet and looks to be interesting.
• assignment 3 is now ready.

Design Issues

• What are some questions we might ask ourselves as we design a type system?
• Some questions have to do with the "base types" in our system.
  • Do we type objects in our language?
  • If so, do we type at run time, compile time, both?
  • What primitive types do we provide?
  • What compound types do we provide?
• Some questions might have to do with user-definable types in our system.
  • Can users define new types?
  • Can they define new primitive types?
  • Can they define new compound types?
  • Can they define new type constructors?
• Some might have to do with the interpretation of types.
  • Do we treat types as having fixed-size or arbitrary-size representations?
• Can you think of any others?

Type Equivalence

• Of the many reasons we use types, one of the most important is in ensuring that objects are only used in "appropriate" places.
  • Arithmetic operations should only be applied to objects on which you can perform arithmetic (and often only to objects of an equivalent type).
  • Values should only be assigned to variables of an equivalent type.
  • ...
• Hence, it is important to determine when two types are equivalent (in the senses used above).
• Often, type equivalence is attacked from a practical perspective: what equivalencies can we reasonably determine?
• To answer this question, we'll consider a few basic types and variable declarations. It is often easiest to ask whether we can assign a variable of one type to a variable of another type. Here are some sample types and corresponding variables.

  type intreal = record
                    x: integer;
                    y: real;
                  end;
       intreal_alias = intreal;
       ir = record
              a: integer;
              b: real;
            end;
       realint = record
                    y: real;
                    x: integer;
                  end;
       irr = record
               a: integer;
               b: real;
               c: real;
             end;
       intrec = record
                  x: integer;
                end;
       iarr = array[1..10] of integer;
       iare = array[2..11] of integer;
  var
     rec1: intreal;
     rec2: intreal_alias;
     rec3: ir;
     rec4: irr;
     rec5,rec6: record a: integer; b: real; end;
     rec7: record a: integer; b: real; end;
     rec8: realint;
     rec9: intrec;
     rec10: intrea;
     arr1: iarr;
     arr2: iare;
     arr3,arr4: array[1..10] of integer;
     arr5: array[1..10] of integer;
  

• There are a number of strategies one might use to determine equivalence, including structural equivalence, named structural equivalence, name equivalence, and declaration equivalence.
• In structural equivalence, two types are equivalent if they have the same structure.
  • rec1 and rec3 are structurally equivalent as they are both pairs of (integer,real).
  • rec1 and rec8 are not structurally equivalent, as they order their elements differently.
• In structural equivalence under naming, two types are equivalent if they have the same structure and the named components of each structure have the same names.
  • rec1 and rec3 are not structurally equivalent under naming as they name their pairs differently.
  • rec3 and rec6 are structurally equivalent under naming.
• In name equivalence, two types are equivalent if they are named and have the same name.
  • rec1 and rec2 are not name equivalent.
  • rec1 and rec10 are name equivalent.
• In declaration equivalence, two types are equivalent if they lead back to the same type name. This accommodates variables.
• A related concept is assignment compatibility: can we safely assign a variable of one type to another type? Often, we may need to do some coercion to allow such assignments.

Type Coercion

• Often, when performing operations on values we may need to coerce a value from one type to another.
  • When you add the integer 3 and the real number 4.5, we need to coerce 3 to a real.
  • When you print the real number 4.5, you need to coerce it to a string.
  • ...
• How do we handle such issues?
  • Disallow them and consider them violations of standard usage.
  • Allow them, but require programmers to explicitly coerce from one type to another.
  • Allow them, and automatically determine an appropriate coercion.
  • ...
• Are there reasons to make each choice? Certainly. We'll discuss them.
• How do we convert, given the underlying representation?
  • Interpret the bit sequence for one as if it were the bit sequence for the other.
  • Build an equivalent object.
  • ...
• What kinds of coercions should we allow (explicitly or implicitly)?
  • More general types to less general types? (E.g., real to int.)
  • Less general types to more general types? (E.g., int to real.)
  • What if neither type is more/less general than the other?
  • Should we permit a loss of accuracy? If so, how do we determine that loss of accuracy?
  • If multiple coercions are possible, which should we choose? Consider 3 + "4".
  • Should we notify the programmer if we coerce?