4 ms·

No, even the second edition is hugely out of date. First, note that basically the first half of the book is about parser implementation. Then, it basically jus

No, even the second edition is hugely out of date. First, note that basically the first half of the book is about parser implementation. Then, it basically just teaches you that there's only one parser and it's called LALR. Of course, they didn't include anything like packrat, but even worse, they pretend like a LALR generator is still better than LR, even though LR was extended to be tractable for large grammars years ago. And even with all that, it's far too high level to be of use in actually engineering a compiler (which, by the way, is a good intro book).

niggler 14y ago
packrat is not a panacea: once you try to add left-recursion into the mix, it becomes much slower than LALR parsers. LALR represents a nice tradeoff: both LR and packrat involve much much larger state tables than LALR parsers.
- Locke1689 14y ago
  That's not the point. The point is to impart information and let the compiler designer choose which is appropriate. The ordering is also confusing because the grammar parsers go from less powerful to more powerful. However, LALR is after LR. Edit: Oh, and for C++ you need a GLR, which isn't even covered in dragon.
eru 14y ago
> And even with all that, it's far too high level to be of use in actually engineering a compiler (which, by the way, is a good intro book). I actually found it way too low level. And not meaty enough.
wglb 14y ago
I can't argue with your "hugely out of date" note. It is likely that I am also out of date, not having written compilers since the mid-80s. Do you have an opinion about the Holub book? Also I have a collection of Davidson papers about code generation that I haven't looked at since back then.
- Locke1689 14y ago
  Unless you need to for speed or compat reasons, I don't like writing parsers in C. Remember, a compiler is a translator from text to (often)text. You're going to be dealing with a lot of strings and probably allocations for your AST. You should think about using a language which doesn't make string manipulation and memory management like pulling teeth. In general, I'd say the ML family is best for writing a general-purpose compiler. SML even gives your compiler a formal semantics for free.

niggler 14y ago

packrat is not a panacea: once you try to add left-recursion into the mix, it becomes much slower than LALR parsers. LALR represents a nice tradeoff: both LR and packrat involve much much larger state tables than LALR parsers.

Locke1689 14y ago
That's not the point. The point is to impart information and let the compiler designer choose which is appropriate. The ordering is also confusing because the grammar parsers go from less powerful to more powerful. However, LALR is after LR. Edit: Oh, and for C++ you need a GLR, which isn't even covered in dragon.

eru 14y ago

> And even with all that, it's far too high level to be of use in actually engineering a compiler (which, by the way, is a good intro book). I actually found it way too low level. And not meaty enough.

wglb 14y ago

I can't argue with your "hugely out of date" note. It is likely that I am also out of date, not having written compilers since the mid-80s. Do you have an opinion about the Holub book? Also I have a collection of Davidson papers about code generation that I haven't looked at since back then.

Locke1689 14y ago
Unless you need to for speed or compat reasons, I don't like writing parsers in C. Remember, a compiler is a translator from text to (often)text. You're going to be dealing with a lot of strings and probably allocations for your AST. You should think about using a language which doesn't make string manipulation and memory management like pulling teeth. In general, I'd say the ML family is best for writing a general-purpose compiler. SML even gives your compiler a formal semantics for free.