[Instructions] [Search] [Current] [Syllabus] [Handouts] [Outlines] [Assignments]

**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.

- 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).

- 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

_{}::= exp_{1}PLUS term*exp*_{}.tree = OpExp(PLUS.pos, exp_{1}.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)*

- 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.

- 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`

inlet 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.

Back to Digression on proving grammars equivalent. On to Type checking, continued.

[Instructions] [Search] [Current] [Syllabus] [Handouts] [Outlines] [Assignments]

**Disclaimer** Often, these pages were created "on the fly" with little, if any, proofreading. Any or all of the information on the pages may be incorrect. Please contact me if you notice errors.

Source text last modified Mon Oct 12 11:44:23 1998.

This page generated on Mon Oct 12 11:44:31 1998 by SiteWeaver.

Contact our webmaster at rebelsky@math.grin.edu