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 With this paper I ll derive the need for recursive types by, defining recursion in the Untyped Lambda Calculus extending it with Simple Extension of the Simply Typed Lambda Calculus and in the end, showing the limiations of these constructs (especially concerning the fix operator). Further I ll introduce Recursive Types by the derivation of the µ-operator showing and explaining examples (sumlist and Objects) Additionally I ll show the power of Recursive Types by explaining the Definition of a well-typed fix-point combinator (which we were missing in the first chapters). In the end I want to clarify the concept by comparing it to the implementation in Java and / or Haskell. In my opinion, 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 2.1 Structure Explaining the structure of this paper (most likely a shorter form of the abstract). 3 Derivation Explain that we use a simplified and invalid syntax for the lambda calculus Short introduction in this chapter including basic introduction in factorial 3.1 Recursion in the Untyped Lambda Calculus The Untyped Lambda Calculus is defined as follows: Syntax t ::= x λx.t tt terms: variable abstraction abstraction Figure 1: Grammar of the Untyped Lambda Calculus As the definition shows, their is no recursion built in the Untyped Lambda Calculus. (explain why). Wherefore following definition of the factorial is not possible: factorial = λn.if n = 0 then 1 else n factorial(n 1) 2

3 The reason is that it is not allowed to reference the variable in the definition, which is defined by the definition itself. This would only be possible if the language would have a built in recursion. But it is possible to gain recursion in a language without recursion. That for the factorial function must be abstracted in a first step: abstracted-factorial = λf actorial.λ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 for it. Therefore following definition of the 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 the existing-factorial does not exist yet, it is possible to define a factorial0-function, which works correctly for the argument 0. That for simply pass the identity-function as first argument to the abstracted-factorial. factorial0 = abstracted-factorial identity 3

4 Which leads to following implementation: factorial0 = λn.if n = 0 then 1 else n identity(n 1) It is cleary visible that the factorial0-function works for the argument 0 but not for any higher values. But with this definition is is possible to define a factorial1-function like this: Which is the same as: factorial1 = abstracted-factorial factorial0 factorial1 = abstracted-factorial abstracted-factorial factorial0 And leads to following implementation: factorial1 = λn.if n = 0 then 1 else n factorial0(n 1) As it is clearly visible, the factorial1-function works for the arguments 1 and 0. This process can be repeated an infinite time, which would end in a definition like this: factorial =abstracted-factorial abstracted-factorial abstracted-factorial abstracted-factorial abstracted-factorial abstracted-factorial abstracted-factorial... factorial0 Figure 2: abstracted-factorial applied to itself an infinite time Or written in a more compact, even tough invalid form: factorial = abstracted-factorial factorial Figure 3: Compact even tough invalid form of figure 2 Which is a function, which adds always one more call of the abstractfactorial if the right hand side is substitiuted. But again, it is not possible 4

5 to use the defined function in the definition itself, since it would require recursion built in the language. What is necessary to define a working factorial is the fixpoint of the abstracted-factorial. A fixpoint is a value of a function, when applied to a function, results in the same value again. For example x is in following example the fixpoint of the function f: x = f(x) Figure 4: Definition of the fixpoint x for the function f In the Lambda Calculus a fixpoint is a function, which applied to another function, returns a function, which takes the same arguments. With that in mind it is obvious that the factorial-function from figure 3, which was pointed out to be invalid, is a fixpoint of the abstracted-factorial function. To retrieve a valid fixpoint of the abstracted-factorial, a fix-point-combinator can be used. The normaly used fix-point-combinator in the Untyped Lambda Calculus is the Curry s paradoxical combinator Y [Castagna2012]. The definition looks as follows: 1 fix = λf.(λx. f(λy. x x y))(λx. f(λy. x x y)) Figure 5: Definition of the fix-point-combinator Unfortunantly is the definition of the fix-point-combinator is not very intuitive and hard to understand. But simply summarized leads the application of it to the function f 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 figure 2, by simply applying the fix-point-combinator 1 There is a slightly simpler fix-point-combinator for the call-by-name setting, which is useless in the call-by-value setting 5

6 to the abstracted-factorial function: factorial = fix abstracted-factorial Summarized can the recursive factorial function be defined like this in the Untyped Lambda Calculus: abstracted-factorial = λf actorial.λn.if n = 0 then 1 Short summary factorial = fix abstracted-factorial 3.2 Extending Recursion with Simply Types else n factorial(n 1) Recursion in the Untyped Lambda Calculus has been derived in Chapter 3.1. In this chapter will be done the same for the Simply Typed Lambda Calculus. The obvious first approach is to simply add types to a recursive function, for example the already known factorial function. abstracted-factorial = λfactorial:nat Nat. λn:nat. if n = 0 then 1 else n factorial(n 1) factorial = fix abstracted-factorial But how could the fix-point-combinator be typed? This is actually not possible only using simply types. The reason for this is the fact, that the fixpoint-combinator is a divergent combinator. Which means it is not possible to reduce the term to its normal form, because it always diverges. But since the Simply Typed Lambda Calculus is stronlgy normalized [REFERENCE], a normal form is necessary to deduce the type [REFERENCE]. As a workaround a new primitive fix can be added. Where the evaluation and typing rules looks as follows: Syntax t ::=... f ix t terms: variable 6

7 fix(λx : T 1.t 2 ) [x (fix(λx : T 1.t 2 ))]t 2 Add Typing Rules Align Better To have a more intuitive syntax, the so called letrec binding construct can be used: letrec x : T 1 = t 1 in t 2 which is defined to be the same as: def = let x = fix(λx : T 1.t 1 ) in t 2 With this extensions, recursive functions like the well-known factorial can simply be defined like this: letrec factorial : Nat Nat = λm : Nat.if n = 0 then 1 else n factorial(n 1) 3.3 Need for Extension of Simply Types In Chapter 3.2 simple typing was added to the fix-point-combinator. But since the fix-point-combinator can t be typed directly, new primitive types has been added as language features. Still the problem remains, that the resultant typed fix-point-combinator is not well-typed. This because a program, for example a static type checker, can not decide if the term satisfies the type definitions (because, as already pointed out, their is no normal form). It is obvious that a well-typed implementation of the fix-point-combinator is needed to express well-typed recursion. That for a new general mechanism will be introduced. Namely, the Recursive Types. References for this statements 4 Introducing Recursive Types Recursive Types are an extension of the Simply Typed Lambda Calculus. They allow to define recursive type definitions without defining new constants, as done in REFERENCE. Therefore is a new operator introduced, the µ- operator. It can be seen as an abstraction operator for types, as λ is an 7

8 abstraction operator for functions. Additionally it allows to define recursive type definitions, which will lead to infinite type trees. An example for the use of the µ operators is the definition of a NatList: NatList = µx. < nil : Unit, cons : Nat, X > Figure 6: Definition of NatList with µ-operator With this definition is NatList an infinite type, since X is part of the definition itself. Replacing X once with the definition is called unfolding. After unfolding the type NatList once, it looks like this: NatList = µx. < nil : Unit, cons : Nat, < nil : Unit, cons : Nat, X > > Figure 7: One time unfolded NatList The process of unfolding can be repeated an infinite time, wherefore it is called an infinite type. With the equi-recursive approach, which explanation won t be covered with this paper, are two µ-definitions, even tough one is unfolded, considered to be equal. In other words, two types can be equivalent without being the same. Their are algorithms to check this equivalence, for example by a type checker, which are proven to be correct [AmadioCardelli1993]. 4.1 Examples for Recursive Types Besides the already shown NatList are there other great examples to show the power of Recursive Types. It is for example possible to type a counter object, with an get, inc and dec method, where the get method returns the current value and the inc and dec method are modifying the value. This can be done by defining following type: Counter = µc. get : Nat, inc : Unit C, dec : Unit C This type can now be used when creating a new object: 8

9 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 8: Defining a purely functional counter object with Recursive Types The newly created object c does now have the type Counter. After calling for example the inc method on it (c.inc unit) a new object is returned, which contains the incremented value but still has the same type Counter. This is a purely functional approach for objects. The role of the Recursive Types is, that the returned object does have the exactly same type as the object before. Eventually adding another example? 4.2 Enhancing Fix-Point-Combinator Finally after introducing the Recursive Types it is possible to define a welltyped call-by-name fix-point-combinator. It is defined as follows: Clarify if and why it is not necessary to type call-by-value fix-point-combinator fix T = λf : T T.(λx : (µa.a T ).f(x x))(λx.(µa.a. T ).f(x x)) With this definition are the two occurrences of x typed with the infinite type µa.a T. Even tough recursive types break the property of strong normalization, it is possible to define well-typed recursive terms. why? Summarize power of well-typed fix-point combinator 5 Comparison to high level languages Clarify the concept of Recursive Types by show differences and / or equalities to implementations in Java and / or Haskell. Show Recursive Types in Java (= iso-recursive) 9

10 6 Conclusion A short summary about the paper. 10