5 ms·

My humble opinion: do not get the Dragon book - it puts too much focus on parser theory and implementation which is in my opinion not the hard part of compiler

My humble opinion: do not get the Dragon book - it puts too much focus on parser theory and implementation which is in my opinion not the hard part of compiler construction. Most modern languages use a handwritten recursive descent parser anyway and the interesting part starts after you have the AST (code generation and register allocation).

cbsmith 7y ago
> which is in my opinion not the hard part of compiler construction It depends on whether you are compiling C++ or not. ;-)
- dfox 7y ago
  Parsing C++ is not that hard if you use hand rolled recursive descent parser. On the other hand hacking some parser generator framework to be able to parse C++ is hard and IMO mostly pointless busywork.
  - chrisseaton 7y ago
    > hacking some parser generator framework ... is hard and IMO mostly pointless busywork Bingo. We spent decades formalising and automating something... that was never that hard in the first place.
    - dfox 7y ago
      In context of parsing the situation when all the state machine/language theory has it's place is when you have some reason to care about compiler passes and generate output while reading input. That is, when you are not constructing some intermediate in-memory representation of whole compilation unit, presumably because you are running on system with (very) limited memory. For programming language compilers this ceased to be interesting limitation in 80's.
  - nemoniac 7y ago
    Not that hard? It's literally undecidable! https://news.ycombinator.com/item?id=21154565 https://news.ycombinator.com/item?id=21154565
    - chrisseaton 7y ago
      That's not what 'hard' means in this context. Requiring template instantiation (or some other interplay I'm not aware of) doesn't make parsing harder - it just means it can't be done independently. And what's more that kind of interplay is easier outside a parser framework! Many languages are not very pure for parsing. If you're writing a parser using lex and bison this means bending over backwards to make it work.
chrisseaton 7y ago
> My humble opinion: do not get the Dragon book - it puts too much focus on parser theory and implementation This is my strong opinion as well. Almost everyone fixates on parsing. I've been working on an interpreter/compiler full time since 2013, so coming up for eight years. I think I've spent maybe three or four days working on the parser. It's a vanishingly small part of the job. I wish compiler courses started with an AST, and then parsing was a separate course unrelated to compilers.
- protomikron 7y ago
  Yes - it's probably the case, because there is nice theory behind it (DFAs for lexing and grammars for parsing). What I can really recommend (and me and others have recommended it already countless times) is TECS: The elements of computing systems (also know as "Nand2Tetris"). Although it also covers other parts like the hardware stuff it lets you implement - an assembler - a VM - a compiler that compiles a simplified Java-like language to this VM It takes a bottom-up approach, but if you go through all projects you get a really good view about the big picture. However as it does code generation via an intermediate VM language it doesn't really touch register architectures as a compilation target. Anyway I highly recommend that book.
- whatshisface 7y ago
  The small amount of time spent on writing the parser might have something to do with how well-understood that area of computer science is. If nobody had ever written those books which were mostly about parsing, then maybe writing the parser would be the hardest part.
  - chrisseaton 7y ago
    I don’t think so. Almost everyone abandons all the theory and just writes recursive descent. It's not the case that they're using it but have just come to see it as normal. They're not using it.
    - tempguy9999 7y ago

cbsmith 7y ago

> which is in my opinion not the hard part of compiler construction It depends on whether you are compiling C++ or not. ;-)

dfox 7y ago
Parsing C++ is not that hard if you use hand rolled recursive descent parser. On the other hand hacking some parser generator framework to be able to parse C++ is hard and IMO mostly pointless busywork.
- chrisseaton 7y ago
  > hacking some parser generator framework ... is hard and IMO mostly pointless busywork Bingo. We spent decades formalising and automating something... that was never that hard in the first place.
  - dfox 7y ago
    In context of parsing the situation when all the state machine/language theory has it's place is when you have some reason to care about compiler passes and generate output while reading input. That is, when you are not constructing some intermediate in-memory representation of whole compilation unit, presumably because you are running on system with (very) limited memory. For programming language compilers this ceased to be interesting limitation in 80's.
- nemoniac 7y ago
  Not that hard? It's literally undecidable! https://news.ycombinator.com/item?id=21154565 https://news.ycombinator.com/item?id=21154565
  - chrisseaton 7y ago
    That's not what 'hard' means in this context. Requiring template instantiation (or some other interplay I'm not aware of) doesn't make parsing harder - it just means it can't be done independently. And what's more that kind of interplay is easier outside a parser framework! Many languages are not very pure for parsing. If you're writing a parser using lex and bison this means bending over backwards to make it work.

chrisseaton 7y ago

> My humble opinion: do not get the Dragon book - it puts too much focus on parser theory and implementation This is my strong opinion as well. Almost everyone fixates on parsing. I've been working on an interpreter/compiler full time since 2013, so coming up for eight years. I think I've spent maybe three or four days working on the parser. It's a vanishingly small part of the job. I wish compiler courses started with an AST, and then parsing was a separate course unrelated to compilers.

protomikron 7y ago
Yes - it's probably the case, because there is nice theory behind it (DFAs for lexing and grammars for parsing). What I can really recommend (and me and others have recommended it already countless times) is TECS: The elements of computing systems (also know as "Nand2Tetris"). Although it also covers other parts like the hardware stuff it lets you implement - an assembler - a VM - a compiler that compiles a simplified Java-like language to this VM It takes a bottom-up approach, but if you go through all projects you get a really good view about the big picture. However as it does code generation via an intermediate VM language it doesn't really touch register architectures as a compilation target. Anyway I highly recommend that book.
whatshisface 7y ago
The small amount of time spent on writing the parser might have something to do with how well-understood that area of computer science is. If nobody had ever written those books which were mostly about parsing, then maybe writing the parser would be the hardest part.
- chrisseaton 7y ago
  I don’t think so. Almost everyone abandons all the theory and just writes recursive descent. It's not the case that they're using it but have just come to see it as normal. They're not using it.
  - tempguy9999 7y ago