Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My opinion is that a compiler is best understood as partial evaluation of an interpreter. So I'd start with an interpreter and give an example of compilation which simply concatenates the code parts of the interpreter without dispatch logic. This is what compilation is. The rest is optional optimizations.

Similarly, I think parsing is best understood by implementing a parsing algorithm. While popular algorithms like LL and LR are rather complex, CYK algorithm is straightforward to implement, directly corresponding to the definition of context-free grammar. Other algorithms are optimizations.

For ordering, I think it is best to start with AST and its interpretation. And then parsing and lexing (in that order). And then compilation. And then extending the language with features. And then various optimizations.



If you want any chance of understanding real compilers, the "optional" optimizations and parsing algorithms are actually pretty important. I do think starting with an interpreter for an AST is just as good a method as starting with code generation, and code optimization can probably wait until the end, but teaching parsing should avoid any kind of CYK/LL/LR unless you're specifically teaching grammar theory.

Using a parser generator of some kind is possibly okay to teach the concept of a grammar, but it's terrible for error handling, efficiency, and simplicity. For most programming languages, nothing beats a plain old hand-written recursive descent parser (optionally with pratt parsing for expressions) on those metrics. And indeed, most compilers I've seen in production are written that way.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: