4 ms·

This book should be the second or maybe third step of your journey into PL compilers. The first step is to write an interpreter yourself, for a simple language

by fooker 2y ago

This book should be the second or maybe third step of your journey into PL compilers. The first step is to write an interpreter yourself, for a simple language you create, without knowing anything about interpreters or language design. The second step is to rewrite it, and make less mistakes! :) If you don't do this, you are never going to appreciate the nuances of this topic. And you are going to skip over concepts that don't seem important.

bruce343434 2y ago
For me, this book demystified these topics and allowed me to do your second and third step in the first place :) It's okay to not come up with/reinvent from first principles every technique on your own. It's normal to stand on the shoulders of giants.
- fooker 2y ago
  I'd think of it as riding a bike vs reading about riding a bike.
  - macintux 2y ago
    I’d much rather have someone, or something, providing guidance as I learned to ride a bike. Of course you’re less likely to end up with a head injury writing an interpreter, but still, it’s not exactly a crime to learn before doing.
  - kleinsch 2y ago
    When you learn to ride a bike, someone teaches you how to do it. You could go out and fall down a few times by yourself so it’s more fulfilling when you have instruction, but I wouldn’t say that’s the most efficient path.
kccqzy 2y ago
That's exactly what I did. My own experience with the first step is to write a TeX-like language with macro definition and macro replacement. About a few days into the project I kept running into so many bugs that really instilled a more academic culture in me and I started to read books. But it was still a wonderful first step: without it you might not have even realized that this is a book-worthy topic.
PhilipRoman 2y ago
That brings back some memories... Having just started learning Java I wanted to create my own language. It wasn't that bad, I even managed to implement an operator precedence algorithm without looking it up. It worked by scanning the list of tokens and each time finding the highest priority subexpression. There was no recursion involved, just good old manual pushing and popping on a stack. The problem was that I didn't really understand parsing so most of the language was implemented using copious amounts of string.split and string.replace, predictably leading to some concepts not being nestable. Really wish I had archived the source code for that.
- fuzztester 2y ago
  what do you mean by some concepts not being nestable?
  - PhilipRoman 2y ago
    From what I remember, variable references started with a dollar sign and you'd need to apply a new level of escaping (another dollar sign) to variable names with each inner loop, otherwise the variables would be substituted once and kept for all loop iterations. You can sometimes see similar issues in shell scripts, the following command prints three empty lines instead of numbers: sh -c "for i in 1 2 3; do echo $i; done" There were countless other restrictions too, some expressions could only take a variable name. Statements were delimited by lines (and optionally also by semicolons) so any loop or conditional, regardless of nesting depth, had to fit inside a single line. Due to usage of string.split, initially all semicolons had to have a space before them, I remember feeling very smart when I added automatic splitting of "abc;" into two tokens "abc" and ";"
kelnos 2y ago
For me, I just didn't know where to start, and thought that these sorts of projects were simply magic that were beyond my skills. But reading Crafting Interpreters showed me that all I needed was a little nudge in my thinking. I don't think I would have ever attempted to write an interpreter without first reading something like CI... I never would have gotten to your step three.

by fooker 2y ago

bruce343434 2y ago

For me, this book demystified these topics and allowed me to do your second and third step in the first place :) It's okay to not come up with/reinvent from first principles every technique on your own. It's normal to stand on the shoulders of giants.

fooker 2y ago
I'd think of it as riding a bike vs reading about riding a bike.
- macintux 2y ago
  I’d much rather have someone, or something, providing guidance as I learned to ride a bike. Of course you’re less likely to end up with a head injury writing an interpreter, but still, it’s not exactly a crime to learn before doing.
- kleinsch 2y ago
  When you learn to ride a bike, someone teaches you how to do it. You could go out and fall down a few times by yourself so it’s more fulfilling when you have instruction, but I wouldn’t say that’s the most efficient path.

kccqzy 2y ago

That's exactly what I did. My own experience with the first step is to write a TeX-like language with macro definition and macro replacement. About a few days into the project I kept running into so many bugs that really instilled a more academic culture in me and I started to read books. But it was still a wonderful first step: without it you might not have even realized that this is a book-worthy topic.

PhilipRoman 2y ago

That brings back some memories... Having just started learning Java I wanted to create my own language. It wasn't that bad, I even managed to implement an operator precedence algorithm without looking it up. It worked by scanning the list of tokens and each time finding the highest priority subexpression. There was no recursion involved, just good old manual pushing and popping on a stack. The problem was that I didn't really understand parsing so most of the language was implemented using copious amounts of string.split and string.replace, predictably leading to some concepts not being nestable. Really wish I had archived the source code for that.

fuzztester 2y ago
what do you mean by some concepts not being nestable?
- PhilipRoman 2y ago
  From what I remember, variable references started with a dollar sign and you'd need to apply a new level of escaping (another dollar sign) to variable names with each inner loop, otherwise the variables would be substituted once and kept for all loop iterations. You can sometimes see similar issues in shell scripts, the following command prints three empty lines instead of numbers: sh -c "for i in 1 2 3; do echo $i; done" There were countless other restrictions too, some expressions could only take a variable name. Statements were delimited by lines (and optionally also by semicolons) so any loop or conditional, regardless of nesting depth, had to fit inside a single line. Due to usage of string.split, initially all semicolons had to have a space before them, I remember feeling very smart when I added automatic splitting of "abc;" into two tokens "abc" and ";"

kelnos 2y ago

For me, I just didn't know where to start, and thought that these sorts of projects were simply magic that were beyond my skills. But reading Crafting Interpreters showed me that all I needed was a little nudge in my thinking. I don't think I would have ever attempted to write an interpreter without first reading something like CI... I never would have gotten to your step three.