Tail-Call Interpreters in Rust – Jimmy Ostler
lordgoati.us
lordgoati.us
There is a time and place for text and retro-CRT effects, this isn't one.
Another thing that is kinda neat: there is a duality (a bidirectional transform) between the AST for a tree walking interpreter and the AST for a stack machine. To create the stack machine AST, all you do is remove any occurrence of the expression type in the tree-walking AST; these values are now found on the stack. Obvious when you think about it, but useful nonetheless. I don't think there is a simple equivalent for a register machine as, unless you have an infinite number of registers, you need to do register allocation.
(If the author reads this, my name changed from Noel to Neal at some point. I don't really mind though; my name is a bit unusual and I've been called all sorts of things.)
If I may leave some feedback here...
It'd be cool if you could add some syntax highlighting, because being at it is, it's hard to distinguish comments from code paths. The code snippets are just Scala anyway, aren't they?
Why, in the switch dispatch- and the subroutine threading-variants, is the recursive call in the dispatch function done with a call to loop(...)? Is that some Scala specific thing for recursion?
Syntax highlighting was a discrepancy between my local env and the Netlify env that deploys the site.
`loop` is what I usually call tail-recursive loops in my personal style. I think I changed that to `dispatch` for the blog post and didn't push the change all the way through.
I think it'd be good to update the about page with that info: https://noelwelsh.com/landing/about/
Hope that clears it up.
(Add (LoadConst 1) (LoadVar x))
[PushConst 1, PushVar x, Add]
enum Expr:
case Add(left: Expr, right: Expr)
case Lit(val: Double)
enum Expr:
case Add
case Lit(val: Double)
The transformation in the other direction is not purely syntactic as you have to know that, e.g., Add gets two parameters from the stack and add those parameters back in.
class Add : Node {
Node left;
Node right;
int interpret() {
int l = left.interpret();
int r = right.interpret();
return l + r;
}
}
class Add : Node {
Node left;
Node right;
void compile(bc: ByteCode) {
left.compile(bc);
right.compile(bc);
bc.push(OP_ADD);
}
}
YMMV, but OP, if you read this, please consider disabling the text-shadow for code snippets... or disabling syntax highlighting in code snippets. These two things are not a good thing together.
There's people reading this blog with all types of devices, screens, lighting and range of visual acuity. Even if you're blessed with perfect vision and excellent displays, it should be obvious that readability has been lowered for no obvious reason.
The point of a blog is for people to read it, so it fails at its foremost job.
Bringing the brightness levels of the background and text closer together doesn’t ever seem to work, but being able to add a slight blurry dropshadow behind behind each character might be a way to reduce the artifacts OLEDs seem to create when my eyes are tired.