||6 days ago|
|nix||6 days ago|
|review||4 months ago|
|sample-apps||3 months ago|
|scripts||4 months ago|
|src||3 months ago|
|tests||3 months ago|
|.envrc||1 year ago|
|.gitignore||4 months ago|
|README.md||4 months ago|
|elm.json||4 months ago|
|flake.lock||6 days ago|
|flake.nix||6 days ago|
|next-features.json||4 months ago|
|shell.nix||6 days ago|
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.