
Racklog: Prolog Style Logic Programming [pdf] - mindcrime
https://plt.eecs.northwestern.edu/snapshots/current/pdf-doc/racklog.pdf
======
hjek
See also Racket Datalog: [https://docs.racket-
lang.org/datalog/index.html](https://docs.racket-lang.org/datalog/index.html)

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...](https://docs.racket-
lang.org/datalog/interop.html#%28def._%28%28lib._datalog%2Fmain..rkt%29._write-
theory%29%29)

[1]: [https://sqlite.org/affcase1.html](https://sqlite.org/affcase1.html)

~~~
gnulinux
Hmm I'm fine with prolog, I love it, but I'm not sure how it can be used in
practice. There are really efficient SQL implementationa like postgres that we
already spent millions of dollars and man-decades developing. My guts would
tell me whatever prolog implementation I'll use, they will not be as reliable
as one of these battle tested technologies. Maybe there is an opportunity
here, if there is a demand for prolog. Having seen companies where SQL was
used very extensively for analytics, data storage etc I can't see how prolog
wouldn't help. Of course there are cultural problems too, people know SQL, but
only a tiny minority know prolog.

~~~
hjek
> Hmm I'm fine with prolog, I love it, but I'm not sure how it can be used in
> practice.

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](https://www.youtube.com/watch?v=G_eYTctGZw8)

[1]: [https://xmonader.github.io/prolog/2018/12/21/solving-
murder-...](https://xmonader.github.io/prolog/2018/12/21/solving-murder-
prolog.html)

[2]:
[https://en.wikipedia.org/wiki/Hierarchical_and_recursive_que...](https://en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL)

~~~
gnulinux
I think you misread my comment. I am pro-prolog but I'm skeptical of some of
the details such as ACID complaint, being battle-tested, getting predictable
performance etc.

> 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.

~~~
hjek
> I think you misread my comment.

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.

