Compiling a Forth
Posted3 months agoActive3 months ago
healeycodes.comTechstory
calmmixed
Debate
60/100
ForthProgramming LanguagesCompiler DesignInterpreters
Key topics
Forth
Programming Languages
Compiler Design
Interpreters
The article describes the author's attempt to compile a Forth-like language, sparking a discussion about the essence of Forth and the challenges of implementing it.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
16h
Peak period
4
15-18h
Avg / period
2.3
Key moments
- 01Story posted
Oct 6, 2025 at 9:52 AM EDT
3 months ago
Step 01 - 02First comment
Oct 7, 2025 at 1:26 AM EDT
16h after posting
Step 02 - 03Peak activity
4 comments in 15-18h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 8, 2025 at 3:31 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45491470Type: storyLast synced: 11/20/2025, 1:45:02 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Eg the naive tokenizer would probably not work for .” for example.
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.
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
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.
A while ago I tried to put together a kit to make it easier to get started writing interpreters:
https://github.com/codr7/shi