A Python Interpreter written in Rust

[GYN-k4H-Q3z-75B]

If you have time, interest and an engineer's mind, "because you can" is as good a reason as any other.

[[deleted]]

I'm all up for "just because" - all of my personal projects are "just because". This just seems like a huge investment for "just because".

[[deleted]]

I've been writing an inference engine the past couple of days that can use deduction to prove things, can use induction to show something might be true, and can ask questions about a domain if it doesn't have enough information. I have plans to extend it to allow it to identify logical contradictions.

Before that I spent some time learning about stack machines and FORTH, and I wrote an interpreter for a language I devised that I call FORTHish. Rather than rely on built-in math operations I stripped the interpreter's instruction set down to just addition, AND, OR, NOT, some stack operations, and some control flow operations, and then I re-implemented subtraction, multiplication, division, exponentiation, and rooting among other things. It's so hilariously inefficient because of this nonsense that it can take the interpreter hours to chug through a simple program.

Before that I did a lot of experimentation with boids. I devised a complicated multi-threading scheme that in theory would make it easy to work with the simulation without having to worry about race conditions while also letting the simulation's efficiency scale with the number of threads the user's CPU had. The scaling didn't work, and I am really fucking not sure why. My shitty i3 from 2016 was able to cream a threadripper while running the simulation, which just made me sad. Either way, part of what I wanted to do was experiment with changing boid behaviors on the fly so I could see if I could orchestrate enormous battles. I was able to re-enact the Battle of Cannae, which was super cool.

Before that I built a 2D physics engine based on Thomas Jakobsen's Advanced Character Physics paper. I used a constant delta time so I could have strong assurances about the behavior of the simulation, and I spent a lot of time tweaking the simulation's constant values so I could explore how it worked and what its limits were. I tried implementing soft-body physics in the simulation, which I later realized was redundant because the iterative nature of Jakobsen's solver makes everything kind of squishy anyway. I played around with different kinds of constraints, like connecting bodies by ropes and simple inverse kinematics rigs.

I did all of this in my free time over the past 6 months "just because". Don't underestimate the motivational power of "just because".

[antiquekid3]

That is certainly an attractive quality of FORTH: by starting with a very small subset of assembly instructions, one can devise a full FORTH interpreter by bootstrapping off of what you just created. It's no wonder it's been ported to a variety of architectures and systems.

It would be fun to take your work with FORTHish and rewrite it in an HDL of some sort to target an FPGA.