VIEWS: 0 PAGES: 34 POSTED ON: 3/20/2013
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?
Pages to are hidden for
"rec"Please download to view full document