- Amazon Student members save an additional 10% on Textbooks with promo code TEXTBOOK10. Enter code TEXTBOOK10 at checkout. Here's how (restrictions apply)
Language Implementation Patterns: Create Your Own Domain-Specific and General Programming Languages Paperback – Jan 10 2010
|New from||Used from|
Special Offers and Product Promotions
Frequently Bought Together
Customers Who Bought This Item Also Bought
No Kindle device required. Download one of the Free Kindle apps to start reading Kindle books on your smartphone, tablet, and computer.
To get the free app, enter your e-mail address or mobile phone number.
""Throw away your compiler theory book! Terence Parr shows how to write practical parsers, translators, interpreters, and other language applications using modern tools and design patterns. Whether you're designing your own DSL or mining existing code for bugs or gems, you'll find example code and suggested patterns in this clearly written book about all aspects of parsing technology.""--Guido van Rossum, Creator of the Python language""This text is excellent. The exposition plus the examples makes otherwise complex ideas very clear and accessible. Well done!""--Tom Nurkkala, Associate Professor, Computer Science and Engineering, Taylor University
About the Author
Terence Parr is a professor of computer science and graduate program director at the University of San Francisco, where he continues to work on his ANTLR parser generator (http://www.antlr.org) and template engine (http://www.stringtemplate.org). Terence has consulted for and held various technical positions at companies such as IBM, Lockheed Missiles and Space, NeXT, and Renault Automation. Terence holds a Ph.D. in computer engineering from Purdue University and was a postdoctoral fellow at the Army High-Performance Computing Research Center at the University of Minnesota, where he built parallelizing FORTRAN source-to-source translators. He is the author of "The Definitive ANTLR Reference":http://pragprog.com/titles/tpantlr.
Inside This Book(Learn More)
Top Customer Reviews
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.Read more ›
Most Helpful Customer Reviews on Amazon.com (beta)
As it turns out there's a big difference. If you want to be the ultimate guru of compilers (eg. contributing an even more efficient compiling technique for language X or creating a language that forces us all to reconsider what we know about compilers) you need both, the theory the practice (because without the theory you wouldn't know how to improve or make obsolete an existing technique, and without the practice you wouldn't be able to put that knowledge to work inside a language compiler). Now if you just want to be able to deal with your DSL (domain specific language), create data readers, code generators, source-to-source translators, source analyzers, etc. you'll love the hands on information presented in this book.
Let's be honest, how many of us developers are required or willing to create a language from scratch together with its compiler or interpreter versus the ones that just need to parse an XML file, process a DSL or create a configuration file reader? I would say that there are much more developers in the later group. But fortunately we all (or almost all) share one thing in common: we know software patterns! This is how the author structured the book, offering patterns (ala Gamma et al) that you can use when creating your language processors (an excellent approach in my opinion since each pattern focuses on different stages of language processing which helps the developer modularize the solution and understand how the different parts of the "machine" work without loosing sight of the big picture).
So, in case you're wondering "what is this guy talking about?". A compiler is a program that transforms code created in one language into another (eg. C source code into executable code). Normally the transformation goes from a higher level language to a lower level language (eg. to machine code)(if it's the other way round we have a "decompiler"). When the transformation happens between languanges on the same level we're dealing with a language translator or converter (normally called "source-to-source translator")(eg. Sharpen, an open source framework created by the db4o team that converts Java code to C#). A compiler is likely to perform several operations such as lexical analysis, preprocessing, parsing, semantic analysis, code generation, and code optimization (which are directly or indirectly covered in the patterns offered in the book). The ultimate tool for developers interested in building compilers is a compiler-compiler or parser generator which, as you might have already guessed, provides a high level description language to help you build your own compiler (this usually involves the creation of a lexer and a parser).
However, I feel I should mention that there's a whole lot of complexity in handling and maintaining all the intermediate information when you're creating your own compiler for your own language which is covered only indirectly in this book. There's also no detailed explanation of the final steps of a compiler implementation such as machine code generation and optimization, register allocation, etc. Overall this is an excellent book for day-to-day language applications (involving parsing, translations, etc).
Now I find pretty important to mention who the author is. Terence Parr created the ANTLR parser generator (antlr.org) and the StringTemplate engine (stringtemplate.org). He's a professor of computer science that's no theorist (this guys has real practical experience!). He has so much experience that he started to see these patterns when developing language processors coming again and again. The end result is this book that presents a compilation of those patterns.
The structure of the book is pretty straight forward. Four general parts:
* Getting Started with Parsing: where you'll learn about the general architecture of language applications and review the patterns that involve parsing.
* Analyzing Languages: where you'll see how to use the parsing techniques described in the previous section to build trees that hold language constructs in memory, how to walk those trees to track and identify various symbols (such as variables and functions) and how to determine the type of the expressions. Overall you'll learn how to check whether an input stream makes sense.
* Building Interpreters: four interpreter patterns are presented that vary in terms of implementation difficulty and run-time efficiency. In the two previous parts the focus was on patterns that verify the syntax of an input sentence and make sure that it follows a set of semantic rules. In this part the focus is on patterns for processing the input sequences (not just validating them).
* Translating and Generating Languages: here you'll learn how to translate one language to another and how to generate text using the StringTemplate engine.
The patterns are laid in the order you'd follow to implement a language (section 1.2, "A Tour of Patterns" describes how all the patterns fit together). There are 31 patterns in the book, each with four parts: purpose, discussion, implementation and related patterns. The implementation section provides illustrative code in Java (but it's not meant to serve as a library). You don't need a background in language theory or compilers to understand the book but you have to have a solid programming background and be confortable with the concept of recursion in algorithms.
Overall, if you're a developer that has to deal with any of the use cases described in this review this book *must* be in your bookshelf (but if you're really into compilers you should also have Aho's Dragon book next to it =)
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.
Plenty of people much more educated and experienced in the art and science of language design than I am will surely write insightful reviews about the merits of this book from the perspective of specialists. I'm writing this review for the rest of us.
Terence Parr continues his campaign to make superb language-development tools accessible. Have you ever wondered how your compiler really works? Maybe you've dreamed about creating your own scripting language -- the one that works the way *you* want -- but you're not Larry Wall. Well, take heart. Professor Parr's second ANTLR book is here. Maybe you never took a course in compiler design (I haven't.) or maybe you have and are still wondering how to do anything practical with it. This book is for you. You very well might not become the next Guido van Rossum, but you will come away with a deeper appreciation of language implementation -- probably enough to create your personal dream language.
I call this the "second ANTLR book," but that's a gross oversimplification. If you already know that ANTLR stands for ANother Tool for Language Recognition, then the next thing you need to know is that this book is about much more than ANTLR. You also may know that ANTLR is written in Java. But you don't need to know Java to get value from this book. (In fact ANTLR itself can target C, C# and several other languages besides Java.) Although the book uses ANTLR to describe example languages, and Java to implement them, the author very cleanly separates concepts from tools and implementation details, in a way which is consistently pragmatic and never drifts off into the clouds. There is no pedagogic hand-waving here. This is the real stuff. And when you grasp it, you too will be able to create everything from "simple" data format translators to script interpreters and maybe even some non-optimizing compilers. Really.
This book fills that gap quite nicely. It is free of excess jargon and gets right to the point of creating new languages. Each chapter builds up the reader's repertoire of techniques and tools for writing programs that create programs. For a relatively short book, the author does a fine job of covering scanning, parsing, type checking, interpreters, virtual machines and code generation.
If you've ever wanted to build your own language but fell short when it came to the theory behind it, this book is the one to check out.
Great book for ANTLR, not so great for other implementation environments.
Look for similar items by category
- Books > Computers & Technology > Microsoft > Development > .NET
- Books > Computers & Technology > Programming > Languages & Tools > Compiler Design
- Books > Computers & Technology > Programming > Languages & Tools > Compilers
- Books > Computers & Technology > Programming > Software Design, Testing & Engineering > Software Development
- Books > Textbooks > Computer Science & Information Systems > Computer Science
- Books > Textbooks > Computer Science & Information Systems > Programming Languages
- Books > Textbooks > Computer Science & Information Systems > Software Design & Engineering