A couple of months ago I wrote a Forth interpreter, because I'd always wanted to. I haven't really used it in anger, but passes the basic ANS Forth tests, so it should be reasonably complete.
(It's here: https://github.com/EtchedPixels/FUZIX/blob/master/Applicatio... It's a single, portable C file which is also an executable shell script containing an awk script! It compiles to about 8kB of code on a microcontroller.)
From the experience I learnt two main things about Forth:
(a) the realisation of how Forth works, and the way in which the language bootstraps itself out of nothingness, and the way in which it takes about two basic principles and then builds an entire language out of them, is truly mind expanding. The process was full of 'aaah!' moments when it all came together and I realised just how elegant it was.
(b) actually engineeri
Read the rest
ng a Forth interpreter, and dealing with the ANS spec, was an exercise in frustration. Those elegant principles are compromised at every stage of the process. The spec defines things which no sane person would define. I'd implement a word, and it'd be clean and work, and then the ANS tests would fail and I would realise that the specification dictates a particular half-arsed implementation which makes no sense whatsoever. The process was full of 'uuugh!' moments when I saw a thing in the spec and realised how much more complicated it would make my life.
Examples follow:
- double words are pushed onto the stack in high word / low word order. Regardless of whether your architecture is big or little endian. Good luck with using 64 bit load/store instructions!
- DO...LOOP is defined to use the return stack for temporary storage. Valid Forth programs can't call EXIT from inside a DO...LOOP structure. If you try, your program does a hyperspace jump and crashes.
- BEGIN...REPEAT is defined not to use the return stack for temporary storage. Valid Forth programs are allowed to call EXIT from inside a BEGIN...REPEAT structure.
- DO...LOOP has different termination characteristics depending on whether you're counting up or down.
- Mismatched control flow structures are not just not detected, but they are actually, in certain combinations, defined to work. The spec actually defines what some of them do --- IF, THEN, BEGIN, WHILE, REPEAT, if I recall correctly --- and lets you mix and match them. Good luck if you want to use different, more efficient implementations.
- The memory model assumes that Forth is the sole owner of the memory. It starts at the bottom and works up. When compiling a word, you have to decide what address it's being written to before you know how long it's going to be. Want to share the heap with something else? Good luck with that.
- Division. How overcomplicated can it be? Answer: extremely.
- Rearranging values on the stack gets old very, very, very quickly.
- Forth isn't typed! Except where it is, and it doesn't check them, and if you get them wrong my the gods have mercy on your soul, because the interpreter surely won't.
I would still say that anybody with any interest in programming should learn at least the basics of Forth, and should write at least the core of a Forth interpreter. (It won't take long, and you'll learn a hell of a lot.) But I'd be really hesitant about recommending it for real programming use, other than for the special niches where it excels, such as embedded systems. Most of the problem is that it's overspecified; it would be so much simpler, faster, and easier to understand if the spec had more undefined behaviour in it. I now understand why so many people just ignore it and write their own dialect. Strong type checking would really help, too.