Compiling a Forth(healeycodes.com)
healeycodes.com
Compiling a Forth
https://healeycodes.com/compiling-a-forth
9 comments
Having written a Forth-like native-code compiler (https://github.com/kragen/stoneknifeforth) and also a game in Gforth, I can't claim to be a Forth expert, but I agree. A lot of the weaknesses of the language (such as no compile-time checking of even the number of arguments to a subroutine, much less their types, and its terseness) are shored up by the interactivity of the environment. Some of the short words in Forth like ? only make sense in that context. And some things that might otherwise be weaknesses, like variables being static, become strengths in that context. (If you store into x in a word you're testing, you can see what got stored there with x ?.)
More generally, Forth, considered as a programming language, is not very good compared to other languages of a similar level, such as C or assembly. Its strength is as an interactive environment. (And none of what I've said here implies that you have to use a block editor.)
This is all fairly abstract, but it's not the first time I've talked about it, so I did an ASCIIcast last year demonstrating me writing a square root subroutine: https://asciinema.org/a/621404 I screwed it up in the middle and had to debug it, which is where Forth's interactivity shines. You may want to watch it on double speed, though. You can also get the pleasure of watching me learn that Gforth has readline-like command-line history!
That said, I think you're exaggerating a bit. I haven't seen a Forth compiler that's only a few hundred bytes, and I don't think the blocking PIO in Chuck's IDE driver is a good way to access an IDE disk, although it's adequate for initial bootstrapping.
More generally, Forth, considered as a programming language, is not very good compared to other languages of a similar level, such as C or assembly. Its strength is as an interactive environment. (And none of what I've said here implies that you have to use a block editor.)
This is all fairly abstract, but it's not the first time I've talked about it, so I did an ASCIIcast last year demonstrating me writing a square root subroutine: https://asciinema.org/a/621404 I screwed it up in the middle and had to debug it, which is where Forth's interactivity shines. You may want to watch it on double speed, though. You can also get the pleasure of watching me learn that Gforth has readline-like command-line history!
That said, I think you're exaggerating a bit. I haven't seen a Forth compiler that's only a few hundred bytes, and I don't think the blocking PIO in Chuck's IDE driver is a good way to access an IDE disk, although it's adequate for initial bootstrapping.
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.
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.
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.
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.
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:
https://github.com/codr7/shi
A while ago I tried to put together a kit to make it easier to get started writing interpreters:
https://github.com/codr7/shi
Read jonesforth if you want to learn how a Forth can be implemented and bootstrapped simply. Like other comments in this thread point out, this implementation isn’t really Forth and completely misses the point of Forth.
This was a well written post! It makes me want to create my own forth-like language
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