Notes on evaluating λ-calculus terms and abstract machines

Transcription

1 Notes on evaluating λ-calculus terms and abstract machines J.R.B. Cockett Department of Computer Science, University of Calgary Calgary, T2N 1N4, Alberta, Canada November 17, Introduction In this document we discuss evaluation strategies for λ-terms. We shall present six different evaluation strategies. They are distinguished by whether they are by-value (basically innermost) or by-name (basically outermost) and what sort of normal form they aim to produce. There are three normal forms weak head normal form, head normal form, and normal form. To implement the λ-calculus one must take the further step of translating these reduction strategies into the actions of an abstract machine for which one compiles λ-terms into code. This makes for very simple yet powerful evaluation techniques which are relatively efficient. We illustrate this with two machines: a modern version of Landin s SECD machine and the Krivine machine. 2 Evaluation strategies There are two basic families of evaluation strategies (reduction strategies) for the λ-calculus: byvalue and by-name. The former family of evaluation strategy, by-value, evaluates arguments (and sometimes function bodies) before applying a function to its arguments. The by-value strategies are relatively simple to implement and are reasonably efficient, however, they suffers from a significant defect: they may not find a normal form (or a weak head normal form) even if there is one. The by-name evaluation strategy, are (perhaps) more complex to implement as they leave the arguments unevaluated: this can make the evaluation very inefficient as unevaluated terms can be duplicated thereby doubling the cost of their evaluation. However, the by-name strategies have an important theoretical advantage: if there is a normal form (weak head normal form) they will find it. Because of this considerable effort has been into to making these strategies more efficient and this has led to the development of graph reduction techniques for lazy evaluation : these underly the evaluation of Haskell programs for example. In graph reduction the duplicated terms are shared and, thus, are only evaluated once: in terms of the number of -reduction steps, lazy evaluation does the minimal number possible: however, there is an overhead to sharing terms in order to keep track of when a term has been already evaluated which will sometimes make it less efficient than the simpler by-value evaluation. Both by-value and by-name strategies come in different forms depending on where the evaluation terminates if it does terminate. The weak strategies aim to produce a result in weak head normal form. The essential feature of the weak evaluation strategies is that they never 1

2 evaluate the bodies of λ-abstractions. These evaluation strategies are closely related to what is actually implemented in functional languages: the tendency is to want to compile (and optimize) function bodies and thus to never modify them while the program is running. The strong evaluation strategies aim to produce a term in η-normal form. Strong reduction strategies are primarily of theoretical interest: for example strong by-name evaluation is a leftmost outermost reduction often called normal order reduction and is guaranteed to find a normal form if there is one. Finally there are the head reduction strategies: these evaluate the term to head normal form. Head reduction strategies do go inside the top level λ-abstractions but no others. Head evaluation is also closely related to evaluation strategies for functional languages: when constructors for datatypes are not built in and are natively expressed in the λ-calculus they involve a top level binding which the evaluation must go under. Lastly a remark: writing down formally how an evaluation strategy works may seem easy... but, in fact, it is not so easy! The crucial issue is: how exactly does one efficiently find the next redex to reduce? For example, saying that one always reduces the leftmost outermost redex tells one how to find the next redex from the global perspective of the whole term: however, an implementation of an evaluation which searches for redexes by starting from scratch at each step would be very inefficient and this is never done in practice. Thus, more detailed descriptions are necessary. To this end, below, we use both inference systems and recursive descriptions of the evaluation techniques. (One reason for using inference systems is actually because you must get used to using them!) These lead ultimately to the abstract machines which are used in practice for evaluation. 2.1 By-value evaluation strategies We shall start by discussing by-value evaluation strategies. We shall discuss two of these byvalue strategies. The first first strategy is the innermost strategy: here whenever a reduction is performed all the subexpressions of the redex must be in normal form. Thus the reduction C (λx.m) N C M[N/x] can only be performed once M and N have been reduced to normal form. The second strategy is the rightmost evaluation strategy here the above reduction can be performed but only when N is in normal form. This means that in rightmost evaluation one does not evaluate function bodies - λ-abstractions before applying them. This from a programming perspective is very natural as normally one wishes to compile function bodies into code which one does not rewrite Innermost evaluation This is a strong reduction strategy. As described above, in this strategy one can only perform a -reduction when the subexpressions of the redex are already in normal form. This means that when one encounters a redex one must recursively reduce all it subexpressions this can be done in parallel before one performs the reduction of that redex. This does have the slightly peculiar property that one reduces the body of functions before one applies them and this is not usually how functional languages are implemented. The strategy can be described by the inference system in Table 1. The inferences in the system are to be read as saying that, in order to conclude the statement below the line, one must first have 2

3 M λx.m N N (λx.m ) N L L L M N L Evaluate to abstraction M P Q N N M N (P Q) N Evaluate to application M y N N M N y N Evaluate to variable Var(x) x x Variable M M λx.m λx.m Abstraction Table 1: Innermost Evaluation concluded all the things above the line. Thus, the first rule of Table 1 says that, in order evaluate M N to L written as M N L below the line one must: (a) Evaluate M to an abstraction of the form (here we are working up to α-equality) λx.m. This is indicated by M λx.m If, in fact, M does not evaluate to an abstraction we will use one of the next two rules which are designed to cover the other possible cases. (b) Evaluate N to N, written N N. (c) Perform the -reduction (λx.m ) N (d) Evaluate L to L, that is L L. Consider the following examples: Example 2.1 L. 3

4 (1) Consider the by-value evaluation of (λx.(λy.yy)x)z:. (a) λy.y y λy.y y var(x) (b) x x (c) (λy.y y) x x x (d). x x x x (λy.y y) x x x (a) (λx.(λy.y y) x) λx.x x(b) z z (c) (λx.x x) z z z (d). z z z z (λx.(λy.y y) x) z z z (2) Notice that (λxy.y) Ω does not have a terminating innermost by-value reduction as one must evaluate Ω := (λx.x x) (λx.x x) before one can reduce -reduction at the root of this term: the reduction of Ω, of course, never terminates. Similarly, (λxy.y) (λy.ω) will not have a terminating innermost reduction because of the presence of Ω. (3) We shall use the evaluation of square square 2 as a running example where square := λx.x x In addition we shall, to facilitate this example, allow ourselves the assumption that when two numbers are multiplied they can be reduced to the answer, e.g Here is the structure of the by-value evaluation: (a). square square (a). square square. (b) 2 2 (c) square (d) (b) square 2 4 (c) square (d) square (square 2) 16 4

5 Notice how every subexpression gets evaluated before the whole expression. Also how one normalizes the function bodies: here they are already taken as being in normal form. We may also express the innermost reduction strategy very simply as a recursive function on λ-terms: Rightmost evaluation I(x) = x I(x N) = x I(N) I((λx.M) N) = I(I(M)[I(N)/x]) { L[I(N)/y] I(M N) = λy.l I((M N) P ) = I(M N) I(M) otherwise The basic reduction strategy adopted by SML and OCaml is a weak rightmost reduction strategy. This means arguments to functions are evaluated before functions are applied to them and it is weak because functions are never evaluated. The strong rightmost by-value reduction strategy, however, does allow function bodies to be evaluated but only when they are not applied to any argument. This makes it more complicated to describe as the reduction involves aspects of weak reduction until it is discovered that the λ-term cannot ever be applied when the reduction is pushed under the λ-abstractions Weak rightmost evaluation We shall start by describing the weak rightmost reduction system. The weak reduction strategies reduce λ-terms to what is called weak head normal form. Thus, t w whnf(t) when the reduction terminates we shall see shortly that Ω has no weak head normal form. By way of contrast, the strong rightmost reduction strategy, if it terminates, will do so only at a normal form, thus t s nf(t). A λ-term, M, is in weak head normal form 1 in case it is a λ-abstraction, M = λx.n, or it is of the form M = x N 1... N p where x is any variable. Shortly we shall see that why it is called a weak head normal form it is a head normal form which, in addition could be a λ-abstraction. The weak rightmost reduction strategy is described in Table 2. The key difference is that when a λ-abstraction is encountered the evaluation stops and never goes inside/under the abstraction. Notice also that, the system does evaluate arguments in a rightmost fashion, although the evaluation which distinguishes the cases has been put first for clarity. In fact, the order of evaluation of the arguments does not actually matter and, indeed, can be done in parallel. Thus, if we take the first rule what it says in detail is: In order to evaluate M N to L:, (a) Evaluate N to N. 1 Weak head normal forms were introduced by Simon Peyton Jones to reflect the form to which functional languages actually evaluate. 5

6 (b) M w λx.m (a) N w N (c) (λx.m ) N L (d) L w L M N w L M-evaluate to abstraction (b) M w P Q (a) N w N M N w (P Q) N M evaluate to application (b) M w y (a) N w N M N w y N M evaluate to variable Var(x) x w x Variable λ-abstraction λx.m λx.m Weak reduction Table 2: Weak Rightmost Evaluation (b) Evaluate M to an abstraction λx.m. If it does not evaluate to an abstraction use the appropriate one of the rules which follow... note that each requires that (a) be performed. (c) Perform the -reduction (λx.m )N L. (d) Evaluate L to L. The system even if one evaluates the arguments in a different order, does ensure that arguments are evaluated before functions are applied: this is the key feature of by-value evaluation. Example 2.2 (1) Consider the weak rightmost evaluation of (λxy.y) (λy.y Ω) λ-abstraction (a) (λy.y Ω) w (λy.y Ω) λ-abstraction (b) (λxy.y) w (λxy.y) (c) (λxy.y) (λy.y Ω) λy.y λ-abstraction (d) (λy.y) w (λy.y) (λxy.y) (λy.y Ω) w λy.y This shows that under weak rightmost reduction (here we have swapped (a) and (b) to get strict rightmost reduction) one can have non-terminating subterms which never get evaluated. Note that the innermost reduction strategy will not terminate on this term. 6

7 (2) Note that weak rightmost reduction does not terminate on Ω nor does it terminate on (λxy.y) Ω. We may also express the weak rightmost reduction using a recursive algorithm as follows: R w (λx.l) = λx.l R w (x) = x { Rw (M R w (N M) = [R w (N)/y] R w (M) = λy.m R w (M) R w (N) otherwise Strong rightmost evaluation The idea of strong rightmost evaluation is to perform a rightmost evaluation which does end at a normal form when it terminates. This means, in particular, that the evaluation will sometimes have to go inside λ-abstractions but only when it is not the argument of a -reduction. The reduction strategy is described in Table 3: notice that is more complex as one must flip from a weak reduction strategy to a strong reduction when the head term is not a λ-abstraction and it is necessary to force the evaluation of the arguments. This does mean that one needs to know how the head term evaluates before deciding whether to initiate a strong reduction of the argument. This system is largely a curiosity! It illustrates the technique of getting a full reduction by having a mutually recursive reduction strategy. It is perhaps worth mentioning that this reduction system is best implemented as first evaluating the function to determine how the argument needs to be evaluated (either strongly or weakly). This may be expressed as recursive function by: R s (x) = x R s (λx.m) = λx.r s (M) { Rs (M R s (M N) = [R ws (N)/y]) R ws (M) = λy.m R ws (M) R s (N) otherwise R ws (x) = x R ws (λx.m) = λx.m { Rws (M R ws (M N) = [R ws (N)/y]) R ws (M) = λy.m R ws (M) R s (N) otherwise 2.2 By-name evaluation strategies These are basically outermost evaluation strategies. In an outermost evaluation strategy one always performs -reductions steps which are closer to the root of the term before those which are further from the root. This therefore is exactly the opposite of an innermost evaluation strategy. Thus, if two redexes are nested on must always choose to develop the one closest to the root first. Of course, this does not completely determine the order so one usually combines this with a leftmost strategy which requires that the one always first evaluates the leftmost redex of any two redexes which are in parallel, in the sense of being on different branches of the tree: this is called the leftmost outermost evaluation strategy (were on reads leftmost as a modifier on the basic outermost strategy). 7

8 (b) M ws λx.m (a) N ws N (c) (λx.m ) N L (d) L s L M N s L M-evaluate to abstraction (b) M ws P Q (a) N s N M N s (P Q) N M evaluate to application (b) M ws y (a) N s N M N s y N M evaluate to variable Var(x) M s M x s x Variable λx.m s λx.m Strong reduction (b) M ws λx.m (a) N ws N (c) (λx.m ) N L (d) L ws L M N ws L M-evaluate to abstraction (b) M ws P Q (a) N s N M N ws (P Q) N M evaluate to application (b) M ws y (a) N s N M N ws y N M evaluate to variable Var(x) x ws x Variable λ-abstraction λx.m ws λx.m Weak reduction Table 3: Strong Rightmost Evaluation 8

9 (a) M w λx.m (b) (λx.m ) N (c) L w L M N w L L Leftmost (to abstraction) (a) M w P Q (b) N w N M N w (P Q) N Leftmost (to application) (a) M w y (b) N w N M N w y N Leftmost (to variable) Var(x) x w x Variable λ-abstraction λx.m w λx.m Weak reduction Table 4: Weak by-name evaluation Weak by-name evaluation This is essentially the strategy underlying lazy functional languages except, of course, that these languages use graph reduction techniques to avoid the duplications of subterms which is caused by a -reduction. The reduction here is to weak head normal form. Thus, the evaluation never goes inside/under a λ-abstraction. The strategy is described in Table 4 and, if it terminates will do so on a weak head normal form. The strategy has the merit of being remarkably simple. As mentioned a defect of by-name evaluation is that it can duplicate unevaluated terms, this duplicate the evaluation work making the technique very inefficient. Recall that this problem can be overcome by using graph reduction techniques to share the duplicated terms. Below is an simple illustration of the problem: Example 2.3 9

10 (1) Consider the evaluation of (λxy.y) Ω (λz.n): λ-abstraction (a) λxy.y λxy.y (b) (λxy.y) Ω λy.y λ-abstraction (c) λy.y λy.y (a) (λxy.y) Ω λy.y (b) (λy.y) (λz.n) (λz.n) λ-abstraction (c) λz.n λz.n (λxy.y) Ω (λz.n) λz.n Notice that this evaluates a weak head normal form: Ω, in contrast to the by-value strategies, is never evaluated and, because N is the body of an abstraction we never have to reduce this. (2) Consider the evaluation of square square 2 where square := λx.x x Again, to facilitate this example, allow ourselves the assumption that when two numbers are multiplied they can be reduced to the answer, e.g and that one must to evaluate two multiplied expressions one must minimal evaluate each expression. Here is then (roughly) the structure of the weak by-name evaluation of this expression: defn. and λ-abstraction (a) square λx.x x (b) (λx.x x) (square 2) (square 2) (square 2) (c). square 2 4. square (square2) 16 (square 2) (square 2) 16 square (square 2) 16 Notice how subexpression are not evaluated but duplicated leading to duplicated the evaluation work. We may write this evaluation strategy as a recursive function: N w (x) = x N w (λx.m) = λx.m { Nw (M N w (M N) = [N/y]) N w (M) = λy.m N w (M) N w (N) otherwise 10

11 2.2.2 Strong by-name evaluation As before the purpose of strong by-name reduction is to obtain a normal form rather than a weak head normal form. This means the reduction strategy must sometimes be forced to go inside λ- abstractions: controlling this aspect of the evaluation causes the strategy to be more complex. As above this leads to needing a second evaluation steps N ws N which recursively used the strong evaluation N s N. The evaluation strategy is described in Table 5 together with its mutually recursive definition. The importance of this evaluation strategy is that, if there is a normal form for N, then this reduction strategy will terminate by finding that normal form. This is proven using the standardization theorem which says that any reduction sequence in the λ-calculus can be rearranged to be an outermost reduction and this in turn can be rearranged to be a leftmost outermost reduction. 2.3 Head evaluation The last evaluation strategy is to head normal form: a λ-term is in head normal form if it is of the form λx 1...x n.y N 1...N p where n, p N and so include the possibility of being 0! To evaluate to head normal form it is necessary to evaluate inside the topmost λ-abstractions. This means again that the expression of the reduction strategy is more complex and requires a mutual recursion. This is called a head reduction because, after going inside top-level λ-abstractions, one searches for reductions on the application chains by repeatedly looking down the left branch until a non-application is found: this is the head term of the application chain. If the head term is a λ-abstraction one has a reduction. One simply repeats this process until the head is a variable. 11

12 (a) M w λx.m (b) (λx.m ) N (c) L L M N L L Leftmost (to abstraction) (a) M w P Q (b) N N M N (P Q) N Leftmost (to application) (a) M w y (b) N N M N y N Leftmost (to variable) Var(x) x x Variable M M λx.m λx.m Abstraction (a) M w λx.m (b) (λx.m ) N (c) L w L M N w L L Leftmost (to abstraction) (a) M w P Q (b) N N M N w (P Q) N Leftmost (to application) (a) M w y (b) N N M N w y N Leftmost (to variable) Var(x) x w x Variable Abstraction λx.m w λx.m Weak reduction N (x) = x N (λx.m) = λx.n (M) { N (M N (M N) = [N/y]) N w (M) = λy.m N w (M) N (N) otherwise N w (x) = x N w (λx.m) = λx.m { Nw (M N w (M N) = [N/y]) N w (M) = λy.m N w (M) N (N) otherwise Table 5: Strong by-name evaluation normal order reduction 12

13 (a) M w λx.m (b) (λx.m ) N (c) L L M N L L Head evaluate (to abstraction) M w P Q N N M N (P Q) N M w y M N y N Head evaluate (to application) Head evaluate (to variable) Var(x) x x Variable M M λx.m λx.m Abstraction (a) M w λx.m (b) (λx.m ) N (c) L w L M N w L L Head evaluate (to abstraction) M w P Q N N M N w (P Q) N M w y M N w y N Head evaluate (to application) Head evaluate (to variable) Var(x) x w x Variable Abstraction λx.m w λx.m Weak reduction H(x) = x H(λx.M) = λx.h(m) { H(M H(M N) = [N/y]) H w (M) = λy.m H w (M) H(N) otherwise H w (x) = x H w (λx.m) = λx.m { Hw (M H w (M N) = [N/y]) H w (M) = λy.m H w (M) H(N) otherwise Table 6: Head evaluation 13

14 3 Abstract machines Abstract machines reorganize the evaluation into simple machine transitions which one aims to make nearly constant time steps. One then starts the machine in a state determined by the desired computation and repeatedly do transitions until a final state is reached when one publishes the answer! If one arranges each step to correspond to an instruction then one can compile λ-terms down to a sequence of instructions. Reorganizing the computation into this from allows one to compile λ-terms into code sequences of instructions and introduces the opportunity for more efficient and simpler evaluation due to this compilation step. We shall describe two abstract machines below: a modern version of Landin s SECD machine and the Krivine machine. 3.1 The CES machine or the modern SECD machine The modern SECD machine, which is the CES machine, is a simplification of Landin s original SECD machine (see Paulson s notes). It implements a weak by-value reduction of the λ-term by compiling the term into CES code which is run to obtain the weak head normal form (if it exists) of the λ-term. There are two improvements over Landin s SECD machine: it does not have a dump as the stack doubles up as a dump and it uses a simpler instruction set. The CES machine is a state machine with transitions: the state is a triple consisting of: C: A code pointer, C, which points to the current instruction. E: An environment, E, which holds the values of variables. These are accessed using De-Bruijn s Indices. S: A stack S holding both intermediate results continuations (closures). Here we shall illustrate the CES machine with additional instructions for integers, Booleans, and Lists. This means that we must augment the λ-calculus with arithmetic instructions and list instructions. For arithmetic we add constants (meaning integers, k), with instructions for addition, Add, multiplication, Mul, and comparison leq. For booleans we add constants True and False and the conditional If. For lists we add the constants Nil and Cons and the case instruction. The resulting instructions for a CES machine are: 14

15 Instruction Clo(c) App Access(n) Ret Explanation Push closure of code c with current environment on the stack Pop function closure and argument, perform application Push n th value in the environment onto the stack. Return the top value on the stack and jump to the continuation on the stack Arithmetic instructions: Const(n) Add Mul Leq push the constant n on the stack Pop two arguments from the top of the stack and add them Pop two arguments from the top of the stack and add them Pop two arguments from the top of the stack and compare them Boolean instructions: True False If Push the constant True on the stack Push the constant False on the stack Pop an argument from the top of the stack and depending on whether it is True or False evaluate the appropriate branch. List instructions: Cons push the Cons applied to the top two elements of the stack onto the stack Nil push the constant Nil on the stack Case(c 1, c 2 ) if Cons t 1 t 2 is on the stack pop it and push t 2 and t 1 onto the environment. Evaluate c 2 Case(c 1, c 2 ) if Nil pop it and evaluate c 1 To compile a λ-term into CES code one essentially converts the λ-term into de Bruijn notation and then translates the term into CES-machine code. This one can do in two steps. However, below we present it as one big step. Recall the translation into de Bruijn notation replaces variables by indexes: Example 3.1 Here is the De Bruijn notation for the following λ-terms: (λx.xx) (λx.x) (λ.(#1 #1))(λ. #1) (λx.λy.(xy)) (λx.x) (λy.y) (λ. λ.(#2 #1))(λ.#1)(λ.#1) The compilation into CES-machine code for a λ-term is as follows: 15

16 Lambda Terms Compilation λx.t v [Clo( t x:v ++[Ret])] M N v N v ++ M v +[App] x v [Access(n)] where n = index x v k v a + b v a b v a b v True v False v If t {True t 0 False t 1 } v Nil v Cons(a, b) v Case t {Nil t 0 Cons x y t 1 } v This translation has two slightly subtle aspects. [Const(k)] b v ++ a v ++[Add] b v ++ a v ++[Mul] b v ++ a v ++[Leq] [True] [False] t v ++[If( t 0 v ++[Ret], t 1 v ++[Ret])] [Nil] b v ++ a v ++[Cons] t v ++[Case( t 0 v ++[Ret], t 1 x:y:v ++[Ret])] 1. The translation is always done in a variable context, v: one starts with the empty variable context. The variable context is a stack of variable names and is used when one wants to translate a variable into its de Bruijn index: the index is just the depth of the variable in the context subscripting the translation. The de Bruijn index indicates how the value of the variable can be accessed in the environment of the CES-machine. In particular, when translating a case expression, the Cons branch requires that one adds the variables in the pattern to the context which changes how the debruijn indexes are calculated. 2. In the translations for closures, cases, and conditionals, one must add a return instruction Ret, to the end of the code fragments within these constructs as after executing such a code fragment one must return to executing the code which followed the construct and is pushed as a continuation onto the stack. Example 3.2 Example of compilation: (1) (2) Let us compile Ω: (λx.x + 1)2 [] = [Const(2), Clo( (x + 1) [x] ++[Ret]), App] = [Const(2), Clo([Const(1), Access(1), Add, Ret]), App] (λx.x x) (λx.x x) [] = (λx.x x) [] ++ (λx.x x) [] ++[App] = [Clo( (x x) [x] ++[Ret]), Clo( (x x) [x] ++[Ret]), App] = [Clo([Access(1), Access(1), App, Ret]), Clo([Access(1), Access(1), App, Ret]), App] The machine Transitions in Modern SECD Machine are: 16

17 Before After Code Env Stack Code Env Stack Clo(c ) : c e s c e Clos(c, e) : s App : c e Clos(c, e ) : v : s c v : e Clos(c, e) : s Access(n); c e s c e e(n) : s Ret : c e v : Clos(c, e ) : s c e v : s Const(k) : c e s c e k : s Add : c e n : m : s c e (n + m) : s Mul : c e n : m : s c e (n m) : s Leq : c e n : m : s c e (n m) : s True : c e s c e True : s False : c e s c e False : s If(c 0, c 1 ) : c e True : s c 0 e Clos(c, e) : s If(c 0, c 1 ) : c e False : s c 1 e Clos(c, e) : s Nil : c e s c e Nil : s Cons : c e v 1 : v 2 : s c e Cons(v 1, v 2 ) : s Case(c 1, c 2 ) : c e Cons(v 1, v 2 ) : s c 1 v 1 : v 2 : e Clo(c, e) : s Case(c 1, c 2 ) : c e Nil() : s c 2 e Clos(c, e) : s Where Clos(c, e) denotes closure of code c with environment e and e(n) is the n th -element of the environment. The machine is started with a code pointer and the environment and stack empty: Code = c Environment = Nil Stack = Nil The final state is reached when the code stack is empty: the answer should they be sitting on the top of the stack Code = Nil Environment = Nil Stack = v : the answer is v! As an example of an evaluation in the Modern SECD machine, let us evaluate Const(2) : Clo[Const(1) : Access(1) : Add : Ret] : App This, as was shown above, is the compilation of (λx.x + 1) 2. 17

18 Code Env Stack Const(2) : Clo(c) : App Nil Nil Clo(c) : App Nil Const(2) App Nil Clos(c, Nil) : 2 Const(1) : Access(1) : Add : Ret 2 Clos(Nil, Nil) Access(1) : Add : Ret 2 1 : Clos(Nil, Nil) Add : Ret 2 2 : 1 : Clos(Nil, Nil) Ret 2 3 : Clos(Nil, Nil) Nil Nil 3 where c := Const(1) : Access(1) : Add : Ret. Fixed points For a by-value machine, such as the CES-machine above, using a fixed point combinator will often cause a non-terminating behaviour. However, this can be avoided by a judicious choice of fixed point combinator. The idea is to use the fact that the machine only evaluates terms to weak head normal form, thus it is possible to avoid the undesirable behaviour of a fixed point combinator by choosing one which evaluates initially to a closure. Here is an example of one which works (see Larry Paulson s notes for example): λf.(λa.f (λx.a a x)) (λa.f (λx.a a x)). In fact, this is a fixed point combinator in a slightly unusual way as to show it is such we must use the η-rule: (λf.(λa.f (λx.a a x)) (λa.f (λx.a a x))) F (λa.f (λx.a a x)) (λa.f (λx.a a x)) F (λx.(λa.f (λx.a a x)) (λa.f (λx.a a x))x) = η F ((λa.f (λx.a a x)) (λa.f (λx.a a x))) F ((λf.(λa.f (λx.a a x)) (λa.f (λx.a a x))) F ) The extra abstraction produced by this fixed point combinator, which necessitated a use of the η-equality in the proof above, stops the CES machine from repeatedly unwrapping the fixed point leading to an an undesirable infinite behaviour. While this works this is not very efficient! The question of how to make this more efficient has, of course, been considered as the machine has been the basis of many implementations. The technique which is often used in practical implementations is to replace a recursive definition by a closure which, when the fixed point is called, actually points back to itself: this is called tying the knot and gives an efficient implementation. However, it is fairly drastic as it requires a pointer modification. A less drastic approach to this is to allow the machine to call subroutines in which case recursion can be implemented as a direct recursive call. In effect one is tying the knot with such an approach but as in effect one is allowing pointers to code. To implement this one has to add to the machine a program store, Prog, and a command Call which in the machine has the transition: 18

19 Before After Code Env Stack Code Env Stack Call( f ) : c e s Prog( f ) e Clos(c, e) : s The called code must always end with a Ret to ensure that the code in the closure after the call is correctly initiated. The question remains, however, whether one can implement fixed points directly in the machine. It turns out that this can also be done 2. This does not require the use of pointers or adding a program store: one adds instead a native fixed point combinator, Fix(l). One then has to have a compilation to CES-machine code for this native fixed point and some additional transitions in the CES-machine. The compilation step is as follows: Fix(λfx.N) x = Fix( N x:f:x ++[Ret]) Fix(λf.N) x = Fixc( N f:x ++[Ret]) The two translation phrases are needed to handle the case when the function being fixed has one or more arguments and the (more unusual but possible) case when the function has no arguments. The code has to accommodate the these two cases slightly differently. Here the translation of N assumes that the two arguments f and x are bound so the de Bruijn indexes for f and x in the code must take this into account. Notice also that the code inside the fixed point combinator must be applied to two arguments: the first is the fixed point itself and the second is the argument of the function. Here is how the machine must be modified: Before After Code Env Stack Code Env Stack Fix(c ) : c e s c e FixClos(c, e) : s App : c e FixClos(c, e ) : v : s c v : FixClos(c, e ) : e Clos(c, e) : s Fixc(c ) : c e s c e FixcClos(c, e) : s App : c e FixcClos(c, e ) : s c FixcClos(c, e ) : e Clos(c, e) : s The application for a fixed point not only applies the code but also inserts the fixed point below the argument of the application (if there is one) in the environment so that a recursive call can be serviced correctly. Here are some questions: 1. What happens when one evaluates Ω? 2. Given a Church numeral can you translate it into an integer? 3. Can you sum the elements of a list of integers? 4. Give the λ-representation of a list of numbers can you translate it into a built-in list? 5. Can you program the factorial of a number recursively? 2 Thanks to Nathan Harms for working this out!!! 19

20 3.2 The Krivine machine The Krivine machine is remarkable for its simplicity. An aspect which is a bit subtle is interpreting its output: for this one must reverse compile the state of the machine into a λ-term. It performs a weak by-name reduction for pure λ-terms producing a weak head normal form. As for the CES machine it is based on a state consisting of a triple of code, environment, and stack. The environment and the stack, however, now both contain closures which makes the machine more uniform. As for the CES machine, the Krivine machine uses de Bruijn notation to facilitate compilation to code. The Krivine machine has just three instructions: Instruction Push(c) Access(n) Grab Explanation Pushes a closure of the code c with current environment on the stack Continues with the n th closure in the environment. Moves the top value of the stack onto the environment The compilation from de Bruijn terms is also remarkably simple unlike for the CES machine translation no appending of code is required: Lambda Terms λ.m M N #(n) Compilation Grab : M Push([ N ) : M [Access(n)] Finally the machine transitions are: Before After Code Env Stack Code Env Stack Access(1) : c Cls(c, e ) : e s c e s Access(n + 1) : c : e s Access(n) : c e s Grab : c e Cls(c, e ) : s c Cls(c, e ) : e s Push(c ) : c e s c e Cls(c, e) : s The start state for the Krivine machine has an empty environment and state with the code generated form a (closed) λ-term. The final state is reached when no more transitions can be made. The result is a (suspended) machine state which can be reverse compiled into a λ-term. There are three possible ways in which the machine can get stuck : while doing an Access, a Grab, or one can run out of code. If one starts with a closed term, for an Access to fail a Grab must first have failed, thus, the machine must get stuck at a Grab or when the code is empty. However, it is not hard to see that the code never becomes empty. Thus, one always terminates if indeed it does terminate with some code applied to an environment. The environment is a list of closures each consisting of code and environment pairs - thus, to reverse compile one recursively reverse compiles the environments into a stack of λ-terms. Then to reverse compile the top code environment pair one uses the stack of λ-terms obtained by reverse compiling the environments to substitute the access commands which are not then bound in the code reverse compiled to a λ-term The de Bruijn 20

21 index value beyond the binding depth of the term itself, indicates the depth of the term in the environment with which it should be substituted. Here is the description of reverse compiling: one starts with the machine state (c, e, ) for which the reverse compilation is c, e 0 rev as defined below. Push(c) : c, e i rev = c, e i rev c, e i rev Grab : c, e i rev = λ. c, e i+1 rev Access(n), e i rev = #(n) n i Access(n), e i rev = e(i) 0 rev n > i 21