I feel like this might still be too high level. A better approach may be to teach by the example of writing a basic FORTH environment from machine instructions, then basic helpers written in the language, and working up from there.
Various types of better things can be added in once there's something to optimize.
Edit: I was probably thinking of this version that I likely read a couple years ago:
This is a how-to-write-a-FORTH tutorial that I wrote a few years ago. It's particularly nice that you get to see how various control structures are implemented, like IF, CASE and even comments!
The immediate reply covers my feelings for how the __introductory__ class should proceed: minimal assembly and maximum programmer clarity.
""
rsaarelm on Jan 28, 2017 [-]
Working through Jones Forth got me up to speed on both understanding how Forth works and getting my hands dirty with some practical assembly coding.
Once I got a better idea of Forth, I also realized that Jones stays in assembly for rather long. He builds up the entire interpreter from raw assembly words, because you need the interpreter to start parsing textual Forth source. But you if you could somehow write Forth before the interpreter is put together, it would be quite natural to switch to Forth much earlier. And it turns out you can do that. Jones even defines the `defword` macro. But for some reason he makes very little use of it. Rewriting most of the code leading up to INTERPRET using defword was a fun exercise.
The next step would've been making the whole system bootstrapping by rewriting the assembler in Forth, but x86 machine code generation is hairy enough that I bailed out at this point.
""
Various types of better things can be added in once there's something to optimize.
Edit: I was probably thinking of this version that I likely read a couple years ago:
https://news.ycombinator.com/item?id=13505285
Quoting their post
"" rwmj on Jan 28, 2017 [-]
This is a how-to-write-a-FORTH tutorial that I wrote a few years ago. It's particularly nice that you get to see how various control structures are implemented, like IF, CASE and even comments!
Part 1: http://git.annexia.org/?p=jonesforth.git;a=blob;f=jonesforth...
Part 2: http://git.annexia.org/?p=jonesforth.git;a=blob;f=jonesforth...
(github mirror: https://github.com/AlexandreAbreu/jonesforth/blob/master/jon... https://github.com/AlexandreAbreu/jonesforth/blob/master/jon... )
Previous HN comments: https://news.ycombinator.com/item?id=10187248
""
The immediate reply covers my feelings for how the __introductory__ class should proceed: minimal assembly and maximum programmer clarity.
"" rsaarelm on Jan 28, 2017 [-]
Working through Jones Forth got me up to speed on both understanding how Forth works and getting my hands dirty with some practical assembly coding.
Once I got a better idea of Forth, I also realized that Jones stays in assembly for rather long. He builds up the entire interpreter from raw assembly words, because you need the interpreter to start parsing textual Forth source. But you if you could somehow write Forth before the interpreter is put together, it would be quite natural to switch to Forth much earlier. And it turns out you can do that. Jones even defines the `defword` macro. But for some reason he makes very little use of it. Rewriting most of the code leading up to INTERPRET using defword was a fun exercise.
The next step would've been making the whole system bootstrapping by rewriting the assembler in Forth, but x86 machine code generation is hairy enough that I bailed out at this point. ""