Class 22: Type Checking, Concluded

Held Friday, October 18, 2002

Summary

Today we continue our explorations of type checking and type equivalence with some examples from C and some further questions.

Notes

• I hope you have a great break.
• It's close enough to break that we may have a shorter class, since I know many attention spans are down.
• Some of you asked me how I'd approach phase 2 of the project.
  • Choice 1: Use a generic Node object or build a separate class for each nonterminal. I think it's more elegant to build a separate class for each nonterminal, but I'd probably write a program to do that for me (i.e., with something that translates text files to class files). I would start with the generic Note in either case.
  • Choice 2: Predictive parser with a procedure per nonterminal vs. predictive parser with stack vs. SLR parser. I would probably write a predictive parser with a procedure per nonterminal and generate a tree that matches the original grammar rather than the modified grammar.

Overview

• C's coercion rules
• Type Equivalence, Continued
  • Records
  • Two common forms
  • Arrays
  • Constants
• More Fun with C

Fun with C

I thought you might enjoy this quote from Kernighan & Ritchie (2nd edition, p. 198).

Many operators cause conversions and yield result types in a similar way. The effect is to bring operands into a common type, which is also the type of the result. This pattern is called the usual arithmetic conversions

First, if either operand is a long double, the other operand is converted to a long double.

Otherwise, if either operand is a double, the other is converted to double.

Otherwise, if either operand is a float, the other is converted to float.

Otherwise, the integral promotions are performed on both operands; then, if either operand is unsigned long int, the other is converted to unsigned long int.

Otherwise, if one operand is long int and the other is unsigned int, the effect depends on whether a long int can represent all values of an unsigned int; if so, the unsigned int operand is converted to long int; if not, both are converted to unsigned long int.

Otherwise, if one operand is long int, the other is converted to long int.

Otherwise, if one operand is unsigned int, the other is converted to unsigned int.

Otherwise, both operands have type int.

Wasn't that fun?

More Type Equivalence

• Kinds of type equivalence:
  • Structural: Two types are the same if they have the same structure.
  • Name: Two types are the same if they have the same name (or can be reduced to the same name through type aliases).
• We'll continue our example from the previous class (records), considering some unnamed types.
• We'll also look at some odd consequences of structural equivalence for recursively defined types.
• We'll consider related issues for arrays
  • Size
  • Bounds
  • Name
• We'll also consider the implications of type names on someone's ability to write constants in a type.

More Fun with C

• Consider the following pseudo-C. What will the output be?

  #include <stdio.h>
  int printval(int val)
  {
    printf("%d\n", val);
    return val;
  } 
  int main() {
    int x;
    x = printval(2) + printval(3) * printval(5);
    (void) printval(x);
    return 0;
  }
  

• What's the value of the expression i++ - i++?