Compiler Construction | Lecture 7 | Type Checking

Lecture 7: Type Checking
Hendrik van Antwerpen
CS4200 Compiler Construction
TU Delft
October 2018

Title Text
!2
Source
Code
Editor
Parse
Abstract
Syntax
Tree
Type Check
Check that names are used correctly and that expressions are well-typed
Errors
This Lecture

Reading Material
3
The following papers add background, conceptual exposition,
and examples to the material from the slides. Some notation and
technical details have been changed; check the documentation.

!4
Type checkers are algorithms that check names and types in programs.

This paper introduces the NaBL Name Binding Language, which
supports the declarative deﬁnition of the name binding and scope rules
of programming languages through the deﬁnition of scopes,
declarations, references, and imports associated.
http://dx.doi.org/10.1007/978-3-642-36089-3_18
SLE 2012
Background

!5
This paper introduces scope graphs as a language-independent
representation for the binding information in programs.
http://dx.doi.org/10.1007/978-3-662-46669-8_9
ESOP 2015
Best EAPLS paper at ETAPS 2015

!6
Separating type checking into constraint generation and
constraint solving provides more declarative deﬁnition of type
checkers. This paper introduces a constraint language
integrating name resolution into constraint resolution through
scope graph constraints.

This is the basis for the design of the NaBL2 static semantics
speciﬁcation language.
https://doi.org/10.1145/2847538.2847543
PEPM 2016

!7
Documentation for NaBL2 at the metaborg.org website.
http://www.metaborg.org/en/latest/source/langdev/meta/lang/nabl2/index.html

!8
This paper describes the next generation of the approach.

Addresses (previously) open issues in expressiveness of scope graphs for
type systems:

- Structural types

- Generic types

Addresses open issue with staging of information in type systems.

Introduces Statix DSL for deﬁnition of type systems.

Prototype of Statix is available in Spoofax HEAD, but not ready for use in
project yet.
The future
OOPSLA 2018
To appear

Why types?
- Last week: "guarantee absence of run-time type errors"
What is a type system?
- A type system is a tractable syntactic method for proving the absence of
certain program behaviors by classifying phrases according to the kinds of
values they compute. [Pierce2002]
Discuss using a series of untyped examples
- Do you consider the example correct or not, and why?
‣ That is, do you think it should type-check?
- If incorrect: what types will disallow this program?
- If correct: what types will allow this program?
Why types?
!10

How do types show up in programs?
- Type literals describe types
- Type deﬁnitions introduce new (named) types
- Type references refer to named types
- Declared variables have types (x : T)
- Expressions have types (e : T)
‣ Including all sub-expressions
Preliminaries
!11
class A {
B b;
int m(int i) {
return i + b.f;
}
}
class B {
int f;
}

Types Example
!12
4 / "four"
4 : number
"four" : string
/ : number * number → number
typing prevents undefined runtime behavior
simple
types

Types Example
!13
7 + (if (true) { 5 } else { "four" })
7 : number
5 : number
- typing (over)approximates runtime behavior
- programs without runtime errors can be rejected
"four" : string
if : ?
no
simple
type

Types Example
!14
function id(x) { return x; }
id(4); id(true);
4 : number
true : boolean
id : ∀T.T→T
- richer types approximate behavior better
- depends on runtime representation of values
polymorphic
type

Types Example
!15
if (a < 5) { 5 } else { "four" }
- richer types approximate behavior better
- depends on runtime representation of values
5 : number
"four" : string
if : number|string
union
type

Types Example
!16
float distance = 12.0, time = 4.0
float velocity = time / distance
distance : float<m>
time : float<s>
velocity : float<m/s>
- no runtime problems, but not correct (v = d / t)
- types can enforce other correctness properties
unit-of-measure
type

- Simple int, float→float, bool
- Named class A, newtype Id
- Polymorphic List<X>, ∀a.a→a
- Union/sum (one of) string|string[]
- Unit-of-measure float<m>, float<m/s>
- Structural { x: number, y: number }
- Intersection (all of) Comparable&Serializable
- Recursive μT.int|T*T (binary int tree)
- Ownership &mut data
- Dependent – values in types Vector 3
- ... many more ...
What kind of types?
!17

Why types?
- Statically prove the absence of certain (wrong) runtime behavior
‣ “Well-typed programs cannot go wrong.” [Reynolds1985]
‣ Also logical properties beyond runtime problems
What are types?
- Static classiﬁcation of expressions by approximating the runtime values they
may produce
- Richer types approximate runtime behavior better
- Richer types may encode correctness properties beyond runtime crashes
What is the difference between typing and testing?
- Typing is an over-approximation of runtime behavior (proof of absence)
- Testing is an under-approximation of runtime behavior (proof of presence)
Why types?
!18

Types inﬂuence language design
- Types abstract over implementation
‣ Any value with the correct type is accepted
- Types enable separate or incremental compilation
‣ As long as the public interface is implemented, dependent modules do not change
Can we have our cake and eat it too?
- Ever more precise types lead to ever more correct programs
- What would be the most precise type you can give?
‣ The exact set of values computed for a given input?
- Expressive typing problems become hard to compute
- Many are undecidable, if they imply solving the halting problem
- Designing type systems always involves trade-offs
Types and language design
!19

Comparing Types
!21
interface Point2D { x: number, y: number }
interface Vector2D { x: number, y: number }
var p1: Point2D = { x: 5, y: -11 }
var p2: Vector2D = p1
Is this program correct?
- No, if types are compared by name
- Yes, if types are compared based on structure

Comparing Types
!22
interface Point2D { x: number, y: number }
interface Point3D { x: number, y: number, z: number }
var p1: Point3D = { x: 5, y: -11, z: 0 }
var p2: Point2D = p1
- No, if equal types are required
- Yes, if structural subtypes are allowed
- When is T a subtype of U?
‣ When a value of type T can be used when a value of U is expected
- What about nominal subtypes?
‣ interface Point3D extends Point2D

Combination example: generics and subtyping
!23
class A {}
class B extends A {}
B[] bs = new B[1];
A[] as = bs;
as[0] = new A();
B b = bs[0];
subtyping on arrays &
mutable updates is unsound
- unsound = under-approximation of runtime behavior
- feature combinations are not trivial

Comparing Types
!24
int i = 12
float f = i
- No, ﬂoats and integers have different runtime representations
- Yes, possible by coercion
‣ Coercion requires insertion of code to convert between representations
- How is this different than subtyping?
‣ Subtyping says that the use of the unchanged value is safe

What kind of relations between types?
- Equality T=T – syntactic or structural
- Subtyping T<:T – nominal or structural
- Coercion – requires code insertion
Type Relations
!25

!27
Source
Code
Editor
Parse
Abstract
Syntax
Tree
Type Check
Check that names are used correctly and that expressions are well-typed
Errors

What is a type system?
- A type system is a tractable syntactic method for proving the absence of certain
program behaviors by classifying phrases according to the kinds of values they
compute. [Pierce2002]
Type system specification
- (Formal) description of the typing rules
- For human comprehension
- To prove properties
Type checking algorithm
- Executable version of the specification
- Often contains details that are omitted from the specification
 
 
Developing both is a lot of work, often only an algorithm
Type system of a language
!28

What should a type checker do?
- Check that a program is well-typed!
- Resolve names, and check or compute types
- Report useful error messages
- Provide a representation of name and type information
‣ Type annotated AST
This information is used for
- Next compiler steps (optimization, code generation, …)
- IDE (error reporting, code completion, refactoring, …)
- Other tools (API documentation, …)
How are type checkers implemented?
How to check types?
!29

Computing Type of Expression (recap)
!30
function (a : int) = a + 1
rules
type-check(|env):
Fun(x, t, e) -> FUN(t, t')
where <type-check(|[(x, t) | env])> e => t'
type-check(|env):
Var(x) -> t
where <lookup> (x, env) => t
type-check(|env):
Int(_) -> INT()
type-check(|env):
Plus(e1, e2) -> INT()
where <type-check(|env)> e1 => INT()
Fun("i", INT(),
Plus(Var("i"), Int(1)))
FUN(INT(), INT())

Inferring the Type of a Parameter
!31
function (a : int) = a + 1
rules
type-check(|env):
Fun(x, t, e) -> FUN(t, t')
where <type-check(|[(x, t) | env])> e => t'
type-check(|env):
Var(x) -> t
type-check(|env):
Int(_) -> INT()
type-check(|env):
Plus(e1, e2) -> INT()
Fun("i", INT(),
Plus(Var("i"), Int(1)))
FUN(INT(), INT())
Unknown t!
- What are the consequences for our algorithm?
- Our types are not known from the start, but learned gradually
- A simple down-up traversal is insufﬁcient

How can we type check this program?
- Is there a possible down-up strategy here?
- Why are the type annotations not enough?
- What strategy could be used?
Two-pass approach
- The ﬁrst pass builds a class table
- The second pass checks expressions using the
class table
- Does this still work if we introduce nested
classes?
Checking classes
!32
class A {
B m() {
return new C();
}
}
class B {
int i;
}
class C extends B {
int m(A a) {
return a.m().i;
}
}

What are challenges when implementing a type checker?
- Collecting necessary binding information before using it
- Gradually learning type information
What are the consequences of these challenges?
- The order of computation needs to be more ﬂexible than the AST traversal
How to check types?
!33

Type Checking
with Constraints
34

Two phase approach
- First record constraints (type equality, name resolution)
- Then solve constraints
Separation of concern
- Language specific specification in terms of constraints
- Language independent algorithm to solve constraints
- Write specification, get an executable checker
Advantages
- Order of solving independent of order of collection
- Natural support for inference
- Many constraint-based formulations of typing features exist
- Constraint variables act as interface between different kinds of constraints
 
Combining different kinds of constraints is still non-trivial!
Constraint-based type checking
!35

!36
Source
Code
Editor
Abstract
Syntax
Tree
ErrorsCollect Constraints Solve
Type checking proceeds in two steps
language
specific
language
independent
Parse

Use Variables and Constraints
!37
Eq(VAR("a"), INT())
Eq(INT(), INT())
+
VAR("a") => INT()
rules
type-con(|env):
Fun(x, e) -> (FUN(t, t'), C)
where !VAR(<fresh>) => t;
<type-con(|[(x, t) | env])> e => (t', C)
type-con(|env):
Var(x) -> (t, [])
type-con(|env):
Int(_) -> (INT(), [])
type-con(|env):
Plus(e1, e2) -> (INT(), [ C1*, C2*,
Eq(t1, INT()),
Eq(t2, INT()) ])
where <type-con(|env)> e1 => (t1, C2*)
where <type-con(|env)> e2 => (t2, C1*)
function (a) = a + 1
Fun("i", Plus(Var("i"), Int(1)))
FUN(VAR("a"), INT())
Constraint solving order != constraint generation order

Types
- Static approximation of runtime values computed by expressions
- Prove correctness properties, such as the absence of runtime errors
Type Checking
- Check if programs are well-typed, according to the type system rules
- Challenges around computation order and partial information
Constraint-based type checking
- Language-speciﬁc speciﬁcation
- Language-independent solver
- Resolution order is independent of the AST traversal order
Summary
!39

Except where otherwise noted, this work is licensed under

Compiler Construction | Lecture 7 | Type Checking

More Related Content

What's hot (20)

Similar to Compiler Construction | Lecture 7 | Type Checking (20)

More from Eelco Visser (20)

Recently uploaded (20)

Compiler Construction | Lecture 7 | Type Checking