RetroForth 2021.1

I did not find gforth or factor to be very easy to get up and running with.

If you want to learn forth concepts, you can build one yourself easily in any language (lots of examples), but Assembly or C are the most idiomatic as they allow you to get to a much lower level.

Every forth system is different, but they share a lot of design fundamentals. There are almost too many to count.

If you're okay with closed source, 8th has a very nice free version if you just want to get a hang of writing forth code in it. I usually recommend that one check out 8th as it comes with all the niceties of modern scripting languages and can cross-compile to a lot of systems, has GUI support, bluetooth, iPhone/Android, modern data structures, database support...etc.

It's also a bit confusing that most Forth systems were traditionally for embedded work. There are a few commercial offerings (SwiftForth and VxForth) for that. It used to also be extremely common to bootstrap new hardware with Forth as you got a full REPL so you could interactively interact with the hardware and test out each piece before a compiler like C could be ported to the system. I'm not sure how common that is now, but there are a lot of Forth systems that are pretty barebones compared to modern languages. You have to look around.

Factor is higher level with built-in support for lambdas (called "quotations") and a garbage collector and a ready made library. If traditional Forths are like C than Factor is like C#. You'll still get many of the same concepts but without the low-level friction that'll hamper you making fun things.

Probably the most straightforward thing to do is to learn and implement your own based on an early Forth like FIG Forth or Forth 83: http://www.forth.org/fig-forth/contents.html

http://forth.sourceforge.net/standard/fst83/

There are certain cosmological nuances of Forth that come through by the time you get to where you have bootstrapped IF ELSE - and while later Forths add more features(which is great for production uses) they aren't the essence of Forth, which is in the minimalism.

Factor is also so much different that it deserves another category, despite syntactic resemblance.

A few comments follow; note that I'm not unbiased :)

RetroForth is smaller and easier to build than gforth or Factor. I actively use it and seek to improve it, and I've been told the documentation is good, though I still feel I have a long way to go on that front. It's not a traditional Forth, but it works well for me. I borrow things from traditional Forth, colorForth, Factor, 8th, and other languages when I think they make sense for my needs. Releases are quarterly, with daily snapshots provided.

Gforth is big and I find it to be difficult to build from source. If you need or want a traditional/standard Forth, it's probably what I'd recommend if using one of the commercial ones isn't an option. Definitely build it from source though; the releases are infrequent and the development versions have a lot of bug fixes and improvements.

Factor is big, has lots of interesting stuff, but apart from stacks and colon decisions, really doesn't feel like Forth to me. It is under active development, but releases other than snapshots are very infrequent (last in 2018). Building from source isn't something I've done with this in years, and platform support is more limited (Linux, Windows, macOS, on x86 or x86-64). I've borrowed some ideas and terminology from Factor over the years and would consider it worth learning from.

I recommend studying a simple Forth implementation. rwmj wrote a tutorial/x86 implementation, now widely called Jonesforth:

Main x86 source to bootstrap minimal interpreter/compiler: https://github.com/nornagon/jonesforth/blob/master/jonesfort...

Further Forth definitions: https://github.com/nornagon/jonesforth/blob/master/jonesfort...

rwmj gave some background in comments on the HN story: https://news.ycombinator.com/item?id=10187248

Forth is sort of live image like Smalltalk, and great for designing languages/DSLs in like Lisp which is also homoiconic.

> Forth compilers can be bootstrapped from not-very-much assembler

Do you have any resources handy on how one could do that from scratch?

I think that very much depends on the Lisp in question. Even if you want a Scheme style Lisp which really needs some form of GC, you can implement a very rudimentary one using bump allocation. Basically just allocate memory by bumping the stack pointer and clear out everything at specific boundaries (i.e. you have some memory that is fixed at startup with the interpreter, basic functions, and constants but after that have well defined points where you clear out everything).

If you want something closer to assembly, you can just use a normal Lisp and have the Lisp compile itself to an assembly program, but with the benefit of things like variable names whatever other abstractions you can come up with. This approach is taken by Fairlylog[1] which is implemented in Racket but produces Verilog. You are basically writing a new language which compiles to assembly, but with the benefit of better tooling. Racket gives you the benefit of things like syntax-parse for writing the parser in a way that gives good error messages and more flexibility than a parser generator.

[1]: https://pkgs.racket-lang.org/package/Fairylog

Lisp surely can and has been.

Basically start with a s-exp based Assembler, add a macro support subset and go from there.

> Forth compilers can be bootstrapped from not-very-much assembler on an embedded system. That's not really true for Lisp and Smalltalk

Sectorlisp[0] is an attempt to make a lisp that can fit in a bootsector (512 bytes). It's currently ~1.5 bootsectors; larger than the smallest forths, but certainly in the same ballpark.

Stage0[1] is an attempt to make a boostrappable seed from a minimum of binary dependencies. I recommend taking a look at what it says[2] on the matter, though it's too long to quote here.

0. https://github.com/jart/sectorlisp

1. https://savannah.nongnu.org/projects/stage0/

2. https://git.savannah.nongnu.org/cgit/stage0.git/tree/README.... skip to ‘stage2’

And for those interested in an FPGA version with similar features, check out the J1 and J1B (32 bit) CPUs by James Bowman.

Remarkable machines in 200(ish) lines of Verilog.

It shows my email in the upper right, so it is signed in to something apparently.

That is correct.

I use FreeBSD and OpenBSD, the ports/packages for others are contributed by others.

The current ePub isn't put together right, so it just has headings for the pages and no actual content. You can find the docs in the archive as Markdown files.