While i have seen the basics of vanilla prolog (atoms, predicates, cuts, lists and all that jazz) and a godawful implementation of an agent communication system that works on SICStus prolog. I would like to know more because i think that this language might be a powerhouse in per se.
Since my studies are quite basic in this regards i would like to expand my knowledge on it and kind of specialize myself both in this world and another world (ontologies :D) that i really enjoy.
What's prolog like in 2024? what are you wonderful people doing with it?
thanks from a dumbass :D
I would check out Markus Triska's work to have your mind blown:
- no proper module nor package system in the modern sense.
- in large code bases extra-logical constructs (like cuts) are unavoidable and turn Prolog code into an untenable mess. SWI prolog has single-sided unification guards which tackle this to a degree.
- lack of static and strong types makes it harder to write robust code. At least some strong typing would have been nice. See Mercury as an example of this.
All being said, Prolog is amazing, has a place in the future of programming, and gives you a level-up understanding of programming when you get how the types in every OO program is a Prolog program itself.
Currently I'm focusing on creating easy-to-use embeddings of Trealla Prolog using Wasm. You can find my TypeScript library here: https://github.com/guregu/trealla-js and Go library here: https://github.com/trealla-prolog/go. The goal is to make the libraries as painless as possible. Trealla is a portable and lightweight Prolog written in C that supports CLP(Z) and is broadly compatible with Scryer. It's quite fast! I'm currently using it for some expert system stuff at $work and as an internet forum embedded scripting language for $fun.
Speaking of Scryer, they recently got their WebAssembly build working and I hope to contribute a JS library for them in the future as their API stabilizes. Scryer and Trealla are both aiming for ISO compatibility, so it's my hope that we can foster an ecosystem for modern ISO Prolog and provide more embeddings in the future. It's super convenient to get logic programmer superpowers in your favorite language. Also check out Scryer's new website: https://www.scryer.pl/
For something on the silly side, check out https://php.energy. Prolog Home Page, it's web scale :-). It's proof that you can integrate Prolog with bleeding edge stuff like Spin (server-side wasm ecosystem).
In practice, there are some very performant and maintained implementations with small but helpful communities.
Also in practice. With all of this power, it's clear that anything could be done (well) in Prolog, but it's not always clear what that way might be. DCGs are an example of a beautiful, elegant, simple, powerful way of building parsers (or state machines) that was not immediately evident to the Prolog community for some time. The perpetual conundrum as a user will be "I could do it this way, but there are certainly better ways of doing this, and I have many avenues I could explore, and I don't know which might be fruitful in what timeline".
A few dedicated clever people and idealists and dreamers talking about ontologies and building things I don't understand, e.g. the link in https://news.ycombinator.com/item?id=40994780 that could either be genuinely "Prolog is suitable for things no other language is" or "Fusion is 10 years away" or "Perpetual motion is here and so is cold fusion!", I can't tell. But I suspect from the lack of visible activity out in the wider world, closer to the latter than the former. Or perhaps the people able to make use of its strengths are few and far between.
There's a saying about driving to a town which has been hollowed out and is now a road through some empty store fronts and car parks: "there's no there there". The soul of a place is missing, it's no longer a destination, just some buildings on some land. Prolog has the opposite of that, a main road straight past it, few buildings or people, but there is a there there - an attractor, spark of something interesting and fun. Buried in years of cruft. Might be a Siren's call though, a trap - but if it is it appears less dangerous than the LISP one.
Often bad teachers only present the declarative aspect of the language.
By virtue of being declarative, it allows to express inverse problems in a dangerously simple fashion, but doesn't provide any clue for a solution. And you are then using a declarative language to provide clues to guide the bad engine toward a solution. Making the whole code an awful mashup of declarative and imperative.
Rules :
- N integer, a integer > 1, b integer > 1
- N := a * b
Goal :
N = 2744977
You can embed such a simple problem easily but solving it is another thing.
The real surge of Prolog and other declarative constraint programming type of language will be when the solving engines will be better.
Unification is limited to the first order logic, high-order logic unification is undecidable in the general case. So we probably will have to rely on heuristics. By rewriting prolog goal solving as a game, you can use deep learning algorithms like alphago (Montecarlo tree search).
This engine internally adds intermediate logical rules to your simply defined problem, based on similar problems it has encountered in its training set. And then solve them like LLM, by picking the heuristically picking the right rule from intuition.
The continuous equivalent in a sort of unification is Rao-Blackwellisation (done automagically by deep-learning from its training experience) which allows to pick the right associations efficiently kind of the same way that a "most general unification algorithm" allows to pick the right variable to unify the terms.
The search algorithms for logic programming are simply slow, it's a very interesting idea in programming languages, but there's a reason it's not widely used.
> PROLOG, its misery. Logic programming was bound to failure, not be- cause of a want of quality, but because of its exaggerations. Indeed, the slogan was something like « pose the question, PROLOG will do the rest ». This paradigm of declarative programming, based on a « generic » algorithmics, is a sort of all-terrain vehicle, capable of doing everything and therefore doing everything badly. It would have been more reasonable to confine PROLOG to tasks for which it is well-adapted, e.g., the maintenance of data bases.
> On the contrary, attempts were made to improve its efficiency. Thus, as systematic search was too costly, « control » primitives, of the style « don’t try this possibility if... » were introduced. And this slogan « logic + control13 », which forgets that the starting point was the logical soundness of the deduction. What can be said of this control which plays against logic14? One recognises the sectarian attitude that we exposed several times: the logic of the idea kills the idea.
> The result is the most inefficient language ever designed; thus, PROLOG is very sensitive to the order in which the clauses (axioms) have been written.
You might also want to look at Erlang which is used in the Industry and would be helpful for your future. Joe Armstrong was originally inspired by Prolog and he conceived Erlang as Prolog-Ideas+Functional/Procedural+Concurrency+Fault-Tolerance. Hence you might find a lot of commonalities here. Here is a recent HN thread on a comparison - https://news.ycombinator.com/item?id=40521585
There is also "Erlog" (by Robert Virding, one of the co-creators of Erlang) which is described as, Erlog is a Prolog interpreter implemented in Erlang and integrated with the Erlang runtime system. It is a subset of the Prolog standard. An Erlog shell (REPL) is also included. It also says, If you want to pass data between Erlang and Prolog it is pretty easy to do so. Data types map pretty cleanly between the two languages due to the fact that Erlang evolved from Prolog. - https://github.com/rvirding/erlog
The prolog community is pretty active. SWI has a discourse group. There's SWISH, CLP(FD/Z), abduction via CHR (a rewrite system) or libraries like ACLP. Prolog is homoiconic, and it achieves it in a unique way, via things like functor/3 and =../2 rather than a macro system. There's growing interest in ISO-standard, pure, monotonic prolog for writing large, clean prolog codebases. SWI is the most mature prolog, but Scryer and Trealla are very active and ISO conformant. Trealla is quite embeddable, particularly in javascript codebases. There's also janus for python, and the community is looking to integrate prolog with LLMs.
Prolog shines for writing bidirectional parsers, NLP, expert systems, abductive reasoning, and constraint logic programming. Pure monotonic prolog has some very useful properties in terms of debuggability, making it useful for large prolog programs. There's also some interesting work in developing pure io (library(pio)). Prolog also has a few different techniques for coroutining, including shift/reset. Markus Triska has a very nice youtube series and book on prolog that's worth watching/reading.
The main downside to prolog is really just that there's a steep learning curve to it that puts a lot of people off and prevents it from gaining more traction, similar to why langs like lisp, haskell, and idris have trouble gaining traction. SWI has a lot of features, but it's also not ISO conformant, and a lot of libraries aren't portable and/or feel very procedural/imperative, which defeats the purpose of prolog. The useful libraries can often be ported to less popular prologs that are more promising, like scryer and trealla. For example, I managed to port ACLP to trealla yesterday without much effort, which is a pretty useful abductive system for writing expert systems or any sort of abductive reasoning.
Related areas like constraint programming are still very relevant.
I don't publish episodes often but I have a lot of good interviewees lined up :)
In general, I would advice you to look beyond Prolog and explore Answer Set Programming, the Picat language, and the connections between logic programming and databases (SQL, RDF or otherwise). Not instead of Prolog, but in parallel. Prolog is awesome!
It's difficult to make a case for it. The declarative paradigm is nice, but compared to other languages you're only saving a couple for-loops. I think its benefit comes from expressiveness for problems where clpfd can be applied. I once built an internal tool with Python and SWI Prolog that combined user input with CLPFD to configure test accounts in a consistent and useful way. Users could provide partial constraints, and the system would fill in the rest. Again, the ease of clpfd is great.
I've had some fun generating Prolog facts/databases with LLMs and it's something I want to explore more.
Note: I was just messing around with Prolog this week: https://hpincket.com/adding-an-easter-egg-to-our-numeronym-p...
For "proper" Prolog, in 2024 it is a niche language alive in specific constraint solving applications, but not really used outside of that. I haven't seen anyone attempting at using prolog as a general purpose language since the 90'.
Datalog and logic-inspired languages tend to pop up here and there as domain-specific languages.
Rego is a recent incarnation which had good adoption for k8s and other "modern" systems. However, when trying to get people in my org to adopt it in practice, I saw engineers struggle with the paradigm when complexity grows to more than toy problems.
One interesting development recently is a load of research into, reverse engineering of and emulation of the 1986 Sega AI Computer[1], which used prolog under the hood for mostly educational software. Unfortunately it does not seem there is a way to actually write some prolog for the thing today :(
Edit: ... and on performance vs SWI Prolog, too
Prolog may excel in some niche cases that are documented out there which is fine. For the majority of cases I can think of...it is too esoteric.
Prolog is SUPER cool though as is it's history. You should definitely play with it a bit.
I have tried to use it in combination will LLMs unsuccessfully, partly because the domain was not specific enough. Otherwise you need a lot of real world knowledge and a large fact database.
Logic engines for first order logic in RDF/OWL also have interesting logical inference abilities, like graphdbs.
Any programming language can do "logic" and the work at MIT/CSAIL in probabilistic programming may turn out to be a better way to combine fuzzy logic and formal proofs.
Not sure this answers your question, but maybe this points towards some interesting directions.
Think about it this way. In a regular programming language you write code and then write unit test cases to validate it.
In prolog, all you do is write the test cases and then its up to the compiler to write and run the code for you. In other words you define a set of cases for which a logic is supposed to hold true. The compiler then decides what the code must look like if that is the case.
This might look easy for simple True/False kind of cases. But when you have to write test cases for functions that return deeply nested data structures and all their variations. Then it becomes easier said than done. The other part that makes Prolog hard to get, is you are only allowed recursion to iterate or define things. All of this makes it a little hard to think, write and trouble shoot Prolog.
If you are reading Prolog code then try to think of it like you have access to a code repo's unit test cases, but the actual code doesn't exist. The test cases are considered sufficient enough to define the code in a concrete way.
As you might have started to notice by now. This is actually harder than writing the code itself. In a regular programming language, you get sufficient space to write a function that might not do 100% of what was intended(bugs). Im prolog such an adventure will produce absolutely something else altogether.
I'm also considering a prolog like domain specific language to make a state syncing engine with pure declarations of how the state in system A is reflected in System B, etc.
Prolog itself may not be mainstream, but it is an answer to a the universal problem space of constraint solution, so comp sci will always be in its long shadow.
title: Fifty Years of Prolog and Beyond (2022)
https://github.com/stassa/louise
Louise is a Meta-Interpretive Learning (MIL) system. MIL is like a second-order Prolog where first-order programs are learned from higher-order programs by Resolution. There's a long thread of literature on MIL going back to 2014 but it now seems we're starting to move towards applications, e.g. I'm doing a post-doc where I use MIL to learn autonomous behaviours for an agent that must guide a mobile robot in survey missions. Other colleagues are working on applications in biology. We're going slowly because there's very few of us but MIL is a powerful technique that extends the soundness and completeness of SLD-Resolution to induction, so I'm hopeful that good things will happen with a bit of elbow grease and a bit of patience.
Prolog and logic programming is one, together with its relative, constraint logic programming, and its relative mixed integer programming, which in turn is part of the broader linear and convex programming family.
What else should we put in that category?
That narrows down the already small niche where one would choose Prolog by probably a few orders.
What I've seen in practice is that while Prolog may be good at describing a solution, its performance is often too lackluster and brittle for actual deployment: it probably fits more as a prototyping language before you do a classic implementation of the solution in a more traditional language.
--
1: https://doc.flix.dev/fixpoints.html
2: https://news.ycombinator.com/item?id=25513397
Maybe a use case for new AI models could be creating more old fashioned expert systems written in LISP or Prolog that are easier for humans to audit. Everything tends to come back full circle.
https://www.amazon.com/Paradigms-Artificial-Intelligence-Pro...
Prolog could certainly use some serious improvements to its tooling. But the language is simple enough that it doesn't prove too much of an issue. You can get some much out of language it can be very powerful. In the system we've built it makes up a purely logical core that is completely referentially transparent, we leave all the ecky side effecting to a host program.
Something I never really grokked however is: when to reach for it?
It seems like a powerful tool for a certain class of problems, but somehow I never seem to stumble upon them.
An obvious candidate is problems that map clearly to solvers that can limp along with sub-state-of-the-art performance. Solving sudokus is the classical classroom example. But somehow again, never really ran into something that maps to that (I have worked mostly in compilers and distributed system, with a smattering of application programming (frontend/backend)).
Any ideas or anecdotes?
In the 2000s I was interested in inference over RDF and wanted something a bit more than RDFS and OWL and found out about Datalog:
https://en.wikipedia.org/wiki/Datalog
There wasn't a lot of literature on it or implementations then but a few years later people realized it's a great query language for complex queries that does a great job on transitive closures, can do math (unlike OWL which won't do it because Gödel proved first order logic + math is a hot mess)
I took a comparative programming languages course circa 1993, the instructor thought that that Prolog was a taste of the future of programming. At first I thought the way you can implement ordinary procedural code in Prolog was really clever but if you write very much of it I think it is awkward; for instance it is common to treat procedural success as a logical failure because that gets the behavior you want.
It's counterintuitive that you could write a reasonably fast interpreter for Prolog but Warren figured out how to do it and it really is a neat trick. In the 1980s the Japanese Fifth Generation project dreamed about parallel Prolog on a machine with 100s of CPUs but it was discovered pretty quickly that you couldn't really parallelize Prolog execution so they came up with the less expressive language
https://en.wikipedia.org/wiki/KL1
I am amused to see papers today where people are working on tasks similar to what they worked on in that project, parallelizing them with commodity hardware, and get scaling curves that look very similar to what was done with KL1. (In the end the 5GP settled on the same message-passing architecture that everybody else did until the GPU revolution came)
One of the nicest examples in Prolog is writing a parser by just writing the productions which works because Prolog's resolver is quite similar to a common parsing algorithm. In the large however, you can add a library to a normal programming language like Python or Java where you write the same grammar in a DSL and it is handled by the library.
See also production rules systems which use "forward chaining" with the RETE algorithm and variants for an approach which looks like Prolog in some ways but works in the reverse direction. My favorite example of this now is
I built a prototype of a stream processing engine where the control plane was implemented as a set of production rules that would build a processing pipeline of reactive operators, key-value and triple stores and then tear it down. Unlike another stream processing engine I worked on, mine always got the right answers. I think a production rule system could be the target of a "low code" system. I'm a little disappointed that I've never seen a Javascript framework that uses production rules because they are a great answer to asynchronous communication choreography. (See complex event processing)
The issue of Prolog is that you need to code your rules manually. Doing ML with Prolog is possible, but very clumsy. Better stick to Python.
Speed is irrelevant, because most problems suitable for Prolog are exponential. Implementation is irrelevant, because SWI-Prolog does all you need with good integrations, except that it's a bit slower. But that's irrelevant, see above.
Learning Prolog is a great experience for any advanced computer science student. It amazes, doesn't it?
Questions such as "give me table with a glossary of basic Prolog terminology with examples" as well as others can be helpful.
If your data is in a relational database consider Logica - a Datalog family language that compiles to SQL and runs naturally on SQLite, Postgres, DuckDB and Google BigQuery.
Easy to install, easy to play with in CoLab or any other Jupyter notebook.
Works for data analysis (aggregation, filtering etc) that is commonly associated with SQL, as well as recursive logical querries commonly associalted with Logic programming per-se.
Here is what it looks like for a data-analysis-ish query of finding popular baby names over time:
# Count babies per year.
NameCountByYear(name:, year:) += number :- BabyNames(name:, year:, number:);
# For each year pick the most popular.
TopNameByYear(year) ArgMax= name -> NameCountByYear(name:, year:);
# Accumulate most popular name into a table, dropping the year.
PopularName(name: TopNameByYear());
The classic grand-parent rule looks as usual:
Grandparent(a, c) :- Parent(a, b), Parent(b, c);
Here is a recursive program for finidng distances in a directed graph:
D(a, b) Min= 1 :- Edge(a, b);
D(a, b) Min= D(a, x) + D(x, b);
Links to CoLabs:
Grandparent, ancestor: https://colab.research.google.com/drive/1lujnnUOXsF6VrC9__jV...
Distance in graph:
https://colab.research.google.com/drive/1sOCODHqN0ruxZSx_L-V...
Github repo: https://github.com/EvgSkv/logica
* It is a dialect of Prolog
* It reads from and writes to SQLite database format as well as CSV. This allows you to preprocess or postprocess data Souffle produces, or Souffle reasons. E.g. you can generate bunch of data in Python, output Sqlite, reason in Souffle. Load reasoning output back into python via sqlite.
* It is pretty feature complete when it comes to logical reasoning, and transactional database management. You get best of both Prolog and Sqlite worlds.
https://en.wikipedia.org/wiki/Fifth_Generation_Computer_Syst...
>The Fifth Generation Computer Systems (FGCS; Japanese: 第五世代コンピュータ, romanized: daigosedai konpyūta) was a 10-year initiative begun in 1982 by Japan's Ministry of International Trade and Industry (MITI) to create computers using massively parallel computing and logic programming. It aimed to create an "epoch-making computer" with supercomputer-like performance and to provide a platform for future developments in artificial intelligence. FGCS was ahead of its time, and its excessive ambitions led to commercial failure. However, on a theoretical level, the project spurred the development of concurrent logic programming.
>The term "fifth generation" was intended to convey the system as being advanced. In the history of computing hardware, there were four "generations" of computers. Computers using vacuum tubes were called the first generation; transistors and diodes, the second; integrated circuits, the third; and those using microprocessors, the fourth. Whereas previous computer generations had focused on increasing the number of logic elements in a single CPU, the fifth generation, it was widely believed at the time, would instead turn to massive numbers of CPUs to gain performance.
[...]
>Concurrent logic programming
>In 1982, during a visit to the ICOT, Ehud Shapiro invented Concurrent Prolog, a novel programming language that integrated logic programming and concurrent programming. Concurrent Prolog is a process oriented language, which embodies dataflow synchronization and guarded-command indeterminacy as its basic control mechanisms. Shapiro described the language in a Report marked as ICOT Technical Report 003,[7] which presented a Concurrent Prolog interpreter written in Prolog. Shapiro's work on Concurrent Prolog inspired a change in the direction of the FGCS from focusing on parallel implementation of Prolog to the focus on concurrent logic programming as the software foundation for the project.[3] It also inspired the concurrent logic programming language Guarded Horn Clauses (GHC) by Ueda, which was the basis of KL1, the programming language that was finally designed and implemented by the FGCS project as its core programming language.
>The FGCS project and its findings contributed greatly to the development of the concurrent logic programming field. The project produced a new generation of promising Japanese researchers.
https://www.sjsu.edu/faculty/watkins/5thgen.htm
>The Japanese Fifth Generation project was a collaborative effort of the Japanese computer industry coordinated by the Japanese Government that intended not only to update the hardware technology of computers but alleviate the problems of programming by creating AI operating systems that would ferret out what the user wanted and then do it. The Project chose to use PROLOG as the computer language for the AI programming instead of the LISP-based programming of the American AI researchers.
The Japanese National Fifth Generation Project: Introduction, survey, and evaluation:
https://stacks.stanford.edu/file/druid:kv359wz9060/kv359wz90...
>Abstract:
Projecting a great vision of intelligent systems in the service of the economy and society, the Japanese government in 1982 launched the national Fifth Generation Computer Systems (FGCS) project. The project was carried out by a central research institute, ICOT, with personnel from its member-owners, the Japanese computer manufacturers (JCMs) and other electronics industry firms. The project was planned for ten years, but continues through year eleven and beyond. ICOT chose to focus its efforts on language issues and programming methods for logic programming, supported by special hardware. Sequential 'inference machines' (PSI) and parallel 'inference machines' (PIM) were built. Performances of the hardware-software hybrid was measured in the range planned (150 million logical inferences per second). An excellent system for logic programming on parallel machines was constructed (XLI). However, applicationswere done in demonstration form only (not deployed). The lack of a stream of applications that computer customers found effective and the sole use of a language outside the mainstream, Prolog, led to disenchantment among the JCMs.
Japan's Fifth Generation Computer Systems: Success or Failure?
https://www.reddit.com/r/prolog/comments/owb0xg/japans_fifth...
https://instadeq.com/blog/posts/japans-fifth-generation-comp...
>This post is a summary of content from papers covering the topic, it's mostly quotes from the papers from 1983, 1993 and 1997 with some edition, references to the present and future depend on the paper but should be easy to deduce. See the Sources section at the end.
[...]
>Prolog vs LISP
>Achieving such revolutionary goals would seem to require revolutionary techniques. Conventional programming languages, particularly those common in the late 1970s and early 1980s offered little leverage.
>The requirements clearly suggested the use of a rich, symbolic programming language capable of supporting a broad spectrum of programming styles.
>Two candidates existed: LISP which was the mainstream language of the US Artificial Intelligence community and Prolog which had a dedicated following in Europe.
>LISP had been used extensively as a systems programming language and had a tradition of carrying with it a featureful programming environment; it also had already become a large and somewhat messy system. Prolog, in contrast, was small and clean, but lacked any experience as an implementation language for operating systems or programming environments. [...]
>Fun Trivia
>The one commercial use we saw of the PSI machines was at Japan Air Lines, where the PSI-II machines were employed; ironically, they were remicrocoded as Lisp Machines.
If you're curious what the flaw is, think Empiricism vs Rationalism.
Lol.
Lmao. Even.