Book Review: Build Your Own .NET Language and Compiler by Nilges

Summary: Very good for what it does.

First, some clear demarcation about what this book isn't: if you want a book with a really strong theoretical background in compiler design, this isn't it. I have Programming Language Pragmatics by Scott, and I recommend it.

Second, if you want a book about compiling to IL for direct execution, this isn't that book either. Frankly, this book is poorly titled in that respect. I don't yet have Compiling for the .NET Common Language Runtime by Gough, but it supposedly focuses specifically on this topic.

So what is this book? It's a practical, highly readable book about how to build a scripting language interpreter in VB.Net. A compiler theory textbook can teach you the principles involved in scanning and parsing, but it's likely to leave you wondering how you actually put any of that to use in real code. This book fills in enough theory to have an idea of what you're doing (with a little to spare), and lets you dive right in and work with practical real-world algorithms and code for actually doing it.

If you are a working programmer and you want to add a scripting language to an application you've written, it's easy to conclude that it's way too complicated to do all that stuff. This book is a fantastic antidote for that. It goes through things like tokenization, formal grammars, and recursive descent parsing in plenty of detail, any anyone who understands the basic CS building blocks of data structures and algorithms should find the coverage easy to follow. The text sometimes meanders a little too much, but it's still far more readable than anything else on the topic that I've run across.

My main criticism of this book is that it's a lot better about how to read in a language than how to do something with the result once you've read it in. The included interpreter operates on top of its own limited stack-based virtual machine, and the parser emits opcodes for it. This isn't covered in nearly enough detail, and my sense is that it's because the author isn't really thrilled with his interpreter. My gut feel is that this is kind of a neither-fish-nor-foul solution. A powerful solution for emitting opcodes would generate legitimate IL for the CLR, which the author gives a brief overview of, but doesn't follow through enough to produce real-world code. By contrast, I think a simpler solution for purely interpreted code would produce directly evaluatable function, statement, and operator objects, and not worry about emitting a language or dropping variables on a stack. The author's solution would seem to lack either the performance advantage of the former solution, or the simplicity and conceptual clarity of the latter. The only advantage I can see is pedagogical: it teaches you how to generate opcodes from a parse tree without wading through the complexity of a real-world imtermediate form like IL, GNU RTL, or Java bytecode.

Still, as long as performance isn't paramount, this is a solution that will actually work as an interpreter for a scripting language in the real world. This book covers a lot of ground, without ever completely losing its practical approach. Even though there are some flaws, and some areas I would have loved to see covered in greater detail, this is a tremendously useful book for the right audience.

Tags: C#, scripting, .Net, CLR, compiler