Build Your Own .Net Language and Compiler

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 l

It is very entertaining and well written. Does a great job of explaining a difficult topic. The sample code works great.

Looking at all the reviews, I felt that I definitely had to add my own two-cents. When I read the first couple chapters of this book, I was a bit underwhelmed. I read through the compiler flyover and thought, "well, that is cool, building a calculator." I then went to the next step and actually took the code that he included and began to write my own C# port of the integer calculator. At this point, I really started to get the gist of what was great about this book: the code isn't there to support the book, instead the book is there to support the code. So many books that I read have contrived examples in the code to supplement the words. With this book, you should start with the code and use the book as a reference to understand what the code is doing. I'm actually working on a voice-enabled home automation project on my (ever-so-geeky) spare time, and this book had EXACTLY what I needed at EXACTLY the level that I needed it to further my project. Sure, it isn't a graduate-level book on compiler theory, but I don't think that is what it is meant for. On the other hand, this book doesn't pander to the reader by re-explaining what an if-statement is. The world needs more intermediate/advanced-level books on .Net techniques, and I've found that APress is the major source for this level of books. Additionally, I started writing about my experiences with this book on my blog, and Edward showed up and has been actively commenting on my ideas, lending his expertise to my learning. After looking around a bit, I've noticed that he is doing this regularly on people's blogs. That, in itself, is impressive to me, and I'm thankful that he has been willing to be part of the community.

As I read this book I had to wonder what planet the people that trashed it were from. I couldn't speak better of it and I think the author did a FANTASTIC job of making it entertaining and informative. It's very direct and to the point and I didn't get left hanging on one area. The code works the way he says it does and it's plenty to work with. Oh gee, it's not an 1200 page textbook covering every dark nuance of compiler theory. Somehow I figured that out before I openened it up. Hell I think the footnotes and quotes alone justify the price of the book. Everyone is entitled to their opinion but I think the people trashing it are either nuts or have some ax to grind in general. I have yet to come across an APress title on .NET that wasn't at a minimum a 3 and everyone I can think of off of the top of my head is a 4 or 5 (weighted heavily to 5). If you want a fun, interesting and just all around cool book to help you start in the world of writing your own .NET Compiler - this book is it.

The previous review is so off base I just had to comment.This book addresses one of the most complex topics in computer science: designing and building a language. Most college books on the subject are nearly incomprehensible. This one can be understood, with some work, by most developers.This was definitely NOT a rush job. Yes, some of the copyrights go back to 1998, but this reflects one of the things that makes this book unique. Most books contain code written just for the book: small and simple examples. This book contains a huge amount of code that has obviously been under development and evolving for a long time. The code has a level of documentation, error checking and self-consistency testing that is rare to see even in commercial code, much less sample code for a book. The author may have written the original compiler in a few days, but he himself mentions that he then went on to rewrite it completely as clearly obvious by looking at the sample code.As to the compiler not creating MSIL code, that's only partially true. The author does show how to create MSIL code. In fact, there is a great example where you can see how much faster MSIL compiled code executes. But the complete example runs on an interpreter which is exactly what you would expect from a Quick Basic. It was, after all, an interpreted language.The best part of the book is being able to enter code into the Quick Basic compiler, and watch it step by step as it is tokenized, parsed, and executed. It's like a "visible" compiler, and provides more insight into how a language works than a thousand pages of text could do.This is not a book about the codedom part of .NET and code generation, though there is some coverage of that. Code generation is just one part, maybe the easiest part, of compiler design. This is a book about language design and construction, and how to use those techniques both for traditional languages and even for unique applications such as defining rules for a credit scoring application (the example in the book).This book is not always an easy read (if only because the material is very complex), and the author does digress on occasion more than I liked. But the overall scope and uniqueness, along with some amazing sample code to play with, is enough for me to forgive its flaws and grant it five stars regardless.