Clojure: &env and &form

Inside the body of defmacro you can call &env and &form to get a bit of interesting information that may or may not be helpful.

Here's a few examples that demonstrate how &env and &form can be used.
(note: I'm using Clojure 1.2)

&env
By default &env is nil.

user=> (defmacro show-env [] (println &env))
#'user/show-env
user=> (show-env)
nil

However, if any bindings exist, &env gives you the names of the bindings as the keys of a map.

user=> (let [band "zeppelin" city "london"] (show-env))
{city #<LocalBinding clojure.lang.Compiler$LocalBinding@78ff9053>, band #<LocalBinding clojure.lang.Compiler$LocalBinding@525c7734>}

Okay, now we're getting somewhere. What's a Compiler$LocalBinding? I'm not exactly sure, and I've never bothered to look into it. I've been told that the 'values' from &env may change in the future, so I wouldn't rely on them anyway. Since I can't rely on them, I haven't found the need to look into what they are.

Back to the keys. They sure look like symbols.

user=> (defmacro show-env [] (println (keys &env)) (println (map class (keys &env))))
#'user/show-env
user=> (let [band "zeppelin" city "london"] (show-env))                              
(city band)
(clojure.lang.Symbol clojure.lang.Symbol)

As the example shows, they are definitely symbols. However, these symbols don't have a namespace.

user=> (defmacro show-env [] (println (keys &env)) (println (map namespace (keys &env))))
#'user/show-env
user=> (let [band "zeppelin" city "london"] (show-env))                                  
(city band)
(nil nil)

Since the symbols don't have a namespace there didn't seem to be much fun I could do with them; however, you can use the symbols in your macro to print the values, as the following example shows.

user=> (defmacro show-env [] (println (keys &env)) `(println ~@(keys &env)))                      
#'user/show-env
user=> (let [band "zeppelin" city "london"] (show-env))                     
(city band)
london zeppelin

Printing the values of bindings can be a helpful trick while you are debugging.
&form
&form can be used to get the original macro invocation.

user=> (defmacro show-form [] (println &form))                               
#'user/show-form
user=> (show-form)
(show-form)

Okay, not very interesting so far. It gets a bit more interesting when your macro takes a few arguments.

user=> (defmacro show-form [a b] (println &form))       
#'user/show-form
user=> (show-form 50 100)                        
(show-form 50 100)
user=> (show-form a 100) 
(show-form a 100)

So, you can get the arguments. Notice you can grab both 50 and 100.

user=> (defmacro show-form [a b] (println (next &form)))
#'user/show-form
user=> (show-form 50 100)                               
(50 100)
user=> (defmacro show-form [a b] (println (map class (next &form))))
#'user/show-form
user=> (show-form 50 100)                                           
(java.lang.Integer java.lang.Integer)

Interesting. So I have a few integers I can work with, if I wish. What about 'show-form'?

user=> (defmacro show-form [a b] (println (map class &form)))       
#'user/show-form
user=> (show-form 50 100)                                    
(clojure.lang.Symbol java.lang.Integer java.lang.Integer)

'show-form' is a symbol, as expected. Which brings us back to a previous example, shown again below.

user=> (defmacro show-form [a b] (println (map class &form)))
#'user/show-form
user=> (show-form a 100)                                     
(clojure.lang.Symbol clojure.lang.Symbol java.lang.Integer)

Okay, 'a' is also a symbol, unsurprising, but perhaps it's interesting since 'a' doesn't exist anywhere except in our invocation. You can probably do some interesting things here, like allow people to specify enum values and append the enum yourself.

user=> (ns user (:import [java.util.concurrent TimeUnit]))                                                     
java.util.concurrent.TimeUnit
user=> (defmacro time-units [& l] (->> (next &form) (map (partial str "TimeUnit/")) (map symbol) (cons 'list)))
#'user/time-units
user=> (time-units SECONDS MILLISECONDS)                                                                       
(#< SECONDS> #< MILLISECONDS>)

Would you want to use &form instead of just using the arguments (stored in l)? Probably not. This isn't an exercise in what you should do, but it does demonstrate what you could do.

So &form must be returning a list, right?

user=> (defmacro show-form [a b] (println (map class &form)) (println (class &form))) 
#'user/show-form
user=> (show-form 50 100)                                                            
(clojure.lang.Symbol java.lang.Integer java.lang.Integer)
clojure.lang.PersistentList

A list. Correct.

And, I'm in a macro, so I can do anything I want with this list. Maybe I just want to print the arguments. Easy enough.

user=> (defmacro show-form [a b] `(println ~@(next &form)))
#'user/show-form
user=> (show-form 50 100)                                  
50 100

Of course, there are a million things I could do. You get the idea.

One other interesting thing to note is that &form has metadata.

user=> (show-form 50 100)                                 
{:line 132}

Perhaps you don't care about line numbers, but they definitely can come in handy when you are writing a testing framework.

I use &form in expectations and I believe LazyTest uses &env. I guess you never know what you're going to need...

Compatible Opinions on Software

I'm switching teams this month. I'll be working out of the DRW New York City office in the near future. I've been with my current team for almost 2 years, and I've learned plenty of valuable lessons. I'm not sure if the most valuable take-away centers around Compatible Opinions on Software; however, it's definitely the take-away that seems to remain in the fore-front of my memories.

The guys I work with in the DRW CT office are truly talented. Each individual on my team is someone I would consider to be a great software developer. As a result, we don't tend to have discussions on issues that where one answer is clearly right and another is clearly wrong. Instead, we often find ourselves in situations where one or more individuals have differing opinions and a "correct" answer cannot be found. Despite everyone being an excellent developer, several members of the team have incompatible opinions on software.

Here's the net result: Quality software. We aren't talking about a problem that caused projects to fail. On the contrary, our customer is very happy and the team is largely happy with the product we deliver. Unfortunately, as a teammate puts it, I seem to be immune to complacency. Even though things are good, I wont be satisfied until they are great. And, I feel that incompatible opinions on software is our largest production thief.

In general, it seems that anything can cause incompatible opinions. However, to make clear what I'm talking about, here is a short sample list of incompatible opinions I've run into:

• powerful language vs. powerful IDE
• monolithic application vs many small components
• what level of duplication is acceptable, and why
• specialization vs generalization
• team size

For the majority of my career I've believed - if I work on a team of excellent developers everything will simply fall into place. I now believe that being technically excellent is only the first requirement. I also believe that you can have two technically excellent people who have vastly different opinions on the most effective way to deliver software.

Two developers who prefer a powerful language may or may not be more productive than two developers who prefer a powerful IDE. However, both of the previous pairs will be more productive than one developer who prefers a powerful language teamed up with one developer who prefers a powerful IDE.

I'm not talking about people who love IntelliJ but are perfectly willing to learn emacs. If you're open to working in emacs then you have a compatible opinion with an emacs zealot. I'm talking about people who have tried the opposing point of view and still have a strong opinion that it's not the best way to deliver software. Putting those people on the same team only ensures a never-ending battle about why things aren't as good as they could be.

Of course, having differing views can be a good thing. Diversity ensures all kinds of benefits. I'm not suggesting that you rid yourself of all diversity. However, for the sake of productivity, I suggest that you do your best to avoid working with someone who has both an opposing view and is as inflexible as you are on the subject. The more central the subject is to the project, the more likely it is that productivity will be lost.

Let's get back to a concrete example. For me personally, I strongly prefer Clojure to Java. That's not to say that Java doesn't have it's place, it does. But, if both languages are valid choices, I'll always opt for Clojure. Given that opinion, I'm more effective if I'm working with someone else that prefers Clojure to Java. The language decision is important to me, very central to the project, and likely to be an ongoing issue.

Building off of the previous example, I don't personally care if we use IntelliJ or Emacs. As long as the IDE or editor choice is a reasonable one, I'm happy to use whatever someone else on the team prefers. I welcome diversity on compatible opinions. In fact, it's likely that diversity on compatible opinions will lead to greater productivity as better solutions are found.

So what can you do? The obvious answers: I've started making a list of opinions that I'm less flexible about. If I'm interviewing for a teammate, I'll ask questions to ensure we have compatible opinions on software. If I'm interviewing for a new job, I'll ask the interviewers about their opinions on software. To a certain extent I've always asked these questions, but I think I'll have better results if I identify which of my opinions I'm less flexible about and focus a bit more on ensuring that there aren't any conflicts.

If you already have a team in place and aren't looking to leave it's a bit harder to resolve incompatible opinions on software. Depending on the size of your team, you may be able to split the team up into smaller groups of people who have compatible opinions on software. Obviously, this will depend on having enough people to allow for a split, and having software that can be logically divided. If you can pull this off, you also get the nice benefit of seeing the results from doing things differently, without having to change your approach until it makes sense for you.

At this point I've worked on three different teams that achieved a level of productivity greater than that of any other teams I've been a part of. Of course, there are several factors that contributed to the success of all three teams. However, all three teams had compatible opinions on software, and avoided an entire class of problems that erode productivity. You'd have a hard time convincing me that those two things weren't somehow related.

Clojure: Using Java Inner Classes

Recently, I wanted to add some specific behavior to my Clojure application when any uncaught exception occurred. This is easy enough by calling the setDefaultUncaughtExceptionHandler (sDUEH); however, it's worth noting that the sDUEH takes a Thread.UncaughtExceptionHandler argument. Clojure has no problem giving you access to inner classes, but the syntax is slightly different: Outer$Inner in Clojure is the same as Outer.Inner in Java.

It's easy to use the REPL and determine if you have things correct.

user=> Thread$UncaughtExceptionHandler
java.lang.Thread$UncaughtExceptionHandler

This works without issue, because java.lang is (generally) available in Clojure.

If you want access to an inner class that is not in java.lang you'll want to import it directly. For example, the following REPL session shows how you can access the ThreadPoolExecutor.DiscardPolicy class.

user=> ThreadPoolExecutor$DiscardPolicy
java.lang.Exception: Unable to resolve symbol: ThreadPoolExecutor$DiscardPolicy in this context (NO_SOURCE_FILE:0)
user=> (ns my-ns (:import [java.util.concurrent ThreadPoolExecutor$DiscardPolicy]))
java.util.concurrent.ThreadPoolExecutor$DiscardPolicy
my-ns=> ThreadPoolExecutor$DiscardPolicy
java.util.concurrent.ThreadPoolExecutor$DiscardPolicy

Returning the entire class in the REPL should suffice as proof that everything is working fine; however, the code below is a brief example of using Thread$UncaughtExceptionHandler in a larger context.

jfields:Documents jfields$ cat inner.clj
(def handler (proxy [Thread$UncaughtExceptionHandler] [] 
  (uncaughtException [thread exception]
    (println thread exception))))

(Thread/setDefaultUncaughtExceptionHandler handler)

(/ 12 0)


jfields:Documents jfields$ java -cp ../dev/clojure-current/clojure.jar clojure.main -i inner.clj
#<Thread Thread[main,5,main]> #<CompilerException java.lang.ArithmeticException: Divide by zero (inner.clj:0)>

As you can see from the command-line output, the exception is handled by the proxy of Thread$UncaughtExceptionHandler.

Clojure: fnil

The fnil function was added to Clojure in version 1.2. The fnil function is a great addition that allows you to write code that works for all cases where an argument isn't nil, and handle the case where it is nil.

From the documentation: The fnil function takes a function f, and returns a function that calls f, replacing a nil first argument to f with a supplied value.

A simple example is working with + and nil.

user=> (+ nil 1)
java.lang.NullPointerException (NO_SOURCE_FILE:0)
user=> (def new+ (fnil + 0))
#'user/new+
user=> (new+ nil 1)
1

As you can see, the + function throws an exception if an argument is nil; however, we were easily able to create our own new+ function that handles the first argument being nil.

In isolation, it might be hard to see how this is valuable. However, once combined with high order functions it's easy to see the benefit.

Several months ago I wrote about composing functions and used the update-in function as my final example of what I thought was the best implementation. What I didn't address in the blog entry was how to handle the first update.

As you can see from the following code, the first update will fail if a default value isn't populated.

user=> (def current-score {})                          
#'user/current-score
user=> (defn update-score [current {:keys [country player score]}]
         (update-in current [country player] + score))
#'user/update-score
user=> (update-score current-score {:player "Paul Casey" :country :England :score -1})
java.lang.NullPointerException (NO_SOURCE_FILE:0)

At the time of the writing Clojure 1.2 was not production ready, and I used a definition of update-score that was much more verbose, but did handle nil.

user=> (defn update-score [current {:keys [country player score]}]                    
         (update-in current [country player] #(+ (or %1 0) score)))         
#'user/update-score
user=> (update-score current-score {:player "Paul Casey" :country :England :score -1})
{:England {"Paul Casey" -1}}

While the above code works perfectly well, it's obviously not nearly as nice to read as the example that doesn't need to concern itself with nil.

However, Clojure 1.2 is now production ready and the fnil function is available. As a result, you can now write the following version of the update-score function that is obviously preferable to the version that uses the or function.

user=> (defn update-score [current {:keys [country player score]}]                    
         (update-in current [country player] (fnil + 0) score))                
#'user/update-score
user=> (update-score current-score {:player "Paul Casey" :country :England :score -1})
{:England {"Paul Casey" -1}}

I'll admit that fnil wasn't my favorite function when I first found it; however, it's become indispensable. Looking through my code I find (fnil + 0) and (fnil - 0) a few times, and I definitely prefer those to the versions that use the or function.

Clojure: partial and comp

Clojure provides a few different options for creating functions inline: fn (or the #() reader macro), partial, and comp. When I first got started with Clojure I found I could do everything with fn and #(); and that's a good place to start. However, as I produced more Clojure code I found there were also opportunities to use both partial and comp to create more concise code.

The following examples are contrived. They will show how partial and comp can be used; however, they aren't great examples of when they should be used. As always, context is important, and you'll need to decide when (or if) you want to use either function.

The partial function takes a function and fewer than the normal arguments to the function, and returns a function that takes a variable number of additional args. When called, the returned function calls the function with the specified args and any additional args.

The partial function can often be used as an alternative to fn or #(). The following example shows how you can use either #() or partial to multiply a list of integers by .01 (convert pennies to dollars).

user=> (map #(* 0.01 %1) [5000 100 50])  

(50.0 1.0 0.5)

user=> (map (partial * 0.01) [5000 100 50])

(50.0 1.0 0.5)

In a straightforward example, such as the one above, it's really up to you which you'd prefer. However, if you want to specify a predicate that takes a variable number of args then the case for partial starts to become a bit more noticeable.

user=> (map #(apply str "price & tip: " %&) [5000 100 50] (repeat "+") [2000 40 10])

("price & tip: 5000+2000" "price & tip: 100+40" "price & tip: 50+10")

user=> (map (partial str "price & tip: ") [5000 100 50] (repeat "+") [2000 40 10])  

("price & tip: 5000+2000" "price & tip: 100+40" "price & tip: 50+10")

I haven't come across an example yet that made me think: The partial function is definitely the right choice here! However, I have passed around a few functions that had several arguments and found I prefer (partial f arg1) to #(f arg1 %1 %2 %3) and #(apply f arg1 %&).

The comp function takes a variable number of functions and returns a function that is the composition of those functions. The returned function takes a variable number of args, applies the rightmost of functions to the args, the next function (right-to-left) to the result, etc.

In a previous blog entry I used comp to return the values from a map given a list of keys. Below you can find the same example that shows the definition and usage.

user=> (def select-values (comp vals select-keys))

#'user/select-values

user=> (select-values {:a 1 :b 2} [:a])           

(1)

As you can see from the example, comp creates a function that takes a map and a sequence of keys, calls select-keys with that sequence, then calls vals with the result of calling select-keys. As the documentation specifies, the functions are called from right to left.

In general I find myself executing some functions directly with some data. In that case I generally use the -> macro. For example, if I already have a map and I want a list of the keys I'm probably going to write code similar to what's found below.

user=> (-> {:a 1 :b 2} (select-keys [:a]) vals)

(1)

However, there are times when you need a function that is the composition of a few other functions. For example, taking a list of numbers, converting them to strings, and then converting them to keywords.

user=> (map (comp keyword str) [1 2])

(:1 :2)

The same thing can be done with #(), as the example below shows.

user=> (map #(keyword (str %1)) [1 2])

(:1 :2)

While the code above works perfectly well, I definitely prefer the version that uses the comp function.

Like so many other functions in Clojure, you can get by without partial and comp. However, I find my code more readable and maintainable when I use tools specifically designed to handle my current problem.