I find it a little amusing that it claims "toy compilers are too simplistic and do not prepare the novice compiler writer to construct a useful compiler", and then chooses Scheme, effectively bypassing the whole process of parsing... which IMHO is half the fun of writing a compiler.
Seeing the elegance of recursive descent (and refactoring it into table-driven operator-precedence) and how it can turn recursive structures like expressions and statement blocks into linear sequences of instructions is something I think everyone writing a compiler should experience.
However, I agree with an incremental approach, and that is nothing new; personally I think Jack Crenshaw's tutorial series (started in 1988) is one of the best:
It's interesting to note that Jack doesn't specialise in compilers, nor computer science for that matter, yet his explanations are far clearer to me than many of those who do.
> how it can turn recursive structures like expressions and statement blocks into linear sequences of instructions
I think this is one of the key concepts in a compiler, yet I don't think it has much to do with parsing.
Parsing (in a compiler) is the act of taking a linear sequence of characters or tokens, and turning them into a rich AST structure.
The back end of the compiler is what takes this recursive structure and flattens it out into a linear sequence of instructions that "mean" the same thing as the tree.
Parsing is critical, of course, for building a working compiler. But I think not focusing on surface syntax gets to the key recursive-to-linear insight you mention more directly!
This is not a necessary step, and is specifically not done in a lot of simpler compilers. E.g. most "Wirth-type" compilers never build an AST.
There are lots of good reasons to build ASTs if you want to do complex analysis and optimisation, and it simplifies the presentation of some things, but calling the code generator module straight from the parser in many ways makes the direction connection clearer.
effectively bypassing the whole process of parsing... which IMHO is half the fun of writing a compiler
Fun for compiler writers, perhaps ;) I am a big fan of languages with minimal syntax because complicated grammar affects the user as well. The machine may do the hard work of translating the source code, but the user still has to do some degree of translation of their own in their head while reading it.
I view source code as a kind of interface, and I like simple, clean interfaces.
>> It's interesting to note that Jack doesn't specialise in compilers, nor computer science for that matter, yet his explanations are far clearer to me than many of those who do.
Yes. It's written with a practical approach in mind. Once you get that idea, feel free to study compiler textbooks like "the Dragon Book",for example, for in-depth theory.
Seeing the elegance of recursive descent (and refactoring it into table-driven operator-precedence) and how it can turn recursive structures like expressions and statement blocks into linear sequences of instructions is something I think everyone writing a compiler should experience.
However, I agree with an incremental approach, and that is nothing new; personally I think Jack Crenshaw's tutorial series (started in 1988) is one of the best:
http://compilers.iecc.com/crenshaw/ (original 68k version)
http://www.pp4s.co.uk/main/tu-trans-comp-jc-intro.html (x86 version)
It's interesting to note that Jack doesn't specialise in compilers, nor computer science for that matter, yet his explanations are far clearer to me than many of those who do.