Lessons learned building a toy compiler
jaseemabid.github.io
Lessons learned building a toy compiler
1–10 of 23 posts
Re: Lessons learned building a toy compiler
#2It's nice to have a small example of how to compile to LLVM, but the compiler is a bit more limited than what the blog post makes it appear.
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.
Re: Lessons learned building a toy compiler
#3I love seeing articles like this... my compiler design course in college was one of my favorite. Also, one of the most useful. Parsers and lexers are useful in so many places besides just code compilers.
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.
Re: Lessons learned building a toy compiler
#4I love seeing articles like this... my compiler design course in college was one of my favorite. Also, one of the most useful. Parsers and lexers are useful in so many places besides just code compilers. 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 wr…
Well you can do both at the same time, it is called local lexing: https://arxiv.org/abs/1702.03277
Re: Lessons learned building a toy compiler
#5I love seeing articles like this... my compiler design course in college was one of my favorite. Also, one of the most useful. Parsers and lexers are useful in so many places besides just code compilers. 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 wr…
I think lexing is unnecessary with some methods, e.g. parser combinators and (I think) Might’s “Parsing with Derivatives”. And there are other tactics, like the other commenter mentioned.
Re: Lessons learned building a toy compiler
#6I love seeing articles like this... my compiler design course in college was one of my favorite. Also, one of the most useful. Parsers and lexers are useful in so many places besides just code compilers. 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 wr…
Well you can do both at the same time, it is called local lexing: https://arxiv.org/abs/1702.03277
I did mention in my post that the separate lexing step is not strictly necessary. I was just pointing out that a lexer follows the definition of "quintessential" more than parser does.
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.
Re: Lessons learned building a toy compiler
#7I love seeing articles like this... my compiler design course in college was one of my favorite. Also, one of the most useful. Parsers and lexers are useful in so many places besides just code compilers. 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 wr…
I think lexing is unnecessary with some methods, e.g. parser combinators and (I think) Might’s “Parsing with Derivatives”. And there are other tactics, like the other commenter mentioned.
There are alternatives, certainly. And lisp style languages are especially easy to parse without a lexer. I was just taking issue to the term "quintessential" being used. In a classical sense, the lexer comes first.
Re: Lessons learned building a toy compiler
#8Earlier quoted context omitted.
Well you can do both at the same time, it is called local lexing: https://arxiv.org/abs/1702.03277
I did mention in my post that the separate lexing step is not strictly necessary. I was just pointing out that a lexer follows the definition of "quintessential" more than parser does. 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.
Yes, both stages are still present in that approach, and that is a good thing, because clearly it is useful to separate lexing and parsing. It's just that the two stages are intertwined and thus lexing can be dependent on the parsing context. So it is not really going from "raw text to parsing".
Re: Lessons learned building a toy compiler
#9Author of the post here. AMA :)
Re: Lessons learned building a toy compiler
#10I think the most underrated part is:
"untyped lambda calculus is harder"