Gforth 1.0

Posted by joshcsimmons 2 days ago

Comments

Comment by Hendrikto 2 days ago

Some sorely needed context:

> [Gforth is] a free, fast, featureful and portable implementation of the Forth 2012 language.

> Gforth runs under GNU, BSD, and similar systems, MS Windows and MacOS X and should not be hard to port to other systems supported by GCC.

Comment by daitangio 2 days ago

If you love HP-RPN calculators, you may love Forth as well. Forth is a very interesting language, I find it a bit too complex for my little brain but give it a spin if, you have 2 free hours

Comment by jacquesm 1 day ago

It's not complex, it is just that it requires a different mental model because of the lack of named parameters. Stack offsets are harder to remember than things with names, more so because they change all the time as you push and pull data.

Comment by MaxBarraclough 1 day ago

Like many languages, Forth can get complicated if you really get into the weeds. These 2 papers [0][1] (both by one of Gforth's creators) illustrate the sorts of intricacies you can run into. The trickier subtleties have to do with Forth concepts like interpretation and compilation (which have their own meanings in Forth), and have little to do with Forth's use of stacks.

In Forth's defence, other languages also have tricky subtleties, e.g. C++. Neither language prioritises theoretical purity, of course. They would be very different languages, with different drawbacks and advantages, if they did.

Both papers touch on whether the behaviours of certain unusual Forth constructs are well-defined according to the ANS Forth language standard. This sort of discussion should be quite familiar to C++ programmers.

[0] State-smartness - Why it is Evil and How to Exorcise it (Ertl, 1998) http://www.euroforth.org/ef98/ertl98.pdf

[1] State-smartness: Applications, Pitfalls, Alternatives (Ertl, 2001) https://www.complang.tuwien.ac.at/papers/ertl01state.pdf

Comment by jacquesm 1 day ago

I just implemented an ANSI compatible Forth so I'm reasonably familiar with those nasty bits, the 'DOES>' and 'DEFER' words in particular were interesting and caused me to have to rewrite some stuff that I had assumed was already stable.

Comment by mitxela 1 day ago

For me, the most interesting thing about Forth is it's "thin-ness". Getting from machine code to a Forth REPL can take about 4 kilobytes.

Comment by jnpnj 1 day ago

Same, people often described it as the lisp of assembly. You get a lot of freedom of abstraction over almost direct bare metal.

Comment by sramsay 1 day ago

Yes. Or "Lisp for hardware nerds." ;)

Comment by jacquesm 1 day ago

Exactly, and if you build your inner interpreter properly it is wicked fast.

Comment by fallat 1 day ago

The standard library is lacking some really nice conveniences. I'm working on correcting this and teaching Forth as a "grassroots" language for people who want to go back to the joy of programming as an art. The 100rabbits folks have already done a lot of work around proliferating that idea but I want to work outside of the Uxn machine that they use. Mark my words, us programmers are not phased by AI stealing the joy of programming :) The day job business programming, sure. But that was only fun sometimes. Forth will continue to exercise our brains and work through logic and data flow problems - skills we can bring to guiding agents for the day job.

Comment by vanderZwan 1 day ago

Since you're working on your own thing that may or may not be like a traditional Forth at all, and also mention Uxn, you might find some ideas in Ben Bridle's Bedrock worth stealing:

https://benbridle.com/projects/bedrock

In particular the reasoning for what he changed compared to Uxn might be insightful:

https://benbridle.com/articles/bedrock-differences-from-uxn

Comment by MaxBarraclough 1 day ago

> Mark my words

We will also compile them, and reference their execution tokens from the dictionary.

Comment by fallat 1 day ago

Hahahahaha, nice one!

Comment by isr 1 day ago

Have you considered factor? Its from the joy-inspired branch of the forth/concatenative family, but its a heavily underrated, batteries included language. Which has a bit of a smalltalk feel given its image-based deployment and the "live" nature of its tools (graphical repl, object inspectors, etc)

Comment by MaxBarraclough 1 day ago

Factor looks like a more conventional language, with dynamic typing, automatic memory management, etc. It sounds quite far from Forth's roots as a compact assembly sequence that enables interpretation of a minimal language just barely atop the bare metal.

fallat said they were interested in teaching a 'grassroots' language. By that I think they mean something with a minimal core language and compact interpreter, so Forth seems like the better fit.

Comment by fallat 1 day ago

Yep. You've nailed it

Comment by jacquesm 1 day ago

I just did a big project using Forth and it is every bit as useful as it was in the past. Yes, there no security model, and you're going to have to work to manage your project, no fancy IDE or editor. I took a piece of code I wrote in 1988 and built it out to pass the Forth standard core words test and some extensions as well, then added all of the Raspberry Pi io devices as primitives. This makes it a super useful little toolkit (6K loc, 0 dependencies) to build embedded systems with in the robotics space.

I did consider using Gforth and another one that Don Hopkins pointed me to but I the end the familiarity with my own code won out over first reading myself into a large project. It all worked pretty well, the device I built with it is performing way beyond my expectations and I'm really happy I chose Forth even though it is a choice that I think only very few people would have made because it feels so old-fashioned. What especially pleased me is the lack of superstructure and the ease with which the whole thing could be moved between machines of varying word-size and underlying CPU architecture.

Forth still has a place. Now I need to get my grubby hands on some GA 144s.

Comment by stephen_cagle 1 day ago

Not Forth, but if you want a game that kind of feels a little like the GA144 then you might be interested in TIS-100 https://store.steampowered.com/app/370360/TIS100/ .

Comment by jacquesm 1 day ago

Interesting. I just saw the GreenArrays website is down, that's not good news.

And what I meant was I want the actual hardware. I may have to make it myself.

Comment by anta40 2 days ago

Nice to see gforth is still being maintained.

BTW, on the other side, looks like gforth still lacks the ability to create native OS executable, something like:

gcc myprog.c -o myprog

Comment by nickcw 2 days ago

You may enjoy ccforth then which is a mostly gforth compatible compiler which compiles to native via C.

https://github.com/ncw/ccforth

I wrote it as an experiment in having both a forth interpreter and compiler running at the same time.

Comment by lebuffon 1 day ago

Whoa! That is a really nice piece of work. Congrats!

Comment by jan_m_savage 2 days ago

That’s because Gforth is a threaded-code VM that saves dictionary images rather than compiling to native code.

As you prolly know, Forth blurs compile time and run time in general, and there’s no so-called clean compile, then link boundary like in C.

SwiftForth, VFX Forth, and iForth do emit real executables, and there are smaller native-code Forths for Linux too, but then the opportunity cost is losing Gforth’s portability and its standards-heavy library ecosystem.

Comment by MaxBarraclough 1 day ago

> That’s because Gforth is a threaded-code VM that saves dictionary images rather than compiling to native code.

That's not correct. Gforth features a JIT compiler, although they don't call it that, they call it dynamic superinstructions. It will be enabled if you run gforth-fast. If I understand correctly, the native code sequences are always generated at runtime, and cannot be baked into an image file.

• Dynamic Superinstructions https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Dyn...

• [PDF] Code-Copying Compilation in Production An Experience Report (2025) http://www.euroforth.org/ef25/papers/ertl.pdf