Fork 0
A bad datalog, which hopefully will become better over time. Maybe someday it'll even be released as a package! https://datalog.bytes.zone
Go to file
Brian Hicks 4f55a607d4 remove the checkPhase 2021-09-14 05:27:43 -05:00
nix update registry 2021-09-13 17:28:51 -05:00
review don't use custom type constructors rule 2021-05-10 22:23:45 -05:00
sample-apps go back to the single-construction API 2021-06-14 17:26:15 -05:00
scripts add elm/parser 2021-05-25 16:07:38 -05:00
src go back to the single-construction API 2021-06-14 17:26:15 -05:00
tests go back to the single-construction API 2021-06-14 17:26:15 -05:00
.envrc nixify 2021-04-27 20:41:10 -05:00
.gitignore make nix-build work 2021-05-13 16:32:34 -05:00
README.md credit Jamie for his help 2021-05-12 15:42:19 -05:00
elm.json add elm/parser 2021-05-25 16:07:38 -05:00
flake.lock flakeify 2021-09-13 17:24:18 -05:00
flake.nix remove the checkPhase 2021-09-14 05:27:43 -05:00
next-features.json update roadmap 2021-05-12 15:18:03 -05:00
shell.nix flakeify 2021-09-13 17:24:18 -05:00


Bad Datalog

This is a not-so-good datalog that someday might grow into a less-bad datalog.

It's got some stuff in it:

  • A simple relational database for storage and queries
  • Datalog frontend to give a nicer frontend for writing queries
  • All in Elm, so you can embed it in your frontend project (if you're using Elm... which I am!)

It still needs some stuff before it's "good":

  • A sample app
  • Aggregation of any kind
  • Any level of query plan optimization (in fact right now we definitely have the worst possible performance in a lot of cases.)
  • It might not be safe to store databases in the model (that is, it will break the Elm debugger because the Set implementation we use embeds a comparison function. It would be possible to take this out, but would require more effort than I want to make at the moment I'm writing this README.)
  • Nice errors that say exactly where the problem is in the query
  • A DSL to parse from a string to a datalog program (this would make it way easier to introduce new variables, among other things.)
  • Warnings for situations where queries might not work the way you expect (e.g. doing reachable(a, c) :- reachable(a, b), reachable(b, c). instead of reachable(a, c) :- link(a, b), reachable(b, c).)
  • Indexes or primary keys of any kind for faster queries
  • Named fields instead of just using positional semantics.

I plan to implement those things in roughly that order (maybe adding or dropping a few as I go) and releasing this as an Elm package when it's ready. The rankings are in next-features.json in the root of this repo, and can be fed into elo.bytes.zone for further ranking.


A prior version of this project (88454c3c and prior) used prolog semantics internally instead of a relational algebra (think "lots of loops" instead of "query plan".) This turned out to be kind of a hassle, unfortunately, and I felt very stuck.

One day I complained about this in the #alumni-checkins stream on the the Recurse Center Zulip, and Jamie Brandon helped me a lot by pointing out that industrial datalogs have gone away from prolog semantics to relational algebras, and that I should consider doing the same. That got me unstuck, and now here we are!

If you used datalog.bytes.zone before, you'll have used the prolog-like version. I haven't gotten to the point where it makes sense to write the parser for the DSL for the new version, but soon the current code in this repo will live at that location too!

Here are some miscellaneous ideas on the Elm Discourse which introduce what I think might be possible: Brainstorming: relational programming in Elm


This doesn't have a license yet. It'll probably be MIT or BSD-3-Clause or something similar eventually, but for now it's source-available but all-rights-reserved.