HSS: quick update, and interesting papers

Haven't done too much with Spider Solitare in Haskell lately. Added a help command and some other little nicities. Still need to finish the input and move validation.

Been reading the Comparing Approaches to Generic Programming in Haskell which has been interesting.

Also, in a Reddit topic about Chicken Scheme I discuss why I've settled on using Python for the majority of our development projects at my company. Even though I think Haskell is the bee's knees as far as expressiveness and concicseness goes.

HSS: Now barely useable!

We (by we I mean me) are getting close to a 1.0 release for Spider Haskell. Download the source code at the right, as usual.

Mostly just been working on the UI for playing a game on the console. There's barely any input validation. And there's no checking to see if a move is valid at all. So if you want to play, it is on the honor system.

But, all the basics are there, if not completely tested. Undo was easy to implement, because we keep a list of all the previous game states. This was actually one of the stumbling blocks of the original CL version. Because that version was doing in-place modifications, it was a lot of work to implement the undo. We would look at the move history, and manually reverse it. So we had to do things like also keep track of any cards that were revealed by the move.

The two codebases are now roughly the same size. However, there is some duplicated code in the CL version (was starting to re-organize the project before working on it), so that doesn't mean anything.

To do: Do full command validation (don't want a String to Int conversion to blow up), and move validation. And maybe a little in-game help.

And after that, we can start trying to solve Spider Solitare, once and for all. :-)

HSS: Move Validity

More code for the Spider Solitaire game in Haskell, download link at the right as usual.

I haven't made a whole lot of progress, but I'm slowly churning through the functionality that was implemented in the Common Lisp version.

Included with the current version is the calculation of 'card clusters' as I call them. Here's the important bits of that:

-- card clusters
--
-- A cluster is a set of cards which may be moved at once.  Like an 3, 2, 1
-- of clubs, for example.
--
-- In a column of the tableau, clusters are marked from 0 at the bottom
-- on up.  So it is only valid to move cluster 0.  But we keep track of the
-- other clusters in the column for strategic purposes.

compute_cluster :: [Card] -> [Int]
compute_cluster [] = []
compute_cluster xs = reverse $ rv_cards (reverse xs) 0
    where
        rv_cards [] _ = []
        rv_cards [x] y = [y]
        rv_cards (x1:x2:xs) y = y : (rv_cards (x2:xs) new_y)
            where
                new_y = if (plays_on_match x1 x2)
                            then y
                            else y + 1

-- True if c1 plays on c2, False otherwise
plays_on_match Card -> Card -> Bool
plays_on_match c1 c2 =
    case (plays_on c1) of
        Just x -> x == (c_value c2) && (c_suit c1) == (c_suit c2)
        Nothing -> False

I've a bit of a dilemma as far as where to store data. In the CL version, what cluster a particular card was in card data structure itself. I'm debating if this is a good idea or not.

So say we've just made a move, so we're creating a new instance of the Spider_Game data structure, which will have the modified column(s). Do we compute the new columns, and then create a new version of them with the clusters properly filled in? Seems a bit inefficient.

And why exactly am I worried about efficiency at this point? Isn't premature optimization one of the great sins of a programmer?

Side note, I realize there are issues with the layout of the site, and it doesn't work so hot when your pre-formatted text is 80 columns wide, and the blog itself only wants me to post 60-column wide text. I'll need to fix that.

Edit: Trying out this really simple template, which allows wider columns for the blog post itself.