{"id":135,"date":"2006-08-29T08:30:00","date_gmt":"2006-08-29T08:30:00","guid":{"rendered":"http:\/\/scientopia.org\/blogs\/goodmath\/2006\/08\/29\/a-lambda-calculus-rerun\/"},"modified":"2016-06-21T21:06:13","modified_gmt":"2016-06-22T01:06:13","slug":"a-lambda-calculus-rerun","status":"publish","type":"post","link":"http:\/\/www.goodmath.org\/blog\/2006\/08\/29\/a-lambda-calculus-rerun\/","title":{"rendered":"A Lambda Calculus rerun"},"content":{"rendered":"

I’m on vacation this week, so I’m recycling some posts that I thought were particularly interesting to give you something to read.<\/p>\n

In computer science, especially in the field of programming languages, we tend to use one particular calculus a lot: the Lambda calculus. Lambda calculus is also extensively used by logicians studying the nature of computation and the structure of discrete mathematics. Lambda calculus is great for a lot of reasons, among them:<\/p>\n

    \n
  1. It’s very simple.<\/li>\n
  2. It’s Turing complete.<\/li>\n
  3. It’s easy to read and write.<\/li>\n
  4. It’s semantics are strong enough that we can do reasoning from it.<\/li>\n
  5. It’s got a good solid model.<\/li>\n
  6. It’s easy to create variants to explore the properties of various alternative ways of structuring computations or semantics.<\/li>\n<\/ol>\n

    The ease of reading and writing lambda calculus is a big deal. It’s led to the development of a lot of extremely good programming languages based, to one degree or another, on the lambda calculus: Lisp, ML, and Haskell are very strongly lambda calculus based.<\/p>\n

    The lambda calculus is based on the concept of *functions*>. In the pure lambda calculus, *everything* is a function; there are no values *at all* except for functions. But we can build up anything we need using functions. Remember back in the early days of this blog, I talked a bit about how to build mathematics? We can build the entire structure of mathematics from nothing but lambda calculus.<\/p>\n

    So, enough lead-in. Let’s dive in a look at LC. Remember that for a calculus, you need to define two things: the syntax, which describes how valid expressions can be written in the calculus; and a set of rules that allow you to symbolically manipulate the expressions.<\/p>\n

    Lambda Calculus Syntax<\/h3>\n

    The lambda calculus has exactly three kinds of expressions:<\/p>\n

      \n
    1. Function definition: a function in lambda calculus is an expression, written: “λ param . body<\/code>” which defines a function with one parameter.<\/li>\n
    2. Identifier reference: an identifier reference is a name which matches the name of a parameter defined in a function expression enclosing the reference.<\/li>\n
    3. Function application: applying a function is written by putting the function value in front of its parameter, as in “x y<\/code>” to apply the function x<\/code> to the value y<\/code>.<\/li>\n<\/ol>\n

      Currying<\/h4>\n

      There’s a trick that we play in lambda calculus: if you look at the definition above, you’ll notice that a function (lambda expression) only takes one parameter. That seems like a very big constraint – how can you even implement addition with only one parameter?<\/p>\n

      It turns out to be no problem, because of the fact that *functions are values*. So instead of writing a two parameter function, you can write a one parameter function that returns a one parameter function – in the end, it’s effectively the same thing. It’s called currying, after the great logician Haskell Curry.<\/p>\n

      For example, suppose we wanted to write a function to add x and y. We’d like to write something like: λ x y . x + y<\/code>. The way we do that with one-parameter functions is: we first write a function with one parameter, which returns another<\/em> function with one parameter.<\/p>\n

      Adding x plus y becomes writing a one-parameter function with parameter x, which returns another one parameter function which adds x to its parameter:<\/p>\n

      λ x . (λ y . x + y)<\/code><\/p>\n

      Now that we know that adding multiple parameter functions doesn’t *really* add anything but a bit of simplified syntax, we’ll go ahead and use them when it’s convenient.<\/p>\n

      Free vs Bound Identifiers<\/h4>\n

      One important syntactic issue that I haven’t mentioned yet is *closure* or *complete binding*. For a lambda calculus expression to be evaluated, it cannot reference any identifiers that are not *bound*. An identifier is bound if it a parameter in an enclosing lambda expression; if an identifier is *not* bound in any enclosing context, then it is called a *free* variable.<\/p>\n

        \n
      1. *λ x . plus x y*: in this expression, “y” and “plus” are free, because they’re not the parameter of any enclosing lambda expression; x is bound because it’s a parameter of the function definition enclosing the expression “plus x y” where it’s referenced.<\/li>\n
      2. *λ x y.y x*: in this expression both x and y are bound, because they are parameters of the function definition.<\/li>\n
      3. *λ y . (λ x . plus x y*: In the inner lambda, “*λ x . plus x y*”, y and plus are free and x is bound. In the full expression, both x and y are bound: x is bound by the inner lambda, and y is bound by the other lambda. “plus” is still free.<\/li>\n<\/ol>\n

        We’ll often use “free(x)” to mean the set of identifiers that are free in the expression “x”.<\/p>\n

        A lambda calculus expression is completely valid only when all of its variables are bound. But when we look at smaller subexpressions of a complex expression, taken out of context, they can have free variables – and making sure that the variables that are free in subexpressions are treated right is very important.<\/li>\n

        Lambda Calculus Evaluation Rules<\/h3>\n

        There are only two real rules for evaluating expressions in lambda calculus; they’re called α and beta. α is also called “conversion”, and beta is also called “reduction”.<\/p>\n

        α Conversion<\/h4>\n

        α is a renaming operation; basically it says that the names of variables are unimportant: given any expression in lambda calculus, we can change the name of the parameter to a function as long as we change all free references to it inside the body.<\/p>\n

        So – for instance, if we had an expression like:<\/p>\n

        λ x . if (= x 0) then 1 else x^2<\/em><\/p>\n

        We can do α to replace X with Y (written “α[x\/y]” and get):<\/p>\n

        λ y . if (= y 0) then 1 else y^2<\/em><\/p>\n

        Doing α does *not* change the meaning of the expression in any way. But as we’ll see later, it’s important because it gives us a way of doing things like recursion.<\/p>\n

        β Reduction<\/h4>\n

        β reduction is where things get interesting: this single rule is all that’s needed to make the lambda calculus capable of performing *any* computation that can be done by a machine.<\/p>\n

        Beta basically says that if you have a function application, you can replace it with a copy of the body of the function with references to the parameter identifiers replaced by references to the parameter value in the application. That sounds confusing, but it’s actually pretty easy when you see it in action.<\/p>\n

        Suppose we have the application expression: “*(λ x . x + 1) 3*<\/code>“. What beta says is that we can replace the application by taking the body of the function (which is “*x + 1*”); and replacing references to the parameter “*x*” by the value “*3*”; so the result of the beta reduction is “*3 + 1*”.<\/p>\n

        A slightly more complicated example is the expression:<\/p>\n

        λ y . (λ x . x + y)) q<\/em><\/p>\n

        It’s an interesting expression, because it’s a lambda expression that when applied, results in another lambda expression: that is, it’s a function that creates functions. When we do beta reduction in this, we’re replacing all references to the parameter “y” with the identifier “q”; so, the result is “*λ x. x+q*”.<\/p>\n

        One more example, just for the sake of being annoying:<\/p>\n

        “(λ x y. x y) (λ z . z × z) 3<\/em>“.<\/p>\n

        That’s a function that takes two parameters, and applies the first one to the second one. When we evaluate that, we replace the parameter “*x*” in the body of the first function with “*λ z . z × z<\/code>*”; and we replace the parameter “*y*” with “3”, getting: “*(λ z . z × z) 3*”. And we can perform beta on that, getting “*3 × 3*”.<\/p>\n

        Written formally, beta says:<\/p>\n

        λ x . B e = B[x := e] if free(e) ⊂ free(B[x := e]<\/p>\n

        That condition on the end, “if free(e) subset free(B[x := e]” is why we need α: we can only do beta reduction *if* doing it doesn’t create any collisions between bound identifiers and free identifiers: if the identifier “z” is free in “e”, then we need to be sure that the beta-reduction doesn’t make “z” become bound. If there is a name collision between a variable that is bound in “B” and a variable that is free in “e”, then we need to use α to change the identifier names so that they’re different.<\/p>\n

        As usual, an example will make that clearer: Suppose we have a expression defining a function, “*λ z . (λ x . x+z)*”. Now, suppose we want to apply it:<\/p>\n

        (λ z . (λ x . x + z)) (x + 2)<\/em><\/p>\n

        In the parameter “*(x + 2)*”, x is free. Now, suppose we break the rule and go ahead and do beta. We’d get “*λ x . x + x + 2*”.<\/p>\n

        The variable that was *free* in “x + 2” is now bound. Now suppose we apply that function: “*(λ x . x + x + 2) 3*”. By beta, we’d get “3 + 3 + 2”, or 8.<\/p>\n

        What if we did α the way we were supposed to?<\/p>\n