## Friday, January 29, 2010

### Deriving the Y Combinator in Erlang - Part 2: Abstraction

This is the second post in a series on the Y combinator. Part 1

In the last post on the Y combinator, we established that some functional languages (such as Erlang) make it hard to have recursive, anonymous functions. Namely, there is no name that is bound to the "current" anonymous function. Furthermore, we established that we could work around this problem by passing the anonymous function to itself. When we concluded, we had derived this much:

```Helper = fun(Helper2, N) ->
case N of
1 -> 1;
_ -> N * Helper2(Helper2, N - 1)
end
end,

Fact = fun(X) -> Helper(Helper, X) end
```

This post will focus on extracting the Y combinator from the above code. We will follow a sequence of transformations, each with a specific intent. In the end, we will hopefully have some beautiful code.

#### Reducing the Number of Arguments

This factorial algorithm started with a function that took a single parameter. This function called itself with successively smaller values, until it reached a base case. However, we muddied the waters by passing the function around as well. We would like to return to having a one-parameter function. We can accomplish this by creating another level of closure:

```Helper = fun(Helper2) ->
fun(N) ->
case N of
1 -> 1;
_ -> N * (Helper2(Helper2))(N - 1)
end
end
end,

Fact = fun(X) -> (Helper(Helper))(X) end
```
Now it is clear that our recursive function is really only calling itself with one parameter.

#### Simplifying the Recursive Function Call

The place where we make the recursive call is rather ugly. We have to build the function upon which we will recurse before we can actually call it. It would be better if the recursive function was explicitly named. We can do that, too:

```Helper = fun(Helper2) ->
fun(N) ->
case N of
1 -> 1;
_ ->
PAHelper2 = fun(Z) -> (Helper2(Helper2))(Z) end,
N * PAHelper2(N - 1)
end
end
end,

Fact = fun(X) -> (Helper(Helper))(X) end
```

We call the new identifier `PAHelper2` to suggest that it's a partially-applied version of `Helper2`.

We can simplify the body further by moving `PAHelper2` to a higher scope.

```Helper = fun(Helper2) ->
PAHelper2 = fun(Z) -> (Helper2(Helper2))(Z) end,
fun(N) ->
case N of
1 -> 1;
_ -> N * PAHelper2(N - 1)
end
end
end,

Fact = fun(X) -> (Helper(Helper))(X) end
```

As an aside, you might find this step overly complicated. You may ask, why did we not simply define `PAHelper2 = Helper2(Helper2)`? Why the extra indirection? We don't actually want to evaluate `Helper2` just yet. In fact, if we were to do so, we'd end up in an infinite loop. If the first step of `Helper` is to immediately call `Helper2` (an alias for `Helper`), we'll be recursing on ourself with no way to ever terminate.

#### Extracting the Anonymous Function

Right now, the body of our algorithm is embedded deeply within some necessary plumbing. We would like to extract our algorithm from the center of this. This is quite easy:

```Helper = fun(Helper2) ->
PAHelper2 = fun(Z) -> (Helper2(Helper2))(Z) end,
FactRec = fun(Self) ->
fun(N) ->
case N of
1 -> 1;
_ -> N * Self(N - 1)
end
end
end,
FactRec(PAHelper2)
end,

Fact = fun(X) -> (Helper(Helper))(X) end
```

Now we can pull it outside the body of `Helper`.

```FactRec = fun(Self) ->
fun(N) ->
case N of
1 -> 1;
_ -> N * Self(N - 1)
end
end
end,

Helper = fun(Helper2) ->
PAHelper2 = fun(Z) -> (Helper2(Helper2))(Z) end,
FactRec(PAHelper2)
end,

Fact = fun(X) -> (Helper(Helper))(X) end
```

#### Simplifying Fact

We're getting close, but the definition of `Fact` still leaves something to be desired. However, in order to make it simpler, we have to first make it messier. Start by moving `Helper` inside the definition for `Fact`:

```FactRec = fun(Self) ->
fun(N) ->
case N of
1 -> 1;
_ -> N * Self(N - 1)
end
end
end,

Fact = fun(X) ->
Helper = fun(Helper2) ->
PAHelper2 = fun(Z) -> (Helper2(Helper2))(Z) end,
FactRec(PAHelper2)
end,

(Helper(Helper))(X)
end
```

Our goal is to build a general-purpose function `Y` that takes a function ```F ``` and produces a self-recursive version of that function. Right now, the innermost part of `Helper` makes an explicit reference to `FactRec`. We want to eliminate that explicit reference:

```FactRec = fun(Self) ->
fun(N) ->
case N of
1 -> 1;
_ -> N * Self(N - 1)
end
end
end,

Fact = fun(X) ->
Y = fun(Proc) ->
Helper = fun(Helper2) ->
PAHelper2 = fun(Z) -> (Helper2(Helper2))(Z) end,
Proc(PAHelper2)
end,
Helper(Helper)
end,
(Y(FactRec))(X)
end
```

Now that we've done this, `Y` no longer has any bound variables, so we can pull it out of `Fact` completely:

```FactRec = fun(Self) ->
fun(N) ->
case N of
1 -> 1;
_ -> N * Self(N - 1)
end
end
end,

Y = fun(Proc) ->
Helper = fun(Helper2) ->
PAHelper2 = fun(Z) -> (Helper2(Helper2))(Z) end,
Proc(PAHelper2)
end,
Helper(Helper)
end,

Fact = fun(X) ->
(Y(FactRec))(X)
end
```

Of course, if we want, we can simplify some of these definitions. `Y` can become a normal Erlang module function (rather than a function value). `Fact` itself can be curried - we can eliminate the noise of the explicit parameter. Also, `FactRec` doesn't need to be named anymore - it can become the anonymous function that we originally intended:

```y(F) ->
G = fun(G2) ->
F(fun(Z) -> (G2(G2))(Z) end)
end,
G(G).

Fact = y(fun(Self) ->
fun(N) ->
case N of
1 -> 1;
_ -> N * Self(N - 1)
end
end
end)
```

Unfortunately, the `y` function only supports functions that take a single parameter. Some languages have a "splat" operator that can be used to represent "all the parameters;" unfortunately, Erlang does not. Instead, it can be useful to define a family of y functions that deal with functions taking more than one parameter:

```y2(F) ->
G = fun(G2) ->
F(fun(Y, Z) -> (G2(G2))(Y, Z) end)
end,
G(G).
```

#### Conclusion

We have shown the difficulty in defining recursive, anonymous functions in Erlang. We showed a simple solution to this problem, and then generalized the plumbing to make it easier to use. While this is not necessary in all functional languages, I hope that this is useful to anybody working in a strict language, such as Erlang.

I am planning more posts on this topic. One post will explain the strange step I took in Simplifying the Recursive Function Call. Others will explain just what a fixed point is, what the fixed point combinators are, and how the Y combinator satisfies the definition of a fixed point combinator.

## Monday, January 18, 2010

### Deriving the Y Combinator in Erlang - Part 1: Intuition

This is the first of a series on the Y combinator. Part 2

When I heard about the fixed point combinators before, I didn't know what to make of them, so I filed the topic away in my brain. However, when I was working on implementing continuations in Erlang, I ended up building a small structure that reminded me of the Y combinator. With a little massaging, I extracted the actual Y combinator, and proceeded with what I was working on.

The actual definition of the Y combinator is insanely dense:

`Y = λf·(λx·f (x x)) (λx·f (x x))`
This is precisely why I didn't understand it at first - that definition means nothing to me. We need a more intuitive way to think about it.

Suppose you decide to write the factorial function in Erlang. A simple (by which I mean unoptimized) implementation might look like this:

```fact(N) ->
case N of
1 -> 1;
_ -> N * fact(N - 1)
end.
```
There's nothing particularly complicated here - we're just calling `fact` recursively. But what happens if you try to make `fact` into a fun (an anonymous function in Erlang). Watch:
```Fact = fun(N) ->
case N of
1 -> 1;
_ -> N * ??? (N - 1) %%How do we call ourselves? Fact isn't yet bound!
end
end.
```
In some languages, we could replace the `???` with `Fact`. Unfortunately, Erlang doesn't let you do this. If you tried, Erlang would say that `Fact` is unbound. This is true - until we've finished defining the fun, we can't assign it to `Fact`. Other languages provide you with a magic variable that represents the current function (Javascript has `arguments.callee`). Again, as far as I know, Erlang doesn't provide such a variable. Does that mean that we have no hope?

Let's look at this problem one step at a time. We need something to stand in for the `???`. We need a name that represents the current, anonymous function. Where can we get that from? In functional Erlang, there are only three ways that names are bound - by closure, by parameter, or by local definition. We can't close over it, because the anonymous function isn't yet defined. We can't create a local definition, because the local scope is too narrow a scope for that. That leaves only one possibility - we need to pass the anonymous function to itself.

```Helper = fun(Helper2, N) ->
case N of
1 -> 1;
_ -> N * Helper2(Helper2, N - 1)
end
end.

Fact = fun(N) -> Helper(Helper, N) end.
```
OK, so we created a helper function - more on that in a minute. `Helper` (formerly `Fact`) now takes an extra parameter, which just creates another name for the current, anonymous function. Since we intend for that to be the same as `Helper`, we call it `Helper2`. We know that `Helper` is a fun/2. Since `Helper2` is supposed to be another name for `Helper`, then `Helper2` must be a fun/2 as well. This means that, when we call `Helper2`, we need to also tell it about itself - that is, we need to pass `Helper2` along when we call `Helper2` to recurse.

Now that leaves us to deal with the function `Fact`. Clearly, `Fact` needs to call `Helper`. We noted that `Helper` is a fun/2, so again, we need to call it with two parameters. The intent of the extra parameter to `Helper` was to be able to pass `Helper` to itself, so we do just that.

Believe it or not, we have just derived the concept behind the Y combinator. We have invented a scheme that allows an anonymous function to know itself, even in a language that doesn't directly support this. This is (I believe) the purpose behind the Y combinator. However, we're not yet done. There is still some cruft that we would like to eliminate. In particular, we hand-built the plumbing to route `Helper2` around. We would like to use higher order functions to eliminate this. This is what the Y combinator does - it manages the plumbing of anonymous functions that refer to themselves.

In the next part, we will continue the derivation of the Y combinator in Erlang. Our goal is to eventually be able to write something like this:

```Fact = y(fun(Self) ->
fun(N) ->
case N of
1 -> 1;
_ -> N * Self(N - 1)
end
end
end).
```
It's not perfect, but in a language that doesn't directly support anonymous function recursion, it's not too bad!