To anyone else interested in really understanding forth, Brad Rodriguez's "Moving Forth" series is the best I've ever read (and I don't imagine much has changed since), including a great explanation on "DOES>", widely regarded as the most difficult part of the forth kernel. You can read it online here:
Nice! Writing a Forth in 8086 assembly was how I got into programming as a teenager too (my Dad had been into Forth as a hobby for a long time). It was a great way to start -- a Forth compiler/system is relatively simple to build yourself from the ground up. https://github.com/benhoyt/third
I don't really know forth, but it seems like people who learn it really like it; can someone give me a high-level explanation to while it's easier to write Forth instead of C for low-level programming?
I haven't written a Forth, but have read a lot about it.
Essentially you start out writing some assembly definitions as named routines and once those are defined you start using that. Forth doesn't have a compiler in the traditional sense. Rather it has a dictionary with stored definitions that you either run from or add to. Besides that, your main data structure is the stack. So your code reads from the stack, does some calculation, returns data to the stack, and calls the next word. This can be very powerful as the implementor can truly understand the entire language. Who can say that about C, Python...etc? With that being said, the whole thing is super Spartan, so unless you implemented a feature, it isn't there. So although Forth is cool, the scientific work I do with matrices would require me to rewrite all of that in my Forth, so it would be a non-starter. Forth really shines for hardware work in my opinion.
Look at JonesForth as an intro to building your own Forth, and Leo Brodie's books on how to use Forth. Every Forth system written probably shares the same core design, but they are all different and as unique as snowflakes. Look at 8th as an example of a very affordable commercial Forth based language written by one man that can cross compile to Windows, Linux, BSD, Mac, Android, & iPhone , has a built-in GUI, encrypted binaries, is pretty speedy and well supported with a small but happy user base. It is an interesting point that there are few languages with that level of features and stability that are not made from the work of lots of people.
In addition to other comments, as I understand, bootstrapped Forth and similar languages usually compile down to code that is not optimal speed-wise, but a lot more compact that usual, because it's basically all CALL instructions (i.e. every word definition defines a function, and every use of the word inside the definition is a call to the corresponding function). This can be a desirable trade-off when you're dealing with a platform that has, say, 8 kilobytes of RAM to work with for all your code.
> (i.e. every word definition defines a function, and every use of the word inside the definition is a call to the corresponding function)
Yeah, which supposedly brings one of the big downsides of Forth, which is that one easily ends up with a program that has been refactored too aggressively into smaller words.
Since you can bootstrap it in assembly and then gradually build up from there, you don’t need a compiler. The only platform specific code is the little bit of assembly used to get the most basic Forth words up and running, and then you can build everything with those building blocks, oftentimes on the target machine itself. In that regard, writing Forth feels like a combination of Lisp and assembly.
I wouldn't say it's easier to write Forth than C, but it's definitely more suited to resource-limited 8-bit systems with very little RAM.
IMHO Forth is more like an even more reduced Lisp, a "reverse Lisp" if you want, because of Forth's stack architecture (instead of (+ 1 2) in Lisp to add the number 1 and 2, you would write "2 1 +" in Forth, this puts the numbers 2 and 1 on the "stack", and then executes the word "+", which takes the topmost 2 numbers from the stack, adds them, and puts the result back on the stack.
So you get many advantages of Lisp (building complex programs incrementally from very simple building blocks), but in a much more reduced package which can even run on 8-bit computers with just a few KB of memory.
It's way easier to bootstrap a Forth interpreter on a weird, restricted system like a calculator than, say, a C compiler. You can't run a C compiler on a TI graphing calculator but a self-hosted Forth is totally non-insane thing to run on one.
RPN is Forth-like in that they're both stack based. Their 28/48/49/50G line shipped with RPL(Reverse Polish Lisp) which was heavily inspired by both Forth and Lisp. Very weird language but I always enjoyed programming those calculators.
The ancient HP41 and HP71 did have Forth interpreter ROMs available.
Can someone clear up how to refer to Forth? I’ve heard “a Forth”, “your Forth”, and just “Forth”, and the title says “Forth-Based.
My best guess is it’s “a Forth” because you’re implementing a new language yourself, in the style of, but distinct from, the original Forth programming language. Is this correct?
With Forth there are a handful of core words you really need to get things going, some ubiquitous but not mandatory convenience ones, and then it's up to what best fits the platform. There is no such thing as "the" Forth.
Isn't Lisp just the same?
The TI-84+ series is such a specific technological niche that it makes sense to write a Forth customized for it platform, which the author of this OS did earlier[0]. This repo is an OS though, so "Forth-based" means the OS is built on a Forth platform but with enough extra features that it is more than just a Forth language at this point.
Also, arguably, the part where it is compiled through Scheme might make the purists say it's not a true Forth (which tend to be self-hosting).
Most Common Lisp folks have hijacked the word "Lisp" to mean Common Lisp.
Then you have Lisp-1 and Lisp-2 definitions, so when you say "a Lisp" people will wonder which you fall into, and it'll be one of the first asked questions.
Depending on your audience, they may have a very fixed idea what "Lisp" means, and it may be a very detailed concept.
You would not learn nearly as much from that. This is analogous to '17 year old builds car' and then going 'wouldn't it be easier to just buy a Toyota?'. Sure it would be easier, but this was never about ease.
Very happy to see young people still fooling with this stuff, despite the ubiquity of smart phones etc.
I just uploaded the code to github: https://github.com/hoytech/tiforth
To anyone else interested in really understanding forth, Brad Rodriguez's "Moving Forth" series is the best I've ever read (and I don't imagine much has changed since), including a great explanation on "DOES>", widely regarded as the most difficult part of the forth kernel. You can read it online here:
https://www.bradrodriguez.com/papers/index.html
Also I have to confess I stole the division routine for my forth from Brad's CamelForth: https://github.com/hoytech/tiforth/blob/master/forth.z80#L50...
Quickly looking it over I notice I used m4 as the macro-expander (haha I've since grown out of that).