An Ale Introduction

They say you’re not a great JavaScript programmer until you’ve written your own framework – hence all of the half-assed attempts. Similarly you can’t really say you understand programming language design until you’ve implemented your own Lisp. So here we are.

But why Lisp? The answer is straight-forward. Because even though over sixty years have come and gone since Lisp was first introduced, no language beats it for simplicity and power. None! And I dare you to prove me wrong. John McCarthy, may he rest in peace, designed a language that is as close to perfection as a human can hope to achieve.

What is Ale?

Ale is a Lisp-1. In this way it is more like Scheme than like Common Lisp. Unlike many Lisps, Ale does not support both interpreted and compiled operation. Instead, when the programmer performs an (eval), Ale immediately compiles the form and invokes its abstract machine. And unlike nearly all Lisps, bindings in Ale are immutable, even in namespaces.

Ale borrows from Scheme and Clojure where syntax is concerned, but it diverges in many ways. It is designed to be hosted in a Go process. It is also designed to allow multiple hosted instances within that process, each one being completely isolated from the other.

What’s Next?

There’s still quite a bit of stuff missing from Ale. The runtime is only partially complete, the compiler performs very little optimization, the VM could be faster, the code generation could be far more efficient, and the type system (if you can call it that) gets involved way too late in the game.

In spite of all that, there is a very solid foundation here for building something that people might actually want to use, myself included, and I invite you to join in on the fun.

Thanks for reading,

Thomas Bradford
Berlin, Germany
April 6, 2019