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!