

Basics of Compiler Design [pdf] - lapenne
http://www.diku.dk/hjemmesider/ansatte/torbenm/Basics/basics_lulu.pdf

======
rlm
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/>.

------
Bjoern
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...](http://www.amazon.com/Compilers-Principles-Techniques-Alfred-
Aho/dp/0201100886)

~~~
eru
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...](http://research.microsoft.com/en-
us/um/people/simonpj/papers/slpj-book-1987/) [2]
<http://en.wikipedia.org/wiki/Dragon_Book>

------
10ren
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.

------
Simucal
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.

~~~
wlievens
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.

~~~
eru
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.

~~~
wlievens
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.

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

------
friism
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.

