Racklog: Prolog Style Logic Programming [pdf]
plt.eecs.northwestern.edu
plt.eecs.northwestern.edu
I dig logic programming, but I wish Racklog had better (or any?) constructs for storage. Racket Datalog can serialize a theory[0], but that still means you'll have to write it in its entirety to the disk after any accumulation of facts.
In my opinion the SQL language is inferior to Prolog, but in most SQL systems incremental update isn't a problem.
Here's a comparison of SQLite with xml-files-in-a-zip-file[1] (and the zip-based file format has similar problems as serializing a Datalog theory):
> It is difficult to update individual entries in a ZIP archive. It is especially difficult to update individual entries in a ZIP archive in a way that does not destroy the entire document if the computer loses power and/or crashes in the middle of the update. It is not impossible to do this, but it is sufficiently difficult that nobody actually does it. Instead, whenever the user selects "File/Save", the entire ZIP archive is rewritten. Hence, "File/Save" takes longer than it ought, especially on older hardware. Newer machines are faster, but it is still bothersome that changing a single character in a 50 megabyte presentation causes one to burn through 50 megabytes of the finite write life on the SSD.
[0]: https://docs.racket-lang.org/datalog/interop.html#%28def._%2...
NB: GraphBLAS runs in the recently-released RedisGraph. The Datalog linear-algebra approach is so close to simi-ring primitives in GraphBLAS. A Datalog implementation on GraphBLAS could be slick as hell. The GraphBLAS code is implemented by Tim Davis, and the code is pristine.
[1] A Linear Algebraic Approach to Datalog Evaluation (2017) [pdf] https://arxiv.org/abs/1608.00139
[2] GraphBLAS http://faculty.cse.tamu.edu/davis/GraphBLAS.html Discussion: https://hn.algolia.com/?query=GraphBLAS&sort=byPopularity&pr...
Well, that rings similar to what is said about Lisp sometimes, and I think it can easily be refuted by pointing to instances where it is being used in practice[0].
There are some problems that are fairly easy to solve in Prolog, but would be very difficult to express in SQL[1]. And recursive relations, which are at the core of Prolog, only made their way into SQLite 4 years ago[2].
My comment was specifically about those Prolog/Datalog implementations in Racket. Other Prolog implementations might be dealing sensibly with incremental updates (but I don't know).
> Having seen companies where SQL was used very extensively for analytics, data storage etc I can't see how prolog wouldn't help.
You can't see how Prolog wouldn't help, as in Prolog can only be an improvement over SQL?
[0]: https://www.youtube.com/watch?v=G_eYTctGZw8
[1]: https://xmonader.github.io/prolog/2018/12/21/solving-murder-...
[2]: https://en.wikipedia.org/wiki/Hierarchical_and_recursive_que...
> Well, that rings similar to what is said about Lisp sometimes, and I think it can easily be refuted by pointing to instances where it is being used in practice[0].
I don't think this is relevant. (I'm also a very strong fan of lisp). Most criticism of lisp is to the language itself. People acknowledge that lisp is theoretically possible to solve complex problems easily but they claim this slows us down in practice. This is not my claim against prolog. I think the language is pretty powerful, but I'm not sure if we can find something as rock solid as postgres.
> Prolog can only be an improvement over SQL?
Yes, precisely.
Yea, I did misread a bit of it.
> I think the language is pretty powerful, but I'm not sure if we can find something as rock solid as postgres.
While PostgreSQL may be better for most projects, SWI Prolog is also usable for practical problems, although (if I'm not mistaken) SWI Prolog requires all facts to be loaded into memory, so there's a limitation in scale. And yes, I could't find any resources indicating whether the SWI Prolog database is ACID compliant.
But with Racklog and Racket Datalog it doesn't make sense to talk about whether they're ACID compliant as there's not yet any storage mechanisms, so they are not yet usable in any context involving persistent data. The limitations of those implementations are very different from limitations with Prolog/Datalog as such.
More to the point- SQL is a database language used to store and retrieve data, while Prolog and logic programming languages, like Racklog are languages used to reason over relations, which are naturally stored in a relational database.
So, with Prolog/Racklog, you get a database, plus an inference engine with all the power of the first-order predicate calculus. With SQL, you get a database.
You can write Racklog with the Prolog syntax as well though.[0]
> So, with Prolog/Racklog, you get a database, plus an inference engine with all the power of the first-order predicate calculus. With SQL, you get a database.
That might be true for most Prolog implementations, but Racklog doesn't have a database (and that was what I was whinging about).
[0]: https://docs.racket-lang.org/racklog/Racklog_Module_Language...
However, what I say above is still true when it comes to most Prologs. The comparisons to SQL always seem to miss the point that, though Prolog terms are stored in a database, Prolog is not a database language.