Topi Kettunen

Sila Dev Log: Waffling on Next Steps but Getting Back on the Saddle

Some time ago, I was actively working on my own compiler project whenever I had spare time. Unfortunately, life got in the way, and the project sat on the back-burner for a while. A big reason was my new solo music project, which took up much of my energy.

Alongside recording, I’ve also been diving into Opusmodus for composition and analysis, a wonderful showcase of what Common Lisp can enable in creative domains.

Another factor behind the pause was that I had coded myself into a corner due to some early architectural decisions. I even tried refactoring, but although the codebase was still relatively small, it quickly became frustrating. The dynamic nature of Common Lisp, while incredibly powerful, made larger-scale refactoring feel trickier than I’d like. To be fair, that’s more a reflection of my skills than a flaw in Lisp itself. I still deeply value its flexibility, macro system, and directness.

Recently, I found myself needing to work quite a bit with C++ and LLVM in other contexts, which naturally made me wonder if my compiler project should make the jump as well. LLVM, in particular, seemed appealing: it already provides a robust backend infrastructure, excellent tooling, and cross-platform portability, which would spare me from reimplementing a lot of low-level machinery. The timing also aligned with my recent switch to an Apple Silicon machine. Since most of the existing code was tailored for x86-64, I was facing the task of implementing a new backend for aarch64 anyway. Using LLVM started to feel like not only a practical choice, but also an opportunity to learn its internals more deeply.

I briefly toyed with the idea of sidestepping the C++ API by generating LLVM IR directly from Lisp, which would have allowed me to keep most of my workflow in Lisp while still taking advantage of LLVM. However, I figured that diving into the C++ API would refresh my C++ knowledge and give me a more complete view of how LLVM is actually designed to be used. At the same time, I also considered jumping ship entirely and using a statically typed language like Haskell, which might have made large-scale refactoring and correctness guarantees easier in the long run.

Haskell, with its type system, has always impressed me, and projects like Coalton make that style of typing accessible within Common Lisp. Still, as much as I admire Haskell, it simply doesn’t spark the same joy as Lisp.

So despite the temptations of C++, LLVM, or even Haskell, I’ve decided to continue with good ol’ Common Lisp. It’s the language that excites me the most, and ultimately, joy in the process is what keeps projects like this alive.