Lessons learned building a toy compiler(jaseemabid.github.io) |
Lessons learned building a toy compiler(jaseemabid.github.io) |
With that said, I think there is one small issue in the article:
> The quintessential first step in any compiler is parsing the source string into an Abstract Syntax Tree
If there is a quintessential first step in writing a compiler it is doing lexical analysis with a lexer to break the program up into tokens. Then using a parser to create the AST. While you could go straight from the raw text to parsing, it makes it a lot easier if you lex it first.
I'll update the post with this feedback.Thank you.
That paper is very recent. It sounds like it is still doing both steps just concurrently and with feedback. It isn't skipping the lexing step altogether. The benefit of separation is decreased code complexity and easier debugging.
It's not quite `a compiler for simply typed lambda calculus', but only for a small fragment without higher-order functions. One currently cannot write lambda terms that take functions as arguments.
I was curious how the compiler represents closures and manages memory, mainly because I'm looking for a small example of how to do garbage collection in LLVM. But it turns out that the parser doesn't allow function types yet and the compiler itself doesn't implement closures yet.
I never took a course in writing compilers at University but have always been interested - where would be the best place to start for somebody interested in doing this? To dip their toes into the water if you will?
1. Write a scheme in 48hrs in Haskell
2. Kaleidoscope tutorial by LLVM developers
I used it for AutoSar applications, where you create tailored embeded programs from a DSL specification.
For instance, from a Chomsky's hierarchy of languages perspective lexing and parsing are simply language analysis at two different levels on the hierarchy with lexing focused on the "regular" language embedded within a larger context-free or context-sensitive language.