swi-mqtt-pack VS souffle

Not a lot of code but a somewhat different use of Prolog than you're likely to see elsewhere. I used my fork of a MQTT library for Prolog (https://github.com/sprior/swi-mqtt-pack) to implement the central controller for my home automation system. The system responds to MQTT events and then coordinates the appropriate action by sending MQTT messages to other home services. Recent versions of SWI-Prolog also support redis and I've started using that to store device configuration and state between services. The MQTT version is actually a reimplementation of my previous version which used CORBA for inter-service communication.

I don't distribute the home automation code however it's pretty specific to my house. The MQTT library provides some building block examples.

I forked an abandoned implementation of MQTT for SWI-Prolog by olsky, my fork is at https://github.com/sprior/swi-mqtt-pack

Look in the examples directory for some basic pub/sub code.

The Prolog code that runs in my house is pretty specific to my house so I figured the best way to open source things would be as a framework more than an implementation. You can contact me via issues on the github repo and prod me into adding some more advanced examples - I've learned a lot since my last commit on the repo.

I've started using the Redis functionality recently added to SWI-Prolog, so my code now responds to MQTT messages and uses state queried from Redis to help determine what actions (implemented by sent MQTT messages) to send out. The beauty is that since I don't do anything that blocks significantly in the Prolog code it is now single threaded - even the MQTT listening. It still responds quickly enough and is MUCH easier to deal with than multi-threaded.

An example of what I'm doing is I built a bunch of ESP8266/EESP32 display devices that control neopixels/OLED/LCD displays. When one of those devices boots it sends a MQTT message announcing its location and capabilities (display type, bit depth, dimensions). Prolog receives that message and then stores that info in Redis. So that device info is all dynamic.

So then later Prolog might get a notification that something is in the driveway. All by MQTT it requests an image from the appropriate camera, then sends the image off to Sighthound and deepstack image recognition servers. The Sighthound front end sends a message back to Prolog with a description of any vehicle spotted which Prolog then matches against known vehicles. If it determines for example that a Fedex truck is in the driveway then Prolog sends notifications around the house - it queries all the display devices from Redis and then based on the capabilities of each devices creates a JSON formatted MQTT message to send to each announcing the Fedex truck. It then also sends a MQTT message to some Java code that connects with Google and sends a push message to an Android app I wrote that displays the alert on my phone and watch.

Before I switched to MQTT I was using Prolog with CORBA as the message transport and back then I also had Visual Basic and MS Agent as part of the system. One night I got bored and a little while later had 3 Peedy the Parrot characters singing Row Your Boat in a round across three different computers coordinated by Prolog. It was actually only a page worth of custom Prolog code for that.

There's Souffle[1] that can synthesize C++ for you that you then compile with the rest of your C++.

[1]: https://souffle-lang.github.io/

> In fact, we could have used Datalog to achieve our data goals — but that would mean we have to build our own Datalog implementation, backing data store, etc. We don’t want to do that.

Surprising that creating a whole new language made more sense then a backend. I wonder if they did a proof of concept with an existing logic system like Souffle¹ or Rel² first.

¹ https://github.com/souffle-lang/souffle

² https://relational.ai/blog/rel

Consider using Datalog (the incredible subset of Prolog) for this perfect use case. Compared to Prolog, you get:

1. Free de-duplication. No more debugging why a predicate is returning the same result more than once.

2. Commutativity. Order of predicates does not change the result. Finally, true logic programming!

3. Easy static analysis. There are many papers that describe how to do points-to analysis (and other similar techniques) with Datalog rules that fit on a single page :O

Souffle[0] is a mature Datalog that is highly performant and has many nice features. I highly recommend playing with it!

[0] https://souffle-lang.github.io

Still, there are many useful tools based on these ideas, used by programmers and mathematicians alike. What you describe sounds rather like Datalog (e.g. Soufflé Datalog), where you supply some rules and an initial fact, and the system repeatedly expands out the set of facts until nothing new can be derived. (This has to be finite, if you want to get anywhere.) In Prolog (e.g. SWI Prolog) you also supply a set of rules and facts, but instead of a fact as your starting point, you give a query containing some unknown variables, and the system tries to find an assignment of the variables that proves the query. And finally there is a rich array of theorem provers and proof assistants such as Agda, Coq, Lean, and Twelf, which can all be used to help check your reasoning or explore new ideas.

It's true that this SPARQL-inspired view of Datalog as a triplestore query language is quite a narrow interpretation compared to something closer to the academic Prolog roots like https://souffle-lang.github.io/ - what do you feel are the most important differences?

Very cool! I love the sqlite install everywhere model.

Could you compare use case with Souffle? https://souffle-lang.github.io/

I'd suggest putting the link to the docs more prominently on the github page

Is the "traditional" datalog `path(x,z) :- edge(x,y), path(y,z).` syntax not pleasant to the modern eye? I've grown to rather like it. Or is there something that syntax can't do?

I've been building a Datalog shim layer in python to bridge across a couple different datalog systems https://github.com/philzook58/snakelog (including a datalog built on top of the python sqlite bindings), so I should look into including yours

TerminusDB CTO here.

Echoing what triska said, CLP(ℤ) and friends are some of the most under-appreciated aspects of prolog implementations.

I'm amazed that programmers still don't have access to CLP when trying to do scheduling and planning solutions.

As an example in practice, what if you want to know about a transaction in which a number of entities transitively had holdings in one of the beneficiaries of the transaction at that particular time. The date window is not known, and the date windows are important in the ownership chain as well as the transactions that are being undertaken.

With CLP(FD) you can ask for a window of time, and the solution will zoom in on an appropriate time window which exists for the entire chain and match the time of the transaction.

Now try to do this query in SQL. It's almost impossibly hard.

I can't wait until I have the time to implement constraint variables for TerminusDB, but at the minute we are still working on more prosaic features.

Aside from that there are very interesting program correctness and optimisation systems which are based on prolog (usually a datalog). For instance Soufflé: https://souffle-lang.github.io