For me, personally, the best way to start learning about the design of persistent virtual machines is to create a working persistent implementation of the Forth Programming Language.

Forth is a wonderfully minimal programming language that hosts it's own interactive development environment.

Within a simple Forth implementation essential topics are explored, including:

• Stack based execution
  • The stack sits at the heart of common virtual machines, like the [wp>Java_Virtual_Machine|JVM] or [wp>Common_Language_Runtime|CLR]. Forth is a stack based programming language where the programmer is able to directly interact with the stack, instead of having it abstracted away beneath friendlier syntax.
• Execution environment
  • Forth provides a minimalist development environment that is incredibly power and, once you get used to it, enjoyable to use. The experience challenges you to reconsider the necessity of all the features that we now have in our bloated IDEs.
• Instruction set design
  • Forth's minimalism extends to it's instruction set. Forth provides a complete, powerful language using a set of words that is much smaller than the opcodes supported by the typical virtual machine.
• Portability
  • Forth is easily ported to new hardware because most of the instruction set is implemented using just a handful of core words that use native machine code. To port to a new environment only those core words need to be ported.
• Interactive and Active development
  • Before we had Agile and Refactoring we had Thinking Forth by Leo Brodie. The subtitle says it all: “A Language and Philosophy for Solving Problems.”
• Progressive Word Definitions
  • Forth has a feature that I see as important for Plip Plop Programming. When a word is updated, it does not affect existing words, which will continue to use the version of the word as it was at the time of compilation. This frees the programmer to change words without having to constantly regression test.

Rather than working from a specification, I will be using NibbleForth as my model of Forth. I've chosen NibbleForth because it implements a fully functioning, minimalistic, version of Forth using Python code that is easy to read and understand.

I have chosen NibbleForth over more compact implementations such as Tiny Forth because of this simplicity and clarity of implementation.

NibbleForth was written by Ben Hoyt as an experiment on compact code. The source can be found in his GitHub account: https://github.com/benhoyt/nibbleforth.

One limitation to NibbleForth is that it does not support Progressive Word Definitions. It just maintains a dictionary of word definitions as text rather than compiling to execution tokens. I will need to fix this.

I don'st have much spare time to spend on this project, so I need to break the whole think up into neat little chunks. I expect this to keep my busy until at least the end of 2025.

The goal is to move as quickly as possible to a SQL driven VM with an debugger API that can be accessed through a web application.

1. Simple Execution
   1. Python script and tests
   2. SQL + PHP version with tests
   3. HTMLX based debugger
2. Compilation
   1. Python script and tests
   2. SQL + PHP version with tests
   3. HTMLX based debugger