You've implemented a stack calculator, which misses the big picture: the stack is an implementation detail that enables a lot of the nifty stuff, but Forth is a "braided language" - the whole is more than the sum of the parts. Each part of it is just implementation, and the implementation is kept simple, but all of it needs to be there to make it completely usable. The distinction is important and non-trivial to the design of the interpreter.
To get there, please implement some of the metaprogramming words found in one of the standardized Forths(and if you aren't sure which one, use an earlier spec like Forth83 since the core wordset is smaller, so you run into the "hard stuff" faster).
Forth used in anger towards an application actually tends to resemble Fortran: procedural idioms flinging around lots of named temporary variables. The stack, being just implementation, doesn't give any assistance for everyday programming, unless you extend the system to do so. This is a point on which modern concatenative languages have diverged and tried to add some rigor into it.
tdeck 8 hours ago [-]
If you're interested in learning more about how FORTH works I, I can recommend two very old books.
The latter doesn't even mention FORTH, and describes some very archaic CPU architectures, but I found it fascinating because it builds things from the ground up.
anadem 3 hours ago [-]
Loeliger's 'Threaded Interpretive Languages' jumpstarted my career in the late 1970s: I built a networked water management system based on their code, which was my first big project, earning me £1,500. Note that there's a bug in their code (I no longer remember exactly where) so getting it off the ground was tricky.
elcritch 7 hours ago [-]
In particular learning about threaded interpreters, sub-routine interpreters, etc is very eye opening. That and really internalizing that everything, even code, is really just numbers.
gabrielsroka 8 hours ago [-]
1. You should add a URL when you you create a post on HN. You can indent code two spaces on HN, eg:
technically, "header only libraries" can be exceptions to C code not being in header files. See STB as an example https://github.com/nothings/stb. The advantage theoretically is that you can #include this library and use its code and types from just one file, its a decent model IMHO, but it can be jarring to someone unfamiliar with header only libraries.
uecker 4 hours ago [-]
They have plenty of downsides and only one very minor advantage: You need to copy only a single file instead of two into your source. I am still puzzled why anybody could think this is a good idea...
fjfaase 10 hours ago [-]
Interesting. I am currently in the process of writing an interpreter for a similar stack based language. I already wrote a compiler for this language to x86 assembly that can be compiled to an ELF. The language is used as an intermediate language for a C compiler that I am writing. It is maybe less Forth-like than your language. For more information see: https://github.com/FransFaase/MES-replacement For the interpreter have a look at: stack_c_interpreter.c
Your experiment is certainly a good tool to grok stack mechanics, but that is only one element of what makes a Forth what it is. You're missing out on other crucial ingredients: colon definition and immediateness.
It's already pretty efficient but I'm working on it to make it even more efficient so I can use it as some sort of primitive fragment shader for an art project. This Forth variant is intended to execute Forth Haikus, as defined by the Forth Salon website.
junifekhan 5 hours ago [-]
[dead]
Rendered at 22:13:34 GMT+0000 (Coordinated Universal Time) with Vercel.
To get there, please implement some of the metaprogramming words found in one of the standardized Forths(and if you aren't sure which one, use an earlier spec like Forth83 since the core wordset is smaller, so you run into the "hard stuff" faster).
Forth used in anger towards an application actually tends to resemble Fortran: procedural idioms flinging around lots of named temporary variables. The stack, being just implementation, doesn't give any assistance for everyday programming, unless you extend the system to do so. This is a point on which modern concatenative languages have diverged and tried to add some rigor into it.
Starting FORTH https://archive.org/details/LeoBrodieStartingFORTHIntroducti...
Threaded Interpretive Languages https://archive.org/details/R.G.LoeligerThreadedInterpretive...
The latter doesn't even mention FORTH, and describes some very archaic CPU architectures, but I found it fascinating because it builds things from the ground up.
3. I'm not an expert in C but I thought header files shouldn't have code in them. The code should be in a .c file
4. Maybe move the code from USAGE into its own .c file.
At WHY2025, I gave a talk about the reasons why am working on this. See: https://www.youtube.com/watch?v=akzyyO5wvm0
I wrote a series of articles that can help in that kind of discovery: http://tumbleforth.hardcoded.net/
https://news.ycombinator.com/item?id=45039301
Forth can be beautifully and efficiently implemented in portable c++ using the using continuation passing style via the clang musttail attribute.
Have a look at Tails (not my project):
[1] https://github.com/snej/tails
It's already pretty efficient but I'm working on it to make it even more efficient so I can use it as some sort of primitive fragment shader for an art project. This Forth variant is intended to execute Forth Haikus, as defined by the Forth Salon website.