In chapter 3, section 5 of Let Over Lambda Doug Hoyte introduces us to defmacro/g!, a version of defmacro that allows us to use g-bang notation to indicate variable bindings that should be gensym’d.

The example macro is nif from On Lisp, which is converted to use defmacro/g!:

If we macroexpand a call to nif, we’ll see that the variable g!result has indeed been gensym’d:

I thought about this for a moment and then I remembered that Clojure’s defmacro provides a similar, somewhat terser syntax out the box. I opened my PDF of Clojure Programmming by Emerick et al and skipped to chapter 5, section Hygiene, sub-section Gensyms to the rescue to look up the details.

This is how we could write a capture-safe nif in Clojure:

Which is a little nicer IMHO.

For the memory of a lifetime, Recall, Recall, Recall.

Attention fellow .NET developers, I’ve just published Recall to GitHub. Check it out & let me know what you think.

Introduction

ClojureCLR is one of my favourite open source projects. It’s a port of Clojure to the CLR, the execution engine of the .NET platform. It’s a comprehensive port that includes almost all the features of the Java version. You can reuse any .NET assemblies from ClojureCLR, and because ClojureCLR produces regular .NET assemblies from your Clojure code, you can integrate with your existing programs written in other .NET languages. But even if you’re forced to keep writing code in another language, you can still leverage Clojure features, like its excellent concurrency support. (Something I’ll be writing about in a future post) That’s because Clojure isn’t just a language, it’s also a library.

Clojure proper is contained in a single jar file, which makes it dead easy for Java developers to include in their programs. ClojureCLR, unfortunately, spans 36 (!) assemblies, and if you’ve read Rob Rowe’s post Calling Clojure from C# you’ll have seen that you need to reference at least 10 assemblies from your C# program in order to call Clojure code. What’s worse, depending on the subset of features you use, it can be difficult to determine exactly which assemblies need to be referenced. Wouldn’t it be great if we could reduce the number of assemblies you need to reference to just one? Well, that’s exactly what I set out to do last week, and in this post I’ll be describing how I did it.

Assemblies as Embedded Resources

Say you try to load an assembly called MyAssembly by calling Assembly.Load("MyAssembly"); the CLR binder will look for MyAssembly in a few different places, in order:

1. The GAC
2. The application base directory
3. The list of directories in the current AppDomain’s private bin path

If the binder fails to find MyAssembly in any of these places, it will raise an AssemblyResolve event. You can subscribe to this event to provide the assembly from another source, like an embedded resource. In my forked ClojureCLR repository I’ve added the following code to Lib/RT.cs:

Clojure.dll contains all the other ClojureCLR assemblies as embedded resources.

This however, isn’t enough. Since the ClojureCLR runtime loads assemblies dynamically, a change needs to be made to determine whether a given assembly can be loaded from an embedded resource, and then do so instead of looking for it on the load path. There are actually two overloads of RT.load; the first takes a relative assembly path as an argument and calls the second overload, which additionally takes a boolean specifying whether to raise an error if the assembly can’t be loaded. I modified the former to determine if the assembly is present as an embedded resource, and added an additional boolean argument to the latter, which if true, causes it to load the embedded assembly. Here’s the code, with some omissions for readability:

I also had to add an overload for Compiler.LoadAssembly that takes a byte array in place of a FileInfo object, and move the logic to a new method Compiler.InitAssembly that’s called by both overloads. And that’s pretty much the long and short of it. Now we just have one assembly to reference: Clojure.dll. (Strictly speaking this isn’t true, since you still have to reference the two DLR assemblies Microsoft.Scripting.dll and Microsoft.Dynamic.dll, but as far as ClojureCLR assemblies go, there is now only one)

OMG, in 2011 the Windows API still only allows 256 character path names! Here’s an excerpt from this MSDN article:

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters.

Just came across the following paragraph in Functional Programming in C#:

The situation regarding tail call optimization on the .NET platform and in the C# language is a bit confusing. The CLR (Common Language Runtime) supports tail call optimization through a special tail instruction in IL. The C# compiler doesn ’ t generate that instruction, although the F# compiler does, for example. The execution infrastructure of the .NET environment offers a second point where this kind of optimization can be performed, which is the JIT compiler that translates IL into native assembly code. When JIT compiler optimizations are switched on, by default only in Release build mode in Visual Studio, the 64 – bit JIT compiler can perform its own tail call optimizations, but unfortunately the 32 – bit JIT compiler can ’ t. In some ways, having the JIT compiler make this step is a good thing because it covers all .NET languages equally. But the fact that the 32 – bit and 64 – bit versions behave differently makes it quite unfortunate that C#, unlike F#, doesn ’ t have language level support for tail call optimization.

Wow. WTF.

Setting up Emacs for Clojure hacking used to be a scary process, but not anymore, thanks to clojure-mode and the swank-clojure leiningen plugin. Here I explain the easy-peasy way to install & configure both. Not for the sadomasochistic.

First, add the following to your .emacs, if you don’t already have it. This requires package.el to be installed. It comes pre-installed with Emacs 24 onwards, but if you don’t have it, you can always get it here. Just drop it into your Emacs site-lisp directory.

(require 'package)
(add-to-list 'package-archives '("marmalade" . "http://marmalade-repo.org/packages/"))

Now install clojure-mode by eval'ing the following in the scratch buffer. (C-x C-e after each line)

(package-refresh-contents)
(package-install 'clojure-mode)

Yes! Emacs is now setup to hack Clojure. Next we need to install the swank-clojure plugin for leiningen. First, follow the instructions on the leiningen project page to install leiningen for your system, if you don’t already have it. Then, do as the swank-clojure project page says and you’re golden! Really, that’s all there is to it.

Happy hacking!

I use Emacs to hack Common Lisp & Clojure code. Here’s my .emacs which I’ve bastardized from EmacsWiki and the Interwebs.

Ever since learning Clojure I’ve longed for a nicer way to declare vectors and hash-tables in Common Lisp. Today I stumbled upon this cool essay by Frank Duncan Jr explaining how he implemented a Ruby-like syntax for hash-tables in Common Lisp. I’ve modified his code to implement a literal syntax for vectors & hash-tables reminiscent of Clojure.

P.S If you know how to eliminate some of the duplication in the above code, and/or make it more efficient, please let me know!

I find it somewhat irritating that there’s no javadoc equivalent for Clojure forms, so I wrote a little macro, cljdoc. I hope you find it useful. Improvements welcome!

I just published jetty-wrapper to github.

jetty-wrapper is a thin wrapper around the Jetty webserver. As such, it includes functions to start/stop Jetty instances. All of the code was lifted verbatim from the 0.3 branch of Compojure.