>>
https://t3x.org/lisp64k/prolog.htmlLike most "Prolog implemented in a LISP" examples, that's not Prolog. It's a Prolog-like LISP language that is missing the point. Implementing Prolog in Lisp is only "trivial" if you try to do something trivial and call it "implementing Prolog in LISLP", instead of actually, you know, implementing Prolog. In Lisp.
Since we're discussing an article by Markus Triska, and he's commented on the same thing, I'll let him do the honours:
https://github.com/triska/lisprolog
Some online books show how to implement simple "Prolog" engines in Lisp. These engines typically assume a representation of Prolog programs that is convenient from a Lisp perspective, and can't even parse a single proper Prolog term. Instead, they require you to manually translate Prolog programs to Lisp forms that are no longer valid Prolog syntax. With this approach, implementing a simple "Lisp" in Prolog is even easier ("Lisp in Prolog in zero lines"): Manually translate each Lisp function to a Prolog predicate with one additional argument to hold the original function's return value. Done. This is possible since a function is a special case of a relation, and functional programming is a restricted form of logic programming.
I'll just add that this idea of a "trivial" implementation of Prolog in Lisp seems to come from SICP which itself proudly shows off how to "trivially" do the job. I once sat through a couple of hours of lecturing on Logic Programming and Prolog by Gerald Sussman, on youtube, just to try and form a mental model of his mental model about Prolog. I waited, and waited, and waited in vain for the other shoe to drop, thinking "well he must be coming to the subject of Resolution theorem-proving any moment now" but he never did. Instead he presented a version of Prolog that is quite unrecognisable by any working Prolog programmer, from the syntax, right down to the semantics; a version that only seemed to loosely share ideas like backtracking and pattern matching with Prolog. One-sided pattern-matching mind, not unification, because unification is, for some reason, really scary to Lisp and functional programming folks. A "Prolog" with the syntax of Scheme and with the semantics of Lisp variables and primitives like eval and so on. And when he was finally asked "how is real Prolog different" at the end of the lecture he said "because Prolog programmers have a really efficient interpreter". Meaning, I guess, the Warren Abstract Machine. Very disappointing.