1. Type Systems

2. Haskell & ML: Interesting Features
Type inferencing
Freedom from side effects
Pattern matching
Polymorphism
Support for higher order functions
Lazy patterns / lazy evaluation
Support for object-oriented programming
31 March 1999
CS655 - P.F. Reynolds

3. Type Inferencing
Def: ability of the language to infer types without having programmer provide type signatures.
SML e.g.:
fun min (a: real, b)
= if a > b
then b
else a
type of a has to be given, but then that’s sufficient to figure out
type of b
type of min
What if type of a is not specified?
- could be ints
- could be bools...
31 March 1999
CS655 - P.F. Reynolds

4. Type Inferencing (cont)
Haskell (as with ML) guarantees type safety
Haskell example:
eq = (a = b)
a polymorphic function that has a return type of bool,
assumes only that its two arguments are of the same type and can have the equality operator applied to them.
ML has similar assumption, for what it calls equality types.
Overuse of type inferencing in both languages is discouraged
declarations are a design aid
declarations are a documentation aid
declarations are a debugging aid
31 March 1999
CS655 - P.F. Reynolds

5. Polymorphism ML: fun factorial (0) = 1 Haskell: factorial (0) = 1
= | factorial (n) = n * factorial (n - 1)
ML infers factorial is an integer function: int -> int
Haskell:
factorial (0) = 1
factorial (n) = n * factorial (n - 1)
Haskell infers factorial is a (numerical) function: Num a => a -> a
31 March 1999
CS655 - P.F. Reynolds

6. Polymorphism (cont) ML: fun mymax(x,y) = if x > y then x else y
SML infers mymax is ambiguous
fun mymax(x: real ,y) = if x > y then x else y
SML infers mymax is real
Haskell:
mymax(x,y) = if x > y then x else y
Haskell infers mymax is an Ord function
31 March 1999
CS655 - P.F. Reynolds

7. Polymorphism (Cardelli & Wegner)
Universe, V, of all values
A Type is a set of values selected from V (subset of V)
Sometimes only way to enumerate is through constants and functions
An Ideal is a type that satisfies certain "technical" properties
(one would not identify a type containing integers and Int-> Int functions)
All types found in programming languages are ideals
(Value) Having a type::= membership in a set.
Because ideals can overlap, a value can have many types
A type system (in a language) is a collection of ideals of V
Languages provide support for defining which types are mappable onto ideals
31 March 1999
CS655 - P.F. Reynolds

8. More Terms
Monomorphic Type System: a value belongs to at most one type
Polymorphic Type System: a value may belong to many types
Mostly Monomorphic Mostly Polymorphic
One or the other characterizes individual languages
Polymorphism, as it relates to:
values and variables: may have more than one type
functions: arguments can be of > one type
types: operations are applicable to operands of more than one type
31 March 1999
CS655 - P.F. Reynolds

9. Polymorphism: A Taxonomy
Universal: infinite number of types with common structure
Parametric: uniformity of type structure
is achieved by type parameters
Universal
Inclusion: object can belong to many
different classes that need not be
disjoint (subtypes & inheritance)
Polymorphism
Overloading: same name used to denote
different functions. Use determined
from context
Ad Hoc
Coercion: a semantic operation required
to convert an argument to a type
expected by a function.
Ad Hoc: finite set of potentially unrelated types.

10. Exploring Terminology…
Is inclusion polymorphism a kind of parametric polymorphism?
Consider invocation of a method (behavior) in C++ (Smalltalk): selection is based (parametrically) on type…
Why is inclusion polymorphism not a form of parametric polymorphism?
Are generics (templates) a form of universal polymorphism?
Cardelli & Wegner: no
Day et. al.: yes (parametric)
Is there a difference between/among subtypes, subclasses and inheritance?
Subtypes: derived type’s methods/data subsume parent type’s
Subclasses: structuring
Inheritance: subtypes + subclasses -> specialization
31 March 1999
CS655 - P.F. Reynolds

11. Cardelli on Type Systems
purpose is to prevent occurrence of execution errors during runtime
Type Sound Language
absence of execution errors holds for all program runs that can be described in a programming language
Typechecker
method for determining if type errors occur
ambiguities in language specifications often lead to different type checker implementations, hampering language soundness.
Type
“Upper bound” (maximal set) on range of values a variable can take on
Typed Language
one in which variables can be given (nontrivial) types
How about “can assume”?
31 March 1999
CS655 - P.F. Reynolds

12. More Cardelli on Types Explicit / implicit typing Trapped errors
as names suggest…
Trapped errors
execution error when computation stops “immediately”
Untrapped errors
execution errors that go unnoticed and cause arbitrary behavior
Safe program fragment
one that does not (cannot?) cause untrapped errors to occur
Safe language
one in which all program fragments are safe
31 March 1999
CS655 - P.F. Reynolds

13. Safety and Typed Languages
“Untyped languages may enforce safety by performing run time checks.”
“Typed languages may also use a mixture of run time and static checks.”
-- Is an untyped language that enforces safety
comprehensively at run time equivalent to a
typed language that uses run time checks
exclusively?
31 March 1999
CS655 - P.F. Reynolds

14. Off on Good Behavior Forbidden errors Good Behavior (well behaved)
all untrapped errors plus some trapped errors
(what trapped errors might be included?)
Good Behavior (well behaved)
no forbidden errors occur
a well behaved program fragment is safe
Strongly checked language
One in which all (legal) program fragments have good behavior
no untrapped errors occur
none of the specified trapped errors occur
other trapped errors may occur - programmer must avoid them
(notice avoidance of “strongly typed”)
31 March 1999
CS655 - P.F. Reynolds

15. Safety and Typed Typed Untyped ML LISP Safe C Assembler Unsafe
-- Cardelli argues languages should be safe and typed
(Should type system be implicit, or explicit, or both?)
31 March 1999
CS655 - P.F. Reynolds

16. ML Type Inferencing Key concepts: Type variables Substitution
Unification
Most general unifiers
Inferencing
Hindley-Milner
31 March 1999
CS655 - P.F. Reynolds

17. Type Variables/Instances
tyvar::= ‘identifier
e.g.: ‘a ‘b ‘m
provide for polymorphism
Type instances:
int <: ‘a -- int is an instance of ‘a
int list <: ‘a -- list of ints is an instance of ‘a
int list <: ‘a list -- int list is an instance of list of ‘a
int <: ‘a list -- int is NOT an instance of list of ‘a
A precise definition requires substitution for type variables
31 March 1999
CS655 - P.F. Reynolds

18. Substitution/Unification
replacement of type variable by another type variable or a concrete type
e.g. Replacing ‘a by int, or ‘a by ‘b list
Unification:
t1 and t2 are unified by substitution s if
st1 = st2
e.g. unification of ‘a * int and int * ‘b is:
‘a --> int, ‘b --> int
(yielding int * int)
31 March 1999
CS655 - P.F. Reynolds

19. Most General Unifiers Make no unnecessary assumptions:
‘a list and ‘b are unified by ‘a --> int list, ‘b --> int list list
‘a list and ‘b are unified by ‘b --> ‘a list
Which unifier is more general?
s1 is an instance of s2 iff
there exists s such that s1 = ss2
For example above:
s = ‘a --> int list
The most general unifier of types t1 and t2 is a substitution s such that:
t1 and t2 are unified by s
and there is no more general s’ that also unifies t1 and t2
31 March 1999
CS655 - P.F. Reynolds

20. ML Type Inferencing Example
fun find p [] = false
| find p (x::S) = if p x then true
else find p S
Initial type environment:
false: bool
true: bool
if: bool * ‘e * ‘e -> ‘e
No assumptions about find:
find: ‘k
lambda: new r with fresh type variables for parameters:
p: ‘i
(x::S): ‘j
31 March 1999
CS655 - P.F. Reynolds

21. ML Type Inferencing Example (2)
fun find p [] = false
| find p (x::S) = if p x then true
else find p S
Analysis:
(x::S) implies ‘j --> ‘c list
p x implies ‘i --> ‘c -> ‘l
if p x implies ‘l --> bool
if ... true else find ... implies ‘k --> ‘m -> bool
find p implies ‘m --> (‘c -> bool) * ‘n
find ... S implies ‘n --> ‘c list
Composing all substitutions yields:
(x::S): ‘c list
p : ‘c -> bool
find: (‘c -> bool) * ‘c list -> bool
31 March 1999
CS655 - P.F. Reynolds

22. Constraint-Based Type Inference and Parametric Polymorphism Ole Agesen (Stanford) 1994
Constraint-based analysis: technique for inferring implementation types
Using flow analysis to build network of type variables connected by constraints
Program can be viewed as collection of slots and expressions
x ¬ 0 // slot declaration
x := y + 1 // Expression (y+1) and slots (x,y)
31 March 1999
CS655 - P.F. Reynolds

23. Three Step Process: Steps 1 & 2
Allocating "type variables" to every slot and expression
Initially empty
Process of type inference binds types to type variables
On termination of inferencing, type variables hold "sound types"
Inference exhibits montonicity: type variables have types added, only.
Seeding type variables
Find obvious cases where type is known and assign to type variable
e.g. x ¬ // x’s type is the type of the literal 0.
31 March 1999
CS655 - P.F. Reynolds

24. Three Step Process: Step 3
Establishing constraints and propagating (repeat until termination)
Connect type variables into a network by adding directed edges
Nodes are type variables; edges are constraints
Whenever constraint is added, object types are propagated
One constraint generated for each data flow in the program
assignment generates data flow from expr to assigned variable
variable access gens data flow from variable to accessing expression
message send (or func call) generates flows from actuals to formals and result generates flow back to message send (invocation point)
31 March 1999
CS655 - P.F. Reynolds

25. IF Expression Data Flows
31 March 1999
CS655 - P.F. Reynolds

26. Templates
31 March 1999
CS655 - P.F. Reynolds

27. Template Examples
31 March 1999
CS655 - P.F. Reynolds

28. Inference Algorithms Basic - just saw it.
works when all uses of a method are "similar”
fails when two or more uses of method supply different types of arguments, whether or not uses are individually polymorphic
only one max template is created; may need more than one
1-level expansion: retype each method for each send invoking it.
(would separate template shown on right on previous slide into two)
Works when polymorphic call chain is only one level deep
Fails when polymorphic call chain is > 1 level deep
usual case
31 March 1999
CS655 - P.F. Reynolds

29. 1-Level Expansion Algorithm: Failure
31 March 1999
CS655 - P.F. Reynolds

30. P-Level Expansion Algorithm
Generalization of 1-Level algorithm
expand to depth of p, then apply basic algorithm
Size of expanded program is exponential in p !!!
For any p, it’s possible to find a code sequence that requires p+1 expansions.
31 March 1999
CS655 - P.F. Reynolds

31. Adaptive Inference Algorithms
Precise inference algorithms must not mix types
Types mix if two incompatible activation records are represented by the same template
Create lots of templates so they represent fewer activation records
Efficient type inference requires processing as few templates as possible
Template creation carries a computational cost
1-level algorithm does poorly in both cases
Desire algorithm that is precise and efficient
Adaptive algorithms attempt to create templates only when needed
Lump similar activation records in one template when possible
Success is when algorithm operates at a cost proportional to the amount of polymorphism in the program.
31 March 1999
CS655 - P.F. Reynolds

32. Adaptive Inference Algorithms (2)
(N1, N2)
31 March 1999
CS655 - P.F. Reynolds

33. Hash Function Algorithm

34. Hash Function Algorithm (2)

35. Hash Function Algorithm (3)
Algorithm controls polymorphism at receiver well
e.g.
444 value: nil With: nil With: nil.
3.5 value: 100 With: 100 With: 100
will map to receiver types of [integer] and [float] resp. i.e. the two sends do not interfere. Two distinct sets of templates will be created.
Hash algorithm clearly fails on polymorphic arguments since argument types are not considered
One work-around is to always force templates to not be shared for methods such as ifTrue: False
Has obvious computational costs
31 March 1999
CS655 - P.F. Reynolds

36. Iterative Algorithm
A significant improvement over hash function algorithm
First iteration is to apply the basic algorithm
creates one shared template for each method
In subsequent iterations, less is shared
Key idea: use type information on previous iteration to decide whether or not to share templates in current iteration.
typei-1(rcvrExp1, N1) = typei-1(rcvrExp2, N2)
typei-1(argExp1, N1) = typei-1(argExp2, N2)
for:
rcvrExp1 max: argExp1 (in context N1)
rcvrExp2 max: argExp2 (in context N2)
Share a template Û
31 March 1999
CS655 - P.F. Reynolds

37. Iterative Algorithm (2)
Advantage: complete type information is available from previous iteration
Iterative algorithm has more information available when making critical decision
Iterative algorithm uses types of both receiver and arguments (but from the previous iteration)
Termination is a key consideration
after fixed number of steps (e.g )
when a fix point is reached
may never be reached in face of recursion
With this algorithm (using fix-point termination), analysis time is proportional to amount of polymorphism in the program.
31 March 1999
CS655 - P.F. Reynolds

38. Summary
31 March 1999
CS655 - P.F. Reynolds