Derivation for the Necessity of Recursive Types and its Basic Usage

Transcription

1 Derivation for the Necessity of Recursive Types and its Basic Usage Philipp Koster Supervised by Prof. Dr. Farhad D. Mehta Seminar AT Abstract This paper derives the need for recursive types by simulating recursion in the untyped lambda calculus extending it with types of the simply typed lambda calculus showing the flaws of this typed recursion Further recursive types will be introduced by the derivation of the µ-operator defining equality of recursive types defining a well-typed fixpoint-combinator After introducing the recursive types the concept will be clarified with more usage examples. The key challenge of this paper will be to derive and explain the need of recursive types in a simple, nonetheless compact form. 1

2 2 Introduction Most programming languages do have built-in recursion. For example in Java a factorial function, which references itself, can be defined like this: public static long factorial ( long n) { if (n == 1) return 1; else return n * factorial ( n - 1); } The same can be done in the untyped and simply typed lambda calculus. Concerning the typing of the recursion, there exists some flaws, where recursive types will be an elegant solution for. In this paper will first these flaws be shown. Afterwards, will the recursive types be introduced to correct them. In the end, some more examples for the use of recursive types will be shown. 3 Derivation for Recursive Types In this section, the need for recursive types will be derived. Therefore, the factorial function will be implemented in the untyped lambda calculus. Later, the implementation will be enriched with types from the simply typed lambda calculus. In the end, the flaws of this solution will be shown. 3.1 Recursion in the Untyped Lambda Calculus In this section, the possibility to simulate recursion in the untyped lambda calculus, which has no built-in recursion, will be derived and explained. The approach to explain this as easy as possible is inspired by the following article [9]. This paper does not explain the whole untyped lambda calculus to the reader. This means that an understanding of its elements and use is required. Only some selected elements will be recapitulated shortly. If the basic knowledge is not provided, the following papers will help [2], [7]. Additionally, is it important to mention that some terms will be used without defining them beforehand (e.g. if, else, *, =). Furthermore, a slightly invalid form can be used to simplify terms. This, because it will lead to much more compact expressions. 2

3 The untyped lambda calculus is defined as follows: Syntax t ::= x λx.t t t terms: variable abstraction application Figure 1: Syntax of the untyped lambda calculus As known is it not possible to assign a term to a variable and reference this term in the assignment. Therefore, the following definition of the factorial function is not possible: factorial = λn.if n = 0 then 1 else n factorial(n 1) This term would only be possible if the language would have a built-in recursion. But as already said, is it possible to simulate recursion in a language without recursion. Therefore, the factorial function must be abstracted first: abstracted-factorial = λfactorial.λn.if n = 0 then 1 else n factorial(n 1) Simply said, is the new abstracted-factorial function a function, which takes an existing factorial function as argument and returns a working factorial function. Therefore, the following definition of a factorial function would work: factorial = abstracted-factorial existing-factorial But since the existing-factorial function does not exist yet, this finding seems to be useless. But indeed, it points in the right direction. Because even tough 3

4 the existing-factorial function does not exist yet, it is possible to define a function factorial0, which works correctly for the argument 0. To do that, the identity function can be passed as first argument to the abstracted-factorial function 1. factorial0 = abstracted-factorial identity Which leads to following implementation: factorial0 = λn.if n = 0 then 1 else n identity(n 1) It is clear that the factorial0 function works for the argument 0 but not for any higher values. But with this definition it is possible to define a factorial1 function like this: factorial1 = abstracted-factorial factorial0 Which is the same as: factorial1 = abstracted-factorial abstracted-factorial factorial0 And leads to the following implementation: factorial1 = λn.if n = 0 then 1 else n factorial0(n 1) 1 Actually, every function could have been used here. The reason why we chose the identity function is simply because it is the simplest known function. 4

5 As it is clear, the factorial1-function works for the arguments 1 and 0. This process can now be repeated infinitely, which would end in a definition like this: factorial =abstracted-factorial abstracted-factorial abstracted-factorial abstracted-factorial abstracted-factorial abstracted-factorial abstracted-factorial... factorial0 (1) Or written in a more compact, although invalid form: factorial = abstracted-factorial factorial (2) This is a function, which always adds one more call of the abstract-factorial function, if the right hand side is substituted. But again, it is not possible to use the defined function in the definition itself, since it would require recursion built into the language. To define a working factorial function, the fixpoint of the abstractedfactorial function is needed. A fixpoint is a value of a function, when applied to the function, results in the same value again. Or in other words, x is the fixpoint of the function f if: x = f(x) Figure 2: Definition of the fixpoint x for the function f In the lambda calculus the fixpoint is a function which, applied to another function, results in the same function. With that in mind, it becomes clear that the factorial function defined in (2) is a fixpoint of the abstracted-factorial function. 5

6 To retrieve a valid fixpoint of the abstracted-factorial, a fixpoint-combinator can be used. The normally used fixpoint-combinator in the untyped lambda calculus is the Curry s paradoxical combinator Y [3]. Its definition is 2 : fix = λf.(λx. f(λy. x x y))(λx. f(λy. x x y)) Figure 3: Definition of the fixpoint-combinator The definition of the fixpoint-combinator is not very intuitive and hard to understand. But applying it to the function f, leads to following reductions: fix f =f(fix f) f(f(fix f)) f(f(f(fix f))) f(f(f(f(fix f))))... Which is exactly equivalent to applying the abstracted-factorial an infinite time to itself, as done in (2). Therefore, the fixpoint-combinator can be applied to the abstract-factorial function to get the expression from (2): factorial = fix abstracted-factorial 2 There is a slightly simpler fixpoint-combinator for the call-by-name setting, which is useless in the call-by-value setting. 6

7 Finally, the factorial function can be defined in the untyped lambda calculus: abstracted-factorial = λfactorial.λn.if n = 0 then 1 factorial = fix abstracted-factorial else n factorial(n 1) Figure 4: Definition of the factorial function with the fixpoint-combinator Of course can the fixpoint-combinator not only been used for the factorial function, but for all recursive functions. It is even part of functional programming languages like Haskell (see [10]). The next challenge will be to type a recursive function. This will be done in the next section. 3.2 Extending Recursion with Simply Types In section 3.1 have been shown that recursion is possible in the untyped lambda calculus. In this section it will be shown how to extend this recursion with types from the simply typed lambda calculus. As in section 3.1 for the untyped lambda calculus, in this section a basic knowledge for the simply typed lambda calculus is required by the reader. If not provided, the following papers can help [8], [4]. The obvious first approach to get recursion in the simply typed lambda calculus is to simply add types to a recursive function, as the factorial function: abstracted-factorial = λfactorial:nat Nat. (1) λn:nat. if n = 0 then 1 else n factorial(n 1) factorial = fix abstracted-factorial (2) But how could the fixpoint-combinator be typed? This is actually not possible only using simply types. The reason for this is the fact that the simply typed 7

8 lambda calculus is strongly normalizing. This means for every well-typed term a normal form can be found. The normal form is the form of a term which can not be diverged any further. In other words, every well-typed term is guaranteed to halt in a finite number of steps [5]. But since the fixpoint-combinator does not have a normal form, because it never terminates, it is not possible to type it. To get around these circumstances, the simply typed lambda calculus must be extended by adding fix as a new primitive with the corresponding evaluation rules 3. The new primitive and the corresponding typing rule looks like this 4 : New syntactic forms t ::=... fix t terms: variable New typing rules Γ t 1 : T 1 T 1 Γ fix t 1 : T 1 (T-Fix) Figure 5: Adding fix as new primitive with corresponding typing rule With the new primitive the defined factorial function (1) from the beginning of this section is typed correctly. Regarding T-Fix, has the abstractfactorial function t 1 the type Nat Nat. This leads to the resulting type for the factorial function (2), namely N at. From this it follows, that the factorial function is typed Nat Nat. The recursive factorial function have now been typed in the simply typed lambda calculus, by adding a new primitive. But would it be possible to type the fixpoint-combinator itself and getting rid of the manually added fix 3 This extended simply typed lambda calculus is also known as PCF, which was introduced by [6]. 4 The new evaluation rules are not shown, since they are not important for the understanding of the concept. Furthermore, is the letrec construct, which would lead to a simpler syntax, not covered by this paper. 8

9 primitives? This is possible with the recursive types, which will be introduced in the next section. 4 Introducing Recursive Types In this section, the recursive types will be introduced. Recursive types can be used to define a well-typed fixpoint-combinator. In section 3.2, a new primitive was added to get around the fact that it is not possible to assign a type to the fixpoint-combinator with the simply typed lambda calculus. But what type system would be necessary to type following fixpoint-combinator 5? fix = λf.(λx. f(x x))(λx. f(x x)) When applying fix to the abstracted-factorial, the following expression results: fix abstracted-factorial = (λx. abstracted-factorial(x x))(λx. abstracted-factorial(x x)) Since the abstracted-factorial function takes an argument with the type N at, the x function should return this. This leads to the type for x: Nat Nat. But since x is also applied to itself, it has to take Nat Nat as argument too. In other words, the x function has to be able to take arguments with the following types: Nat Nat Nat But since Nat Nat Nat, such a type for x cannot be expressed. Recursive types, or more precisely the µ operator is required for this. 4.1 µ operator The µ operator is an abstraction operator for types, as λ is an abstraction operator for functions. It allows recursive type definitions, which can be used 5 To simplify the expression, the simpler call-by-name fixed point combinator is used. 9

10 to represent an infinite number of types. The µ operator can for example be used to type following NatList 6 : NatList = < nil : Unit, cons : {Nat, NatList} >; This NatList makes use of labeled variants, where nil and cons are field labels. The type of nil is Unit and the type of cons is a 2-tuple {Nat, NastList}. It is clear, that NatList diverges to a infinite tree, since the type of cons recursively references the N atlist. In Java, this type could look like this: public class NatList { public int value ; public NatList list ; } With the µ operator, it is possible to write this type like this: NatList = µx. < nil : Unit, cons : {Nat, X} >; This definition can be read as: NatList is the infinite type satisfying the equation X =< nil : Unit, cons : {Nat, X} >. The exact meaning of this and more usage examples will be shown in the section 4.4. But first, the equality for recursive types has to be defined, by formalizing it. The two different approaches are shown in the next section. 4.2 Equality for recursive types As seen in the previous section, diverges recursive type definitions. Going one step deeper into the type tree is called unfolding. Regarding the definition of the µ-operator µx.t, it means replacing all occurrences of X in the body T with the whole recursive type. For example, does the definition of NatList from the previous section, unfolds to following type: unfold µx. < nil : Unit, cons : {Nat, X} >= µx. < nil : Unit, cons : {Nat, µx. < nil : Unit, cons : {Nat, X} >} > 6 This example of a NatList is taken from [5]. 10

11 But are the old and the new type equal? There are two different approaches to define the equality. The equi-recursive approach defines two types to be equal if they stand for the same infinite tree. In other words, two types are equal, regardless of how many times one of them has been unfolded 7. The consequence of this definition is that it will be complex for a typechecker to decide if two types are equal 8. The second approach is the iso-recursive approach. Two types, one unfolded once, are considered to be different but isomorphic. With the isorecursive approach, the unfold and fold functions must be defined, where fold is the inverse function of unfold. A typechecker can use these methods to decide if two types are isomorphic. The equi-recursive approach is generally more intuitive, but it also requires a more complex typechecker. Additionally, the combination with more advanced typing features can lead to theoretical difficulties and even undecidable typechecking problems [5]. The iso-recursive approach on the other hand, does include more complexity for programs, since the fold and unfold operations must be defined 9. But despite the complexity, most functional programming languages are using the iso-recursive approach. After introducing the µ-operator and defining the equality of recursive types, the initial goal of defining a well-typed fixpoint-combinator can be tackled. This will be done in the next section. 4.3 Well-Typed Fixpoint-Combinator After introducing the µ-operator it is possible to define a well-typed fixpointcombinator. In the introduction of the section 4 it was pointed out, that it is not possible to type following expression: fix abstracted-factorial = (λx. abstracted-factorial(x x))(λx. abstracted-factorial(x x)) It was not possible to type it, since x would need the type Nat and the type Nat Nat. Exactly this is now possible with the infinite type µa.a Nat. 7 The unfold operator does actually not exist in the equi-recursive approach, since the term is unfolded implicitly. 8 There are algorithms to check this equivalence, which are proven to be correct [1]. 9 Even tough these definitions can be hidden. 11

12 This because the infinite type contains both types: Nat = µa.a Nat Nat Nat = unfold µa.a Nat = µa.a Nat Nat Recursive types can be used to define a type for the fixpoint-combinator likes this: fix T = λf : T T.(λx : (µa.a T ).f(x x))(λx : (µa.a. T ).f(x x)) The function f has the type T T. The two occurrences of x have the recursive type µa.a. T. This well-typed fixpoint-combinator fix T can now be used to define well-typed terms. For example, the factorial function can be defined as follows: abstracted-factorial = λfactorial.λn.if n = 0 then 1 factorial = fix T abstracted-factorial else n factorial(n 1) Finally, it is possible to define a well-typed fixpoint-combinator with recursive types. It is not necessary anymore to add fix as a primitive, as done in section 3.2. But recursive types can be used for other things as well. In the next section more examples for the use of recursive types will be shown. 4.4 Examples for Recursive Types In this section, two more examples for the use of recursive types will be shown Hungry Function A simple example for the use of recursive types is the definition of a function, which accepts an infinitely amount of arguments. The function is always 10 The examples are taken from [5]. 12

13 hungry for more. The type and the function can be defined like this: Hungry = µa. Nat A; hungry-function = fix(λf : Nat Hungry.λn : Nat. f); Applying the hungry-function to a number, a new hungry-function will be returned, which accepts again a number. This function does not make a any sense, but it shows the possibility to type it with recursive types Function Objects A good example for the use of recursive types, is the type for a functional object. A functional object can be defined by using records 11. Whereas each field of the record is a function of the object. When calling these functions, not the internal state of the object is mutated, but a new object with the new state is created and returned. The recursive types are used to type the functions accordingly. Counter = µc. {get : Nat, inc : Unit C, dec : Unit C} This type can now be used when creating a new object: c = let create = fix(λf :{x : Nat} Counter.λs : {x : Nat}. {get = s.x, {inc = λ : Unit.f{x = succ(s.x)}, {dec = λ : Unit.f{x = pred(s.x)}} in create {x = 0} Figure 6: Defining a purely functional counter object with recursive types For creating the object c, let bindings are used. The expression let create = fix(...)in create {x = 0} evaluates the fix(...) function and assigns its value 11 A record can be thought of as labeled tuple. 13

14 to create. Afterwards, create is applied to {x = 0}, to create the object c. The created object c can now be used like this: c1 = c.inc unit; c2 = c1.inc unit; Whereas the value for c2 is now 2. As already said, are c1 and c2 different objects. But with recursive types, they have the same type. 5 Conclusion This paper has shown in section 3.1 how recursion can be implemented in the untyped lambda calculus. This was done by using the fixpoint-combinator. In section 3.2 the recursion was extended with types of the simply typed lambda calculus. But it was not possible to type the fixpoint-combinator. This has been solved by adding fix as a new primitive. In section 4 recursive types were introduced. With the µ operator, it is possible to define infinite types. It has been shown that there exists to approaches to define the equality for types with the µ-operator: iso-recursive and equi-recursive. With recursive types, it was finally possible to type the fixpoint-combinator, without adding a new primitive. Besides the possibility to type a fixpointcombinator, more examples of recursive types were shown in section 4.4. References [1] Roberto M. Amadio and Luca Cardelli. Subtyping recursive types. In: ACM Transactions on Programming Languages and Systems (1993), pp doi: / url: lucacardelli.name/papers/srt.pdf. [2] Jonas Biedermann. The untyped lambda calculus - examination of theory and practice [3] Giuseppe Castagna. Object-oriented programming a unified foundation. Birkhauser, [4] Daniel Marty. Simply Typed Lambda Calculus

15 [5] Benjamin C. Pierce. Types and Programming Languages. 1 st. The MIT Press, isbn: , [6] G.D. Plotkin. LCF considered as a programming language. In: Theoretical Computer Science 5.3 (1977), pp issn: doi: url: [7] Daniel Schmid. Untyped lambda calculus [8] Marco Syfrig. Typed Lambda Calculus [9] Mike Vanier. The Y Combinator (Slight Return). Aug url: [10] Wikibooks. Haskell/Fix and recursion Wikibooks, The Free Textbook Project. [Online; accessed 11-December-2016] url: https: //en.wikibooks.org/w/index.php?title=haskell/fix_and_ recursion&oldid=