1. 14
  1.  

    1. 5

      https://www.philipzucker.com/tiny-sqlite-datalog/ is the most recent post in the series. Compiling to SQLite or DuckDB is a compelling option to get a lot of features and performance for not so much work. I also had some notes on compiling a Constraint Handling Rule engine (which has been done before https://github.com/awto/chr2sql ), which is elegant in that it has multiset semantics which matches SQL nicely, but inelegant that destructive rewrites need to be synchronized. I and others are still not unconvinced that a powerful and maintainable egraph rewriting engine could be made using DuckDB. Relatedly, SQLite is an excellent readily available graph pattern matching engine.

      I’ve since discovered that a lot of my python + datalog modelling needs can be achieved using clingo https://potassco.org/clingo/ . That it is not at all self evident that clingo can be used in this way from the webpage is a real shame. I feel it is marketed as a constraint solver in competition with minizinc or SAT solvers, but it is also quite a nice datalog if you write programs in that subset of the language.

      1. 6

        A quick warning about SQLite rowids - I just found out that they aren’t guaranteed to stay constant through a “VACUUM”, which makes it risky to build anything interesting on top of them at all.

        If you add a “id integer primary key” to a table you get an auto-incrementing integer primary key that won’t be corrupted by a VACUUM, so I’m busily switching a bunch of things over to using that instead.

    2. 4

      https://lobste.rs/s/o2qvt1/project_mentat is another wrapping of Datalog around SQLite.