> I feel like my Forth-like compiler and VM capture enough of the spirit of Forth!
Being interactive is core to the spirit of Forth, so I think your feeling is off.
The fact that editing, compilation and execution is folded into single, comprehensive workflow, makes it possible for a Forth system to be situated in very resource constrained environments and evolve while it's running, potentially without any dependence on some other, beefier computer somewhere else.
There are tons of problems avoided with bundling all these capabilities together. There is no question of "which version of the compiler to use?", since it's part of your program, because it's so small (few hundred bytes probably), it can be part of it.
It also has the D-lang, Rust or Zig style `comptime` feature via the immediate mode words.
And the list goes on an on...
Here is a starting point for understanding more of these principles: https://www.ultratechnology.com/lowfat.htm
Chuck Moore's ColorForth (https://colorforth.github.io/cf.htm) takes these ideals to some extremes, allowing an ATA IDE disk driver to be a few words of code only: https://colorforth.github.io/ide.html
I think it's ok to edit forth code in a modern text editor. Following your definition, many modern forth engines wouldn't qualify as a forth. You don't need an antique screen-based editor to get immediate words.
Another thing of the Forth spirit is that the system is supposed to be fully bootstraped (like most Lisps as well), having a very small of words written in Assembly, and then everything else fully bootstraped in Forth and available for customisation.
Forth is a great starting point for designing interpreters/languages.
A while ago I tried to put together a kit to make it easier to get started writing interpreters:
I don’t think a tokenizer like that is a good idea for Forth. You’ve got to read the next space separated thing, find out if it’s supposed to be compiled or run.
Eg the naive tokenizer would probably not work for .” for example.
I agree. The tokenizer in the article completely misses the point of how Forth works: the tokenization is supposed to be driven by the words themselves, i.e. ." is looking for a " delimiter, ( is looking for a ).
Not to mention that the rest of the compiler also misses the point of how Forth works. This compiles a fixed subset of Forth and entirely misses out on the extensibility of the language.
This was a well written post! It makes me want to create my own forth-like language