Normally this is fine, but what if we really wanted to use the mechanics of a state monad to pass some state value that changed type, e.g. some mutually-recursive tree structure we would like to traverse?:

data EvenBranch = EBranch OddBranch Int OddBranch

data OddBranch = OBranch EvenBranch EvenBranch
               | Nil

Well it turns out its not only possible, but relatively simple to use the existing MonadState types with something like a dynamically-typed state, thanks to a couple really fascinating standard Haskell libraries:

Introducing Typeable and Dynamic

The first piece of the puzzle is the Data.Typeable library. The library provides polymorphic functions for extracting type information (in the form of a data type called a TypeRep) from any object in the Typeable type class.

Try this out:

Prelude Data.Dynamic> :t typeOf
typeOf :: (Typeable a) => a -> TypeRep
Prelude Data.Dynamic> typeOf 1
Integer
Prelude Data.Dynamic> typeOf 1 == typeOf 'a'
False
Prelude Data.Dynamic> typeOf 1 == typeOf 2
True

The magic of bringing bits of the abstract type system into the world of data is known as “reification”.

Typeable also provides a method of “casting” any Typeable value as a fixed type, in the Maybe monad. Observe:

Prelude Data.Dynamic> cast 'a' :: Maybe Int
Nothing
Prelude Data.Dynamic> cast 'a' :: Maybe Char
Just 'a'

By using cast the programmer is essentially saying “Compiler, I take it upon myself to deal with any runtime type errors in my code. Take the afternoon off.”

The other component is Data.Dynamic, which uses Typeable (and in fact exports the entire Typeable module) to create a new data type called Dynamic. Thanks goes to Luke Palmer for pointing out the existence of this library to me.

This Dynamic type is like a magic bag for Typeable values:

Prelude Data.Dynamic> :t toDyn
toDyn :: (Typeable a) => a -> Dynamic
Prelude Data.Dynamic> :t fromDynamic
fromDynamic :: (Typeable a) => Dynamic -> Maybe a
Prelude Data.Dynamic> fromDynamic (toDyn 'c') :: Maybe Char
Just 'c'

So by encapsulating an arbitrary Typeable value in a Dynamic, it becomes a monomorphic value that we can use in lists, functions, etc.

A final interesting thing to note is that the existence of Typeable and Dynamic do not in any way change haskell’s static typing. For example, if the compiler cannot infer the type of a value that we cast it will complain of the ambiguity:

Prelude Data.Dynamic> cast 'a' :: (Typeable a)=>Maybe a

    Ambiguous type variable `a' in the constraint:
      `Typeable a'
        arising from an expression type signature at :1:0-32
    Probable fix: add a type signature that fixes these type variable(s)

Furthermore the compiler will not allow you to do something fancy like define a function that says “if the value is an Int pass it to foo, if it is a String, pass it to bar, else return Nothing”.

Defining the Dynamic State Monad

Okay, now let’s get to the fun part and define our new state monad with dynamic state.

module DynamicState
    where

import Control.Monad.State
import Data.Dynamic

type DynamicState a = StateT Dynamic Maybe a

As you can see our new monad is simply the StateT monad transformer, where the state type is a Dynamic (meaning we’ll be able to marshall in and out whatever state types we like), and the inner monad is Maybe for catching any type threading errors.

-- Dynamic 'get' and 'put' functions:
putD :: (Typeable a)=> a -> DynamicState ()
putD = put . toDyn

getD :: (Typeable a)=> DynamicState a
getD = get >>= lift . fromDynamic

Above we define our special getter and setter functions. You can see that they are both very simple: putD simply takes a Typeable state value, converts it to a Dynamic and pushes it; getD gets the Dynamic state, casts it into our requested type, and lifts this Maybe value back into the StateT transformer.

That’s about all there is to it, but a couple more functions are useful if we want to completely hide Dynamic from the user:

-- Compiler will complain if we ignore the returned final state since
-- its type is ambiguous:
runDState :: (Typeable s, Typeable s')=> DynamicState a -> s -> Maybe (a, s')
runDState c = (liftTypState =<<) . runStateT c . toDyn
    where liftTypState (a,s) = fmap ((,)a) $ fromDynamic s

-- ...instead, use this if we want to discard the final state:
evalDState :: (Typeable s)=> DynamicState a -> s -> Maybe a
evalDState c =  evalStateT c . toDyn

Testing it Out

Let’s use the example we presented above (passing a mutually-recursive data type as state) to demonstrate our new state monad.

To begin with, we must make our EvenBranch/OddBranch type an instance of the Typeable class. This is really easy in GHC with the DeriveDataTypeable extension. Just add this to the top of the file:

{-# LANGUAGE DeriveDataTypeable #-}

…and add “deriving Typeable” to the data declarations for those two types.

Now let’s see an example of a correct computation in the DynamicState monad (I’m sorry this is such a bad example, but I hope it demonstrates the point):

 -- a non-sensical and contrived example:
traverseGood :: DynamicState String
traverseGood = do
     -- we "get" a state value of type EvenBranch
    (EBranch l i r) <- getD
     -- ...and here we "put" a different type (OddBranch)!
    if i == 2     then putD r
                  else putD l
    (OBranch l' _)  <- getD
     -- ...and the state type changes back once more:
    putD l'
    (EBranch _ i' _) <- getD
    if i' == 3 then return "found 3 in tree"
               else return "3 not found"

Now we can define a little helper function to test our computation and a test EvenBranch tree we can pass as state:

tree = EBranch Nil 2 (OBranch (EBranch Nil 3 Nil) (EBranch Nil 4 Nil))

test :: DynamicState String -> Maybe String
test c = evalDState c tree

And testing it out with GHCi:

*DynamicState> test traverseGood
Just "found 3 in tree"

Cool! It seems like we got the threading of the state types correct and the algorithm did… what we wanted it to do.

Now let’s intentionally screw up the state, in a slight variation to the code above:

-- sae as above but with a programmer error:
traverseBad :: DynamicState String
traverseBad = do
    (EBranch l i r) <- getD
    if i == 2     then putD r
                  else putD l
     -- Oops! This is not the type of our state at this point!:
    (EBranch l' _ _)  <- getD
    putD l'
    (EBranch _ i' _) <- getD
    if i' == 3 then return "found 3 in tree"
               else return "3 not found"

And testing running this computation:

*DynamicState> test traverseBad
Nothing

This time a casting error was caught in our inner Maybe monad and running the computation simply returned Nothing.

Philosophical Conclusion

The existence of Data.Dynamic allows for library designers to implement some pretty cool things that wouldn’t normally be possible in a statically-typed language. But I wonder to what extent its use is not simply “passing the buck” so to speak.

In other words to what extent can a haskell programmer really handle potential type failure at runtime? If Nothings raised by cast et al. failing eventually simply percolate up into an error message thrown in the user’s face, then Typeable seems not much more than a shim to work around haskell’s type system.

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!

The Data Declaration:

To understand a monad you look at it’s datatype and then at the definition for bind (>>=). Most monad tutorials start by showing you the data declaration of a State s a in passing, as if it needed no explanation:

newtype State s a = State { runState :: s -> (a, s) }

But this does need explanation! This is crazy stuff and nothing like what we’ve seen before in the list monad or the Maybe monad:

1. The constructor State holds a function, not just a simple value like Maybe’s Just. This looks weird.
2. Furthermore there is an accessor function runState with a weirdly imperative-sounding name.
3. Finally, there are two free variables on the left side, not just one.

Yikes! Let’s try to get our head on straight and figure this out:

First of all the State monad is just an abstraction for a function that takes a state and returns an intermediate value and some new state value. To formalize this abstraction in haskell, we wrap the function in the newtype State allowing us to define a Monad instance.

Stepping back from the abstract and conceptual, what we have is the State constructor acting as a container for a function :: s -> (a,s), while the definition for bind just provides a mechanism for “composing” a function state -> (val,state) within the State wrapper.

Just as you can chain together functions using (.) as in (+1) . (*3) . head :: (Num a) => [a] -> a, the state monad gives you (>>=) to chain together functions that look essentially like :: a -> s -> (a,s) into a single function :: s -> (a,s).

Let’s bring the discussion back to actual code and try to make sure we understand those three points of weirdness outlined above. Here’s a stupid example of a function that can be “contained” in our state type:

-- look at our counter and return "foo" or "bar"
-- along with the incremented counter:
fromStoAandS :: Int -> (String,Int)
fromStoAandS c | c `mod` 5 == 0 = ("foo",c+1)
               | otherwise      = ("bar",c+1)

If we just wrap that in a State constructor, we’re in the State monad:

stateIntString :: State Int String
stateIntString = State fromStoAandS

But what about runState? All that does of course is give us the “contents” of our State constructor: i.e. a single function :: s -> (a,s). It could have been named stateFunction but someone thought it would be really clever to be able to write things like:

runState stateIntString 1

See, all we’ve done there is used runState to take our function (fromStoAandS) out of the State wrapper; it is then applied it to it’s initial state (1). We would do this runState business after building up our composed function with (>>=), mapM, etc.

That leaves point 3 unanswered. Let’s start exploring the instance declaration for State.

The Instance Declaration

We’ll start with the first line:

instance Monad (State s) where

We create a Monad instance for (State s) not State. You can think of this as a partially-applied type, which is equivalent to a partially applied function:

(State) < ==> (+)
(State s) < ==> (1+)
(State s a) < == (1+2)

So (State s) is the m in our m a. This means the type of our state will remain the same as we compose our function with (>>=), whereas the intermediate values (the as) may well change type as they move through the chain.

Before we move on to the meat of the instance declaration, I’d like to get your mind calibrated to look at the definitions for return and (>>=):

Whenever you see m a, as in

return :: (Monad m) => a -> m a

…remember that m a is actually

State s a

…and when you remember (State s a), think

(s -> (s,a)).

So in your mind, m a becomes function :: s -> (a,s) everywhere you see it. Just forget about the silly State wrapper (the compiler does)!

The definition of return and Bind

Let’s wet our feet with the definition for return:

    return a = State $ \s -> (a, s)

All return does is take some value a and make a function that takes a state value and returns (value, state value). If we ignore the whole State wrapping business, then return is just (,) :: a -> b -> (a, b)

Now recall the definition of bind:

(>>=) :: (Monad m) => m a -> (a -> m b) -> m b

Which in our case is:

(>>=) ::  State s a        -> 
          (a -> State s b) -> 
          State s b

And which is just a silly abstraction for the super special function composition that’s going on, which looks like:

(>>=) ::  (s -> (a,s))       -> 
          (a -> s -> (b,s))  -> 
          (s -> (b,s))

So on the left hand side of (>>=) is a function that takes some initial state and produces a (value,new_state). On the right hand side is a function that takes that value and that new_state and generates it’s own (new_value, newer_state). The job of bind is simply to combine those two functions into one bigger function from the initial state to (new_value,newer_state), just like the simple function composition operator (.) :: (b -> c) -> (a -> b) -> a -> c

At this point, we can show you bind’s definition:

    m >>= k  = State $ \s -> let
        (a, s') = runState m s
        in runState (k a) s'

You can work through that on your own, keeping in mind that we’re doing function composition here. The main thing to remember is that the s at the top, right after State, won’t actually be bound to a value until we unwrap the function with runState and pass it the initial state value, at which point we can evaluate the entire chain.

A Final Note About The State Monad with do Notation

State is often used like this:

stateFunction :: State [a] ()
stateFunction = do x <- pop
                   pop
                   push x

Remember that the functions above are desugaring to m >>= \a-> f... or if there is no left arrow on the previous line: m >>= \_-> f... That a in there is an intermediate value, the fst in the tuple. The push function might look like:

push :: State [a] ()
push a = State $ \as -> (() , a:as)

The function doesn’t return any meaningful a value, so we don’t bind it by using the < -. For more work with do notation and some fine pictures, see Bonus's post on something awful.