If you aren't familiar with Applicative Functors, they are somewhere in between the familiar and simple Functor class and the Monad class; an abstraction for function application with a context. Check out here for more.

Away from the computer I got out a pad of paper and went about trying to figure out how the < *> method was defined over functions. Here are the types:

The polymorphic type:
(< *>) :: (Applicative f) => f (a -> b) -> f a -> f b

Substitute (x -> ...) for f to get the type for the functions instance:
(< *>) :: (x -> a -> b) -> (x -> a) -> (x -> b)

You can try defining the instance from the type definition; there seems to be only one sensical way. When I did it I was struck by something: the definition for the function above is the same as the S combinator in the SKI combinator calculus!

At that point I started looking for other connections to combinatory logic, and quickly noticed that the class method pure was essentially the K combinator!. Here is the actual instance definition:

instance Applicative ((->) a) where
        pure = const
        (< *>) f g x = f x (g x)

For those not familiar, the SK(I) Combinator Calculus is a formal system for modelling computation, much like the lambda calculus; one can express any computable function using only the three (actually only S and K are necessary) symbols and parentheses. I've written about and implemented the combinator calculus, and you can read more on the wikipedia page.

Exploring the Connection

It's pretty astounding to me that the only two methods required to define an Applicative instance turn out to be sufficient (the details of haskell's type system aside) to define a complete combinator base, capable of expressing any computable function.

At first I wondered whether this connection was the brainchild of some clever haskeller who defined the (->) instance, and therefore somewhat artificial. But it turns out that the definitions for pure and (< *>) fall out quit naturally from the type definitions. So naturally in fact that we can use djinn to automatically derive their definitions!:

Djinn> ? (< *>) :: (x -> a -> b) -> (x -> a) -> (x -> b)
(< *>) :: (x -> a -> b) -> (x -> a) -> x -> b
(< *>) a b c = a c (b c)
Djinn> ? pure :: a -> (x -> a)
pure :: a -> x -> a
pure a _ = a

Observe how the function definitions above could have been pulled right from an explanation of the S and K combinators.

Now let's play with this in GHCi. We'll first define our S and K combinators as the Applicative methods (giving type hints to keep the typechecker happy), then define the I combinator in terms of S and K, then we'll express a Church numeral:

Prelude> :m + Control.Applicative
Prelude Control.Applicative> let s = (< *>) :: (x -> b -> c) -> (x -> b) -> (x -> c)
Prelude Control.Applicative> let k = pure :: a -> (x -> a)
Prelude Control.Applicative> let i = s k k
Prelude Control.Applicative>
Prelude Control.Applicative> let two = s (s (k s) k) i
Prelude Control.Applicative>
Prelude Control.Applicative> two ('x':) []
"xx"

In the last last line above we sort of "render" the church numeral by applying it to a function and value that will construct a list; remember that church numerals represent integers as n-fold function composition; in the lambda calculus the numerical represenatations are more straightforward: two = \f x-> f (f x), but the idea is the same.

Conclusion

It makes a lot of sense that a general type class meant to aid programming in an "applicative" style would have some similarity with the combinator calculus (in which even data is function application), but I thought it was pretty exciting to see such a fundamental computer science concept seemingly emerge naturally out of a library designed to solve a very high-level problem.

I have no idea whether these observations are novel or old and obvious, but would love to hear from anyone who has any thoughts on this.

EDIT: After taking a closer look at Conor McBride and Ross Paterson's paper on Applicative Functor's, I see now that he labels his ((->) a) instance methods with "S" and "K", but does not explore the subject further. So I'm leaning towards obvious.

Thanks for reading :)

So this post comes from that infinitely-recursive rabbit hole of wikipedia topics I’ve been falling down for the last few weeks, and you can probably expect a few more like this one; I’ll try to keep focused.

We begin (as do All Good Things) with the Untyped Lambda Calculus:

The System

The lambda calculus, invented by Alonzo Church, is a formal system for modeling functional computation and logic. It has an extraordinarily simple set of semantics, has no notion of data as a separate idea, and yet (as was proven later) is Turing complete. It serves as the skeleton and sinew of the Lisp and Scheme programming languages.

At its invention it seems that the system sat right at the crossroads of formal logic, mathematics and computational theory and could embrace all three fields. But it quickly became apparent that there were apparent flaws with the Lambda Calculus as a universal system.

The Paradox

In 1935 it was shown that the lambda calculus was logically inconsistent by the Kleene–Rosser paradox. The “paradox” is an apparently self-contradictory lambda expression, and goes like this:

We have a lambda calculus expression we will call 'k', which takes an argument, applies it to to itself, and negates (the ¬ symbol) the result (for some undefined, logical definition of “negate”).

k = λx.( ¬ (x x))

Okay, no problem. But look what happens when we apply the function 'k' to itself:

k k = λx.( ¬ (x x)) k
k k = ¬ (k k)

After we reduce the expression, we seem to be saying that (k k) is equal to the opposite of itself, a self-contradictory statement.

To address this apparent shortcoming of his system, Church went on to define a typed lambda calculus. This new system differentiated between function types and simple terms in order to disallow these kinds of problematic expressions.

But as with many paradoxes, this one was really an issue of perspective…

The Foundation

Church’s new “Simply Typed Lambda Calculus” had an interesting property that the untyped lambda calculus didn’t have: the normalization property.

This more restricted version of the Lambda Calculus was “strongly normalizing”, meaning that any expression could be reduced to some normal form (i.e. a form that cannot be reduced further) through some sequence of rewrite/reduction steps. In programming terms, this means that every expression in the typed lambda calculus is guaranteed to terminate.

That sounds pretty damn useful until you realize that this interesting property also makes Church’s new typed version of his system not Turing complete!

To prove this is so, consider this: imagine you encoded a program in the typed lambda calculus; it searched for (and halted) when it found an integer that was greater than two, and was not the sum of two primes.

Merely being able to encode such a function would imply the function halted, thus disproving Goldbach’s conjecture, one of the great open problems of mathematics. All without even needing to evaluate said expression! The function referred to is of course not expressible in the typed lambda calculus.

It turns out that an apparent logical contradiction was actual the essential secret to computation.

Embracing Inconsistency

When you think of the LC as a model of computation, rather than a framework for logical assertions, the Kleene–Rosser paradox becomes what we might call the “Kleene–Rosser useless function”.

Let’s go ahead and express a nearly identical paradox in haskell:

k :: (Num a) => a
k = negate k

Haskell has no notion of mutability, so what we are saying here is “k is the negation of itself”. No logical fallacies or great existential questions here, just an infinite loop (and not a very useful one)!

Let’s express another similar “paradox”, one we can actually use:

babble :: [ String ]
babble = “blah” : babble

How can a list be equal to itself with an extra element added? Doesn’t that imply a paradox? Well I know the runtime isn’t swayed by that argument, producing an infinite stream of “blah”s. We can even use this stream because of haskell’s lazy evaluation strategy.

But note: it isn’t laziness that lets us get away with defining paradoxes; it just allows us to make use of some more blatant paradoxical expressions without them blowing up in our faces as soon as we call them.

Conclusion and Further Thoughts

Interestingly, there are quite a number of non-turing complete programming languages (or language subsets) that have been created both for theoretical purposes and for practical use. Here are a few. They seem to owe their existence and usefulness to an environment of turing complete systems.

So does this mean that formal logic is Turing Incomplete? Let me know your thoughts, and please let me know if I harmed any knowledge in the making of this post.