I think I’ve been finding use cases at work. Features that I could build with prolog that I don’t think I could build with other languages. Fill-in-the-blank configuration problems that are somewhere between a normal database query and constraint satisfaction. I haven’t made anything beyond a POC though.
I also think there’s a lot of potential to build smaller internal tools with prolog. Prolog + LLMs are a really good match. I think the broad usefulness of prolog has been bottlenecked in the past by the finding/sourcing/formatting correct data, but even cheap LLMs can turn information into prolog facts. You can do all sorts of really neat stuff with a teeny prolog core, and a lot of LLM sourced data.
Like for instance, I made a very rough model of how certain data flows through our many services. Queues, indexers, caches. Came up with a few predicates that describe what a race condition is, what stale data is, then let Claude loose on the codebase to fill in all of the facts. Then in a couple queries, I indeed found a few race conditions and stale data!
Datalog (i.e. prolog without function symbols) still has a lot of practical applications for as a relational language and for logic programming. The polonius borrowchecker for rust originated as a datalog program, for example.
They're not different in any fundamental way, except for function symbols. Cut is obviously irrelevant, so let's talk about the semantics and execution. There's only two important aspects there: infinite recursion and top down/bottom up. Infinite recursion is pretty easy to deal with. We just use tabling (and tabled prolog is still a prolog). Once we've done that, top down and bottom up are equivalent in the absence of function symbols. Then all we have to sort out is the negation semantics. Datalogs typically require restricted negation, so they get 2-valued negation. Prologs don't usually restrict negation, so they usually assume 3-valued WFS. Neither one of these is required though. WFS datalog exists, as do prologs with restricted negation.
Unification is a bit different, but not that important here. It's more important to note that a datalog program will compute the same results in prolog and thus, my previous statement that datalog is essentially prolog without function symbols.
There was a comparison of user expectations in web and database search. Database users expect the search result to include all relevant data, exclude all non-relevant data, and to get an explanation if something look out of place. Web users' expectations are lower, they accept false positives and omissions as long as some elements of the result seem to be correct.
Prolog is like a database. It is mechanical. AI is like web search (which it essentially is).
The same use case it originally had? "Here's some incomplete data, show me all possible paths it could take."
SQL is fine if there are interlinks supporting the direction of your search. But those relationships frequently end up one-way, unless the architect both fights for it, and actually exists.
Yes, there are modern use cases for it. I use it all the time. You can use it for almost everything. See SWIProlog, business backends, web applications, GUI too, you are limited by your imagination.
Personally, I think rule-enforcing GOFAI is what ought be supporting a much-thinner LLM layer that helps translate user requests.
Alas, there's a lot of convenience/hype appeal to just throwing most of the functionality in the magical mad-libs blender and trusting that reliability and security problems won't be too bad.
Prolog is such a weird yet interesting language. Fun times having to program it back in University.
Are there any modern use cases of prolog left, or is it more of academic interest?
I think I’ve been finding use cases at work. Features that I could build with prolog that I don’t think I could build with other languages. Fill-in-the-blank configuration problems that are somewhere between a normal database query and constraint satisfaction. I haven’t made anything beyond a POC though.
I also think there’s a lot of potential to build smaller internal tools with prolog. Prolog + LLMs are a really good match. I think the broad usefulness of prolog has been bottlenecked in the past by the finding/sourcing/formatting correct data, but even cheap LLMs can turn information into prolog facts. You can do all sorts of really neat stuff with a teeny prolog core, and a lot of LLM sourced data.
Like for instance, I made a very rough model of how certain data flows through our many services. Queues, indexers, caches. Came up with a few predicates that describe what a race condition is, what stale data is, then let Claude loose on the codebase to fill in all of the facts. Then in a couple queries, I indeed found a few race conditions and stale data!
Dialog is an interactive fiction programming language with Prolog-style evaluation, but rules are sort of S-exprs: https://dialog-if.github.io/manual/dialog/1c04-dev/lang/exec...
I like this so much I'm trying to invent a reason to use it.
Datalog (i.e. prolog without function symbols) still has a lot of practical applications for as a relational language and for logic programming. The polonius borrowchecker for rust originated as a datalog program, for example.
Datalog uses prolog or prolog-like syntax, but the semantics and execution algorithm are different. But yes, it has practical applications.
They're not different in any fundamental way, except for function symbols. Cut is obviously irrelevant, so let's talk about the semantics and execution. There's only two important aspects there: infinite recursion and top down/bottom up. Infinite recursion is pretty easy to deal with. We just use tabling (and tabled prolog is still a prolog). Once we've done that, top down and bottom up are equivalent in the absence of function symbols. Then all we have to sort out is the negation semantics. Datalogs typically require restricted negation, so they get 2-valued negation. Prologs don't usually restrict negation, so they usually assume 3-valued WFS. Neither one of these is required though. WFS datalog exists, as do prologs with restricted negation.
Unification is a bit different, but not that important here. It's more important to note that a datalog program will compute the same results in prolog and thus, my previous statement that datalog is essentially prolog without function symbols.
Unless, as you note, you've implemented restricted negation, which as you say, is typical.
That said, the old joke is true: when you've seen one Datalog, you've seen one Datalog.
There was a comparison of user expectations in web and database search. Database users expect the search result to include all relevant data, exclude all non-relevant data, and to get an explanation if something look out of place. Web users' expectations are lower, they accept false positives and omissions as long as some elements of the result seem to be correct.
Prolog is like a database. It is mechanical. AI is like web search (which it essentially is).
I don't know SPARQL (or GraphQL) but I'd imagine Prolog would be a fantastic way of querying graph databases.
The same use case it originally had? "Here's some incomplete data, show me all possible paths it could take."
SQL is fine if there are interlinks supporting the direction of your search. But those relationships frequently end up one-way, unless the architect both fights for it, and actually exists.
Yes, there are modern use cases for it. I use it all the time. You can use it for almost everything. See SWIProlog, business backends, web applications, GUI too, you are limited by your imagination.
I also ask, is there any modern use cases of GOFAI left? Is it even a good pre-requisite to study for modern LLMs and gen-AI?
Personally, I think rule-enforcing GOFAI is what ought be supporting a much-thinner LLM layer that helps translate user requests.
Alas, there's a lot of convenience/hype appeal to just throwing most of the functionality in the magical mad-libs blender and trusting that reliability and security problems won't be too bad.
[dead]