rec

					  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?

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:3/20/2013
language:English
pages:34