What happens if Dr. Wielemaker is hit by a van?

For yall the answer is yes as it is written by Paulo Moura who is very keen on portability. The SWI-Prolog version has some additional declarations to make the development tools cooperate better with it.

The redis package is more complicated. Several Prolog systems have emulated the SWI-Prolog foreign language interface. That makes porting parts fairly easy. Other parts depend on more unique features of SWI-Prolog though. Think of dicts (easy enough to implement for any Prolog system but it must be done in the core system), blobs that are used to encapsulate foreign resources in a safe way and provide garbage collection for them (also not that hard for any system than already has atoms with garbage collection) and threads (hard if you do not have them). In general the more modern libraries are harder to port as they more and more rely on SWI-Prolog features.

That is on the agenda to be resolved. How is still an open question. If anyone reads this who has the necessary skills or wants to learn them and is interested to play a role in this, please contact me. The whole thing depends on people, money and a plan :slight_smile: Roughly I see three ways out. One is a big enough stakeholder to make this happen. Another is enough work for SWI-Prolog Solutions that allow hiring someone to take this role and the last is to bring a larger number of stakeholders together to establish paid support that is backed up either by hiring someone or a diverse network of community members capable of covering most areas. Other suggestions?

1 Like

Dear Jan, all,

The question raised by JDS/free-variation, is something that I have raised
in the past both in the old mailing list and at a private discussion with Jan
on ICLP 2015.

I think it is a serious matter and is likely to be a hindrance in people/companies
using SWI-Prolog.

Although SWI is open source and can be cloned, users requiring longevity
cannot depend on the chance that someone competent enough might pick up the project.

My opinion, now and then, has been that a group of people that have required skills and interest
in SWI should form a support committee that will engage in maintaining the project.
To my understanding there are currently at least 2-3 people that understand the deep innards,
2-3 people that understand critical extensions and 2-3 people that have a reasonable
understanding of the overall direction of the project.

Forming a “back-up” committee that will pledge an effort to a continuation project,
that will at a minimum ensure it runs on supported OSes and fix bugs,
can only have a positive impact to people/companies deciding to commit to using SWI.


Nicos Angelopoulos

1 Like

What @nicos is suggesting makes loads of sense to me, since it seems to reproduce the structure of successful longer-term open-source efforts. Of course the question is whether these groups of 2-3 people exist. I’d love to volunteer but I don’t have sufficient knowledge of programming language design to be of much help. Perhaps one could help with some of the libraries?

It’s funny (or a little sad) but I’ve always tried to use as few of the Swi-specific libraries as possible exactly for the reason that I’m not sure that my code will still run after 40 years, if I do. I’ve already basically lost the ability to run all the Prolog code I wrote in 2011 for my undergraduate dissertation, which was written for the proprietary Win LPA compiler. I’m always worried that using any advanced features of any particular Prolog implementation will only hurt the portability of my code somewhere down the line.

But I’m heartened by the news that there are trams in Amsterdam. Dr. Wielemaker is tougher than a tram.

(I’m trying to start a meme :).


In my discussions with Paulo Moura he explained that one key motivation for Logtalk is portability, so that one can use its libraries and thereby seamlessly use any of the support “backend” Prolog systems.

If future existence of a Prolog is a key stake, then Logtalk could be a good choice. But, then again, its also maintained by one person … but, it does change the nature of what needs to be maintained – a VM or libraries and preprocessor code.


I seriously investigated writing a book along these lines last fall. Ultimately, the financial reward wouldn’t have been enough to cover my living expenses while writing it.
It still might happen - I’m approaching retirement age, and at some point might decide to do it as a retirement project.


I have been wondering about LogTalk. Yes that too is one individual, but then we would at least have two, however disjoint, individuals :slight_smile:

It’s an issue in part because Prolog is that rare language that has somehow survived despite its not being taken up much by US academics and US tech companies, vs its relative popularity in Latin America and Europe. (From where I sit it seems that the role of deviant academic programming language in the US is Haskell.) It’s interesting from a “sociological” perspective, and suggests that perhaps its survival might require some support from, say, EU institutions. Has this been tried?

What I mean is this: SWI Prolog could be designated as a European technology project that is clearly valuable, and therefore needs some support, perhaps to fund postdoc positions and its promotion in universities and startups. The French through INRIA do this sort of thing, and hey, the language is originally French :slight_smile:

It would be just amazing if you were to write that book. I get that the book itself isn’t terribly likely to provide the necessary financial return, but I wonder if one couldn’t rig up a kickstarter-like campaign to provide the funding?

1 Like

I had a little revealing experience some time ago:

I wanted to port some Prolog code C – and I immediately noticed how much harder it is to express in C ideas clearly using its data structures and code.

After Prolog i felt like I fell down a few levels in an elevator – to a bottom floor.

Ultimately, what is most compelling in language choice – is programmer productivity – I wonder how Prolog could be positioned very competitively as a productive language for small to medium sized development shops – which are the workhorses (i think) of the (European) economy.


Looks more that if either of the two is hit by a van you have a problem :frowning: Logtalk is great if your Prolog needs are basic. It provides a portable library and a portable code reuse and encapsulation system that is more advanced than what any Prolog system offers.

If your Prolog needs include the stuff from SWI-Prolog that you do not find elsewhere or not in the combination you need it (e.g., unbounded integers and tabling with well founded semantics) you are in the “either one hit by a van” position. Note that Logtalk provides only pure Prolog libraries. If you depend on such libraries from SWI-Prolog you can port them along with your system as the BSD license allows for this. Most of these good old libraries are anyway around in most systems and/or are easily ported as their origin is typically from the 80s and 90s, predating lots of interesting developments

Interesting thought. Something to keep in mind and if anyone has concrete leads to make this work, please share. On the other hand, development was for over 30 years in academic. I think we can get enough commercial stakeholders together to keep it afloat in a sustainable way that doesn’t depend on a single individual. The system is pretty mature and there is quickly growing commercial interest. Let us go for it!

Do you think on something like Pharo Smalltalk did on INRIA (-> Stephane Ducasse for example as one leader and prof.)?



Yes, I totally agree. Recently I resolved: this year I will learn an up-and-coming language. I chose Rust. Within minutes I felt depressed: you have to actually compile the program and run it at the command line. Your program now is this blobby thing, lying on your filesystem, which you invoke over a data file. It’s all so archaic: you can’t talk to the system, interactively.

Two of my best NLP professors in grad school, when pressed on which platform they preferred to work on (as they taught courses in Python), eventually admitted: Prolog. One American, the other at Oxford.

The two main complaints by those who have tried to use Prolog at scale are:

  1. Speed. This is of course a real issue. “It’s kinda slow”, shrugged one of those profs ^.
  2. Tangled programs, unmaintainably complex logic, so that debugging or even understanding what’s going on becomes impossible. My view about this is as long as one doesn’t dynamically assert/retract, and religiously maintains a growing set of unit tests, the great power of the language – which leads to the complex logic of programs – is manageable. Doing so is appropriate for concurrency in any case.

I suspect the ship has sailed in the US. I agree that European small/mid dev shops could well be the commercial target.

One feature that could help a lot is an interactive jupyter-like tool. Does something exist? I know about PlDoc, but I understand it’s not interactive?


Quoting that because hopefully someday it will be at the start of a chapter in a book.

Have you seen SWISH?

This site has Useful Prolog references and many other such items in the categories

Useful Code
Nice to know

Is there is something you think is missing the Wiki topics are just that Wiki so edit away.

This is an interesting discussion. I love the Prolog.I have wanted to start a project on Prolog many times.Every time I missed the little things. I cannot work normally with the DBMS. Of course I can use ODBC, but this is a bad way in 2021. There are always not enough little things, there is no time to do everything yourself. I would like to take ready-made blocks and connect them, I cannot be distracted from the main task.I sigh every time and choose the language in which I will do my task quickly.Now I am writing in Erlang, but I hope to do something in Prolog

It would be good to learn about those little things and then address at least some of them, to reduce the friction in getting up and running.

Perhaps ODBC is out-dated, or perhaps it can be improved significantly, so it just works with one or a few lines of code that can be copied and pasted.

Various databases these days seem to have a REST interface - perhaps that’s the way to go.


I think Prolog’s speed comes down to three things:

  1. Knowledge how to program it succinctly – speed is often a matter of how the solution is expressed. From what I understand Prolog can be close to C, when done right.

  2. the ability to cache solved goals – i.e. tabling – thereby avoid computation (at the cost of memory)

  3. Prologs inherent hash-based / indexed access to facts – while other languages offer approaches, including pointers, arrays, and i guess optimized matrices (tensors).

However, for many enterprise application I suspect that the hash-based access is not a bottleneck.

I think, it would be great to understand what drives development language and environment choice in development shops.

I would suspect that one is the customer existing environment they are working into – often, its based on buy-in of cloud providers – e.g. MSFT Azure, Google Cloud or Amazon AWS.

And, then there are the secondary development environments that come with it - e.g. the .NET ecosystem, or more open systems with Amazon and Google – usually, aligned with mainstream languages.

I guess, if swi-prolog could support for those ecosystems that would be a significant step towards adoption.


I think with a module system, and perhaps somewhat better support for interface (e.g. enforcing public / private) – code complexity can be managed.

for example i want to be able to access postgree via postgresql wire protocol. I want to have a pool of connections.

Some companies have a tool to post features and then have users vote on them – perhaps this is what is needed here as well.