4 ms·

Writing a compiler is still on my list since a few years, but everytime I start I get stuck in the parser. It just doesn't seem to click with me. On the next co

Writing a compiler is still on my list since a few years, but everytime I start I get stuck in the parser. It just doesn't seem to click with me. On the next couple of weekends I'll start again with Flix (flix.dev) and maybe Crafting Interpreters. Wish me luck.

Georgelemental 3y ago
In my compilers class in university, the prof skipped over parsing entirely—our source code was Racket S-expressions.
- freilanzer 3y ago
  Good, it's not the most important or interesting part imo. I also had an entire course about parsing, just not about compilers, and I don't see why many professors give it such an amount of attention.
jjice 3y ago
Something to consider is a parser generator for your language. They get a lot of flack online these days for some reason from people saying "a recursive descent parser is faster and not that hard", but they're generally time consuming if you just want to get something going. PLY (or maybe it's SLY now) for Python is really great.
drdude 3y ago
During my 2015 Compilers class, it was indeed the worst step and hardest to get right. We spent (my and my team mate) about 60%+ of the time making that parser actually parse. The lexing, tokenizing, etc is nothing compared to it. In another project, I used Antlr to avoid the headaches, but there are definitely better alternatives out there (some one mentioned Sly in the comments). Right now, if I want to mess with some transformation passes for an existing language, I would just look for LLVM and Clang for C for example (readily made front end, and backend with hackable middle end). P.S. I am a hobbyist at this stage and you can consider me knowing nothing about LLVM. My advice is based on my friends' (same colleague) who works for nVidia for their CUDA compiler using LLVM. Another reason for me to be interested in LLVM is that I used JVM languages (Scala, Java) for the past 20+ years and with GraalVM and its polyglot support for LLVM based languages; whose support was added using LLVM. my rusty two cents (Rust is awesome too ;)).

Georgelemental 3y ago

In my compilers class in university, the prof skipped over parsing entirely—our source code was Racket S-expressions.

freilanzer 3y ago
Good, it's not the most important or interesting part imo. I also had an entire course about parsing, just not about compilers, and I don't see why many professors give it such an amount of attention.

jjice 3y ago

Something to consider is a parser generator for your language. They get a lot of flack online these days for some reason from people saying "a recursive descent parser is faster and not that hard", but they're generally time consuming if you just want to get something going. PLY (or maybe it's SLY now) for Python is really great.

drdude 3y ago

During my 2015 Compilers class, it was indeed the worst step and hardest to get right. We spent (my and my team mate) about 60%+ of the time making that parser actually parse. The lexing, tokenizing, etc is nothing compared to it. In another project, I used Antlr to avoid the headaches, but there are definitely better alternatives out there (some one mentioned Sly in the comments). Right now, if I want to mess with some transformation passes for an existing language, I would just look for LLVM and Clang for C for example (readily made front end, and backend with hackable middle end). P.S. I am a hobbyist at this stage and you can consider me knowing nothing about LLVM. My advice is based on my friends' (same colleague) who works for nVidia for their CUDA compiler using LLVM. Another reason for me to be interested in LLVM is that I used JVM languages (Scala, Java) for the past 20+ years and with GraalVM and its polyglot support for LLVM based languages; whose support was added using LLVM. my rusty two cents (Rust is awesome too ;)).