[cdcarter]

I agree on the suggestion to do part two, it's where things get really fun!

One thing you can do with the finished Lox (or Monkey, if you prefer WACIG) before going into the world of intermediate representations is implementing a peephole optimizer. You look for reducible patterns in the bytecode, and replace them with optimized bytecode. You can also look for certain patterns and replace naive implementations with native builtins/intrinsics. You can work with the raw bytes of the bytecode, so you don't need to introduce an IR just yet.

The Apex compiler at Salesforce does a vast majority of its optimizations as peeps.

EDIT: I _just_ wrote another comment to someone asking similar questions a few days ago. Here's a link to the parent question, check out my thoughts as well as others in the thread. https://news.ycombinator.com/item?id=36119915

[lukemerrick]

Wow, the whole concept of a peephole optimizer is a bit mind blowing to me. I'm appreciating all the reasons to power through to writing a bytecode VM as the next step.

I'm not sure how far down the compiler I actually will enjoy going vs. exploring ideas around type systems, linters, etc. up near the AST level, but if I do venture down this advice will certainly come in handy!

[erichocean]

Do you have any pointers to papers/books exploring peephole optimizers? I've read a few paper, but found them underwhelming…

[cdcarter]

I don't have an academic background, and I'll agree that the majority of books I have picked up have covered the subject very well. It's a pretty common technique though, for assembly and for bytecode, so I've learned by reading implementations. `peephole.c` in CPython is particularly easy to read with a small understanding of the CPython API. It's a very limited implementation, but the idea goes far. Lots of things that you might expect the compiler to optimize in IR can be done directly from the bytecode instead.