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.

We will be using Lennart Augustsson’s numbers library which can be installed from hackage with cabal-install:

$> cabal install numbers

Consider two functions: the Prelude function sum and genericLength from the List library:

 genericLength :: (Num i) => [b] -> i
 sum :: (Num a) => [a] -> a

…two simple functions that have the potential to be very expensive, depending on the length of the list and the values of the elements.

Say for instance that all we want is to use:

The checkLengths function above has to count every element of every element of every sub-list in order to return a Bool value, and if any of those lists are infinite our program will never terminate:

…or so we might think!

Lazy Natural Numbers

It turns out we can solve our seemingly hopeless situation with a type signature:

And suddenly, as if by magic:

*LazyArithmetic> hopeless
True

What’s going on here? Well it turns out the problem is that Haskell’s built-in numeric types are boring, old-fashioned and (in some cases) just plain wrong. But let’s step behind the curtain and look at how the Data.Numbers library defines the Natural type internally:

 data Natural = Z | S Natural

We see that we’re using an abstract data type to represent non-negative integers, and it looks nearly identical to our list type []. The upshot of that is we gain, in our numeric type and arithmetic operations, the same type of laziness that lists afford us!

So in the above example, hopeless, we need only carry out the operations far enough to see that the result is > 2.

The numeric type in Data.List.Natural are actually known as Peano numbers. They are essentially just lists of units and, as you might imagine, are not the most efficient way to represent an integer.

But they are exactly what we want for this application. If we failed to realize that we could solve our problem with an appropriate numeric representation, we might try to rig up something like this:

…which works identically to checkLengths with Peano Numbers, but completely obfuscates the intention of the function. As usual laziness gives us expressive power rather than an efficiency boost.

Limitations, Haskell’s Numeric Type Classes, and the Numeric Prelude

The Data.Number.Natural library is convenient because it provides Num and Integral instances so we can use the the Natural type with any function that is polymorphic on those classes.

The problem is the Num instance is incomplete and error-prone: and that’s because a natural number type shouldn’t be an instance of Num! We can’t negate a Natural, which in turn makes subtraction dangerous, etc.

*LazyArithmetic> let x = 1 :: Natural; y = 2 in x - y
*** Exception: Natural: (-)

We might wish that haskell’s Numeric type classes were more expressive, allowing for more abstract numeric types. For example it might be more “haskelly” for the length function to be defined with the type:

 length :: Natural n => [a] -> n

After all we don’t use integers for boolean values as in C; we have the abstract type Bool. So why return an Int when a Natural type (or class) might be more expressive? The answer of course is that that gets really complicated really fast.

For one approach at making haskell’s numeric class hierarchy more expressive and flexible, check out the Numeric Prelude. It’s haddock documentation is very thorough and an interesting read, and you can see the sheer number of design decisions necessary for such an undertaking.

For some other approaches and links, see here.

Imagine an n x n grid. You can color cells of the grid such that no rectangle overlayed on the grid will have all four corners colored. Find a grid with the maximum possible colored cells.

So this is a quick and stupid brute force algorithm, but it let me see an optimal 6-grid, which is what I needed. First out imports:

import Data.List
import Control.Monad
import Data.Ord

We’ll call a colored cell True, uncolored False:

type Row = [Bool]
type Grid = [Row]

Given the side length, we’ll spit out all the possible ways a row can be colored:

allRows :: Int -> [Row]
allRows = mapM (\a-> [a,not a]) . flip replicate True

A quick function to see if two rows form a rectangle:

areRectFree :: Row -> Row -> Bool
areRectFree r1 = not . or . delete True . zipWith (&&) r1

An ugly function to return all the n-length ordered subsets of the ordered set of rows. (Note: a grid can move about its columns and rows without changing itself fundamentally, which is why we do the extra effort to not return every n-length permutation of the rows):

allGrids :: Int -> [Grid]
allGrids n = allSubsets n (2^n) (allRows n) 
    where allSubsets 0 _ _ = [[]]
          allSubsets ln (i+1) (r:rs)  
            | ln > i   = [r:rs]
            | otherwise =
                 [ r:rs' | rs' <- allSubsets (ln-1) i rs ] ++ 
                 allSubsets ln i rs

Validate a grid by making sure each pair is rectangle free with every other…

validGrid :: [Row] -> Bool
validGrid [] = True
validGrid (r:rs) = all (areRectFree r) rs && validGrid rs

…and tie it all together:

bestSubset = maximumBy mostColored . filter validGrid . allGrids 
    where mostColored = comparing (length . filter id . concat)

So a best subset of size four looks like:

[[True,True,False,False],[True,False,True,False],[True,False,False,True],[False,True,True,True]]

And a pretty picture:

+--+--+--+--+
|XX|XX|  |  |
+--+--+--+--+
|XX|  |XX|  |
+--+--+--+--+
|XX|  |  |XX|
+--+--+--+--+
|  |XX|XX|XX|
+--+--+--+--+

Does anyone have a more elegant way to represent the allGrids function? In the general sense it finds all n-length ordered subsets of an ordered set when the length of the set is known.