i've come to appreciate, over the past 2 years of heavy Prolog use, that all coding should be (eventually) be done in Prolog.

It's one of few languages that is simultaneously a standalone logical formalism, and a standalone representation of computation. (With caveats and exceptions, I know). So a Prolog program can stand in as a document of all facts, rules and relations that a person/organization understands/declares to be true. Even if AI writes code for us, we should expect to have it presented and manipulated as a logical formalism.

Now if someone cares to argue that some other language/compiler is better at generating more performant code on certain architectures, then that person can declare their arguments in a logical formalism (Prolog) and we can use Prolog to translate between language representations, compile, optimize, etc.

  …the limitations of current machine intelligence largely stem from seeking unified theories or trying to repair the deficiencies of theoretically neat but conceptually impoverished ideological positions. 
  Our purely numeric connectionist networks are inherently deficient in abilities to reason well; our purely symbolic logical systems are inherently deficient in abilities to represent the all-important heuristic connections between things—the uncertain, approximate, and analogical links that we need for making new hypotheses. The versatility that we need can be found only in larger-scale architectures that can exploit and manage the advantages of several types of representations at the same time.
  Then, each can be used to overcome the deficiencies of the others. To accomplish this task, each formally neat type of knowledge representation or inference must be complemented with some scruffier kind of machinery that can embody the heuristic connections between the knowledge itself and what we hope to do with it.

The generated programs are only technically Prolog programs. They use CLPFD, which makes these constraint programs. Prolog programs are quite a bit more tricky with termination issues. I wouldn’t have nitpicked if it wasn’t in the title.

Also, the experiment method has some flaws. Problems are hand-picked out of a random subset of the full set. Why not run the full set?

Check out https://github.com/mthom/scryer-prolog https://www.scryer.pl/

If you are close to Vienna Nov 7th and 8th there is a community meeting https://www.digitalaustria.gv.at/eng/insights/Digital-Austri...

Ah Prolog. So the full circle back to expert systems is complete now, yeah?

This is basically the LLM modulo approach recommended by Prof. Subbarao Kambhampati. Interesting but only works mostly for problems that have some math/first degree logic puzzle at their heart. Will fail at improving perf at ARC-AGI for example... Difficult to mimic reasoning by basic trial and error then hoping for the best: https://www.lycee.ai/blog/why-sam-altman-is-wrong

So we are back to Japanese Fifth Generation plan from 1980's. :)

Super cool. I dig generating rules from within the LLM, but I'm not sure Prolog is the right choice in 2024.

I love Prolog and had the opportunity to use it "in anger" years ago to handle temporal logic in a scheduling app. Great experience, but I've found that more modern rules engines like Drools (anything using the Rete algorithm) are a MUCH better fit for most use cases these days.

If you are into this stuff, you might like the talk I gave on rules engines, prolog and how it led to erlang & elixir. https://www.youtube.com/watch?v=mDnntrhk-8g&t=1s

I tried an experiment with this using a Prolog interpreter with GPT-4 to try to answer complex logic questions. I found that it was really difficult because the model didn't seem to know Prolog well enough to write a description of any complexity.

It seems like you used an interpreter in the loop which is likely to help. I'd also be interested to see how o1 would do in a task like this or if it even makes sense to use something like prolog if the models can backtrack during the "thinking" phase

The draft version of this blog was called - 'Renaissance of Programming Languages'. With so much hidden gems we are re-discovering the full potential of formal languages.

ChatGPT seems to do awful with Prolog. Do you guys have any experiences with using an LLM to write Prolog?

I think this general idea is going to be the key to really making LLMs widely useful for solving real problems.

I’ve been playing with using GPT-4 together with the Wolfram Alpha plugin, and the combo of the two can reliably solve difficult quantitative problems that neither can individually by working together, much like a human using a calculator.

You're telling me the seemingly arbitrary 6 weeks of Prolog on my comp sci course 11yrs ago is suddenly about to be relevant? I did not see this one coming . . .

This is why GitHub CodeQL and Co-Pilot assistance is working better for everyone? basically codeql uses variant of Prolog (datalog) to query source code to generate better results.

I always thought that Prolog is great for reasoning in the semantic web. It doesn't surprise me that LLM people stumble on it.

While the paper is about helping an LLM using Prolog, to give an idea for a realistic application for generating Prolog, here's the zero-shot prompt and response of a basic local Instruct LLM on a challenge to a classic 1998 AI Planning Competition "Logistics" problem re-formulated in English from PDDL, running on a very basic local 8B LLM quant'd to run on 12GB and containing even typos, but not showing the system prompt portion though. I mean, it's quite impressive and the generated state and action predicates can be run right away in the browser on eg. Quantum Prolog much like the container planning problem [1], with the main clause replaced by a generic STRIPS-like indeterministic/backtracking planning routine. Using additional training and/or in-context techniques and prompt reformulation can improve the result further.

Since the action predicates use retract/assert primitives to change state, Quantum Prolog's vardb feature [2] can also be put to good use by transforming the resulting program into an equivalent form that can be backtracked over to perform combinatorical search (whereas assertz/retract in Prolog are destructive and cannot be "undone" automatically to search new states).

But as you also can see from the plan description text, a natural-language description of the problem that an LLM can comprehend only helps so much since it's highly repetitive in stating hundreds of facts about the current and desired package locations. This is where PROLOG actually comes in since you can state those ground facts in clause format, or a DSL format, or a database.

Still, the combination of an LLM (excelling at language tasks) and Prolog (for actually searching a combinatorical space spanned by clauses extracted in a natural way), just as human reach out to a pocket calculator for certain tasks, sure is powerful and has been also explored recently in form or another in academia eg [3]). And this isn't even using tool calling and iterative re-prompting, etc.

[1]: https://quantumprolog.sgml.net/container-planning-demo/part1...

[2]: https://quantumprolog.sgml.net/container-planning-demo/part2...

[3]: "LLMs Can't Plan, But Can Help Planning in LLM-Modulo Frameworks" at <https://arxiv.org/abs/2402.01817>

PROMPT (submitted as-is, including typos):

Write a Prolog program to solve the following logistics problem: Packages must be transported from and to locations inside the six cities named city1, city2, city3, city4, city5, and city6) using trucks, and between those citiesusing airplanes. Each city has two locations: city1 has locations city11 and city12, city2 has locations city21 and city22, city3 has locations city31 and city32, city4 has locations city41 and city42, city5 has locations city51 and city52, andcity6 has locations city61 and city62. Initially, package1 is located at city21, package2 is located at city12, package3 is located in city11, package4 is located in city11, package5 is located in city42, and package6 is located in city31. The aim is to move package1 to city21, package2 to city62, package3 to city61, package4 to city32, package5 to city62, and package6 to city12. In each city, at the locations city11, city21, city31, city41, city51, and city61, there's a truck to transport packages to other locations within the city. There are moreover two airplanes, named plane1 and plane2, located at the airport of city1 at location11 and at the airport of city2 at location22. The airports of the other cities have the locations location32 in city3, location42 in city4, location52 in city5, and location62 in city6. To move packages, a sequence of actions as follows must be performed until the packages have reached their destination. The action load_truck will place a package in a truck at a given location. The action unload_truck will unload a package from a truck at a given location. The action fly_airplane will fly an airplane from one airport to another. The action unload_airplane will unload a package from an airplane at a given location. The action load_airplane will load an airplane with a package at a given location.

RESPONSE:

    % State facts
    
    % Initial state of the packages
    package(package1, city21).
    package(package2, city12).
    package(package3, city11).
    package(package4, city11).
    package(package5, city42).
    package(package6, city31).
    
    % Initial state of the trucks
    truck(city11, city11).
    truck(city21, city21).
    truck(city31, city31).
    truck(city41, city41).
    truck(city51, city51).
    truck(city61, city61).
    
    % Initial state of the airplanes
    airplane(plane1, city11).
    airplane(plane2, city22).
    
    % Action clauses
    % load_truck :- load a package into a truck at a given location
    load_truck :- 
        % If the given location is valid for loading a truck
        location(Loc, City), 
        package(Pkg, Loc), 
        truck(T, Loc),
        % Remove the package from its current location
        retract(package(Pkg, Loc)), 
        % Add the package to the truck
        assertz(package(Pkg, T)), 
        % Assert the new state
        assertz(truck(T, Loc)).
    
    % unload_truck :- unload a package from a truck at a given location
    unload_truck :-
        % If the given location is valid for unloading a truck
        location(Loc, City), 
        package(Pkg, T), 
        truck(T, Loc),
        % Remove the package from the truck
        retract(package(Pkg, T)), 
        % Add the package to its destination location
        assertz(package(Pkg, Loc)),
        % Assert the new state
        assertz(truck(T, Loc)).
    
    % fly_airplane :- fly an airplane from one airport to another
    fly_airplane :-
        % If the airplane is at a valid airport
        airplane(plane, Loc),
        % If there is a valid destination airport
        airport(Dest, DestCity),
        % Remove the airplane from its current location
        retract(airplane(plane, Loc)), 
        % Add the airplane to the destination airport
        assertz(airplane(plane, Dest)).
    
    % unload_airplane :- unload a package from an airplane at a given location
    unload_airplane :-
        % If the given location is valid for unloading an airplane
        location(Loc, City), 
        package(Pkg, A),
        airplane(plane, A),
        % Remove the package from the airplane
        retract(package(Pkg, A)), 
        % Add the package to its destination location
        assertz(package(Pkg, Loc)), 
        % Assert the new state
        assertz(airplane(plane, Loc)).
    
    % load_airplane :- load a package into an airplane at a given location
    load_airplane :-
        % If the given location is valid for loading an airplane
        location(Loc, City), 
        package(Pkg, Loc),
        airplane(plane, A),
        % Remove the package from its current location
        retract(package(Pkg, Loc)),
        % Add the package to the airplane
        assertz(package(Pkg, A)),
        % Assert the new state
        assertz(airplane(plane, Loc)).
    
    % Target state
    target :-
        package(package1, city22),
        package(package2, city62),
        package(package3, city61),
        package(package4, city32),
        package(package5, city62),
        package(package6, city12).
    
    % Main predicate to solve the problem
    solve :- ...
    % BOGUS MAIN AND HELPER CLAUSES OMITTED

Does anyone know why US attorneys and law firms are not using Prolog-based apps to automate the low-hanging fruit of issue-spotting?

Patiently waiting for z3-guided generation, but this is a welcome, if obvious, development. Results are a bit surprising and sound too optimistic, though.

Building on this idea people have grounded LLM generated reasoning logic with perceptual information from other networks : https://web.stanford.edu/~joycj/projects/left_neurips_2023

I made a pipeline using Z3 (another prover language) to get LLMs to solve very specific puzzle problems: https://youtu.be/UjSf0rA1blc (and a presentation: https://youtu.be/TUAmfi8Ws1g)

Some thoughts:

1. Getting an LLM to model a problem accurately is a significant prompting exercise. Bridging casual logical statements and formal logic is difficult. E.g., "or" statements in English usually mean "xor" in logic.

2. Domains usually have their own language expectations. I was doing Zebra puzzles (https://en.wikipedia.org/wiki/Zebra_Puzzle) and they have a very specific pattern and language. I don't think it's fair to really call it intuitive or even entirely unambiguous, it's something you have to learn. The LLM has to learn it too. They have seen this kind of puzzle (and I think most can reproduce the original Zebra puzzle from memory), but they lack a really firm familiarity.

3. Arguably some of the familiarity is about contextualizing the problem, which is itself a prompting task. People don't naturally solve Zebra puzzles that we find organically, it's something we encounter in specific contexts (like a puzzle book) which is not so dissimilar from prompting.

4. Incidentally Claude Sonnet 3.5 has a substantial lead. And GPT o1 is not much better than GPT 4o. In some sense I think o1 is a kind of self-prompting, an attempt to create its own context; so if you already have a well-worded prompt with instructions then o1 isn't that good at improving performance over 4o.

5. A lot of the prompting is really intended to slow down the LLM, to keep it from jumping to conclusions or solving a task too quickly (and incorrectly). Which again is a case of the prompt doing what o1 tries to do generally.

6. I'm not sure what tasks call for this kind of logical reasoning. Not that I don't think they exist, I just don't know how to recognize them. Planning tasks? Highly formalized and artificially constructed problems don't seem all that interesting... and the whole point of adding an LLM to the process is to formalize the informal.

7. Perhaps it's hard to see because real-world problems seldom have conveniently exact solutions. But that's not a blocker... Prolog (and Z3) can take constraints as a form of elimination, providing lists of possible answers, and maybe just reducing the search space is enough to move forward on some kinds of problems.

8. For instance when I give my pipeline really hard Zebra problems it usually doesn't succeed; one bug in one rule will kill the whole thing. Also I think the LLMs have a hard time keeping track of large problems; a context size problem, even though the problems don't approach their formal context limits. But I can imagine building the pipeline so it also tries to mark low-confidence rules. Given that I can imagine removing those rules, sampling the resulting (non-unique, sometimes incorrect) answers and using that to revisit and perhaps correct some of those rules.

Really I'd be most interested to hear thoughts on where this logic programming might actually be applied... artificial puzzles are an interesting exercise, but I can't really motivate myself to go too deep.

Would Creating a prolog dataset would be beneficial, so that future LLM's can be trained on it and then they would be able to output prolog code.

An application I am developing for a customer needed to read constraints around clinical trials and essentially build a query from them. Constraints involve prior treatments, biomarkers, type of disease (cancers) etc.

Using just an LLM did not produce reliable queries, despite trying many many prompts, so being an old Prolog hacker I wondered if using it might impose more 'logic' on the LLM. So we precede the textual description of the constraints with the following prompt:

-------------

Now consider the following Prolog predicates:

biomarker(Name, Status) where Status will be one of the following integers -

Wildtype = 0 Mutated = 1 Methylated = 2 Unmethylated = 3 Amplified = 4 Deleted = 5 Positive = 6 Negative = 7

tumor(Name, Status) where Status will be one of the following integers if know else left unbound -

Newly diagnosed = 1 Recurrence = 2 Metastasized = 3 Progression = 4

chemo(Name)

surgery(Name) Where Name may be an unbound variable

other_treatment(Name)

radiation(Name) Where Name may be an unbound variable

Assume you are given predicate atMost(T, N) where T is a compound term and N is an integer. It will return true if the number of 'occurences' of T is less than or equal N else it will fail.

Assume you are given a predicate atLeastOneOf(L) where L is a list of compound terms. It will succeed if at least one of the compound terms, when executed as a predicate returns true.

Assume you are given a predicate age(Min, Max) which will return true if the patient's age is in between Min and Max.

Assume you have a predicate not(T) which returns true if predicate T evaluates false and vice versa. i.e. rather than '\\+ A' use not(A).

Do not implement the above helper functions.

VERY IMPORTANT: Use 'atLeastOneOf()' whenever you would otherwise use ';' to represent 'OR'. i.e. rather than 'A ; B' use atLeastOneOf([A, B]).

EXAMPLE INPUT: Patient must have recurrent GBM, methylated MGMT and wildtype EGFR. Patient must not have mutated KRAS.

EXAMPLE OUTPUT: tumor('gbm', 2), biomarker('MGMT', 2), biomarker('EGFR', 0), not(biomarker('KRAS', 1))

------------------

The Prolog predicates, when evaluated generate the required underlying query (of course the Prolog is itself a form of query).

Anyway - the upshot was a vast improvement in the accuracy of the generated query (I've yet to see a bad one). Somewhere in its bowels, being told to generate Prolog 'focused' the LLM. Perhaps LLMs are happier with declarative languages rather than imperative ones (I know I am :) ).

Interest in Prolog always ends with the "!". It is ugly and like smack in the head, "you are thinking too much".

That's not going to work. Garbage in - Garbage out is success-set equivalent to Garbage in - Prolog out.

Garbage is garbage and failure to reason is failure to reason no matter the language. If your LLM can't translate your problem to a Prolog program that solves your problem- Prolog can't solve your problem.

I really enjoyed tinkering with languages like Prolog and Coq. Interactive theorem proving with LLMs would be awesome to try out, if possible.

I implemented Prolog and Z3 as a function tool for my little OpenAI Assistants API client. Z3 (SMT-LIB, actually) seemed even more promising. The model speaks both languages. However, I didn't find any convincing use-cases yet. But it seems a logical extension of the idea to provide a programming language via a function tool to solve problems. So you start thinking "What else has text input and output, and a powerful engine in between?"

Use Constraint Satisfaction Problem Solvers. It commes up with Common Lisp with ease.