Dragon Book Compiler

[Charise Zelnick]

CompilersPrinciples, Techniques, and Tools[1] is a computer science textbook by Alfred V. Aho, Monica S. Lam, Ravi Sethi, and Jeffrey D. Ullman about compiler construction for programming languages. First published in 1986, it is widely regarded as the classic definitive compiler technology text.[2]

It is known as the Dragon Book to generations of computer scientists[3][4] as its cover depicts a knight and a dragon in battle, a metaphor for conquering complexity. This name can also refer to Aho and Ullman's older Principles of Compiler Design.

The first edition (1986) is informally called the "red dragon book" to distinguish it from the second edition[5] and from Aho & Ullman's 1977 Principles of Compiler Design sometimes known as the "green dragon book".[5]Topics covered in the first edition include:

Following in the tradition of its two predecessors, the second edition (2006) features a dragon and a knight on its cover, and is informally known as the purple dragon. Monica S. Lam of Stanford University became a co-author with this edition.

In order to cover recent developments and issues, there is an updated second edition from Pearson Education India (4 July 2023), with contributions from Sorav Bansal. This revised and updated edition has new chapters on Programming Language Semantics and Undefined Behaviour Semantics.

This question pertains only to a specific site in the Stack Exchange Network. Questions on Meta Stack Exchange should pertain to our network or software that drives it as a whole, within the guidelines defined in the help center. You should ask this question on the meta site where your concern originated.

If you find yourself in this position, please recommend "Engineering a Compiler" by Keith Cooper/Linda Torczon, or "Modern Compiler Implementation in X" (where X should probably be Java, maybe C), by Andrew Appel. These are excellent introductions to compiler for beginners.

The Dragon Book is a very thorough book, with detailed discussion of theory (especially about parsing). However, this level of detail and theory does not make it a good introductory book. In contrast, the books above present very clearly how to build a compiler, avoiding theory where it is not useful. This makes them superior recommendations for beginners.

The full solution to the problem is don't recommend books you haven't read just because you saw someone else recommend them 20 years ago. Let someone who actually knows the field and has read the books recommend something instead. This is a classic example of people jumping to get rep by just pasting in a standard answer that they actually know nothing about.

Make your own suggestions and if you don't agree with others, vote them down and maybe people will start to see your way. There is nothing wrong with what they are doing in making their suggestions for the book.

While the Dragon Book is certainly very thorough, it is not very clear, or easy to learn from. That was probably acceptable in 1986, or whenever you read it way back when, but there are actual good compiler books now, especially for beginners.

I kinda get your point, it's like people recommending the Knuth books to someone wanting to get started with programming. Whilst iconic, the Knuth books are not the best place to kick things off for a beginner.

Then on each question where you disagree with the recommendation of "the dragon book" post a summary of your conclusions that are relevant to the particular question, (a link to the full review if it's too long to fit nicely in the answer), and your recommendation of your preferred book. Users tend to like answers that have taken the time to explain in detail the pros and cons of both sides. Others will see your review, and perhaps if it is good and people agree they will also link to it. Perhaps others interested in the area will take time to read both books and draw their own conclusions, and up vote your answer.

I saw this same kind of thing with an Operating Systems class in my undergrad degree. The book assigned by the professor was one of the more popular OS books. Very dry, to the point, and was not aimed at beginners. It was still a great book though and an excellent class choice. It was not an easy book for people to start with, but it was still a great resource.

That doesn't make it a bad recommendation in any way though. Lots of CS books tend to not be beginner friendly. They are advanced topics and require a vast array of knowledge to comprehend and understand well.

I'm working on a Playdate Lua wrapper for the (C-based) Chipmunk2D physics library. After spending most of my time fighting cmake and the build environment on Windows I switched over to Nova on Mac, and now building has become remarkably painless.

However, the C language server (C-Dragon/clangd) doesn't get visibility into the compiler flags that are produced by make using C_API/buildsupport/common.mk. I was able to set things right by manually transcribing the gcc flags from the build log to .clangd as follows:

This is a pain though and needs to be updated by hand alongside the makefile, and seems to only take explicit, literal paths. Best practices for clangd seem to be to use cmake and add the following to CMakeLists.txt:

That was the first part of the post -- I found I was not smart enough to understand CMake's documentation (and the Playdate C API docs) well enough to get reliable builds on the command line. Nova's shiny Playdate build integration worked first time, every time, but it's built around Make and not CMake.

Sure, if the Just Works parts of Nova+Playdate don't just work in depth (which is what it's starting to look like) I'm still within the refund window and I can pursue getting more expert with CMake and VS Code to have a more painless build process there, but other pieces of my current project are awkward and irritating enough I was hoping to avoid that.

CMake, by default, simply generates a make file. At that point, you can use the Nova build system. If you add files to your project, you need to update the CMake file and regenerate the make file by running cmake again. So for our example apps, it's as simple as changing in to the project dir in the terminal and running:

Thanks - that clarifies things a bit; I was only messing with CMake previously because my Windows machine is a bit more generously appointed and (understandably) the Windows C API build only works with CMake. The simple provided CMakeLists.txt work great on Windows and Mac/Linux for the samples, but Chipmunk2D drags the build process into the weeds, especially on Windows.

I was able to work out generally what needs to happen, but between the nature of the documentation on CMake.org, the gnarl that occurs when you actually try to support cross-platform building, and the opacity of the outputs that CMake spits out, I felt like I was following a vision that I could not subscribe to. CMake feels like a prayer for simplicity and elegance that just doesn't quite survive in the real world, and I felt like I'd be spending all my time fighting that. Makefiles may not be portable, and they can get hideous (ask me about my first assignment at Microsoft sometime), but I find them a bit easier to muddle through.

But most of the time, I have difficulty understanding the kinds of stuff in the book. Though the content is fine, and I end up asking questions on cs.StackExchange or StackOverflow. Then I thought of reading the reviews of the text and find out whether it is only me who is facing is the problem or there are people like me as well, finding the language hard to understand. Then I came across the review page of this book in good reads and among many reviews, I found one which explains the problem with the text probably. Here it is:

The good thing about this book is it is comprehensive and covers a lot of ground from different vantage points. For example, the parsing chapters also cover the design of lex and yacc apart from basic topics. The type checking and runtime environment chapters had examples from C and ML to cover different scenarios.

Now the bad parts. The book is awfully written and I cannot understand how can a book in its 2nd (or 3rd?) edition continue to be so bad. It was shoddy writing throughout but the prize for the worst writing is these topics:

Another consistent problem is their horrible use of passive voice. This interacts really badly with their discussion of mathematical aspects. While the use of passive voice might be excusable, its shoddy use is not.

Reading this book often felt like deciphering some ancient text. I needed to translate a lot of obtuse writing into something that can be understood in my head. This translation happens for all readings involuntarily but it was alarming I had to consciously do it for this book.

I am not sure why is this book called a "classic" computer science book. It is more like a kind of book that students are forced to study by their professors. This book is impossible to read unless you are following some other source. I followed Prof. Alex Aiken's lectures

This book might be responsible for the unpopularity of the study and research in programming languages. I agree compilers are not easy but this book has taken a difficult topic and made it incomprehensible thereby doing a disservice to this whole field of study.

I am not criticizing the text or authors. The only thing is that probably the text does not suit a self-learner like myself. Could anyone suggest a compiler text to substitute the red dragon book possibly? A book with easy language, such that one easily understand what the authors tried to mean just by reading a sentence once. This would help a self-learner to focus more on the concept rather than getting lost in finding out the meaning behind the lines.

The "problem" with the dragon book is that it is so complete; intentionally so. Over its lifetime there have been tremendous advances in the theory and practice of building compilers. If you want "state of the art", then you want the dragon book, probably a later (harder) edition, even.

3a8082e126