Think again please.

As you see, I was trying to give a benchmark for those two cases. Yet, it was reported as being an ugly hack and not a try at comparing two solutions. I post this short article here not because I wanted a place to cry that I was criticized but because I desired some advice on what should a good benchmark contain and how to write a proper one.

Thanks :)

This post will speak about maze construction. After a few searches for good and valid algorithms, I arrived at Jamis‘ blog. From there, after reading the exhaustive listing of generation procedures, I selected one algorithm to implement in Haskell and to present here. I choose the Sidewinder both because it has a nice name and because it seemed easy to implement in Haskell (requiring little state information and only a few random numbers). It runs very quickly and can be generated on the fly if needed.

It has two disadvantages though: the top row is free of walls and it can be easily solved. If starting on the lower row simple walk until you find an opening to the north and go in that direction. Repeat until you finish. If starting on the top row, you’ll have to do a little backtracking but usually not a time-consuming one. Also, it doesn’t produce all of the possible mazes. Solutions to all these problems will come in following articles, hopefully.

Now, for the generation part, I tweaked the algorithm a little. Instead of deciding at each cell whether to carve east or not, I started by deciding how many cells to carve east before doing any work. This will be clearer soon, after seeing the code.

First, some type definitions used to make the code look cleaner

type Length = Int
type Size = (Length, Length)
type Point = Size

{- The cardinal directions. -}
data Cardinal = N | E | S | W deriving (Eq, Show, Read, Ord, Enum) 

{- A cell. The list contains the openings. -}
newtype Cell = C [Cardinal] deriving (Show, Read) 

{- Simple type for maze. -}
type Maze = Array Size Cell

We have to generate a maze, we will use a function which receives the size of the maze as input and outputs the maze. Since we need randomness, we will be working in the State monad working with a random generator as the state (that’s the State StdGen thing in the signature).

genMaze :: Size -> State StdGen Maze

Basically, the generation is split into two phases: one in which we generate the important points in the maze (ends for working sets and upwards openings) and one in which the actual building is done.

genMaze s@(sx, sy) = do
  (ews, ups) <- gMP s
  return $ build sx sy ews ups

The building process is very simple, it seems that it can be generalized to any other maze generation algorithm with only a few changes. However, this is not true, to use this process you’ll have to obtain a list of important points and build the maze from it. It won’t even work for on-the-fly generation. But this wasn’t the point at that time and is not really relevant now.

build :: Length -> Length -> [Point] -> [Point] -> Maze

We will construct an array of cells, each of them opened to the East and West first.

build sx sy ews ups = runSTArray $ do
  m <- newListArray ((1, 1), (sy, sx)) $ repeat $ C [E, W]

Only north and south walls

Then, using the first set of important points, the eastern openings of some cells will be closed. Using the same set, we will also close some of the western openings such that if a cell claims to be closed eastward the next cell will be closed westward.

  mapM_ (blockCell m E) $ (sx, 1) : ews
  mapM_ (blockCell m W . first (+1)) $ filter (fst . first (/= sx)) ews

East and West closed

After blocking the western edges of each row we will have a set of rows, like in the following picture

  mapM_ (blockCell m W . (\y -> (1, y))) [1 .. sy]

Rows fully closed

We’ll have to open some cells northwards and some southwards, just like we did with the East-West relationship. Then, we will have our maze.

  mapM_ (openCell m N) ups
  mapM_ (openCell m S . second (subtract 1)) ups
  return m

Full maze

Opening and closing cells is in fact modifying the contents of the array.

{-
Block one cell from the maze, represented as an array.
-}
-- blockCell :: Data.Array.MArray Size Cell -> Cardinal -> Size -> m ()
blockCell m d (x, y) = do
  e <- readArray m (y, x)
  writeArray m (y, x) $ block e d

{-
Open one cell from the maze, represented as an array.
-}
-- openCell :: (MArray a Cell m) => a Size Cell -> Cardinal -> Size -> m ()
openCell m d (x, y) = do
  e <- readArray m (y, x)
  writeArray m (y, x) $ open e d

{- Block a cell from one direction. -}
block :: Cell -> Cardinal -> Cell
block (C l) x = C $ filter (/= x) l

{- Open a cell to one direction. -}
open :: Cell -> Cardinal -> Cell
open (C l) x = C $ if x `elem` l then l else x : l

The only remaining part is the generation of the important points, as given by the Sidewinder’s algorithm. Since the first row is special (no walls blocking eastward) we will skip it when generating the points. Only the other rows will be used to generate the important Row Points. After this, do a simple fold to construct the Maze Points used in the above build procedure.

gMP :: Size -> State StdGen ([Point], [Point])
gMP (sx, sy) = do
  points <- mapM (gRP 0 sx) [2..sy]
  return $ foldl (\(x, y) (a, b) -> (x ++ a, y ++ b)) ([], []) points

Generating the RowPoints is simple: generate two random numbers and return the points obtained from them. More exactly, construct a list of them. The numbers will represent the length of the current corridor and the offset at which the opening to the previous row will be carved.

gRP :: Coord -> Length -> Coord -> State StdGen ([Point], [Point])
gRP c sx y
  | sx <= 0 = return ([], [])
  | otherwise = do
    len <- state $ randomR (1, sx)
    up <- state $ randomR (1, len)
    (rx, ry) <- gRP (c + len) (sx - len) y
    return ((len + c, y):rx, (up + c, y):ry)

Basically, the above function is the only one which needs random numbers. However, since we want to be able to change the generation if another, more efficient, algorithm is found, the only exported function should be genMaze.

The entire code can be seen on Github.

Next time we will look at how to do the actual rendering of this maze in Haskell (the above pictures were generated using a modified version of what will be presented then). Afterwards, we’ll touch some more interesting topics related to mazes but I don’t want to spoil anything right now.

The assignment was done in Python with PyGTK. Looking at the documentation for doing custom draws, I saw that one has to use a Pixmap obtained by using an Image object and then use methods associated with the drawing context obtained from it. This works, is easy to reason about but has a small problem.

When you also want to save the image to a file you cannot use the same Pixmap. That is because GTK can only save Pixbuff content, not Pixmaps. And you cannot easily convert between one structure and the other. In fact, you cannot even use Image methods to obtain what you need: Pixbuff or Pixmap. That is because a Image has a backup structure and that backup structure can be a Pixbuff or a Pixmap (or several some others, as taken from PyGTK documentation).

After many failed attempts to do this, I’ve come across the following convoluted solution. It was found after long search through the maze of PyGTK documentation (even dropping a little to the level of GTK documentation and trying a cross-language translation) but it worked at least.

cmap = drawable.get_colormap()
pbuf = gtk.gdk.Pixbuf(gtk.gdk.COLORSPACE_RGB, True, 8, *drawable.get_size())
pbuf = pbuf.get_from_drawable(drawable, cmap, 0, 0, 0, 0, *drawable.get_size())
pbuf.save(fName, 'png')

After this project was finished, I’ve moved to the next which was done in Haskell. There I also had to do a custom drawing but, this time, I’ve turned to using Cairo. Much simpler and easier to reason about. And much simpler to save the images to files if needed.

Unfortunately, the PyGTK documentation seems to fail to mention this or at least give a hint to use Cairo instead of native GTK methods. But this can be fixed since we know that this project is open source.

I’ll come back later with more code related articles. In fact, I think I may start a series of articles soon.

The first one, a id3 classifier was done in C. At the time Haskell was not available as a potential language to write the code into. However, the application offered a lot of option and it was fun and entertaining to work on it. Though not perfect, it is something I am very proud of. Code for it can be found on github and may be forked and improved if needed.

Then, we had to use Reinforcement Learning to make a robot walk in a grid along a certain path. This time, although Haskell was available, I’ve done it in Python because I wanted to have a GUI and the time was too pressing at that moment to try to do this in Haskell. Code also on github.

Later, we had to implement a regression/forecasting program using neural networks. I’ve done it in Python too, also because of the GUI and the available time. This homework raised a small problem, the solution to it will be posted soon. Code is on github, as a demo for a neural network implementation.

And then, there was the last homework, the freely chosen one. Just like the previous semester, I chose to do something in Haskell: to implement a robot which uses genetic algorithms to escape from a maze. I generated the maze using Sidewinder’s algorithm and several questions which will be answered in following posts have arisen. The implementation is not something that I’m extremely proud of (since the convergence is slow – the approach with genetic programming failed). Yet, it is, I believe, a code well written in Haskell, using the right tool for several functions. And I finally learned how to properly use advanced Haskell features, where they are needed, not everywhere or nowhere like in the previous attempts (at least I believe this now).

I’ll come back with something related to Python and GTK soon.

And it does so, with several exceptions. My main disappointment came from the way it handles function signatures. You have the @Override annotation which may help you spot mistakes in overwriting functions from base classes. It helps you doing this but it also fails at some point.

Consider that you have the following interface

public interface ITest {
    public int function1(int x);
    public int function2(int x);
    public int function4(int x);
    public int function5(int x) throws CustomException;
}

with the following CustomException definition.

public class CustomException extends Exception { 

    String msg; 

    public CustomException(String msg){
        this.msg = msg;
    } 

    @Override
    public String toString(){
        return msg;
    }
} 

From this, you would understand that the only exception which could be raised is CustomException from function5. Is this really true?

Let’s see an abstrac class using this interface

public abstract class ATest1 implements ITest { 

    @Override
    public int function1(int x) {
        if (x == 0)
            throw new InvalidParameterException("X must not be 0");
        return x;
    } 

    @Override
    public abstract int function2(int x); 

    @Override
    public int function4(int x) {
        return x;
    } 

    @Override
    public int function5(int x) throws CustomException {
        if (x == 0)
            throw new CustomException("X must not be 0");
        return -x;
    } 

} 

Now, we have one more exception which can be thrown but Eclipse didn’t suggest to add a throws declaration to that method.

Now, consider the following two classes, one of them defining the single left out method

public class Test2 extends ATest1 { 

    @Override
    public int function2(int x) {
        return x + 10;
    }
} 

while the other overwrites a few other methods and doesn’t throw any exception in them.

public class Test1 extends ATest1 { 

    @Override
    public int function2(int x) {
        return x + 1;
    } 

    @Override
    public int function1(int x){
        return x + 1;
    } 

    @Override
    public int function5(int x){
        return x + 100;
    } 

} 

Suppose now, that the user has access only to the interface, he knows only the signatures of functions. In this case, what will the following program do?

    public static void main(String args[]){
        ITest t1 = new Test1();
        ITest t2 = new Test2();
        Test2 t3 = new Test2();
        Test1 t4 = new Test1(); 

        System.out.println(t1.function1(0));
        System.out.println(t1.function2(0));
        System.out.println(t1.function4(0));
        try{
            System.out.println(t1.function5(0));
        } catch (CustomException e) {
            e.printStackTrace();
        } 

        System.out.println(t2.function1(0));
        System.out.println(t2.function2(0));
        System.out.println(t2.function4(0));
        try {
            System.out.println(t2.function5(0));
        } catch (CustomException e) {
            e.printStackTrace();
        } 

        System.out.println(t3.function1(0));
        System.out.println(t3.function2(0));
        System.out.println(t3.function4(0));
        try {
            System.out.println(t3.function5(0));
        } catch (CustomException e) {
            e.printStackTrace();
        } 

        System.out.println(t4.function1(0));
        System.out.println(t4.function2(0));
        System.out.println(t4.function4(0));
        System.out.println(t4.function5(0));
    } 

Each try-catch block above was suggested by Eclipse. As you see in function5 calls, this is not a symmetrical way, giving rise to some errors while refactoring. Hopefully, Eclipse is there and suggests you that there are some exceptions.

Yet, should you make main throw exceptions instead of reporting them, there would be no way to reason why that exception appeared there after changing t4 with t3 in the last line.

However, the above main doesn’t throw CustomException. It throws InvalidParameterException from t2.function1(0), something which is inexplicable from the function’s signature.

This is similar to getting a NullPointerException somewhere where you expected only valid references. Or a segfault in a library function which didn’t present itself as being able to segfault. Something which you cannot fix and the documentation doesn’t explain how it was produced. A bug and a very nasty one.

You may say that this is an unlikely situation, that since you knew what exceptions are thrown, you can add the throws annotation to the interface and then you can document it. However, there are cases of big projects with multiple inheritance paths and lengthy development history with multiple teams of developers. In these instances, it is very common to throw some exception in a method from a class deep down in the hierarchy without needing to report it upwards and document it.

In Haskell, it is simpler. When you change a function’s type to include the possibility of failure, the Maybe you might add must be put in every signature for each function calling you function, you’ll have to change them all. Thus, you’ll surely be forced to document the possibility of failure.

Only head: empty list and Prelude: undefined or exceptions regarding missing patterns can show up (maybe several others but I guess that they can be sorted into one of these three). The last two cases indicate a serious error in the library design and can be fixed, someway or the other. And the first case is the reason why a stack-trace printing debugger for Haskell is so much desired.

But this was a rant about Java, not about Haskell.

EDIT: I hit the post button to early and it is possible that a version with TODOs has appeared in your feed, I’m sorry for that.

First, we have to define a data structure for keeping the network of resistors. I’ll use a structure used a while ago in a C algorithm for solving the network analysis problem but more simplified than what I used at the time. We only need to be interested in networks formed with resistors only, thus we can use only node elimination to solve this problem. Because of this, the data structures used are very simple:

    2 
    3 type Resistance = Double
    4 type Conductance = Double
    5 
    6 type Network a = [(a, Node a)]
    7 type Node a = [WireTo a]
    8 type WireTo a = (a, Resistance)
    9  

As you see, we’ll use two association lists: one to keep the mapping between node ids (those can be almost anything) and one to keep the mapping between the node id and the resistance of the wire connected between that node and the actual node. While this structure prevents the know tying problem (homework: try solving this problem using techniques presented in the linked article), it adds duplicated information: for each wire between nodes a and b we store it in two places: once in node a and once in node b.

The previous paragraph hinted that there are two problems which need to be solved. Firstly, when comparing two wires and two nodes only the ids need to be taken care of, not everything in the pair. Thus, we need to implement our own equality functions.

   10 (===) :: (Eq a) => (a, b) -> (a, b) -> Bool
   11 (a, _) === (b, _) = a == b
   12 
   13 (=/=) :: (Eq a) => (a, b) -> (a, b) -> Bool
   14 (=/=) a = not . (a ===) 

To solve the second problem, I wrote two functions to the user and will demand (expect) that the user will use them to construct any network. Thus, the first function will construct a part of the network: a simple wire (similar to the return function from monads).

   66 -- builds a simple network: a simple wire
   67 buildPart :: (Ord a) => a -> a -> Resistance -> Network a
   68 buildPart a b r
   69   | r < 0 = error "Negative resistance is not allowed"
   70   | a == b = error "No wire can have the same ends"
   71   | a > b = buildPart b a r
   72   | otherwise = [(a, [(b, r)]), (b, [(a, r)])] 

Using this function we can already construct the first test network, as seen in the following picture:

  117 {-
  118 Simple test: a network with only a wire.
  119 -}
  120 testSimple :: Network Int
  121 testSimple = buildPart 0 1 5 

Simple network with only a resistor

The second function will take two networks and construct a new one by joining them (similar to the mplus function from MonadPlus or mappend from Monoid).

   74 -- joins two networks
   75 joinParts :: (Eq a) => Network a -> Network a -> Network a
   76 joinParts [] ns = ns
   77 joinParts (n:ns) nodes
   78   | other == Nothing = n : joinParts ns nodes
   79   | otherwise = (fst n, snd n `combineNodes` m) : joinParts ns nodes'
   80   where
   81     other = lookup (fst n) nodes
   82     m = fromJust other
   83     nodes' = filter (=/= n) nodes

Care must be taken when joining two networks containing the same nodes. To combine them correctly, the following two functions are used:

   85 {-
   86 Combines two nodes (wires leaving the same node, declared in two parts of
   87 network.
   88 -}
   89 combineNodes :: (Eq a) => Node a -> Node a -> Node a
   90 combineNodes = foldr (\(i,r) n -> addWireTo n i r)
   91 
   92 {-
   93 Adds a wire to a node, doing the right thing if there is a wire there already.
   94 -}
   95 addWireTo :: (Eq a) => Node a -> a -> Resistance -> Node a
   96 addWireTo w a r = parallel $ (a,r) : w

When we encounter two parallel resistances, we will transform them immediately.

   98 {-
   99 Reduce a list of wires by reducing parallel resistors to a single one.
  100 -}
  101 parallel :: (Eq a) => [WireTo a] -> [WireTo a]
  102 parallel [] = []
  103 parallel (w:ws) = w' : parallel ws'
  104   where
  105     ws' = filter (=/= w) ws
  106     ws'' = w : filter (=== w) ws
  107     w' = if ws'' == [] then w else foldl1 parallel' ws''
  108 
  109 {-
  110 Reduce two wires to a single one, if they form parallel resistors.
  111 -}
  112 parallel' :: (Eq a) => WireTo a -> WireTo a -> WireTo a
  113 parallel' (a, r1) (b, r2)
  114   | a == b = (a, r1 * r2 / (r1 + r2))
  115   | otherwise = error "Cannot reduce: not parallel resistors" 

Right now, we can construct several more tests, presented in the following pictures

  123 {-
  124 Second test: a network with two parallel wires.
  125 -}
  126 testSimple' :: Network Int
  127 testSimple' = buildPart 0 1 10 `joinParts` buildPart 0 1 6
  128 
  129 {-
  130 Third test: a network with two series resistors.
  131 -}
  132 testSimple'' = buildPart 0 1 40 `joinParts` buildPart 1 2 2
  133 
  134 {-
  135 Fourth test: tetrahedron
  136 -}
  137 testTetra :: Network Int
  138 testTetra
  139   = buildPart 0 1 1 `joinParts`
  140     buildPart 0 2 1 `joinParts`
  141     buildPart 1 2 1 `joinParts`
  142     buildPart 0 3 1 `joinParts`
  143     buildPart 1 3 1 `joinParts`
  144     buildPart 2 3 1 

A collection of networks

Now, we can even build 2D networks by giving Cartesian id’s to nodes. For example, the following is the simplest instance of the XKCD problem (reduced to a minimum configuration).

  146 {-
  147 Fifth test: 2 squares
  148 -}
  149 testSquares :: Network (Int, Int)
  150 testSquares = foldl joinParts [] . map (\(x, y) -> buildPart x y 1) $ list
  151   where
  152     list = [((0, 0), (0, 1)), ((0, 1), (0, 2)), ((0, 2), (1, 2)),
  153       ((1, 2), (1, 1)), ((1, 1), (0, 1)), ((1, 1), (1, 0)), ((0, 0), (1, 0))] 

Small 2D network

Before going into defining the XCKD problem and solving it, we need to implement the algorithm for solving any network of resistors. The following code is not optimized and I am really sure that it can be tweaked a little to allow for infinite structures due to the laziness of Haskell (to solve this is left as a homework). First, the code tests whether we compute a valid answer or not.

   16 {-
   17 Starts the solving phase testing if each node is defined.
   18 -}
   19 solve :: (Ord a) => Network a -> a -> a -> Resistance
   20 solve n st en
   21   | stn == Nothing = error "Wrong start node"
   22   | enn == Nothing = error "Wrong end node"
   23   | otherwise = solve' n st en
   24   where
   25     stn = lookup st n
   26     stnd = fromJust stn
   27     enn = lookup en n

After we are sure that the nodes in question exist in the network, we start the solving process

   29 solve' :: (Ord a) => Network a -> a -> a -> Resistance
   30 solve' n st en
   31   | null candidates = getSolution n st en
   32   | otherwise = solve' (removeNode n (head candidates)) st en
   33   where
   34     candidates = filter (\(x,_) -> x /= st && x /= en) n

When we have only the start and end nodes we return the solution

   63 getSolution :: (Eq a) => Network a -> a -> a -> Resistance
   64 getSolution n st en = fromJust . lookup en . fromJust . lookup st $ n

Otherwise, when we have a candidate node to be removed, we remove it:

   36 removeNode :: (Ord a) => Network a -> (a, Node a) -> Network a
   37 removeNode net w@(tag, nod)
   38   | length nod == 1 = filter (=/= w) net
   39   | otherwise = filtered `joinParts` keep `joinParts` new
   40   where
   41     affectedTags = map fst nod
   42     -- construct the unaffected nodes list
   43     unaffectedNodes = filter (\(a,_) -> a `notElem` affectedTags) net
   44     keep = filter (=/= w) unaffectedNodes
   45     -- and the affected ones
   46     change = filter (\(a,_)-> a `elem` affectedTags) net
   47     -- remove the node from all the maps
   48     filtered = map (purify tag) change
   49     -- compute the sum of inverses
   50     sumR = sum . map ((1/) . snd) $ nod
   51     pairs = [(x, y) | x <- affectedTags, y <- affectedTags, x < y]
   52     new = foldl joinParts [] . map (buildFromTags nod sumR) $ pairs
   53 
   54 purify :: (Eq a) => a -> (a, Node a) -> (a, Node a)
   55 purify t (tag, wires) = (tag, filter (\(a,_)->a /= t) wires)
   56 
   57 buildFromTags :: (Ord a) => Node a -> Conductance -> (a, a) -> Network a
   58 buildFromTags n s (x, y) = buildPart x y (s * xx * yy)
   59   where
   60     xx = fromJust . lookup x $ n
   61     yy = fromJust . lookup y $ n

We can test each of the previously defined networks to see if the algorithm works.

*Main> solve testSimple 0 1
5.0
*Main> solve testSimple' 0 1
3.75
*Main> solve testSimple'' 0 1
40.0
*Main> solve testSimple'' 0 2
42.0
*Main> solve testTetra 0 3
0.5
*Main> solve testSquares (0, 0) (1, 2)
1.4000000000000001

Now, the solution to the XKCD’s problem. First, we define the network: we will take a finite case, between and . By increasing n we will get closer and closer to the actual result (as you will see later, the convergence is pretty good).

  155 build :: Int -> Network (Int, Int)
  156 build n = foldl joinParts [] . map (\(x, y) -> buildPart x y 1) $ list
  157   where
  158     list = [(x, y) | x <- points, y <- points, x `neigh` y, x < y]
  159     points = fillBelow n
  160 
  161 fillBelow :: Int -> [(Int, Int)]
  162 fillBelow n = [(x, y) | x <- [-n .. n], y <- [-n ..n]]
  163 
  164 neigh :: (Int, Int) -> (Int, Int) -> Bool
  165 neigh (a, b) (c, d) = abs (a - c) + abs (b - d) == 1 

An instance of the XKCD problem

Thus, to solve the problem for one iteration we have

  167 solveXKCD :: Int -> Resistance
  168 solveXKCD n = solve (build n) (0, 0) (1, 2) 

And the main, used for printing the results

  170 main = mapM (print . \x -> (x, solveXKCD x)) [3..] 

And now the results. I let the program run until it reached a network of size 25 then I stopped it and plotted the results.

Resistance vs grid size, see the convergence speed

From the plot, it is easy to see that the valid result lies somewhere between and range, just like the valid answer is.

In the end, I’d like to relate to another post from that topic: please add more puzzles like this so that I can do something when I have free time instead of slacking off.

However, during this little free time I had this week, I tried again to parse a simple text file with Alex.

We are given an input file consisting of text and properly enclosed mark-ups like ** for bold text, // for italic text, — for stroked-out text and __ for underline text (each of them enclosing the text enriched with the format). For example, //this should be in italic// should be an italic text.

In order to do this, we begin be specifying the regular expressions used to split the text into tokens (also known as lexing or scanning) and the actions associated with each expression. First, we define the special symbols, used as a mark-up.

00021 
00022 -- put here all characters used to select format
00023 $formatspec = [\*\/_\-]
00024  

Then we specify the expressions and their actions.

00027 
00028 [^$formatspec]+ { takeText }
00029 $formatspec { takeText } -- for single chars (think a * b)
00030 \/{2} { flipFormat Italic }
00031 \*{2} { flipFormat Bold }
00032 _{2} { flipFormat Underline }
00033 \-{2} { flipFormat Strikeout }
00034 

As you see in line 29, we need to handle single appearances of mark-up characters in a separate regular expression. Otherwise, text like “mark-up” or “a * b” will result in a scan error.

Before defining the action, let’s look at how the task at hand was solved. Basically, we will gather as much text as possible without including any format specifier into a single value, constructed using takeText. When we encounter a format specifier we change a global state to inform the subsequent takeText call that the gathered string is enriched with a new format. Because that data is not defined anywhere in the Alex templates, we will have to implement it ourselves. To do that, we tell Alex that we want a monadic wrapper with user data

00018 
00019 -- the monadUserState allows for a monadic parser with user data
00020 %wrapper "monadUserState"
00021  

Then, we define the user data and the initial value for it (don’t change the name of the following functions, they are called this way from the template)

00071 type AlexUserState = [Format]
00072 
00073 alexInitUserState = []
00074  

The Format data is another defined type, its definition may be left as an exercise since it is not relevant here.

Also, although the wrapper is called monadUserState there are no functions defined there to do that. You’ll have to implement them by hand for now, a mail was sent describing the problem on haskell-cafe, maybe it will be solved soon. (Also, this wrapper is not presented in the official documentation for Alex, I have found it while trying to solve other problems by looking at the templates).

00074 
00075 getUserData :: Alex AlexUserState
00076 getUserData = Alex $ \s@AlexState{alex_ust=udata} -> Right (s, udata)
00077 
00078 setUserData :: AlexUserState -> Alex ()
00079 setUserData udata = Alex $ \s -> Right (s{alex_ust=udata}, ())
00080  

The last thing that you need to define is what should be done when the end of the file  (EOF) is encountered. We will return Nothing, making all actions have return type of Alex (Maybe Token) instead of simply Alex Token.

00097 
00098 {-
00099 Remember that this function must also return a token!! We have made it to
00100 return Nothing to enable you to forget about it.
00101 -}
00102 alexEOF :: Alex (Maybe Token)
00103 alexEOF = return Nothing
00104 }
00105  

While this has the advantage that you can use only the good tokens in the Token data definition, it has the disadvantage that two layers of monads are present. Of course, this function can be implemented by each user.

In the end, we need something to start the whole parsing process.  We do this via two functions: one to loop over the text returning it token by token and collecting the results into a list and another to start the whole computation.

00055 
00056 run :: String -> Either String [Token]
00057 run content = runAlex content $ loop []
00058 
00059 loop end = do --alexMonadScan >>= \t -> loop end >>= \e -> return $ t : e
00060   tok <- alexMonadScan;
00061   case tok of
00062     Nothing -> return end
00063     Just t -> loop end >>= \e -> return $ t : e
00064  

The end result looks like this:

[Text [Bold] "This is a bolded paragraph, every word here should be bold ",Text [Strikeout,Bold] "and this part should be stroked out",Text [Bold] " while ",Text [Italic,Bold] "this should be in italic",Text [Bold] " and ",Text [Underline,Bold] "this underlined",Text [Bold] ". ",Text [Italic,Strikeout,Underline,Bold] "This part should have all of the attributes",Text [Bold] "."]

However, this is not yet complete, I guess that no user would want to look at something like that. A conversion function is needed but that is not in the scope of this article. I’ll return on this topic later.

I had four homeworks at Compilers Design. All in Java. In the end, we obtained a compiler for Cool. However, I’ll not insist on this. It was fun on some parts, and bad on others. Maybe I’ll try to change something in the next year.

Then, I had 3 assignments at Artificial Intelligence. One was a simple game in Prolog and is not relevant to this post. The second one was to write a simple liniar planner for a general class of problems in Scheme. As the code on github shows, I ended up writing some Scheme functions to turn it into a more Haskel-ish language. It was a fun project where I have written many folds and maps.

Lastly, the third assignment was more liberal: we had to choose from a series of titles and languages. I decided to implement a multi-agent Minesweeper game in Haskell. The code is now public on github (though it’s yet to be completed on the GUI, it has a few bugs and has some design choices which I’ll want to rewrite). However, this was the most exciting project I’ve been working on this year (until now, I will have to do a Valgrind port in the next semester as part of the Graduation Assignment – don’t know if this is the exact name).

Recently, I’ve tried to implement the KamikazeRace game on Facebook for an Android device. The code is also on github but it was only tested locally (though some of my colleagues are testing it on real devices and bugs are filled in back to me).

Speaking of bugs, recently I’ve moved several of ROSEdu’s repositories from Trac instances to Redmine ones. When this move will be completed and the articles describing the ROSEdu’s projects will be available I’ll come back on this subject.

Right now, I have one more exam to take and I’m going to learn for it in a few moments. Or sleep :)

What happened was that I was dissatisfied with the first version and dreamed a new version which was a total remade of the project. However, I haven’t had the needed time to finish it before school homeworks began so it entered into a complete sleep, just like the blogs and the mmorpg that I was playing.

Now, when I see that I have a little more free time before I’ll have to really start my Graduation Thesis, I find myself thinking about what I wanted this project to be. I find it difficult to restart working on it right now while I am constantly flooded into a stream of ideas. Thus, I have two choices: either I’ll choose to stay and remember what I planned for that project and I’ll start working on it or I’ll start a new project from the most promising idea while trying to note the others somewhere where I know I could find them later (and in an understandable format, I’ve lost too many ideas because I didn’t remember what was I thinking when they poped up into my head).

I’ll chose the second option because it still leaves open the first alternative. Maybe, someday, I’ll restart work on this project or a new idea will make it obsolete (like that one thing which is bugging me for a few days, more on this later).

I’ll be back soon with a more optimistic post, when I’ll have time again to post.