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.

$> cabal install Befunge93

If you want to read about how I designed it you can check out the source above, or take a look at my previous blog post.

Please report any bugs to me, and I’m also very interested in patches or suggestions for performance improvements if anyone ends up being interested in this program.

EDIT: Here is the package page: http://hackage.haskell.org/package/Befunge93

Design

I found that writing the core functionality of the interpreter took almost no time, once I settled on the approach I would take. I used a monad transformer for the first time, StateT:

type REPL a = StateT ProgramState IO a

This let me pass around the state of the computation in the State monad while doing IO actions. This made some potentially-awkward befunge commands really easy to implement.

Here is an excerpt from the function execute :: Char -> REPL () which reads the befunge character at our position and returns the code to execute:

         -- Pop value and output as an integer. funge-98 spec calls for
         -- integer to be followed by a space, so we'll do that too:
         '.' -> do i <- pop
                   liftIO $ putStr $ show i ++" "
        
         -- Pop value and output as ASCII character
         ',' -> do i <- pop
                   liftIO $ putChar $ chr i

         '\\' -> do (a,b) <- pop2
                    push a
                    push b
        
         ':' -> do a <- pop
                   replicateM_ 2 (push a)
        
    -- program flow commands: --
         ' ' -> return ()    

         '>' -> setDirection right
        
         '<' -> setDirection left  
      
         '^' -> setDirection up
      
         'v' -> setDirection down
        
         '?' -> getRandomDirection >>= setDirection 

And here is the program state that gets passed in the monad:

data ProgramState = 
    ES { -- state of the code and stack:
         code :: Code,    
         stack :: Stack,
         -- state of program flow:
         position :: Position, 
         direction :: Direction,
         haltBit :: Bool,
         -- random generator:
         randGen :: StdGen, 
         -- errors or other messages we collect:
         messages :: [String],
         -- should we announce messages and warnings?:
         verbose :: Bool
        } 

I only use the accessor functions (as opposed to pattern matching) to reach into the state in my code, so it was easy to add another state parameter if I wanted to extend the functionality somewhere.

Finally here is the evaluation loop that ties the core of the interpreter together:

evalLoop :: REPL ()
evalLoop = do
     -- extract the command at our position & execute it:
    getCmd >>= execute
     -- print messages in the queue (unless quiet), and clear it:
    printMessages
     -- halt if @ command issued, else move and recurse:
    halting <- gets haltBit
    unless halting (move >> evalLoop) 

I found the most time-consuming parts of this project were in the design decisions and behaviour tweaks related to holes in the ‘93 spec, and tracking down a few silly bugs that came from wrong assumptions about the spec.

Vital in debugging were the CCBI interpreter as well as the pyfunge interpreter. It’s difficult to debug an interpreter when you don’t whether the befunge code you are testing on is buggy or whether your interpreter is!

One last detail that I am proud of is the test suite that I have integrated into my darcs repo. Darcs automatically runs the befunge-93 portion of the amazing mycology test suite by Matti Niemenmaa on each commit, as well as two smaller test befunge programs from phlamethrower, testing that the interpreter hasn’t changed behavior.

Play With It

You can check out the full source for the program here, or get my whole darcs repository with:

$ darcs get --tag=v0.2 http://coder.bsimmons.name/code/Befunge

And here are a few nice programs to try out, written by folks cleverer than I, and stolen from vsync’s funge stuff here.

aturley.bf by Andrew Turley:

>84*>:#v_55+"ude.ub@yelruta">:#,_@>188*+>\02p\12p\:22p#v_$    55+,1-         v
    ^  0 v +1\                   _^#-+*<>22g02g*"_@"*-!1- #v_v>
       >:>::3g: ,\188                  ^^               -1\g21\g22

life.bf by Dmitry M Litvinov:

v>>31g> ::51gg:2v++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
9p BXY|-+98 *7^>+\-0|< + *                                                     *    +
*5 ^:+ 1pg15\,:< + *                                                     ***  +
10^  <>$25*,51g1v+                                                            +
-^ p< | -*46p15:+<+                                                            +
> 31^> 151p>92*4v+                                                            +
 ^_ ".",   ^ vp1< +                                                            +
>v >41p      >0 v+                                                            +
:5! vg-1g15-1g14< +                                                            +
+1-+>+41g1-51gg+v+                                                            +
1p-1vg+1g15-1g14< +                                                            +
g61g>+41g51g1-g+v+                                                            +
14*1v4+g+1g15g14< +                           * *                              +
5>^4>1g1+51g1-g+v+                           * *                              +
^ _^v4+gg15+1g14< +                           ***                              +
>v! >1g1+51g1+g+v+                                                            +
g8-v14/*25-*4*88< +                                                            +
19+>g51gg" "- v  +                                                            +
4*5  v< v-2:_3v+                                                            +
 >^   |!-3_$  v< -+                                                            +
^    < <      <|<+                                                         ***+
>g51gp ^ >51gp^>v+                                                            +
^14"+"< ^g14"!"<++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

prime.bf by Kalyna Zazelenchuk:

222p35*89+*11p>133p                   >33g1+33p   22g33g- v>22g33g%#v_v
 o                                                        >|
  2                             v,,,,, ,,,,,.g22"is prime."< 1                            >    v^                             < ^_@#-g11g22p22+1g22,*25<,,,,,,,,,,,,,.g22"is not prime."<

There is still a lot that could be done, but I think I’m done with it for now. Thanks for looking!