HSS: Pretty Printing and some Moves

More code written supporting the pretty-printing of the playing board. Download link on the sidebar.

Also started implementing some of the moves available. Here's the structure for that:

data Tableau_Location = Tableau_Location { t_col :: Int, t_row :: Int }
    deriving Show

data Spider_Move =
        Regular_Spider_Move {
            sm_from     :: Tableau_Location,
            sm_to       :: Tableau_Location,
            sm_revealed :: Maybe Tableau_Location,  -- Card revealed, by
                                                    -- the move, if any.
            sm_count    :: Int -- number of cards moved
            }
            |
        To_Foundation_Move {
            sm_from     :: Tableau_Location,
            sm_revealed :: Maybe Tableau_Location   -- Card revealed, by
                                                    -- the move, if any.
            }
            |
        Deal_From_Talon
    deriving Show

I'd like to think of a better way to represent the move locations other than integers. Not that it can't be made to work, but using integers seems a little clunky with lists. I'm thinking of changing the tableau to be an array of lists instead.

I haven't actually written the code yet to do the regular game moves, but I can tell it is also going to be a bit clunky.

I should come clean here a little bit... There was a previous version of all this that I wrote in Common Lisp. I only got so far as allowing a human to play the game, there was no solving or AI implemented.

So in part, I've been just re-writing that CL version in Haskell.

However, part of the problem I ran into with that version is that I would have had to do major re-work in order to start implementing the AI. The CL version was written in a very imperative style, and I didn't keep around the old board after making a move. That made writing the undo logic a bit interesting, but I got that working OK.

So anyway, we'll need to keep a more functional style anyway. We're going to have a massive tree of possible moves to keep track of, because there are usually a few possible moves for a given position. The trick, of course, is pruning the branches that will be unproductive.

I think, if I'm doing things right, however, that we'll not be duplicating the card structures except for the ones we're modifying (turning face up, for example). And in a normal spider move, 8 of the 10 columns won't change, so that'll save some memory too.