# lambda calculus

A definition of lambda calculus.

What looks to be a decent intro to lambda calculus.

John Cowan once explained lambda calculus, briefly, on the Lojban list.

[1] is a very brief discussion of lambda calculus as pertains to linguistics.

Nick's stuff posted to the list:

In terms of programming, lambda calculus is very easy to explain. You know

formal parameters and actual parameters? Well, the function with just the

formal parameters is a "lambda expression", and the formal parameters are

the "lambda variables":

LAMBDA x . Factorial (x)

{

Factorial = Factorial (x-1) * x

}

What's x? x is an empty slot, of course. Which gets filled by the actual

value you call it with --- the actual parameter.

Factorial(9).

ce'u, it is claimed, corresponds to that lambda variable x. It's just a

formal param, in programming terms. {ka} is a subroutine in the program

that hasn't been called; it's just a piece of code, with no computed

value.

The minute you fill the value in (call the subroutine), it is further

claimed, you no longer have an abstract piece of code, but something

that's computed a value (true or false, in the Logic universe.) This turns

{ka} with {ce'u} (something which isn't true or false) into {du'u}

(something which is true or false.) Nothing with {ce'u} in it, I'd further

claim, can be true or false.

We've been talking about lambda calculus because that's the theoretical

guts of formal semantics (and of Computer Science). But in itself, it's

just like programming (precisely *because* it is the theoretical guts of

Computer Science (along with two(?) other equally valid and equally powerful forms of computation]

Now, if the above is *not* accessible to non-programmers, I guess I'm

sorry; programmers and logician-linguists are the only people who are

interested (OK, and some theoretical mathematicians.) So the tutorials

online do tend to assume geekdom.

Then again, Lojban tends to, too. :-)

Er, hope this has helped.

mudri doesn't understand Nick's syntax at all (factorial is rather advanced in pure lambda calculus) and dislikes his terminology, so will give another explanation.

Lambda calculus is based on the idea that functions are values. Loosely, ${\displaystyle \lambda x.E}$ is a function such that if ${\displaystyle f\,x{\overset {\mathrm {def} }{=}}E}$, then ${\displaystyle f=\lambda x.E}$. So, it's a compact way of writing anonymous functions. (I use the notation ${\displaystyle f\,x}$ for “the result when ${\displaystyle f}$ is applied to ${\displaystyle x}$” because it's good notation). Alternatively, ${\displaystyle (\lambda x.E)\,z}$ is ${\displaystyle E}$, but with occurrences of ${\displaystyle x}$ replaced by ${\displaystyle z}$.

So, instead of saying “Let ${\displaystyle f\,x=x^{2}}$. Then ${\displaystyle f'\,x=2\cdot x}$.”, we can say “${\displaystyle (\lambda x.x^{2})'=(\lambda x.2\cdot x)}$.”. The power of the lambda calculus is that it allows us to talk about functions directly. As an aside, it's often asked why mathematicians haven't taken to lambda notation. They do have ${\displaystyle x\mapsto E}$ (which avoids the commonly used character ‘λ’), but even that only seems to get used in definitions, making them only slightly shorter.

There are many more interesting things about the lambda calculus, but most are totally irrelevant to everyday Lojban. We don't expect you to encode natural numbers as {ka} phrases, so I won't go into them here. Still, I'd like to take a slight detour to make the connection between lambda expressions and {ka} expressions a bit clearer.

Variable names are messy things. Imagine evaluating the expression ${\displaystyle (\lambda y.\lambda x.x\,y)\,(\lambda x.x)\,(\lambda x.\lambda y.x)}$. One will first get ${\displaystyle (\lambda x.x\,(\lambda x.x))\,(\lambda x.\lambda y.x)}$, then try ${\displaystyle (\lambda x.\lambda y.x)\,(\lambda x.(\lambda x.\lambda y.x))}$. However, the last expression would be wrong. The fourth ‘${\displaystyle x}$’ is bound to the lambda just to the left of it – not the first one – so it shouldn't have been replaced. To avoid this issue and simplify some other things, we can instead use de Bruijn indices.

De Bruijn lambda expressions are equivalent to conventional lambda expressions, but replace named variables with numbers signifying how many ‘${\displaystyle \lambda }$’s have to be passed until we get to the ‘${\displaystyle \lambda }$’ that variable is bound to. For example, the expression ${\displaystyle \lambda x.x\,(\lambda y.x\,y)}$ is written as ${\displaystyle \lambda .0\,(\lambda .1\,0)}$. To get to the ‘${\displaystyle \lambda }$’ the ‘${\displaystyle 1}$’ is bound to, we first have to look past the inner ‘${\displaystyle \lambda }$’.

Why did I mention that? Well, {ka} and {ce'u} work quite like ${\displaystyle \lambda }$ and ${\displaystyle 0}$, respectively. What about other numbered variables? Nested {ka}s don't come up too often in Lojban, so there isn't, as far as I'm aware, a standard solution. {ce'u xi X} would work, .ia.

In Lojban, all of our built-in functions (selbri) yield truth values (not necessarily boolean; that's a topic for another day). So too do {ka} expressions, given that they are built around a bridi. This gives us a limited form of the lambda calculus to work with. How do we use it? The simplest selbri that works with {ka} sumti is {ckaji}. {ckaji} essentially applies its x1 argument to its x2 argument. We essentially have la'e {py. ckaji lo ka ce'u broda} iff la'e {py. broda}. {ce'u} gets replaced, and we remove the {lo ka}. Other selbri acting on {ka} sumti, like {kakne} and {simxu} do more complex things, which aren't generally expressible simply by reärrangement of terms. However, they all require some property (the {ka} phrase) that could be realized by a given sumti, and conceptually test sumti against this property.