The funniest thing is, you can easily write and invent your own control structures in Forth, as well as change the behavior existing ones such as the do/while loop.
\ alter the behavior of do by printing the current index in each loop.
: do immediate
[COMPILE] do \ first compile previous do impl.
' i , \ then print current index
' . ,
;
Not really. Many implementations indeed do that, but only in pursuit of performance - the weakness of interpreted languages is speed. Otherwise one can just implement it as a bytecode interpreter, like e.g. Lua.
heap []any
It greatly helps conceptualizing computation and what's truly essential at it's core.
FORTHs are fun to write. they'll teach you a lot about ruthless simplicity
i don't think FORTH is useful for large programs, but that's not the point of the language
DSL is probably not quite the right word, it could be but generally I think it is still going to be fairly Forth like, but you need to think of it that way. You layout what your program does and then reduce it to a few dozen words which work as a description language for the program, then maybe a 100 more words which those words require along with any glue and together all constitute a reasonably sane language. Then you start from the bottom up and implement all those words. The big trick is having the foresight required to pick the function of each of those hundred odd words well enough that no one will ever have to dig into the the 1000 odd words below that it took to implement them. It really forces you to think about how your program may evolve and the bugs which may crop up, you can't change one of those low level words without affecting all that are built on it and if you do the easy work around things start to get messy.
Not sure how well I explained that, I am no Forth expert but I am getting better.
If anything goes wrong during development you need that model of the stack in your head to debug- I think that's the main differentiator, and if you had a typed forth with local variables, it would enable greater readability ie. I can scan the individual words/ functions without needing that stack model.
Just my POV, not sure if that resonates?
Forths can also have types but it is slightly different, gforth has a float stack with its own commands and you can implement others and any other feature you want.
Once you get used to working global and without type it gets surpringly easy, it is more difficult for me to work with type and scope than without and when I use something like C I am constantly fighting it and feel like erything is needlessly complicated.
and that's why we don't hear from them anymore
((One W. Shakespeare Romeo and Juliet.))
https://archive.org/details/R.G.LoeligerThreadedInterpretive...
https://archive.org/details/mastering-forth-by-anderson-anit...
I've recently been working on a project to lower the barrier to entry for budding language designers. The language is strictly prefix, but could easily be turned into postfix with minor changes.
The idea is to use it to drive an LED matrix and have a simple web UI to develop "fragment shaders" in Forth. It's developed as part of the Lwan project, although currently it generates GIF files on the fly rather than drive a LED matrix.
The source code is here for those that want to play with it: https://github.com/lpereira/lwan/tree/master/src/samples/for...
[0] One of my odder Forths was fs4th, FileSystemForth. It was implemented with Bash aliases and variables, the stacks were just paths, there was a directory called stack and in it there were numbered directories to represent the stack and what you pushed and popped onto the stack were files. It was a weird way to work with files but I could see it having niche uses. I also made a more normal Forth in Bash as a quick project to refresh my Bash skills.
See this repository for a tutorial-approach to building a minimal forth-like language, in golang:
Here is Grok's scheme to make Forth more readable:
Below is a Forth implementation of a simple parser that transforms
(. (+ 1 2)) into 1 2 + . and executes it. This assumes the input is
provided as a string or entered interactively, and the parser outputs
the transformed Forth code to the input stream for execution.
\ Buffer to store transformed output
20 CONSTANT BUF-SIZE
CREATE BUF BUF-SIZE ALLOT
VARIABLE BUF-PTR
: INIT-BUF ( -- )
BUF BUF-SIZE ERASE
0 BUF-PTR ! ;
: ADD-TO-BUF ( c -- )
BUF-PTR @ BUF-SIZE < IF
BUF BUF-PTR @ + C!
1 BUF-PTR +!
ELSE
." Buffer overflow" ABORT
THEN ;
: PARSE-EXPR ( addr u -- )
INIT-BUF
BEGIN
DUP 0> WHILE
OVER C@ CASE
'(' OF DROP 1 /STRING ENDCASE \ Skip (
')' OF DROP 1 /STRING ENDCASE \ Skip )
'.' OF BL ADD-TO-BUF '.' ADD-TO-BUF BL ADD-TO-BUF
DROP 1 /STRING ENDCASE
'+' OF BL ADD-TO-BUF '+' ADD-TO-BUF BL ADD-TO-BUF
DROP 1 /STRING ENDCASE
BL OF BL ADD-TO-BUF DROP 1 /STRING ENDCASE \ Handle spaces
ELSE
DUP ADD-TO-BUF \ Copy number characters
DROP 1 /STRING
ENDCASE
REPEAT
2DROP ;
: EVAL-EXPR ( addr u -- )
PARSE-EXPR
BUF BUF-PTR @ EVALUATE ; \ Execute the transformed string
\ Example usage
: TEST ( -- )
S" (. (+ 1 2))" EVAL-EXPR ;
TESTWriting a new Forth may be an interesting project, but you will not write a good one until you have a few applications under your belt. Forth is a very subtle language. The internet is full of abandoned Forth kernel projects. Many of these may well have succeeded if they had a purpose that was not yet satisfied.
It is perfectly possible to write large applications in Forth. One of our clients has an application of 1.4 million lines of Forth source code. It is hosted on VFX Forth, which compiles Forth to native code. The VFX version runs at least ten times faster than the previous threaded code version, built on MPE's ProForth compiler.
It's a sort of silly trivial example... but I've watched multiple python codebases slowly become unmaintainable because Python has no way to enforce what can be called or overridden by instances or subclasses, and the org grew beyond its ability to enforce discipline about it in code review.
I feel like Forth would offer orders of magnitude more "temptations" for somebody who just needs to get something done, but I've never seen it done at scale.
I used words like IMMEDIATE and POSTPONE to create words that create words. I quickly get lost doing that, though.
Forth is very very cool to play with. Pragmatically, virtually any other language is better.
jshprentz•4d ago
In January 1979, Byte Magazine's Language Forum contained the article, "IPS, An Unorthodox High Level Language."[1] The article described IPS, a language based on Forth, but with the word names translated to German. Thus, Forth's SWAP became VERT, short for vertauschen. The intriguing article concluded with a reference to Charles Moore's 1974 paper, "FORTH, a New Way to Program a Minicomputer,"[2] which was discussed on HN in 2022.[3]
I had recently assembled a Quest Electronics Super Elf computer[4] with an expanded memory size of 4 KB. The IPS article mentioned implementations under 6 KB for 8080, 6502, and RCA COSMAC microprocessors, so I thought Forth might fit. The Super Elf included an 1861 video display controller chip, with a resolution of 64 x 128 pixels (big pixels!). I designed a font of 3 x 5 pixel characters to provide 21 lines of 16 characters. Good luck distinguishing M, N, H, U, and W without some context. I bought a (possibly surplus) keyboard from Radio Shack and screwed it onto a wedge of wood to achieve a usable typing angle.
Moore's paper described about 75 Forth words. I wrote them on index cards and jotted down Forth definitions or RCA 1802 assembly code. I wrote an 1802 assembler in Fortran to ease the conversion into 1802 machine code. I still have the printouts and punch cards in storage.
Development proceeded slowly. During a break at work, I would punch my assembly code for a few Forth words, run the assembler, and bring home the printout. That night I would load previous work into the Super Elf from cassette tape, key in the new words (and changes) via the Super Elf's hex keypad, and save back to another cassette tape. Then I would test the new Forth words and note any changes needed on the printout. Lather, rinse, and repeat until, at last, it all worked.
The finished Forth system consumed a little more than 3 KB of the 4 KB of memory. User programs, data, and Forth stacks occupied the remaining memory. The R key stuck. The @ symbol was a 3 x 5 pixel blob (this is the very important Forth memory fetch operator). But it worked!
I demonstrated the system at the local personal computer club--spun off from the local ham radio club. Based on their enthusiasm, I advanced to developing tinyForth[5] for the TRS-80, a story for another day.
[1] https://archive.org/details/BYTE-MAGAZINE-COMPLETE/197901_By...
[2] https://articles.adsabs.harvard.edu/pdf/1974A%2526AS...15..4...
[3] https://news.ycombinator.com/item?id=33134663
[4] https://www.oldcomputermuseum.com/super_elf.html
[5] https://archive.org/details/80-microcomputing-magazine-1980-...
throwaway71271•1d ago
I started writing forth few months ago, wrote few interpreters, with jit or with types etc, and its just amazing, I think anyone should do it. TBH I don't think any other exercise has thought me as much about programming as this.
I also notice the "return" of Forth, as it is probably the easiest high level language to make for computers with addressable memory and fetch execute cycle. The parser is just few lines of assembly and of course you can write the parser in the inner interpreter's bytecode, you don't even need assembly :) So hobbyists can just "make it" and make their own tiny operating systems with it. Of course everyone makes their own dialect, but I think thats OK. Things like https://github.com/howerj/lfsr LFSR CPU/VM running Forth, or UXN or duskos/collapseos.
Now you can also use language models to help you onboard into the language, it do some practice programs and rewrite one program in many ways.
So if you are young or old and never tried to Forth, don't miss out, its super fun.
anthk•1d ago
0x445442•1d ago
rwmj•1d ago
However if you're creating your own computer from scratch or have other artificial constraints (like it needs to fit into a boot sector[1]), and if you want to really understand precisely how your language works down to the lowest level detail while still having high-ish level constructs, then Forth is the ideal small language for that.
[1] https://github.com/cesarblum/sectorforth
anthk•1d ago
pjmlp•1d ago
rwmj•1d ago
Jach•1d ago
In C this might look like (again in reverse order):
That is, if you program the C in a similar procedural style that closely follows the physical function of the device. It's maybe more common to express similar C code in a state machine style, in which case it'd look a lot different.Is the Forth version actually worth it? To me the C is "good enough", and more explicit or at least clearer as I'm familiar with C. Where Forth could win me over is in its ease of having a truly interactive environment to iteratively develop the software via a REPL, much like Lisp. (But then I'd rather just use Lisp.) My embedded systems hobby work for the last 10+ years has all been really simple, though, so interactivity isn't a big enough advantage to just using C. (When working with hardware, it's somewhat exciting to stick a pin in a breadboard and move it between power and ground to toggle a motor. It'd be even more exciting to do this interactively via REPL commands poking at memory.)
cap11235•1d ago
lxdesk•1d ago
1. Assembly coding within a REPL. Forth supports "load-and-store" without the additional bookkeeping steps of assembly. Once the program works, it can be incrementally rewritten into the assembly if needed, or used to bootstrap something else. Historically this is probably the single biggest usage, because the language works as a blunt instrument for that within the standard wordsets. Lots of programs on the early micros shipped with code that was developed with Forth, but with the Forth interpreter discarded at the last step; and where there is novel hardware and novel applications, Forth tends to come up as the bootstrap.
2. Minimal-dependencies coding. For the same reason that it's a good bootstrapping tool, Forth ends up being portable by assuming nothing. While different Forth systems are all subtly incompatible, the runtime model is small enough to wrangle into doing what you want. Stack machine VMs basically are "Forth with more sandbox and less human-readability".
3. "Big ideas" coding. The "human-readable stack machine" aspect means it's a useful substrate for language design - being programmable, you can shift the imperative interpreter model in the direction of new syntax and new general-purpose data structures, while still retaining a way to drop all the way down to assembly - the biggest downside is that this doesn't let you easily introduce existing library code, so bootstrapping from within Forth would take a long time and you would most likely get stuck on trivial string processing. But Forth as the second of a two-step process where you "compile to Forth" using something more batteries-included is actually pretty reasonable as an alternative to generating a binary or designing an original VM.
entaloneralie•1d ago
I program in forth for a living, and that has been one of my favourite advantage, multiple returns without unecessary re-bindings.
kragen•1d ago
entaloneralie•1d ago
kragen•18h ago