In high school I created ACID1, an interpreter for the BASIC programming language. ACID1 was never completed but I felt I could take the world down with my very own programming language. That did not happen. ACID2 was born some years later in a college dorm. It did not work either.

These failures taught me an important lesson. ACID1 was created with no prior knowledge of language building whatsoever. ACID2 was, however, created with a surplus of theories (the Dragon Book, anyone?). I needed a middle ground.

I found Language Programming Patterns by Terence Parr about a month ago. LIP, if you may, since we are quite pleased with K&R, CLRS, TAOCP, etc... When I picked up LIP, my internal alarm went off, I felt it was going to be a good read.

Guido van Rossum, creator of Python (Python forever!), commented: Throw away your compiler theory book! So I knew. I also found out that professor Parr has been teaching language applications programming for years. Then I knew. The book itself came from the famous Pragmatic Bookshelf. And I knew: LIP would be a good read.

The book did not disappoint me, and will not disappoint any programmer with interests in language applications. LIP is the perfect mix of theory and practice. LIP is the working ACID I did not write.

Parr uses Java for his examples. I confess that I barely know Java. But half the patterns I have translated to Python while reading. This wouldn't have been possible without the great explanations in the book.

Each pattern has a Purpose, a Discussion, an Implementation, and Related Pattern section. Patterns are grouped together in chapters in such a way that when you've completed the chapter, you have a complete skill.

In chapter 2, Basic Patterns, for instance, I reminisced strange symbols like LA, LL(1), LL(k). Only this time they made actual sense and were put in real world examples. Professor Parr explained why you don't need LL(k) for, say, a simple list ([a,b,c]) parser. Programmers will often go miles to accomplish this.

Parr uses his popular tool ANTLR a lot in the text and this might annoy some. It is also my only regret. In his defense, good alternatives to ANTLR are scarce. Oh well. I, who have scant knowledge of Java, completed the book. So should any programmer.

There are 31 patterns in LIP. You dont have to know them all. Just where and how to find them. Chapter 10, Building Bytecode Interpreters, is easily my favorite. For long I wanted to learn how bytecode interpreters work. Chapter 10 discusses two patterns: Stack-Based Bytecode Interpreters and Register-Based Bytecode Interpreters. Popular Lua uses a Register-Based Bytecode Interpreter for example. Python (Python forever!) is Stack-Based.

Chapter 13, Putting It All Together, is the ice cream. In that chapter, Parr shows how to put your patterns together to fix real world problems: finding patterns in proteins structure, building a scripting language to generate 3D scenes, and fixing, sorry I meant tweaking, Java. Needless to say, Chapter 13 is the chapter you must not skip.

I believe chapters 1 through 6 are the core. The matter. The substance, like my chemistry professor used to say. Patterns from these first six chapters are all you need to build a simple language. We are talking no data aggregation and object orientation, right? With Chapter 13 (the one I just discussed), that's seven chapters not to skip.

Fellow dynamically typed languages lovers: Chapter 8, Enforcing Static Typing Rule, will fill our faces with smile and brighten our day, let's not skip it. It is essential knowledge.

Professor Parr has written a classic here. The book deserves a place on the golden shelf. I once asked Brian W. Kernighan what constitutes a good book. And the reply was insightful.

Kernighan wrote that he believes in books that are authoritative, are written by authors who love what they are writing about, instead of what is hot. He added that books should be pragmatic and useful rather than theoretical and philosophical.

Thank you professor Parr, for writing LIP.

I actually bought the book for some rather immediate and specific problems I had to solve, so I rushed through a lot of the material to find what I specifically needed. It is well enough organized that it is possible to use the book for very specific tasks and to jump around quite a bit -- though I would certainly recommend that readers actually read the whole book in a more linear fashion as it was intended (if they have the luxury of time to do so). Scanning some of the material in between, It appears well worth the effort to really learn this material.

One weakness I noticed that was not helped by Kindle was that there are a fair number of acronyms. Most of the time, they are defined and then used, but it took me quite some effort to find exactly what "IR" (intermediate representation) meant; though the context provided tentative hints. Kindle's search engine proved little help with these acronyms on several occasions -- particularly I remember that one, but there were others. I found the exact definition in a later chapter by the hard slog.

For the serious student or researcher who has the time to study the book more methodically, I'd recommend the printed version as almost all of these e-readers are still rather poor substitutes for hard paper and the single strongest advantage they might offer (the electronic search engine) is often unhelpful. It is also hard to find your comments written on the margins because all you are granted is a small speck in the text that you'll never find when searching back over the material. Dropping this one star is mostly due to the frustrations I had with Kindle and maybe not entirely the fault of the author. On the other hand, being available in electronic form was something I appreciated.

I've been a Software Engineer for about 20 yrs. now. Although my work is mostly real-time, embedded systems, I've always had a fascination with compilers and I love writing parsers. The "Dragon Book" has always been a favorite of mine, but can be a bit too theoretical. I'm a meat-and-potatoes kind of guy. I prefer looking at actual code. This book is very well written and practical, less theory (which I already have a good foundation in), more implementation. It is concise and clear. Mr. Parr has a very light and easy to read style of writing. His knowledge of the subject is, of course, top-notch and his ability to convey that knowledge makes me very envious. I've always been impressed with his ANTLr tool, which is why when I went looking for more compiler books, his was one of the first names I thought of.

This is a great book for those who want to learn how to write and exploit parsing technology to create DSL (domain specific languages) and transform programs using parsing technology when regular expressions won't do the job or are too complex to be coded easily.

The book discusses many aspects of compiler technology and interpreter technology. It will help you write a compiler or interpreter using ANTLR3. It goes in depth into the many things you need to know such as - LL(1), LL(k), and LL(*) parsers and symbol tools.

The book instructs one in how to use ANTLR - which is the lexer/parser generator which the author of the book makes freely available. ANTLR is the most powerful generator on the market today and used by many companies such as Oracle.

To get the most from this informative book, you should also buy "The Definitive ANLTR 4 Reference" which Amazon also sells.

Parr is a genius. He has produced the definitive parser generator and the definitive books that enable one to use this generator. Even if one will not use ANTLR, the books are valuable for their overview and in depth discussion of writing compilers and parsers.

Note that the book does not discuss some things necessary for writing a world class compiler such as register allocation. I'm using it to write translators from one language to another and in that application its advice is spot on and extremely helpful.

Very intuitive book!!!

Did not realize that this book is an other version for ANTLR3. But it has something that the new version does not have which I believe helps understanding of a simple compiler.

This book gives some good theoretical foundation for programming language implementation patterns, but many of the examples are tightly coupled to both ANTLR 3 and Java. You need to insert raw java actions directly into the grammar in this version of ANTLR, so many of the examples simply won't work in ANTLR 4 and it's a bit of a waste of time to read the "implementation" sections or follow along with the examples.

Another issue is that there is no instructions on how to set up ANTLR with a modern IDE. I've spent dozens of hours of research and trial-and-error to get anything resembling a modern programmer workflow in Eclipse.

Excellent book. As someone who has been curious about the inner workings of building languages and as one who builds interpreters every so often, this book really helped me learn better fundamentals to tackle this problem.

Since studying this book, I have built custom interpreters mapping data stored in a custom human readable syntax into object instances at work. This has also allowed for working on an interpreter to map voice commands into executed actions on applications. While I certainly am no expert, this book really helped bring me out of the dark into being fairly proficient at building lexers and parsers and using them in real world applications.

Note that I studied Aerospace Engineer formally and study computer science and software engineering outside of that since I love it, so you don't need to be some Computer Science or Software Engineer by education to get a lot of value out of this book.

This book is a good introduction when you want to write your own Domain Specific Language (DSL). I have several books about compiler writing and this has turned out to be the most directly useful. If I were doing this as part of a degree course, I would probably choose the Dragon book. But for my purposes, Language Implementation Patterns is far more useful. If someone wanted to learn how to implement a compiler for an actual project and just wanted nuts and bolts without too much theory, I would choose this book. It is easy to read and it concentrates on actionable programming steps rather than compiler theory. That allows you to get programming early on with small projects to get experience. Then it uses a popular compiler generator tool, ANTLR, to build more comprehensive examples. This made sense to me.

In my experience of writing compilers, the tool you use for the lexer and parser parts is only as important as getting you past those steps in the development. The more difficult part of writing a compiler is usually what you do after your language is parsed and you now have to do something with the parsed tokens. This book describes that stage as well. The book is well written and easy to read, which helps a lot. The book is medium thickness so not too daunting but substantial enough. I would recommend this book for a programmer who needs to implement a compiler or interpreter and doesn't want to get too bogged down in academic theory.

Ich kann das Buch nur jedem empfehlen, der sich mit den Themen Lexer, Parser, Interpreter, ... auseinander setzen will oder muss. Die beschrieben Verfahren und Beispiele sind sehr hilfreich und verständlich. Die Umsetzung in praktischen Anwendungen ist sehr einfach möglich. Zwar sind die Beispiele in Java geschrieben, aber eine Umsetzung in andere Programmiersprachen ist sehr einfach möglich.

Ich würde das Buch immer wieder kaufen.

ANTLRというソフト関係者自身による実践書。内容は極めて具体的でインタープリターのソースコードの例まで載っている。コンピューター言語学的にも、context-sensitiveクラスのコンピュータ言語まで説明されているので現在の研究レベルでは十分である。DSL(Domain Specific Language)を開発しなければ

ならない人なら（量は多いが）この本を読むのが最速だろう。研究者でも出典引用が沢山あるので、プログラムを書きながら随時論文を取り寄せるのも

いいかもしれない。

The premise of the book is that there are useful "patterns" (software design patterns) in language applications and that the author will highlight them and make them relevant to practical language developers. It's not a compiler theory book by any stretch. In fact, the author concedes immediately that the focus is more on specialized languages such as file descriptions (i.e. XLST, SVG) then generalized programming languages. This seems reasonable.

The book can roughly be considered in two halves (not equal in page count) - the first half is about parsing the language to some type of intermediate representation (IR) and the second half is doing something with that IR.

First, the negative(s): The first half of the book has some serious issues with being relevant to the proposed target audience because the focus is basically on using automated grammer tools (ANTLR) for parsing and going to a generic tree format for the IR. Most people writing simple file parsers for things like JSON, XML etc. are unlikely to ever use a tool like ANTLR (even tho it is a wonderful tool) for a whole slew of reasons including:

* The need to learn the ANTLR grammar. Most developers haven't spent much time thinking about formal grammars since University (i.e. BnF) which means you pray the language applications nut on your team who integrated ANTLR into your commercial code base doesn't quit tomorrow.

* The performance and memory overheads of doing multi-stage parsing / IR generation. Parsing something like a GB's worth of XML can take minutes even on a modern computer / smart phone etc.

* The complexity of aiming for a low-level abstract IR. Abstract IRs might be helpful for porting a language to multiple backends, but realistically very few application developers have this requirement. Thus a specialized and high level IR can be far more practical to work with.

* Most file format languages etc. have to deal with malformed input. For example, real-world HTML parsing is as much \about correcting missing tags, conflicting version features usage etc. than getting from a perfect input to an abstract IR. It's pretty hard to address this with any formal grammar parser generator. Yes you could try to preprocess your input before going with your generated parser, but trust me, you'll just end up writing a partial parser implementation and adding extra complexity as a result.

So that makes the first half of the book more relevant to maybe students or hobbyists interested in experimenting with language applications, but less relevant to the average application developer. What isn't ANTLR in the first half is just second year CS material for the most part.

The second half of the book is more practical and better suited to the proposed audience (starting with approx. Ch6 "Tracking and Identifying Program Symbols") because it loses the the focus on a single approach and mostly surveys a wide variety of things you can do with your IR after parsing as well as addressing common challenges like enforcing static types. The interpreter introductions are a nice starting point for someone who has to implement a simple scripting language.

We have pretty slim pickings for books on language applications that aren't meant to be CS course textbooks. As such, this book gets a modest recommendation if you are attempting to implement a simple scripting language because there's enough useful material in the second half that most developers will get something helpful out of it.

Tout est dans le titre. Pour le reste, je savais ce que j'achetais et c'est un livre indispensable dans le domaine. Livre en anglais bien sûr.