# Combinatory logic

Lambda calculus is concerned with objects called *lambda-terms*, which can be represented by
the following three forms of strings:

The motivation for this definition of reduction is that it captures the essential behavior of all mathematical functions. For example, consider the function that computes the square of a number. We might write

It is perhaps surprising that lambda-calculus can represent any
conceivable computation using only the simple notions of function
abstraction and application based on simple textual substitution of
terms for variables. But even more remarkable is that abstraction is
not even required. *Combinatory logic* is a model of computation
equivalent to lambda calculus, but without abstraction. The advantage
of this is that evaluating expressions in lambda calculus is quite complicated
because the semantics of substitution must be specified with great care to
avoid variable capture problems. In contrast, evaluating expressions in
combinatory logic is much simpler, because there is no notion of substitution.

Since abstraction is the only way to manufacture functions in the lambda calculus, something must replace it in the combinatory calculus. Instead of abstraction, combinatory calculus provides a limited set of primitive functions out of which other functions may be built.

In combinatory logic, each primitive combinator comes with a reduction rule of the form

The simplest example of a combinator is **I**, the identity
combinator, defined by

A third combinator is **S**, which is a generalized version of
application:

Note that *T*[ ] as given is not a well-typed mathematical function, but rather a term rewriter: Although it eventually yields a combinator, the transformation may generate intermediary expressions that are neither lambda terms nor combinators, via rule (5).

Bracket abstraction induces a translation from lambda terms to combinator expressions, by interpreting lambda-abstractions using the bracket abstraction algorithm.

The first two rules are also simple: Variables convert to themselves, and applications, which are allowed in combinatory terms, are converted to combinators simply by converting the applicand and the argument to combinators.

It is rules 5 and 6 that are of interest. Rule 5 simply says that to convert a complex abstraction to a combinator, we must first convert its body to a combinator, and then eliminate the abstraction. Rule 6 actually eliminates the abstraction.

The conversion *L*[ ] from combinatorial terms to lambda terms is
trivial:

Note, however, that this transformation is not the inverse
transformation of any of the versions of *T*[ ] that we have seen.

A normal form is any combinatory term in which the primitive combinators that occur, if any, are not applied to enough arguments to be simplified. It is undecidable whether a general combinatory term has a normal form; whether two combinatory terms are equivalent, etc. This is equivalent to the undecidability of the corresponding problems for lambda terms. However, a direct proof is as follows:

has no normal form, because it reduces to itself after three steps, as follows:

Now, suppose **N** were a combinator for detecting normal forms,
such that

From this undecidability theorem it immediately follows that there is no complete predicate that can discriminate between terms that have a normal form and terms that do not have a normal form. It also follows that there is **no** complete predicate, say EQUAL, such that:

David Turner used his combinators to implement the SASL programming language.

and function application corresponds to the detachment (modus ponens) rule