Creating a new PL is so different from changing an existing one.
You need to worry about syntax, locals, scope, error checking, conditionals, interpreter loop, stdlib etc. You can work on these in isolation once you have a working implementation.
(My toy PL now does fizzbuzz!)
miniblog.
Related Posts
One nice feature of cargo that I wasn't previously aware of: you don't need to do anything after updating your Cargo.toml.
In npm, you need to remember to `npm i` after changing package.json. It's not declarative and the state can get out of sync.
I'm changing method definition syntax in my language:
// old
fun (this: Int) inc(): Int { this + 1 }
// new
method inc(this: Int): Int { this + 1 }
The original syntax was inspired by Go, but the new syntax is more grep-friendly and perhaps more readable. Not sure about the verbosity though. Thoughts?
Every time I implement an interpreter with recursion, I regret it.
As soon as I want TCO, or userland control of stack limits, or resumable exceptions, I need my own stack.
This is awkward because it's an upfront design decision. Changing the stack model is a big refactoring.