Documents
User Generated
Resources
Learning Center

# rec

VIEWS: 0 PAGES: 34

• pg 1
```									  A Type System for
Well-Founded Recursion
Derek Dreyer
Carnegie Mellon University
POPL 2004
Venice, Italy
Recursive Modules
• Allow mutually recursive functions/datatypes to
be developed independently

• One of the most commonly requested extensions
to the ML languages

• A number of problems, but we will focus on
interaction of recursion and effects

2
Recursive Module Example

3
Backpatching Semantics
• Evaluation of rec(X. M):

?
loc

4
Backpatching Semantics
• Evaluation of rec(X. M):

?          M[!(loc)/X] * V
loc

5
Backpatching Semantics
• Evaluation of rec(X. M):

V           M[!(loc)/X] * V
loc

6
Backpatching Semantics
• Evaluation of rec(X. M):

?          M[!(loc)/X] * V
loc

• But how do we ensure evaluation of M will not
access contents of loc?

7
Backpatching Semantics
• Evaluation of rec(X. M):

?           M[!(loc)/X] * V
loc

• But how do we ensure evaluation of M will not
access contents of loc?
– Dynamic detection (has run-time cost)
– Static detection preferable, but how?
8
In This Talk...
• Study well-founded recursion at term level
– i.e. ignore issues involving type components,
which are largely orthogonal

• Idea: Treat the act of accessing a recursive variable
as a computational effect

9
Recursion Construct
• rec(X B x : . e)
–   x is the recursive variable
–    is its type
–   e is the expression being evaluated
–   X is the name of x,
which represents the effect of accessing x

• Type system ensures e is pure w.r.t. the effect X

10
Typing Judgment
•  ` e :  [S]
– In context , e has type  with support S

• Support = set of names of rec. var.’s that e may access
– i.e. set of effects that may occur when e is evaluated

• Can only safely evaluate e once rec. var.’s named in S
have been backpatched

11
Some Typing Rules

12
Recursion Rule (First Try)

13
Problem
• Say we use rec to define a recursive function:

• Body has type
• Doesn’t match declared type

14
Problem
• What if we change the declared type accordingly?

• Body matches declared type
• Declared type isn’t well-formed outside of the rec

Something is seriously broken!
15
Key Observation

Once a recursive variable has been backpatched,
the effect of accessing it becomes benign,
so we can ignore it!

16
New Recursion Rule

•  ´X  ,  ´  modulo occurrences of X

• Permits mismatch between  and  as long as it
only involves X

17
Problem Solved
• Now our original example typechecks:

• Body has type
•

18
Using Existing Code
• Say we want to use an existing ML function H

• Well-formedness depends on type of H

19
ML Arrow Type
• Suppose that H has the following ML type:

• In our system, ML arrow (->) corresponds to
since ML functions don’t access recursive variables:

20
Using Existing Code

• Ill-typed: f does not match argument type of H

• Good! H(f) could very well have applied f,
resulting in an access of x.

21
Problem
• But what if we eta-expand H(f)...

• Still ill-typed, even though g is now bound to a value!

22
Rethinking the Judgment
•  ` e :  [S] interpreted as:
– In context , e has type  and may have the
effects in S

23
Rethinking the Judgment
•  ` e :  [S] interpreted as:
– In context , e has type  and may have the
effects in S

• Alternative interpretation:
– In context , ignoring the effects in S,
e is pure and has type 

24
Type Conversion Rule

25
Ignorance is Bliss

• X is in the support when typechecking
• Under support X, type conversion rule allows us
to assign f the type            by ignoring X
• So the code is now well-typed!

26
Original Example

• Still ill-typed: H(f) can’t assume X in the support

• But if H is non-strict, then we would like to make
this typecheck

27
Non-strict Functions
• Can encode non-strict function type for H using
name abstractions (effect polymorphism):

• Given this type for H, example from previous slide
will typecheck

28
Separate Compilation
• Also depends on non-strict function types:
– Want to write rec(X B x : . F(x))
– Only well-founded if F is non-strict

• We introduce “box” types to describe F’s argument:

29
Related Work on
Well-Founded Recursion
• [Boudol 01] and [Hirschowitz-Leroy 02]
– Based on tracking non-strictness of functions
–F:           ) F’s argument appears under n
-abstractions in F’s body
– e.g.
– Used as target for compiling OO language
(Boudol) and mixin module calculus (HL)

30
Related Work on
Well-Founded Recursion
• [Boudol 01] and [Hirschowitz-Leroy 02]
– Somewhat brittle as foundation for
recursive modules:

rec(x.
...(y.e)(3)...       may be
...(y.e)(5)...   well-typed, but...
...)

31
Related Work on
Well-Founded Recursion
• [Boudol 01] and [Hirschowitz-Leroy 02]
– Somewhat brittle as foundation for
recursive modules:

rec(x. let f = (y.e) in
...f(3)...        might not be
...f(5)...        well-typed!
...)

32
Rest of the Paper
• Dynamic semantics and type safety theorem

• Recovering dynamic detection by adding memoized
computations to the language

• Future work:
– Type/support inference
– Lifting to level of modules and full ML

33
Grazie! Domande?

```
To top