Thanks for the recommendation, though I&#x27;d give the caveat that I&#x27;ve been rambling all over the place, especially in the later parts. I also have lots of changes after the latest part that I need to write about...<p>I&#x27;d really like to get a chance to take the time to retrospectively go over and tighten it up. The trouble with that is that it&#x27;s easily 10 times+ as much effort to follow along with a project this way and write about each change as it is to cover the finished code (especially thorny issues such as how to avoid wasting too much time on bug fixes that may or may not have affected understanding of previous parts).<p>Personally, while I&#x27;m very happy that people find my series useful, I&#x27;d recommend perhaps supplementing or starting with Niklaus Wirth&#x27;s books or Crenshaws &quot;Let&#x27;s write a compiler&quot; (one of the ones recommended in the linked artile) for something much more focused. I feel the angles are sufficiently different that it&#x27;s worth it. And Wirth is my big hero when it comes to language and compiler construction.<p>While the other suggestion in the article is well worth a read, I&#x27;d give one caveat: Lots of passes is <i>hard</i> to keep mental track of. My compiler sort-of does something similar in applying multiple transformation stages to the AST, and I&#x27;m mulling collapsing it into fewer stages rather than more because I feel it&#x27;s getting more complex than necessary. You can work around some of the debugging complexity by outputting each stage to a suitable format so you can test each transformation individually, but it&#x27;s still hard to keep track of exactly what each
stage expects and delivers.