[HN Gopher] Compiling Prolog to Forth [pdf]
       ___________________________________________________________________
        
       Compiling Prolog to Forth [pdf]
        
       Author : PaulHoule
       Score  : 86 points
       Date   : 2026-03-03 22:45 UTC (4 days ago)
        
 (HTM) web link (vfxforth.com)
 (TXT) w3m dump (vfxforth.com)
        
       | upghost wrote:
       | 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.
        
         | jhbadger wrote:
         | 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).
        
           | racingmars wrote:
           | 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!
        
             | jhbadger wrote:
             | 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.
        
       | NetMageSCW wrote:
       | 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.
        
         | wizzwizz4 wrote:
         | 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.
        
           | Jtsummers wrote:
           | Threaded interpreters are different than multithreading:
           | 
           | https://en.wikipedia.org/wiki/Threaded_code
           | 
           | https://archive.org/details/R.G.LoeligerThreadedInterpretive.
           | .. - book on the topic
        
       | tombert wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2026-03-07 23:00 UTC)