Thinking about the amount of thought and energy that went into this, back in 1987 -- mostly preinternet, pre-AI. Damn.
I feel really lucky that we get to build on things like this.
There's a great 1986 book "Designing and Programming Personal Expert Systems" by Feucht and Townsend that implements expert systems in Forth (and in the process, much of the capability of Prolog and Lisp).
Ha,you beat me to it! That book was my first thought when I saw this post. I have a copy sitting here on my bookshelf.
Just to expand on how bonkers this book is... they assume that everyone has easy access to a Forth implementation. So they teach you how to build a Lisp on top of it. Then they use the Lisp you just built to build a Prolog. Then, finally, they do what the topic of the book actually is: build a simple expert system on top of that Prolog.
I love it!
To be fair, in the 1980s thanks to the Forth Interest Group (FIG), free implementations of Forth existed for most platforms at a time when most programming languages were commercial products selling for $100 or more (in 1980s dollars). It's still pretty weird, but more understandable with that in mind.
Forth is so interesting.
I've been doing a lot of Forth lately; it's a kind of weird language, and it makes your brain think in a way that is very different than basically any other language out there. It allows you to work at effectively any of level of code, and allows you to easily "lift" low level code into high level.
I've been on/off developing a Forth for the NES. It mostly works, but it's still pretty buggy and I'm still learning how the PPU works so graphics will often get corrupted for things that are non-trivial, but even despite that, I was flabbergasted at how easy it was to get a Forth built for it, and even the decent performance I've been able to get when I compile it.
I don't know that I have much desire to write Forth on modern hardware, but I am still glad I learned it just so I can work at a lower level in a high-ish level language, and I do think that "learning to think in Forth" is a skill that is something most developers should do.
I assisted a graduate student a long time ago in his implementation of the Warren Machine for compiling Prolog. At its core it was essentially a threaded interpreter.
Edit: I'm a silly-billy who doesn't know what words mean. https://en.wikipedia.org/wiki/Threaded_code is not a bad description of a large WAM program, although =/2-inlining and peephole optimisation will turn some procedure clauses into quite sophisticated collections of pattern-matching and unification instructions, which represent a non-trivial computation. Does a tight loop operating over linked lists still count as threaded, if it used to be a tail-recursive procedure call? Or does the term refer instead to the program as a whole? (Probably the second one.)
---
I thought WAM was single-threaded? It does a lot of trickery to simulate "fork, wait, and either kill parent or child" with no copying and minimal rollback, but most of that trickery relies on the absence of threading, and will explode in the presence of such hubristic assumptions as "once we've returned from a procedure, the old stack frame is freed and its memory can be re-used", "a clean-up procedure will be run when we drop objects", and "clean-up procedures do not need to be run when we drop objects".
I would be interested to see approaches that make it work in parallel. Even cheating with Unix and COW would be interesting: since Prolog predicates can have side-effects, a cut in an earlier branch would retroactively cancel the later branches you've eagerly executed in parallel. You'd either have to deal with that somehow (maybe with IO monads?), or invent some notion of (dependent?) purity and then ensure procedures in the dynamic procedure database remain correctly tagged with their purity, transitively (i.e., including all possible callees, unto the deepest generation). I'm not confident the speed-up would be worth the overhead, for most programs.
Threaded interpreters are different than multithreading:
Very interesting stuff. Apparently this is the implementation: https://github.com/dicpeynado/prolog-in-forth
Thinking about the amount of thought and energy that went into this, back in 1987 -- mostly preinternet, pre-AI. Damn.
I feel really lucky that we get to build on things like this.
There's a great 1986 book "Designing and Programming Personal Expert Systems" by Feucht and Townsend that implements expert systems in Forth (and in the process, much of the capability of Prolog and Lisp).
Ha,you beat me to it! That book was my first thought when I saw this post. I have a copy sitting here on my bookshelf.
Just to expand on how bonkers this book is... they assume that everyone has easy access to a Forth implementation. So they teach you how to build a Lisp on top of it. Then they use the Lisp you just built to build a Prolog. Then, finally, they do what the topic of the book actually is: build a simple expert system on top of that Prolog.
I love it!
To be fair, in the 1980s thanks to the Forth Interest Group (FIG), free implementations of Forth existed for most platforms at a time when most programming languages were commercial products selling for $100 or more (in 1980s dollars). It's still pretty weird, but more understandable with that in mind.
Forth is so interesting.
I've been doing a lot of Forth lately; it's a kind of weird language, and it makes your brain think in a way that is very different than basically any other language out there. It allows you to work at effectively any of level of code, and allows you to easily "lift" low level code into high level.
I've been on/off developing a Forth for the NES. It mostly works, but it's still pretty buggy and I'm still learning how the PPU works so graphics will often get corrupted for things that are non-trivial, but even despite that, I was flabbergasted at how easy it was to get a Forth built for it, and even the decent performance I've been able to get when I compile it.
I don't know that I have much desire to write Forth on modern hardware, but I am still glad I learned it just so I can work at a lower level in a high-ish level language, and I do think that "learning to think in Forth" is a skill that is something most developers should do.
I assisted a graduate student a long time ago in his implementation of the Warren Machine for compiling Prolog. At its core it was essentially a threaded interpreter.
Edit: I'm a silly-billy who doesn't know what words mean. https://en.wikipedia.org/wiki/Threaded_code is not a bad description of a large WAM program, although =/2-inlining and peephole optimisation will turn some procedure clauses into quite sophisticated collections of pattern-matching and unification instructions, which represent a non-trivial computation. Does a tight loop operating over linked lists still count as threaded, if it used to be a tail-recursive procedure call? Or does the term refer instead to the program as a whole? (Probably the second one.)
---
I thought WAM was single-threaded? It does a lot of trickery to simulate "fork, wait, and either kill parent or child" with no copying and minimal rollback, but most of that trickery relies on the absence of threading, and will explode in the presence of such hubristic assumptions as "once we've returned from a procedure, the old stack frame is freed and its memory can be re-used", "a clean-up procedure will be run when we drop objects", and "clean-up procedures do not need to be run when we drop objects".
I would be interested to see approaches that make it work in parallel. Even cheating with Unix and COW would be interesting: since Prolog predicates can have side-effects, a cut in an earlier branch would retroactively cancel the later branches you've eagerly executed in parallel. You'd either have to deal with that somehow (maybe with IO monads?), or invent some notion of (dependent?) purity and then ensure procedures in the dynamic procedure database remain correctly tagged with their purity, transitively (i.e., including all possible callees, unto the deepest generation). I'm not confident the speed-up would be worth the overhead, for most programs.
Threaded interpreters are different than multithreading:
https://en.wikipedia.org/wiki/Threaded_code
https://archive.org/details/R.G.LoeligerThreadedInterpretive... - book on the topic