What do people use Prolog for in the real world? I learned about it on a university course and it seems so esoteric compared to other things on the course. Like something invented just for computer scientists to enjoy.
I've just rolled out an internal SWI Prolog app that is similar to one linked to elsewhere in the thread [1]. We have a large Cloud estate with 10s of thousands of resources in it. Detecting unused or misconfigured resources manually isn't practical, and there are significant cost savings to be had by cleaning things up. The Prolog app reads in JSON resource snapshots, creates an in-memory database of facts from it and then applies rules to detect issues. Most of the rules are simple and the ones for detecting unused resources (3 LOC) or resources that reference other non-existent resources (7 LOC) are entirely generic. There's also link metadata that models the possibility of links existing between resource types, even if they aren't always there in practice.
There's TUI that allows querying of issues and the resource hierarchy. Issues can also be output as JSON which is fed into a LLM to produce cleanup actions and management reporting.
The Prolog app is very fast, considering what it's doing, largely because it makes heavy use of tabling so once an issue has been detected it's not recomputed when queries are made.
This sounds like a very useful way to use Prolog. I would also guess that is a more efficient and direct method for performing pattern detection vs an LLM.
Yes, exactly. The issue detection step isn't particularly well-suited to a LLM, as it will tell you itself. The issues can be established deterministically by examining the Cloud resource data with a set of relatively simple rules, and Prolog is ideal for that. Where a LLM comes into the picture is analysis of the symptoms - resource relationships, ages, ownership, hypothesising root causes, generating cleanup plans, management reporting and so on. The interface between Prolog and the LLM is a JSON file containing the detected symptoms which is described to the LLM by a Skill. It all works pretty well.
It's not that sophisticated ;-) There's command editing using readline, result pagination using less and I output links to the reports and the Cloud console using ANSI HTTP link escapes. Primitive but sufficient.
I have a application that has actions and actions can happen pretty much in any order. By default all scenarios should be an error except for ones that are in the boundary of logical steps, e.g.
A few years ago I wrote a workforce scheduling program designed to be used by non-programmers. I worked in a restricted environment so couldn't install anything. The whole thing ran on SWIPL's web offering.
Users simply had to change the basic "facts" (who was available on what days, how many people were needed), and the program solved for the various constraints and offered solutions.
It was maybe about 300 lines of Prolog, no complex dependencies. It replaced a pile of Python scripts that required a lot of state, didn't really work, and could only run on a few specific computers.
For regular users, it was relatively easy to understand and change the facts. SWIPL for web also offers a nice "notebook" interface that lets you mix data, code, and markdown / output blocks so the documentation was inline.
20+ years ago, it was the backend for the business rules engine that processed various logging and monitoring events. The concept was interesting, the performance was terrible, and businesses mostly didn't want to touch it. After I setup clients with a generic set of rules that worked on Prolog facts, most all of my clients were happy to limit their changes to only those fact files.
"Planning, optimization, diagnostics, and complex configuration" [1]
Prolog also works extremely well as a target language for code generation by LLMs for these domains due to it being "higher up in the food chain" compared to procedural languages so to speak, and because Prolog was originally envisioned for classic NLP and hence has a corpus of one-to-one mappings from natural language to logic (as in the example in [3]). So well in fact that even with last-gen models textual descriptions for suitable problems become the bottleneck and you can in many cases just go straight to Prolog code instead ([2]).
Many years ago Maemo (the mobile OS from Nokia) had the profile manager (day mode/night mode etc) written in Prolog. To me it seems like it's a very appropriate application for it.
The JS package manager Yarn had an experimental feature to define dependency constraints using prolog, it made for very concise way to represent the logic.
It never got released for good though. I actually had need of such feature for a project but I thought that using an exoteric programming language and an experimental feature was a bit much. I ended up setting up those constraints as a CI check hand-made script and the code was surprisingly large (~300 lines), but not that hard to understand.
General programming [0], static analysis [1], RDF triple stores [2], authorization systems [3], incremental computation [4] [5], graph DBs [6]. But it is kind of hard to define Datalog exactly, since it is an entire family of technologies based on logic, each extending a clean mathematical model differently.
thanks for your list. appreciated. my question should have been more precise. last time I checked all the Datalog projects I found where either old, unmaintained or have only a single contributor. and that is also true for your examples. I really like Prolog and would love to use Datalog for (RDF) knowledge graph inference.
Then use them! Then those projects will cease having a single contributor or being unmaintained. This doesn't need to be a binary decision (either there is no risk or I won't use it), just choose the project / scope with knowledge that there is some risk in a small community; so internal use rather than client facing, specialized uses, etc.
not sure how using a project adds a contributor. but for the latter - I'm not sufficiently competent at Prolog and friends to meaningfully contribute. I do donate money, though, to projects I regularly use - like for example FreeTube or Linux Mint.
Other than databases, program analysis. The polonius borrow checker in rustc uses datalog internally.
But you can use it for lots of things. Whenever I'm frustrated with graph based tools being slow (like build systems), I run the graph through a datalog engine for comparison. It's usually much, much faster.
Datalog is not a subset of Prolog. It looks that way because both are based on Horn clause logic, while Prolog is more expressive.
This loops Prolog, but terminates in Datalog:
p :- p.
p.
?- p.
This is because the underlying mechanism is completely different. Datalog is like SQL with recursion, you start with known facts and repeatedly applies rules to derive all consequences until nothing new appears. In Prolog, you start from the query and works backward through rules until it either finds a proof or fails.
So, Datalog treats Horn clauses as database constraints/inference rules while Prolog treats Horn clauses as a search program. They use the same mathematical substrate, but completely different computational models.
I used it working on automated tests for telecoms protocols, the practical problem reduces to solving instances of the Pressburger arithmetic, triple exponential time in general (ouch) but we got some results anyway using heuristics. Prolog's a nice space to do high-level heuristics.
Prolog is an elegant abstraction. One of the points of abstractions is that they let us concentrate our optimization efforts in one place. Prolog benefits from many decades of research into how to make it work fast. When your problem does require a Prolog-shaped solution the most sensible thing to do is to use a highly optimized Prolog system instead of reinventing a naive algorithm yourself. Your "inelegant" solution will not be faster.
(This is also the problem with "I'll just quickly implement a Prolog-like DSL when I need it". Sometimes not a bad idea, but you have to be realistic. Your "lightweight" Prolog will be worse in every way compared to serious Prolog implementations).
That sounds intuitively right but breaks down when you ask “inefficient at what?”. Are you efficient with CPU cycles or efficient with human working memory?
Prolog is very succinct and interactive so it is quite nice for modeling and analysing problem spaces, similar to what you might do with Z3 or some other solver library.
Prolog also has exceptionally good string management through DCG:s. If you have a bunch of structured text and want to query it, Prolog allows you to do that. The syntax is very simple so you can even just sed your data into Prolog code and load that sometimes.
Supposedly SICSTUS Prolog is used in flight booking, and NASA did something with it sometime, but that's kind of obscure. If you ever need a rule engine, consider poking it with logic programming for a bit, perhaps it'll turn out both pragmatic and elegant.
Zenlisp it's similar but almost gives an intro CS course (pre SICP)
for the cheap implementing discrete Math and tons of stuff
in pure Lisp, even rational and complex numbers. The end
chapter it's about logic programmer of course.
Like 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:
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.
I used Prolog twice in production, but none of them were what I'd expect to be the "typical" uses.
1. I used GoLog (a Prolog interpreted in Go) for defining some functional tests in the project where the testing infrastructure was otherwise written in Go.
2. I used Prolog (SWI) to write a parser for Thrift (both the definition and binary format) simply because I needed one, and Prolog was convenient.
What I expect people who use Prolog for the stuff it's really good at is databases that encode some complicated business or legal processes. I.e. databases with many complex constraints that have to all somehow come together to produce a solution set. Prolog would also be a good language to encode / query graph databases. So, whatever you can think of being a good match for a graph database would also work well with Prolog.
There are also (even more niche) Prolog derivatives, eg. Ciao or Mercury, that are... well, decent all-purpose languages. You can just use them in the same context where you'd use Python or Haskell respectively. The implementations are pretty solid in terms of performance and correctness... so, if you like the approach, then why not?
https://www.openpolicyagent.org/docs/policy-language
Not quite Prolog as they teach in universities, but its close descendant. Used for policy evaluation, e.g. to validate tree-structured datasets against arbitrary permission rule sets.
Prolog is for logic what inverse kinematics is for robotics.
Where in imperative programming languages you supply arguments to a function and get a result in Prolog you can give the result of a function call and get all argument sets that lead to that result.
But you are right that in production systems you would seldom see Prolog, for reason that you can easily LLM.
Many years ago I used Prolog (BIM Prolog, I believe ) since it was used as an event correlation engine in Tivoli Enterprise Console (IBM). Fun to assert predicates for complex correlation logic.
