Which Forth to start porting from?

Question

I'm looking to develop a new Forth system, aimed at making game development easier on one or possibly several retro console platforms. I'm something of a Forth beginner, and need your help deciding which Forth codebase to start porting from.

I'm basically looking for the merits / disadvantages of particular Forths vs each other. I've read the source to JonesFORTH as well as both praise and criticism of it, and discussions on ANS forth, and have unfortunately been left feeling rather confused. The Forth community, from what I can tell, seems to be fairly brutally divided along the standards-compliance issue, with very good arguments made by both camps as to why the standard is both a good, and a terrible, thing. However I cannot seem to find good practical advice on what exactly the standard changes, other than a general sense that it makes things more complicated and bloaty than they perhaps need to be.

I'm hoping to make development easier for programmers and hobbyists currently scared off by the prospect of developing in assembly or C, so I'm leaning towards a more simple Forth, but I really don't know enough about Forth yet to make an educated decision.

Answer 1

I'm kind of where you are right now. I've been casually reading up on Forth for a while and also think it has a lot of potential--maybe for scripting too. However, I am nowhere near an authority, but here are my thoughts.

First of all, Forth seems to be the ultimate programmable programming language--even more than lisp. To that end, I'm not sure how much C or assembly you'll need to code. I was leaning more towards developing vocabularies in Forth itself. After all, that's how it's supposed to be used.

Second, of the implementations I've tried, I like Gforth and Pforth the best.

Which ones are you using?

Finally, here is a list of online forth reading I've discovered:

Starting Forth

Thinking Forth

Forth Primer

Forth Language

Forth Tutorials

Pforth Tutorial

Gforth Manual

Begin Forth

Forth Links

WikiForth

OLPC Forth

Lets Build a Compiler

Jones Forth

Have you found any others?

Answer 2

A basic Forth system is very small and can quickly be implemented. I think the following page will be very useful for you: "A sometimes minimal Forth compiler and tutorial for Linux / i386 systems". It is a linear tutorial on bootstrapping a Forth system!

Be sure to implement the defining words (words executing at compile time). That is where the power of Forth comes from; making it truely extensible.

I haven't actually tried it, but I once settled for bigFORTH as it is one of the few Forths with an open source license. It is also actively maintained; for instance there was a release earlier this year.

I have collected a set of annotated links about Forth over the past few years. Some of it is hard to find stuff.

Regarding the standards talk: this is a 20 year old discussion. I think it is more important to actually do something instead of talking: implement software, provide killer examples, writing documentation, invite other to participate, etc. Charles Moore has since moved on and done Forth chips, machineForth and ColorFORTH. If you search for "machineForth" and "ColorFORTH" in the annotated list of links it is possible to find some interesting articles and statements. Charles Moore also has a blog now.

Answer 3

I recommend hunting up eForth, the one Ting wrote. Kind of a modern FIG forth in some ways. He has a kernel written in C, but eForth kernels/systems have already been ported to many platforms/cpus most have assembly kernels/cores. However, there's this cool kinda-forth called Factor. It started out as 'just for games' and ended up in a wild and fun corner of the programming language world

Answer 4

One thing you might want to try as a first step is to write a Forth interpreter in some higher level language like Java, C++, Python, etc. It will lack the main benefits of a machine-level Forth: speed and compactness, but by writing your own virtual machine, you'll gain an understanding of the different types of threading, etc., used in various flavors of Forth.

Most new Forth implementations are basically started by looking at the CPU as a virtual machine anyway -- so making an explicit virtual machine is not knowledge wasted when it comes times to move from an interpreted version to a machine-code version. Also, you'll have a blueprint of your own code to cross-reference when building the machine version.

If, however, you are really, really comfortable with machine code, you can probably skip the above step and just port one of the standards directly.

As far as standards, I'd pick some standard, but stay minimal to start with. If you need to go beyond a standard in terms of things other than user-defined words, you can always grow towards that -- either standard or non-standard -- as implementation needs dictate. One of the coolest things about Forth is that it's so simple you can re-write the entire compiler easier than you can re-write some of the Forth code you'll be running on it, lol.