Fork me on GitHub

first paper link is $$$, thank you, Mike


(2nd link is probably golden too, but, man, 800pages kappa)


Another point to consider is that since forward-chaining computes results upfront, applying diffs e.g. new facts can be quite fast once an initial "batch" has been completed.


I wonder if datomic's datalog is still implemented with backward chaining, given team recommends to put the most specific query clause first


so what I am actually trying to achieve/figure out, – is how to sneak rule-based parasite system onto datomic/datascript, without any changes to user api, e.g.: there are d/q, d/transact, d/transact!, and I'd like the defrule to be just a composition of those from user point of view (with some cleverness under the hood, like extra working memory or knowledge base). For example, clara-eav seems to have lots of internals leaking out into user api, making it less and less looking like datomic/datascript, which people already are used to "dev-flow"-wise. One seemingly minor, but I think very important from usability/adoption point ov view – is it is still dsl with custom tokens, which will be highlighted all over the ns as undefined in Cursive and probably some other IDE, on top of being yet another DSL you need to remember semantics of.


re dsl, from

;; Clara fact syntax
[?eav <- :todo/text (= (:e this) :new)]
[?eav <- (a/all) :from [:eav/all (= (:e this) :new)]]

;; ClaraEAV fact syntax
[?eav <- [:new :todo/text]]
[?eav <- (a/all) :from [[:new]]]


why this, if everyone is familiar with let-style bindings, and many libraries manage to represent domain-specific bindings with their custom let forms, eg: let for monads: let for generators: