Class 18: Introduction to type checking

Held Friday, October 9, 1998

Handouts

• Midterm exam.

Notes

• The department has now confirmed that Nathaniel Borenstein will be the Noyce Distinguished Visiting Science Professor next semester. He will most likely teach a two-credit majors-only project course and a two-credit general interest course. He will be giving talks this semester on October 27 (4:15, forum) and 29th (convocation).
• We will reserve the last fifteen minutes of today's class for questions on the exam.
• Next week we will move on to chapter six, so please read ahead.
• A reminder that assignment 8 is optional.
• There were a number of overly difficult question on assignment 6. I apologize for that. In the future, I will make sure to do any written assignment before I distribute that assignment. To that effect, I have done the midterm (and will distribute solution keys at the beginning of class next Friday). In addition, to alleviate some of the workload, all remaining written assignments will be for extra credit (and preparation for the exam) only. This is because it is important that you have sufficient time to work on your coding, and the coding assignments are intended to illustrate a variety of ideas.

Abstract syntax trees, revisited

• What do abstract syntax trees look like?
  • It depends, in part, on how you think programs should be structured.
  • We'll stick fairly close to Appel's version.
• There are three kinds of variables,
  • Simple variables, which have just a name;
  • Field variables which are used to index part of a record and contain both record variable and symbol indicated which part;
  • Subscript variables which are used to index part of an array contain the base array and an expression used as the index.
• There are too many kinds of expressions. Of particular interest are
  • Operation expressions, which encapsulate all of the different ways of applying binary operators (without worrying about the precedence given by the normal grammar). Note that all operations are binary (which means that some tricks are necessary to handle unary operators).
  • Record and array expressions have record and array values, respectively. (Elements of records and arrays are covered by field variables and subscript variables.)
• There are three kinds of declarations
  • Variables,
  • Functions (which can be mutually recursive), and
  • Types (which can also be mutually recursive).
• Most nodes in the abstract syntax tree contain a position field that indicates (approximately) where that structure can be found in the input. This is useful for producing error messages.
• There are no nodes for and and or. This is because they can be simulated with if.
• Note that NULL is used in the abstract syntax tree for "not here", in the cases that things are optional (such as the type of a variable).

Generating abstract syntax trees

• How do we generate abstract syntax trees? By making those trees attributes, and doing syntax-directed translation.
• For example, we might build an expression node with,

  exp ::= exp1 PLUS term
    exp.tree = 
      OpExp(PLUS.pos, exp1.tree, PLUSOP, term.tree)
  

• Similarly, we can build a record with

  exp ::= ID LBRACE assignlist RBRACE
    exp.tree =
      RecordExp(ID.pos, ID.sym, assignlist.list)
  

Types and type checking

• Once we've built the abstract syntax tree, we can begin type-checking the program.
• Type checking involves traversing the AST, determining the types of identifiers (type variables, function variables, and normal variables) and ensuring that they're used correctly.
• Appel advocates a multi-pass type checking strategy.

Environments

• In order to type check, we need to determine the environment in effect for each subexpression.
  • An environment maps identifiers to corresponding information (in this case, the type of a variable or the type structure of a type variable).
• In Tiger, the environment needs to work differently on type identifiers and the other kinds of identifiers (normal variables and function names).
• Many structures in Tiger extend or otherwise modify the environment.
  • In the body of a function, the parameters extend the environment.
  • In a let expression, all the declarations extend the environment.
• The rules for let expressions are somewhat complicated.
• Consider the value of b in

  let a = 5 in
    let var a = a + 2
        var b = a
      in b 
    end
  end
  

• How does that relate to

  let function f(x): int = 5 in
    let function f(x): int = f(x) + 2 
        function g(x): int = f(x)
    in
      g(1)
    end
  end
  

• Is this also related?

  let type a = int in
    let type a = string
        type b = a
        var x : a = ...
    in 
      ...
    end
  end
  

• Is this legal?

  let function g(x): int = f(x)
      function f(x): int = x + 1
      var v = 1
  in
    g(v)
  end
  

• Is this identical (or even legal)?

  let function g(x): int = f(x)
      var v = 1
      function f(x): int = x + 1
  in
    g(1)
  

• Is this legal?

  let type a = int
      var a: a = 1
  in
    a
  end
  

• Can we do weird things with types?

  let type a = b
      type b = a
  in
    ...
  end
  

• How about

  let type a = b
      type b = record { c:a } in
    ...
  end
  

• Or even

  let type a = { a : a } in
    ...
  end
  

• Here's a fun one. Is it legal?

  let type int = string in
    ...
  end
  

• Appel suggests using two environments for type checking: one for type variables and one for other variables.
  • How do you choose which to use? Context.

History

• Created Wednesday, October 7, 1998 (blank template). Later that day I moved the full body here (copied directly from Wednesday's class).
• On Monday, October 12, moved part of the section on type checking to the next class outline.