I've read it as a part of the introductory compiler course at DIKU (Computer Science dept. of University of Copenhagen).

It's good for exactly what the title says: Basics of Compiler Design. It won't make you a compiler guru, but it will give you a good grasp of the fundamentals.

If anyone is interested, I could share the weekly assignments and the exam project from the course.

The advanced compiler course at DIKU uses Modern Compiler Implementation in ML: http://www.cs.princeton.edu/~appel/modern/ml/.

I can only recommend the "Dragon Book". Its old but really a great intro into Compilers. I had the benefit of working with it must say I didn't find anything better so far.

Compilers: Principles, Techniques, and Tools by Alfred V. Aho (Author), Ravi Sethi (Author), Jeffrey D. Ullman (Author)

http://www.amazon.com/Compilers-Principles-Techniques-Alfred...

I found the Dragon Book quite dull, and old fashioned. "Implementing Functional Programming Languages" [1] by Simon Peyton-Jones makes a much more interesting read.

Edit: I guess, we are talking about different Dragon Books. Wikipedia lists [2] at least three. And says about the first: "Principles of Compiler Design is now rather dated [...]."

[1] http://research.microsoft.com/en-us/um/people/simonpj/papers... [2] http://en.wikipedia.org/wiki/Dragon_Book

Just browsing the contents on parsing (what I"m working on), it seems little different from the Dragon book. Has the simplest way to construct a parser really not improved after all these years? What about the LL(*) class of parsers that ANTLR uses, and packrat parsers (I don't use these, have just heard about them).

Or has "parsing" become a pedagogical foundation subject, whose content is determined not by pragmatic usefulness, but by the its role in the curriculum?(e.g. so if you say you've studied "parsing" people can assume you know about LALR, even if no one uses it.) I'm not saying the latter would be a bad thing - we need a common vocabulary - I'd just like to see progress at the core as well as the edges.

In his first section he describes a compiler as something that turns high-level code into machine code. This isn't necessarily true is it?

A compiler is something that takes code in one language and converts it to another. It can be a Python to Javascript compiler, or a C to x86 Assembly Compiler (which can then be assembled using an appropriate assembler).

I'm reading both Louden's "Compiler Construction: Principles and Practice" and the Dragon Book. They are both good so far.

The thing is, if you make the definition too generic, everything turns out to be a compiler. For instance, Photoshop is a compiler that turns commands in the UI (the input language) into PSD files (the output language). It's a lot harder to define terms like "compiler" than it actually seems.

And you have to differentiate your definition for 'compiler' from 'interpreter'. And point out, that those two sit on opposite ends of the same spectrum.

Even that is a fuzzy barrier. You have lots of languages that have the compiler built-in to the runtime environment (Smalltalk, and I guess most lisps?). Anything with JIT blurrs the line, too.

Yes, that's what I was trying to say by mentioning a "spectrum". Threaded interpreters are also closer to compilers than most.

I was taught by this book while at DIKU. It's pretty 'dry' with its LaTex typesetting and all, but thorough and pretty comprehensive within the scope.