Ask HN: What's Prolog like in 2024?

To playing well with Python, this was on a front page some time ago: https://arxiv.org/abs/2308.15893

"The Janus System: Multi-paradigm Programming in Prolog and Python"

How do you normally use Prolog and Python together? I had looked into embedding logic programming within Python in the past, and found a lack of satisfying options, but maybe I didn't know where to look.

There are some benchmarks here of SWI Prolog's benchmark suite on diffrent Prolog systems by Jan Wielemaker the SWI Prolog author:

https://swi-prolog.discourse.group/t/porting-the-swi-prolog-...

He finds Scryer performs worse, which he does comment on, he also explains some tradeoffs and historic choices in SWI's design which affects its performance. I think I have seen the author of Scryer saying that's not surprising and Scryer is still building up core functionality where SWI has had 30+ years to optimise, but I don't remember where I read that.

SWI has a document explaining some strengths and weaknesses regarding performance: https://www.swi-prolog.org/pldoc/man?section=swiorother

Edit: some discussion on Scryer previously on HN: https://news.ycombinator.com/item?id=28966133

I've tried casually to take this approach and what I've found is that basically none of the Prologs out there are really designed to be properly embeddable. Even Scryer Prolog, written in Rust, isn't really set up to linked into a Rust program and run this way. I was able to "sort-of" make it happen, but it wasn't a workflow that had been optimized for.

To be clear what I'd like is to be able to fire up a thread hosting a Prolog runtime and stick predicates into it and query it using an API in the host language's syntax. Instead the best I could do was munge strings together and parse result out, sort-of. And that was after a bunch of time spent trying to reverse-engineer Scryer's API.

I would love to embed a Prolog to host my application's business rules and knowledge. I could see it super useful in a game even (think of the myriad of crazy rules and interactions and special cases in a game like Dwarf Fortress...)

At this point, why not use one of the many other CP solver packages out there and the layers on top like OR-tools?

To me this makes Prolog sound like a tool to reach for similar to SQL. Specialized language for asking specific kinds of search or query over your data.

I concur, Prolog particularly excels at being an advanced configuration, embeddable DSL that allows one to express system configurations that would otherwise be not easily possible using a bespoke configuration language or a format. I have used an embedded Prolog core to express complex installation configurations in the past with a great success, and I would do it again for the right problem space.

Any sufficiently complex type system is indistinguishable from an esolang.

You can always just download the code, nobody's forcing you to use a package manager. It just turns out that unless you want to spend most of your life building and fixing other people's code, it's much easier to use the package manager. The inefficiency is the price we pay, but it's worth it.

Me too! I absolutely see a lack of package manager as a pro. I also hate to saddle anything with 600MB I don't need. 100% agree.

I would go as far as to say that Prolog is more a problem solving language rather than a system building language. Package managers and module systems are for modularization of big systems. You don't need that when solving small recurrent problems. Furthermore, lack of them forces you to avoid dependencies, that most of the time would end as technical debt. IMHO.

don't confuse "module system" with "package manager"

Yes :) we make software that helps sell complex products (If your product has a million options and takes up a whole factory floor you can’t just have a series of dropdowns)

I suspect that his work is related to this: https://www.tacton.com/products/tacton-cpq/configurator/

> Like rules for assigning molecular mechanics force field atom types.

Can you describe a bit more how prolog helped you here? Thanks!

I used DEC's VAX OPS5 for a couple years about around 1990. I quite liked it, and the later versions had some really nice extensions over Forgy's original design.

Then we discovered that our particular rule base could easily be ported into C using a sequence of nested if/thens that ran much faster, and we stopped using OPS5. It was a great tool for doing the initial development, though.

You can use https://logtalk.org for oop in Prolog, use it on top of SWI and you have bidirectional bridges to Python an Java

https://www.swi-prolog.org/FAQ/Python.md

https://www.swi-prolog.org/pldoc/doc_for?object=section(%27p...

what does that mean?

I had similar discussions with people that wanted to encode published research into ontologies. I would ask researchers what they think - the answer was always great idea. I would then follow up with - How would you use it? No response. I finally concluded that it would never happen.

1. No one wanted it enough to pay for it to happen.

2. There is always a turn over of ideas coming and going which can never be sufficiently updated to keep it useful. Again no one would pay anyway.

Tools like LLMs seem to be fill the role now. I would like to see a Prolog integrated with LLMs is someway (lack of imagination fails me how that would happen).

This is why Lenat and CYC had settled on micro-theories. They found it impossible to build a useful universal ontology so had to fracture them on domain boundaries.

your camera example demonstrates that human knowledge is loosely structured and formalized in general, so you can't create strict onthology. One way to work around is to assign some confidence score on statements, so you will have something like that Nikon device is likely camera, and x-ray machine is unlikely camera based on current world model.

I don’t see an issue with saying “X-ray photography machines, and deep-space radio telescopes, are (or at least contains-a, in the case of the telescope) cameras”. They just aren’t ordinary cameras of the sort that a typical person might take a picture with.

I think most of the reasoning you would want to do with a concept of “camera” that excludes X-ray machines and telescopes, but includes night-vision, could be handled with “portable camera”?

Hm, I guess you probably want to include security cameras though..

Ok. “Portable cameras or security cameras”.

Yes, I think that is the experience, for example, in what we called (or call) data science: most of the time is spent in ETLs rather than using ML methods. In a real company linking data difficulty is not technical but time and resource consuming.

Ontology: Study of the nature of being, becoming, existence or reality, as well as the basic categories of being and their relations (philosophy)

What does that have to do with this?

Is there some use of "ontology" in logic I have not heard of?

Imagine it's, like, 1980 - or even earlier - and you can work in a language roughly as nice as Clojure, except the rest of the world is stuck working with pre-ANSI C or Pascal or FORTRAN or COBOL or raw assembly language. There's no Python or Java or C# or Ruby or Perl or Haskell or Scala or Kotlin or Rust or JS/TS. Nothing really resembling our modern idea of a high-level language.

(OK, there was Smalltalk. Let's ignore Smalltalk. Lord knows everyone else did.)

That'll alter your perception of reality a bit. Here they were, in possession of a tool massively more powerful - and more elegant - than what everyone else is using. And moreover, everyone else took a look at it and turned their noses up.

Clearly, you and your fellow Lisp programmers are a different breed, capable of seeing further than the rest of the unwashed masses. In a word, you were better than them.

It sounds like I'm being disparaging, but to a certain extent, I don't even think this was totally a wrong attitude to have. Elitist, definitely, but not wholly unwarranted. Lisp really was - in terms of expressiveness, anyway - really that far ahead of the competition. And yet somehow that competition won. The world is cruel and unjust.

So Lisp becomes a kind of Us v. Them cult: if you've heard the good word of McCarthy, you're one of Us. If not, you're best ignored - too stupid to possibly have anything worthwhile to say.

(If you think I'm exaggerating, spend some time reading the words of Usenet Lisp institution Erik Naggum - R.I.P. - who serves as the most extreme but hardly the only example.)

This blinded Lisp diehards to the outside world, which slowly but surely, in many respects, began to catch up or even exceed Lisp.

The other thing is - not only is Lisp a powerful language, at its core is a beautiful and simple and expressive mathematical idea. Combine that with the way macros allow you to extend the language virtually infinitely, there can be a near religiosity at the heart of Lisp - from one lambda all things depend. Lisp isn't just good engineering - it's a glimpse at the fundamental nature of computation, of the universe itself.

I'm not going to sit here and tell you that this is somehow a terrible thing, per se. But it can be incredibly alluring to the right kind of mind, and once you're in its thralls it's hard to get out. You might be working with the tool, but in another sense the tool is working with you. A Siren Song.

Clojure is probably the most beautiful language I've ever worked with. Nothing is perfect, but Clojure is very simple and elegant.

core.logic is pretty neat, too. Especially as it applies to this thread and the ancestor comments.

Lisps don't get in your way, but they also have no opinions, which is problematic for community development. As a static type fan, it's the only language I think the pros outweigh than one con.

The more nightmarish thing about Clojure is realizing that, in truth, you have no idea what all these dicts you are passing around the terse, nil-punning functions of your codebase hold at any given time.

They seem to disappear with parinfer.

Once you view prolog goal reaching as a game. You can apply Reinforcement Learning methodologies. The goal is writing a valid proof, aka a sequence of picking valid rules and variables assignment.

Value being estimated : The expected discounted reward of reaching the goal. The shorted the proof the better.

The sufficient statistic : The embedding representation of the current solving state (the inner state of your LLM (or any other model) that you use to make your choices). You make sure it's sufficient by being able to regenerate the state from the representation (using an auto-encoder or vae does the trick). You build this statistic across various instances of problems. This tells you what is a judicious choice of variable based on experience. Similar problems yield similar choices.

The crude estimator : All choices of have the same value therefore a random choice, The improved estimator : The choice value is conditioned on the current embedding representation of the state using a Neural Network.

You can apply Rao-Blackwell once again, based by also conditioning one-step look-ahead. (Or at the limit applying it infinitely many times by solving the bellman equation.)

(You can alternatively view each update step of your model, as an application of Rao-Blackwell theorem on your previous estimator. You have to make sure though that there is no mode collapse.)

You don't have to do it explicitly, it happens under the hood by your choice of modelisation in how to pick the decision.

To be precise, a small number of very small Prolog programs can be run backwards.

There are essentially no significant Prolog programs that are reversible with acceptable efficiency.

the bidirectional (relational) aspect of prolog is what got me into this. I love symmetries so it was a natural appeal even before I learned about logic programming (Sean Parent made a google talk about similar ideas implemented in cpp). That said it's very limited. But I wonder how far it could go. (the kanren guys might have more clues)

backtracking is perilous in general; logic programming languages have really nice abilities for such but I don't know how to avoid pathological inefficiency.

For me this kind of criticism is very familiar. It comes from theoretical computer scientists who have these purist ideological convictions about how a declarative language should look and behave, that are as unrealistic, because impossible to implement on a real-world computer, as they are uninteresting for practicing programmers because strictly a matter of aesthetics. Such critics have never made anything useable themselves and are simply angry that someone else made something that works in the real world while they were busy intellectually masturbating over their pure and untouchable vision.

Although I concede that my comment might be a bit unfair to Girard who did, after all, invent the mustard watch.

"The Blind Spot: Lectures on Logic" by Jean-Yves Girard

In The Development of Erlang Joe Armstrong says "We concluded that we would like something like Prolog with added facilities for concurrency and improved error handling".

See pdf linked here - https://news.ycombinator.com/item?id=40998632

The Development of Erlang by Joe Armstrong (pdf) - https://dl.acm.org/doi/pdf/10.1145/258948.258967

TypeDb is a practical Datalog-based database system [1] (with a different syntax). TerminusDb is a project in a similar vein [2], but actually an RDF store at its core. If you want to experiment with the connections between Datalog, relational algebra, and SQL, check out the Datalog Educational System. And if you want to jump into the theory, Foundations of Databases (the "Alice book") is very thorough but relatively readable [4]! Oh, and there's a Google project, Logica, to do Datalog over Postgres databases [5].

[1]: https://typedb.com/ [2]: https://terminusdb.com/ [3]: http://www.fdi.ucm.es/profesor/fernan/des/ [4]: http://webdam.inria.fr/Alice/ [5]: https://github.com/evgskv/logica

Mangle is a language that includes "textbook datalog" as a subset https://github.com/google/mangle ; like any real-world datalog language, it extends datalog with various facilities to make it practical.

It was discussed on HN https://news.ycombinator.com/item?id=33756800 and is implemented in go. There is the beginnings of a Rust implementation meanwhile.

If you are looking for datalog in the textbooks, here are some references: https://github.com/google/mangle/blob/main/docs/bibliography...

A graph DBs short intro to datalog: just like the edges of a graph could be represented as a simple table (src, target), you could consider a database tuple or a datalog or prolog fact foo(x1, ..., xN) as a "generalized edge." The nice thing about datalog is then that as one is able to express a connections in an elegant way as "foo(...X...), bar(...X...)" (a conjunction, X being a "node"), whereas in the SQL world one has to deal with a clumsy JOIN statement to express the same thing.

Don't have any interesting references, sorry. My reasoning is mainly one of simplicity and power. In SQL you need to think in terms of tables, inner joins, outer joins, foreign keys etc. whereas datalog you do everything with relations as in prolog.

Not only is it conceptually much simpler, it's also a "pit of success" situation as thinking in terms of relations instead of tables leads you towards normal forms by default.

Add the ability to automatically derive new facts based on rules and it just wins by a country mile. I recommend giving Soufflé a try.

I haven't worked with GraphDBs enough to comment on that.

Prolog and Datalog example (they are identical in this case)

    % Facts
    parent(john, mary).
    parent(mary, ann).
    parent(mary, tom).

    % Rules
    ancestor(X, Y) :- parent(X, Y).
    ancestor(X, Z) :- parent(X, Y), ancestor(Y, Z).

    % Query
    ?- ancestor(john, X).

Datalog starts by evaluating all possible combinations of facts and rules. It builds a bottom-up derivation of all possible facts:

a. First, it derives all direct parent relationships.

b. Then, it applies the ancestor rules iteratively until no new facts can be derived.

For the query ancestor(john, X):

It returns all X that satisfy the ancestor relationship with john. This includes mary, ann, and tom. The order of rules doesn't affect the result or termination. Datalog guarantees termination because it operates on a finite set of possible facts.

Prolog uses a top-down, depth-first search strategy with backtracking.

For the query ancestor(john, X):

a. It first tries to satisfy parent(john, X). This succeeds with X = mary.

b. It then backtracks and tries the second rule: It satisfies parent(john, Y) with Y = mary. Then recursively calls ancestor(mary, X).

c. This process continues, exploring the tree depth-first.

Prolog will find solutions in this order: mary, ann, tom.

The order of clauses can affect both the order of results and termination: If the recursive rule were listed first, Prolog could enter an infinite loop. Prolog doesn't guarantee termination, especially with recursive rules.

SQL is more verbose. The equivalent of the Datalog/Prolog example above is:

    -- Create and populate the table
    CREATE TABLE Parent (
        parent VARCHAR(50),
        child VARCHAR(50)
    );

    INSERT INTO Parent VALUES ('john', 'mary');
    INSERT INTO Parent VALUES ('mary', 'ann');
    INSERT INTO Parent VALUES ('mary', 'tom');

    -- Recursive query to find ancestors
    WITH RECURSIVE Ancestor AS (
        SELECT parent, child
        FROM Parent
        UNION ALL
        SELECT a.parent, p.child
        FROM Ancestor a
        JOIN Parent p ON a.child = p.parent
    )
    SELECT DISTINCT parent AS ancestor
    FROM Ancestor
    WHERE child IN ('ann', 'tom');

    % Define the base relation
    friend(Person1, Person2).

    % Define friend-of-friend relation
    friend_of_friend(X, Z) :- friend(X, Y), friend(Y, Z), X != Z.

    % Define potential friend recommendation
    % (friend of friend who is not already a friend)
    recommend_friend(X, Z) :- friend_of_friend(X, Z), not friend(X, Z).

    % Count mutual friends for recommendations
    mutual_friend_count(X, Z, Count) :- 
        recommend_friend(X, Z),
        Count = count{Y : friend(X, Y), friend(Y, Z)}.

    % Query to get top friend recommendations for a person
    top_recommendations(Person, RecommendedFriend, MutualCount) :-
        mutual_friend_count(Person, RecommendedFriend, MutualCount),
        MutualCount >= 5,
        MutualCount = max{C : mutual_friend_count(Person, _, C)}.

    WITH RECURSIVE
    -- Base friend relation
    friends AS (
        SELECT DISTINCT person1, person2
        FROM friendship
        UNION
        SELECT person2, person1
        FROM friendship
    ),

    -- Friend of friend relation
    friend_of_friend AS (
        SELECT f1.person1 AS person, f2.person2 AS friend_of_friend
        FROM friends f1
        JOIN friends f2 ON f1.person2 = f2.person1
        WHERE f1.person1 <> f2.person2
    ),

    -- Potential friend recommendations
    potential_recommendations AS (
        SELECT fof.person, fof.friend_of_friend, 
            COUNT(*) AS mutual_friend_count
        FROM friend_of_friend fof
        LEFT JOIN friends f ON fof.person = f.person1 AND fof.friend_of_friend = f.person2
        WHERE f.person1 IS NULL  -- Ensure they're not already friends
        GROUP BY fof.person, fof.friend_of_friend
        HAVING COUNT(*) >= 5  -- Minimum mutual friends threshold
    ),

    -- Rank recommendations
    ranked_recommendations AS (
        SELECT person, friend_of_friend, mutual_friend_count,
            RANK() OVER (PARTITION BY person ORDER BY mutual_friend_count DESC) as rank
        FROM potential_recommendations
    )

    -- Get top recommendations
    SELECT person, friend_of_friend, mutual_friend_count
    FROM ranked_recommendations
    WHERE rank = 1;

DataScript, Datahike, Datalevin, and XTDB 1.x are open-source. (XTDB 2.x is also open-source but has switched from Datalog to its own query language and SQL.) DataScript, Datalevin, and XTDB have been used in production; not sure about Datahike. All of these databases come from the Clojure community and target Clojure as the primary language. The XTDB team has published a comparison matrix at https://clojurelog.github.io/.

Aside: I write a lot more Python than Clojure, and I wish someone ported Datalevin/Datahike/persistent DataScript to Python. I'd try it as an alternative to SQLite. I suspect with thoughtful API design, an embedded Datalog could feel organic in Python. It might be easier to prototype with than SQLite. There are Datalog and miniKanren implementations for Python, but they are not designed as an on-disk database. PyCozo might be the closest thing that exists. (A sibling comment https://news.ycombinator.com/item?id=40995652 already mentions Cozo.)

Not sure if "production ready" but it's worth looking at Cozo:

https://github.com/cozodb/cozo

Has a dialect of Datalog + some vector support. Multiple storage engines for backend including SQLite, so if your concern is data stability that seems like a reasonable, proven option.

Compiling Datalog to SQL with Logica is possibly the easiest path if you need a production ready open source Datalog setup (i.e. choose your favourite managed Postgres provider): https://logica.dev/

Datomic uses Datalog with a weird clojure syntax instead of the usual prolog-like syntax.