A swank growl

I ran into a frustrating puzzle while learning about agents in Clojure. The problem was with a tool, not Clojure itself but a few neat things shook out along the way.

Agents in Clojure are a high level concept for concurrency. They are intended for independent, asynchronous data munging. They're pretty easy to use... basically a value is associated with an agent when it is created, and then when a function is applied to the agent the result becomes its new value.

Here is the definition of a banana agent:

Here is the function which produces its new value:

Here it is in action:

The debug statements are missing! Code invoked by (send) doesn't yield output to the REPL -- it went to a different buffer.

The major symptom of my pernicious problem was that my precious debug statements weren't printing anything. This was a major problem since that was the only way I had to know what was happening. At this point it's important to disclose that I am an unrepentant GNU/Emacs user. This leads to using swank-clojure since a symbiotic REPL is really, really cool.

After much confusion I finally found my precious debug statements! They were hiding in the rarely-used inferior-lisp buffer. It's awkward for me to keep this buffer open so I looked for something... cooler.

Growl is a MacOS X utility which displays notifications in self-dismissing windows. The gap between Clojure and Growl is little more than implementing java.io.Writer. Clojure actually makes it easier than it should be.

It's worth taking a close look at the proxy statement, specifically the write method. It is an abstract, overloaded method in Writer. Only one of those overloads is abstract, and it's NOT the one implemented above. The one implemented above is the only one actually called. Or, you know, quacked. That's neat! I didn't even have to implement all of the abstract methods! All I had to do is what I actually needed to do.

The last piece of the puzzle was making Clojure use the Growl bridge. The binding function made this happen with one line of code. out is the "variable" which Clojure uses for writing to standard out. A call to (binding) gives out a new value. and the old value is restored when (binding) exits. All of the compiled references to out within Clojure automatically use my binding. TOO COOL.

Ta DA!

Wrapping deftype factory methods

(Standard disclaimer: Clojure is a new hobby.)

I'm exploring the upcoming feature in Clojure called deftype. Similar to defining a class in Java, deftype is a way of grouping related data and methods. Actually, it's quite an improvement over the old (defstruct) way. defstruct only groups related data together.

As ever, code examples are based on my side project pokerepl. This entire post focuses on the suits and values in a deck of playing cards.

Here's the old way of doing things:

Here's my first baby step down the new path:

It's longer, but it does more. We get optional type hinting for the data (seen here as #^clojure.lang.Keyword). The type being extended is listed (Object in this case). The override of Object.toString means all instances will be pretty printed automatically.

What you don't see is a "constructor". There's no need because Clojure provides reasonable defaults here; the values for "value" and "suit" are passed to new instances of Card.

Unfortunately that wasn't good enough. Fortunately Clojure is a very dynamic programming language, so I could easily replace the implicitly defined factory function with my own code. To summarize, a call to (deftype Foo [bar]) generates two factory functions (Foo [bar]) and (Foo [bar meta-map ext-map]). It's possible to overwrite these but unclear how to honor the postconditions... exactly what gets returned?

So rather than replace the factory function entirely, I decided to embrace and extend it!

So that's a bit of a mess, but the requirements were too. I needed syntactical sugar to make dealing with this code palatable. And now I have said sugar. The following is now true:

My main gripe with (deftype) is that it complicates editor support. Previously, "defn" and a relatively small list of keywords meant a list was a function definition. Functions indent differently than other types of lists. deftype means the editor is going to have to understand the source better. But, it's a small and good problem to have IMO. Also hoping for destructuring support in vector for param arguments.

The path of least resistance in Clojure

(Edit 2: Standard disclaimer: Clojure is a new hobby.)

Immutable data structures seem like an odd idea, but they are on the path of least resistance in Clojure. This is not the case in languages like Java. In this post I will rewrite a snippet of Java into Clojure and explain the major differences.

The snippet of Java comes from Martin Fowler's bliki posting on Fluent Interfaces. I picked this code snippet because it is concise, reads easily, and fills a common need.

This code clearly links an existing customer to a new, rush order of three items. Consider the "skippable" method... that is probably on the Order object yet works on an OrderLine. The Order code probably finds the newest OrderLine and updates its skippable property. Modifying objects is the path of least resistance in Java, or rather creating objects in an incomplete state and updating them until complete.

Modifying objects in Clojure is not on the path of least resistance. Many Clojure methods return a new, lazy version of the input. Working with return values like this encourages creating complete objects and then using them. Here's an example -- please temporarily ignore the unfamiliar functions and low level of abstraction.

• (struct foo 123 "abc") is basically calling the constructor for the foo class with two arguments.
• (struct-map foo :num 123, :text "abc") calls the constructor with named params rather than positional params
• (let) is how you define local variables, lines and order in the above example.
• (merge old-map new-map) creates a new map by merging existing maps
• (conj) creates a new collection from its arguments
• (get) returns the value for a key in a hash map, or a default value if specified.

It's not obvious but the return value is the output from (merge). That is the last statement in the (let) block, which is the only statement in the body of the (add-order) function. Values flowing like this is in the path of least resistance in Clojure.

Besides doing things in a different order than Java, there is one more very important but subtle difference. Let's say a customer wants two orders:

Some quick code to show how it works:

The new order has been lost because the return value from the function was not captured. This is a silent runtime failure -- not a fun type of problem to chase down. One solution is to rebind "me":

I've been a little dishonest here talking about "objects" in Clojure. As seen here they are little different than hash maps.

For anyone who is interested, the entire source listing for this example follows. Thanks for reading!

More poker with Clojure: what’s in a hand?

Standard disclaimer: Clojure is a new hobby.

In a previous post I wrote some code to create and shuffle a deck of cards. This post demonstrates one way to figure out what a hand is worth according to basic 5 card draw rules.

The implementation is basically one switch statement from a C/Java/Ruby/Groovy/Python perspective. Ruby and Groovy coders will recognize that the return value of the function is the value of the last expression evaluated. So an if statement returns either the value of the true expression or the value of the false expression.

When conditional logic returns values like this, there is no need to use a stack variable to store a return value.

A quick introduction to some of the functions used in the code:

• (if): Aside from returning its true/false expression result, no major difference than Java.
• (cond): Basically a switch statement, returning a value just like (if)
• (let): Defines and initializes "variables" which are immutable.
• #(): This defines an anonymous function. Believe this is a macro for (fn).
• #{}: This defines a set data structure; unordered and no duplicates. Also see the (set). function
• {}: This defines a map data structure, populated with unordered key/value pairs. Bonus: (map key) AND (key map) both return the value for key in a map.

With some minimal descriptions listed, let's dig into the code:

When judging a hand it's critical to know how many of each suit are present AND how many of each value are present. One way to model this is to build histograms for suit and value.

The implementation behind that is not an easy read (probably because it's not great Clojure). Basically this code iterates over the pool of attributes (suits or values) and uses (conj) to aggregate maps into one big map. In the middle a filter function finds all cards matching the current property and then the total number is counted up.

Only one more helper method to go. This method determines whether the hand is a straight, whether all of its cards have consecutive values. The approach taken was a little odd. An array of all possible straight values is built and then segmented into overlapping hands. For example, the first two arrays would be [ace, two, three, four, five] and [two, three, four, five, six]. Each of these possibilities is matched against the hand, using Clojure's facility to compare sets easily.

(some) is a function which returns true when its filter function returns true for any of the collection items it examines.

After all that, here is the hand judging function. It's basically a few local "variables" and a switch statement. Some additional conditional logic appears inside the switch statement as well. This is required to determine whether a hand with three of a kind is a full house (are the remaining cards a pair?).

In the near future all this code will be cleaned up and moved out to BitBucket. Ideally some basic chip tracking and logic would be added so you could actually play poker from a REPL. That's probably much more difficult than it seems, but hopefully this has been useful so far. Please don't hesitate to contact me (goof at foognostic dot net) with any questions!

Shuffling cards with Clojure

Standard disclaimer: Clojure is a new hobby.

One of my friends and coworkers has been gently cluesticking me into learning poker. Along the way he suggested I write a very simple hand generator to get a feel for how the number of players changes the relative strength of your hole cards. Shuffling cards is one small step along the way, and that seemed like a good place to start.

First, let's create a poker namespace to work in and then define some basic constants as keywords in sets.

Next, let's "define a class." I'm quoting that because a struct in Clojure is just a map with some keys to be expected.

Next we actually need, you know, a full deck of cards to shuffle. This was harder than I expected. At first I tried two loops, first iterating over suits and then values. This resulted in a list of ... four lists of... thirteen cards.

Unfortunately (map) didn't work as hoped. I decided to try a list comprehension. This was something I remembered from using once in Python. It turned out to be exactly what I needed:

This yields a lot of text, so let's inspect the output programmatically. (filter) is a function which takes a function and a list; the output consists of the list items for which the function inspects and returns true.

Now that we have the deck straightened out, it's time to shuffle it. I'm getting the feeling there is a beautiful mathmatical way to sort 52 cards involving permutations which would be easy to code functionally. Unfortunately I'm not there yet on either side. This implementation is really crude.

For example, this random-card implementation instantiates java.util.Random each time it is called (and without a seed value). (nth) returns the nth item of a sequence; (seq) is being used here because deck is a hashmap, which doesn't support ordered extraction.

Continuing on with the vulgar display of crude code... here is the shuffle method:

Let's ignore the lack of comments of any sort here. This implementation uses variable arity. That means when the function is passed one parameter the following code will run:

And when two parameters are passed the following code runs:

This is a feature of Clojure. I kind of like it. The way recursion was used here the variable arity made the code simple to read. I probably could have used (recur) for a very similar amount of code, but the dogs had to go out.

So the second chunk of (shuffle) picks a card at random from the unsorted pile, uses (conj) to include it in the sorted pile, uses (disj) to exclude the picked card from the unsorted pile, and then GOTO 10.

And now, with lots of gory code I'm not proud of, here is my first hand of 5 card draw:

Wow, three of a kind. It's almost as if I programmed in a "be nice to Seth" bit somewhere...