Archive for the ‘clojure’ Category

10 reasons to learn Clojure (or any other Lisp)

January 8, 2010

Horror and disgust. Or, more precisely, (horror (and (disgust))). That’s what I felt when I first saw Lisp code. What masochistic idiot could possibly enjoy using such a language? Reading Paul Graham’s essay Revenge of the Nerds was a turning point. Lisp turned out to be a bit like chocolate mousse. At first sight, it might look like dog shit. But once you put aside your prejudices, it turns out to be delicious! Learning Lisp is a bit like learning how to drive a Ferrari, when you only knew how to drive a wheelchair. It’s difficult, but once you get it, it will open up a whole new world for you.

Why should you start learning Lisp? Let me give you some concrete reasons. Some personal frustrations that you might recognise. Frustrations you wouldn’t have had with Lisp. Here are my 10 reasons to learn Clojure (or any other Lisp):

  1. Tired of boilerplate? Tired of having to write the same seven lines of code for each getter and setter? Tired of writing try-catch-finally-catch-finally clauses? Lisp lets you abstract all boilerplate code in simple macros. Once and for ever.
  2. Boilerplate code is no problem? Because “your IDE can generate it anyway”? How often did you change a single line of generated code, because it just didn’t do what you needed? And how often did you have problems, because after that you had to generate the same code again? How often did you have half generated half adjusted code that was unreadable and unmaintainable? Wouldn’t you rather declare a getter and setter in two words, instead of having to generate all this blurring code again and again?
  3. Had to wait for years and years until Sun finally built in an Enhanced For-Each Loop in Java? In Lisp, you’d have created your own for each-loop already years ago. In just a few lines of code. And you’d have used it over and over again.
  4. Libraries are reusable program code. Design patterns are reusable architecture. Libraries can be written once and reused every time. Design patterns have to rewritten again and again. Not in Lisp. In Lisp you’d declare the pattern in a macro and you’d only have to write the actual code.
  5. Thrilled about Domain Specific Languages? In Lisp, embedding languages is the most natural thing to do. And Lisp has been around for over 50 years already. Keep that in mind, the next time a person tells you that the new and overly hyped language X is so great because it supports DSLs so well.
  6. It’s functional! Somehow the idea of reusability got attached to object-oriented programming in the 1980s, and no amount of evidence to the contrary seems to be able to shake it free. But where objects are like big lego blocks, that only fit together in a very specific way, functions can be passed to other functions, combined and reapplied in many ways. And of course, not everything has to be a function.
  7. Were you happy that in your language “everything is an object”? Then look at horrible Java interfaces like ActionListener and think again. An ActionListener is just a function. Wouldn’t you like to treat it as such?
  8. Were you happily surprised when you heard about Aspect Oriented Programming? Were you happy with all the new possibilities it gave you? In Lisp you wouldn’t have needed it. Did you want to add logging to every function? Why not write your own operator for defining a function, that adds logging instantly?
  9. Write less, do more. In chapter 11 of Practical Common Lisp, Peter Seibel writes a unit test framework in only 26 lines of (very readable) code. Less code means less opportunities for bugs and less maintenance. Less code means less work.
  10. Not convinced yet? Then note that Even Jennifer Aniston has quit using other programming languages and now prefers Clojure (see Mark Volkmann’s Clojure Page).

Are there no drawbacks? Sure, learning it will be hard. Writing your first Lisp macros will definitely give you lots of frustrations. But you’ll be rewarded with more power than you’ve ever had in any other language. Think big. Think Lisp. Start today.


Writing a Spring MVC macro in Clojure (part 2)

January 2, 2010

In a previous post, we wrote a Clojure program that implemented two very simple Spring MVC Controllers. The program contained 15 lines of (mainly boilerplate) code. We’ll reduce that to the following:

(ns com.vxcompany.clojuremvc.example
  (:use com.vxcompany.clojuremvc.mvcmacro))

(defmapping com.vxcompany.clojuremvc.MyMapping

    [:index {:info "Life's so much cooler with macros!"}])

    [:another {:info "It's really cooler!"}]))

In part 1 of this manual, we already made a first step. Now, let’s glue the pieces together.

I’m sorry, I lied

My first version of the MVC macro does NOT work. When trying, it went fine when I used the macro within the same jar. It also went fine, when I first expanded the macro manually (macroexpand ‘(defmapping …)). But when I compiled one project with an unexpanded (defmapping), and tried to use that mapping from another project: BAM! The JVM complained that it could not find a method postinit31.

The very short summary is, that in the very special case of (genclass), the macro is expanded at different times. (gensym) might evaluate to different values. And if it does, the JVM looks for postinit33, where it may have been generated as postinit29. So, we should not use (gensym) for generating method names! See also the more detailed explanation here.

To ensure unique method names, we’ll do something else. The post-init method for a mapping will be -MyMapping-postinit. The following code strips the fully qualified class name:

(defn strip
  "Takes the substring of a string, starting at the index returned by
   the application of (function string)."
  [string function]
  (.substring string (function string)))

;;; with the above function, this does it:
(strip (str name) #(inc (.lastIndexOf % ".")))

Making things more Clojurish

We can now take the macro we created in part 1 of the manual, and paste some code into the post-init method, so the class actually contains the mapping. For each mapping above (index.html and another.html), we’ll generate the necessary boilerplate code, and let Clojure paste the url, view name and model in it. We’ll do that in a moment.

First, let’s make things just a little bit nicer. In the original Clojure MVC controller, we used plain strings as keys for the model (“info”). Spring MVC indeed needs strings for the keys. However, in Clojure, we can also use keywords (:info). Can’t we use keywords in our own code, and let the macro convert the keyword into a string?

This function converts any value to a string. If the value is a keyword, the name of the keyword is returned. Otherwise, a default string conversion is done. We used (cond) instead of (if), so we can easily add more cases later. The last case, true, is an easy way to specify a default case.

(defn tostr
  "Replaces the value by a string, e.g. :a becomes \"a\"."
    (instance? clojure.lang.Keyword val) (name val)
    true (str val)))

The next function takes a map (in our case, the model) and does the above conversion to each key in a map. Idiomatic for functional languages, we made the function recursive:

(defn keys-to-strings
  "Takes a map and converts its keys into strings, e.g. {:a 1} becomes {\"a\" 1}"
  (loop [restmap a-map acc {}]
    (if (empty? restmap)
      (let [[key val] (first restmap)]
        (recur (rest restmap) (conj acc [(tostr key) val]))))))

The macro

With the above adjustments, the macro now becomes:

(defmacro defmapping
  "Defines a Spring MVC URL mapping. See example at"
  [name & body]
  (let [this (gensym "this")
        shortname (strip (str name) #(inc (.lastIndexOf % ".")))]
       (defn ~(symbol (str "-" shortname "-postinit")) [~this]
         ~@(for [[url handler] body]
             `(.registerHandler ~this ~url
                 (proxy [AbstractController] []
                   (handleRequestInternal [request# response#]
                     (let [[view# model#] ~handler]
                       (ModelAndView. (tostr view#) (keys-to-strings model#))))))))
         :name ~name
         :post-init ~(str shortname "-postinit")

The for loop adds all the boilerplate code for each mapping in our definition. Note we have to splice ~@, because for returns a single list of statements. We need the separate statements instead of the list. Also note how we fill in the ~url, view# and model# in the template code.

With this macro, we can specify the mapping as we did at the top of this post.

Did we really need a macro?

There’s one question I didn’t answer. Did we really need a macro? Writing macros is more difficult than writing functions. The rule is: use functions if you can. Use macros only if you cannot do the same thing with functions only.

In this case, we clearly need a macro. There is code in the macro, we only want to evaluate AFTER the macro has been expanded. Take the (gen-class) specification. (gen-class) is evaluated at compile time! Functions are not evaluated at compile time! Putting (gen-class) within a function instead of a macro, would have caused very strange effects. Also, we’re passing parameters to the macro (e.g. a class name), that we don’t want to evaluate before calling the macro. Function parameters are always evaluated before the function is called.

So in this case it’s clear. But don’t forget to always ask yourself if you really need a macro, before writing one!


We showed how powerful macros are. The original 15 line UrlMapperHandler code, was reduced to a few lines only, that express the intention of the code much better. Of course, this took some effort. We had to write a macro. But we can reuse the macro each time we need it. And the actual code is much cleaner! In Java, doing the same thing would definitely have been more difficult!

Writing a Spring MVC macro in Clojure (part 1)

December 25, 2009

In a previous post I wrote how to write Spring MVC Controllers in Clojure. The result worked, but contained a lot of boilerplate code. Boilerplate code may be an essential part of a Java program, but in Clojure it certainly isn’t. In fact, because of Lisp’s powerful macro system, in Clojure we can eliminate boilerplate code completely! How? Let’s find out, by writing a macro for creating a Spring MVC controller class.

Macros: a very short introduction

In Lisp, there is no fundamental distinction between data structures and programs. Programs work on data structures. Programs create data structures, read data structures and manipulate data structure. But a Lisp program in itself is also a data structure. Consider the following program:

(* (+ 1 1) 2)

The program is a list (or a Lisp form) with three elements. The first element, *, is the operator. The other elements are parameters to the operator. The second element is another list, that can be decomposed the same way.

Since a program is a list, we can use normal list operators to manipulate it. The following expression replaces the 2 by a 3 in the above expression.

(replace {2 3} '(* (+ 1 1) 2))

Why is this so powerful? In Lisp, like any other programming language, you can write a function that operates on data structures. But since in Lisp programs are also data structures, you can manipulate Lisp code in exactly the same way as data. This makes it possible to extend the language, in ways you’d never thought were possible. In Java, you had to wait for years until they finally built in an extended for loop. In Lisp? You’d have extended the language yourself with just a few lines of code. How? You’d have written a macro.

A macro is like a function, but different. A function returns a value. A macro returns a piece of executable code, that is then evaluated.

The parameters to a function are first evaluated and then passed to the function. The parameters to a macro are first passed to the macro. The macro manipulates the parameters and transforms them into (another) piece of executable code. The return value of the macro is evaluated by Lisp.

Macro evaluation goes in two steps:

  1. Macro expansion: the macro is executed and returns a piece of Lisp program
  2. Evaluation: the piece of Lisp program returned by the macro is interpreted by the compiler and executed

Generating the class

Let’s start with generating an empty subclass of the Spring AbstractUrlHandlerMapping. The macro extension will exist of a (gen-class) command, that generates a class at compile time. The name of the class will be a parameter to the macro. We will write the macro in such a way that


defines an (empty) subclass of AbstractUrlHandlerMapping.

The basic steps for writing a macro are easy:

  1. Backquote ` the code template you want to generate.
  2. Escape ~ the macro parameters in the code template.
  3. Write code that performs the actual transformations on the code (this is the tough part!)

Let’s apply the first two steps.

(defmacro defmapping [name]
    :name ~name
    :extends org.springframework.web.servlet.handler.AbstractUrlHandlerMapping))


(defn -main []
  (println (

The backquoted (`) code is returned literally by the macro. Except the ~name. The ~ character tells Clojure that name, unless the rest of the code, should actually be evaluated when generating the macro expansion. To see the result of the macro expansion, type (macroexpand ‘(defmapping at the REPL.

Adding post-init

Now, let’s make the class actually do something when it’s constructed. We want the macro to return two Lisp forms:

  1. A definition of the -post-init function, and
  2. the above form, that defines the class and refers to the post-init function

However, a macro, like a function, can only return one form. Therefore, we have to wrap the two forms in a (do).

The naive approach would be just to add the post-init method:

(defmacro defmapping [name]
    (defn -post-init [this]
      (println "in init"))
      :name ~name
      :extends org.springframework.web.servlet.handler.AbstractUrlHandlerMapping
      :post-init post-init)))

However, when we compile this, it yields a “Can’t refer to qualified var that doesn’t exist”. What is happening?

Macros in Common Lisp are vulnerable for a mistake called variable capture. Suppose that you wrote a macro that expands to code that uses a variable foo. Suppose that someone else uses the macro within a piece of code, that also uses the variable foo. When the macro is expanded, the piece of code and the macro expansion may interoperate in unintended ways. This is a dangerous and common mistake in Common Lisp.

Clojure protects you from this error. Each symbol you use in a Clojure macro must refer to an existing, qualified name. Otherwise, you’ll get errors like “Can’t intern namespace-qualified symbol” or the error above.

Luckily, the solution is easy. To make sure that variable capture doesn’t occur, you have to let Clojure generate the symbol names for you. You can do this in two ways:

  • Extend the name in your macro code with #. Clojure will generate a unique name, that won’t collide with names in code that’s using the macro. In our example, we will use this# instead of this.
  • Use an explicit (gensym) command. (gensym) generates a new unique symbol for you, that you can assign to a variable and use in your macro. Because we need the post-init symbol in two different occurrences (-post-init and post-init), we will use this approach for

Our code now becomes:

(defmacro defmapping [name]
  (let [post-init (gensym)]
       (defn ~(symbol (str "-" post-init)) [this#]
         (println "in init"))
         :name ~name
         :extends org.springframework.web.servlet.handler.AbstractUrlHandlerMapping
         :post-init ~post-init

Note the following things:

  • The first command, (let [post-init (gensym)] is NOT within the back quote. Therefore, this code is actually evaluated at macro expansion time. The command defines a variable binding post-init, that exists at macro expansion time only.
  • (str “-” post-init) builds a string that prefixes the generated name for the post-init method with a minus. (symbol) translates the string back into a Clojure symbol that can be used within a (defn). Because it is the RESULT of this expression that must be inserted in the macro expansion, and not the expression itself, we escape it with a ~.
  • Just like ~name, we also prefix ~post-init. We do not want the literal value “post-init” as the name of our post-init method, but the value of the post-init variable.
  • All other code within the back quote is returned by the macro literally, and evaluated after returning from the macro.

What’s next?

We created a macro that generates a subclass of AbstractUrlHandlerMapping with a parameterisable name. I explained why macros are so powerful. And I showed you the basic concepts how you create a macro.

The macro itself doesn’t do much yet. In a next post, we’ll add functionality to the class. I’ll show you how you can easily eliminate all the boiler plate code, by just specifying it once and forever in a single macro.

Writing Spring MVC controllers in Clojure

December 4, 2009

Lately, I’m getting more and more absorbed by Clojure. The project I am working on, is a program that helps you solve Sudokus. Not that I like Sudokus, but it’s definitely fun reasoning about them. And reasoning about them in Clojure is even more fun. But that’s not the subject of todays post.

Today, I want to write about writing a web interface in Clojure. In the end, the Sudoku solver needs an interface. Let me first explain you my basic thoughts on web application development.

  1. Separating view and controller is a good thing. I don’t want controller logic in my view. I don’t want styling issues in my controller. Compojure seems like a good and straightforward library, but I do not get the impression that it makes separating view and controller very trivial.
  2. JSP is not evil. I’ve used JSP for many years. I know its ins and outs. As long as you do NOT use scriptless (does anyone still today?), it’s a plain language for defining a view. It has many tag libraries already available. Views in JSP and controllers in Clojure seems a perfect combination to me. Sorry, that makes me skip Conjure too, though it does look promising.
  3. Reinventing the wheel is a bad thing. You don’t write a web framework from scratch. There are many good web frameworks available. Spring MVC is a good web framework. It’s easy to use. It’s stable. I know how to use it.
  4. Clojure is Lisp plus Java. The whole point of using Clojure, is that it makes you access Java Code from Lisp. I want to use existing Java Code. Wasn’t that the whole purpose of Clojure? If not, why would you move from plain old Common Lisp to Clojure anyway?

So, we’ll use Spring MVC as a framework. The views are written in JSP, with Spring MVC tag libraries available. And we’ll write the controllers in Clojure. How do we combine them? Let’s find out.

Hooking into Spring MVC

We enable Spring MVC in a Java Web application, by including the Spring dispatcher servlet in our web.xml. Incoming http requests are then handled by the dispatcher servlet. The dispatcher servlet does basically the following:

  1. The dispatcher servlet sends the request to the proper controller. What request is sent to what controller, is defined in a UrlHandlerMapping.
  2. The dispatcher servlet retrieves a model and a view name from the controller. The servlet sends the model to the view specified by the view name.

The view is plain old JSP. For the second step, we can use a plain old InternalResourceViewResolver. Nothing clojurish there.

The exciting part comes in the first step. The code that returns the model and the view, is written in Clojure. So we must make sure, that the UrlHandlerMapping maps the request to a Clojure controller.

Spring MVC has a number of UrlHandlerMapping implementations readily available. My favourite one is the DefaultAnnotationHandlerMapping. It lets you annotate a method with a url pattern, and then it becomes a controller method. Like this:

public ModelMap sayHello(@RequestParam("name") String name) {
    return new ModelAndView("hello", "model", name);

It’s something similar I want to do in Clojure. I want to define a clojure function, and annotate the url pattern and request parameters. Clojure allows us to define plain old Java Classes. So, what if we just create the equivalent of the above in Clojure? Then we’re done.

Unfortunately, Clojure has no support for annotations (yet). This is not a bad thing for programming in Clojure itself. You do not really need annotations in Clojure, since Clojure gives you much more powerful language constructs. But for programming Clojure, you don’t need Java classes either. The whole purpose of using Clojure instead of Common Lisp, was the availability of Java! So it is actually bad that annotations are not supported.

Of course, we could create controller classes in Clojure, and map them in the Spring configuration file. But that’s not what I want. I want to use the full power of Clojure not only for writing the controllers, but also for configuring them. So we have to make up a trick.

What if we write our own UrlHandlerMapping? We’ll let our implementation retrieve the mapping information from Clojure code, and let it forward the request to Clojure code. Of course, our UrlHandlerMapping implementation itself is written in Clojure.

Let’s write a prototype, to see that the approach indeed works.

Building a prototype

The UrlHandlerMapping we’ll build here, is just a simple prototype. It will map two hard coded paths to two hard coded views. The code is not elegant. But it does prove that we can easily plug Clojure into Spring MVC. And the prototype can be used as a starting point for something more general.

Each clojure file is compiled into a single class file. The top of a clojure file defines a namespace. The name of the clojure namespace is the Java fully qualified class name. To implement our own UrlHandlerMapping, we must extend the Spring MVC AbstractUrlHandlerMapping. We’ll also need some imports later on. So here’s the start:

(ns com.vxcompany.clojuremvc.UrlHandlerMappingPrototype
   :extends org.springframework.web.servlet.handler.AbstractUrlHandlerMapping)
    [org.springframework.web.servlet ModelAndView]
    [org.springframework.web.servlet.handler AbstractUrlHandlerMapping]
    [org.springframework.web.servlet.mvc AbstractController]))

I know. Clojure code can be very short and elegant, but explicitly defining Java classes in Clojure is definitely not. Luckily, this is the only Java class that has to be explicitly available from outside our Clojure library.

To register controllers with the AbstractUrlHandlerMapping, we have to call the registerHandler()-method. The method takes two arguments: a url pattern and a controller. The url handler is a String. The controller is a subclass of the AbstractController class. Creating the controller is easy. Just use the (proxy) function in Clojure. The controller implements the handleRequestInternal()-method, that implements the controller method.

(.registerHandler this "/index.html"
  (proxy [AbstractController] []
    (handleRequestInternal [request response]
      (ModelAndView. "index" "info" "Clojure has done it!")))

AbstractController is the class we want to proxy. [] is a list of empty constructor arguments. handleRequestInternal (that takes a request and a response) is the method we are implementing. And (ModelAndView.) calls the constructor of the ModelAndView class, with three arguments.

The above code maps requests to “/index.html” to the specified controller, that forwards to the index-view, with the text “Clojure has done it!” in a model variable named “info”.

The above code must be executed on construction of the UrlHandlerMappingPrototype. Clojure has two constructs for initialising a class. With :init, you can specify the parameters for the constructor of the superclass. Optionally, :init lets you specify a Clojure variable that contains state information for the object. Within :init, you cannot yet access the this object, since it has not been constructed yet. For that, we need the :post-init. Between :extends … and the right bracket, write:

:post-init post-init

This defines that post initialisation of the class is defined in the -post-init function (the minus symbol is the default symbol for functions implementing a class method). Type (doc gen-class) at the REPL if you want to know more about class definition options. Remember, the REPL and the (doc) function are sometimes bigger friends than Google.

The full class is now:

(ns com.vxcompany.clojuremvc.UrlHandlerMappingPrototype
    :extends ...     
    :post-init post-init)
  (:import ...))

(defn -post-init [this]
    (.registerHandler this "/index.html"
      (proxy [AbstractController] []
        (handleRequestInternal [request response]
          (ModelAndView. "index" "info" "Clojure has done it!"))))
    (.registerHandler this "/another.html"
      (proxy [AbstractController] []
        (handleRequestInternal [request response]
          (ModelAndView. "another" "info" "Clojure has done it again!"))))))

Remember that instance methods (like -post-init) take this as their first argument.

Glueing the pieces together

We wrote the implementation for the UrlHandlerMapping. We still have to create a Spring MVC project, with the UrlHandlerMapping in it. In Netbeans, using the Enclojure plugin, I did:

  1. Create a new Clojure project. Include the Spring Framework, Spring Web MVC and Servlet-API libraries. Define the single class UrlHandlerMappingPrototype.
  2. Create a separate Spring MVC project. Include the Clojure library, and the library (compiled jar) for the Clojure project. Create two views index.jsp and another.jsp, that show the contents of the variable ${info}. In your web.xml include the dispatcher servlet. In the dispatcher-servlet.xml set up an InternalViewResolver.
  3. Tell the Dispatcher Servlet to use the UrlHandlerMappingPrototype. Remove other UrlHandlerMappings. Include the following in your dispatcher-servlet.xml:
<bean class="com.vxcompany.clojuremvc.UrlHandlerMappingPrototype"/>

That’s right. A single line in your dispatcher-servlet.xml does everything. Now run the application and surf to ../index.html and ../another.html, and see that it works.

Is that it?

This is just the beginning. The Clojure code we wrote is very verbose. It does not look as nice as the annotated Java method we had earlier at all! The next step is to put the boilerplate code in a reusable element, so we can just specify the url pattern and the handler method. In Java, we used existing classes and annotations as reusable elements. In Clojure, we have something much better. I’ll use the above code as an example why Clojure’s macros are so powerful. But that’s something for another post. In the meantime, enjoy writing your controller methods in Clojure!