Fork me on GitHub

Thanks, Mike and W. Reading into both clara and eav sources now. However I still have strong feeling, something clever can be figured out on top of “vanilla” datalog (or very tightly coupled with). Eav seems to wrap clara, and only pretend to be datomic-like, in dsl layer. I’ll dig deeper into how attribute in conjunction with :aevt index can be used to pre-narrow down query space, as clara does with records-as-ruletypes


@misha Clara implements a forward-chaining, Rete based, engine. Datalog I believe is backward-chaining and maybe based on something like miniKanren or something? Either way, they aren’t the same. So that’s a correct observation.


And typically on this path, you’ll have to consider the trade offs of the different styles of engine.


I wasn’t suggesting changing a DSL will change the fundamentals of the underlying engine for you there. It was just if you had EAV style data to represent as facts, and wanted to use them with a forward chaining engine.


does forward-chaining give any speed, or other guarantees/properties, which clara relies on explicitly (comparing to backward-chaining)?


@misha I think that’s a more difficult question to answer succinctly. There are some papers out there that do discuss this exact topic (which I think we should work to link to in some Clara reference docs sometime soon). It looks like this paper and (a paper the above references) section on “3.2.1 Data-Driven and Goal-Driven Search” have some guidelines and more overview on the topic. I think there is a lot more out there than this though. The key concept being, • forward-chaining emphasizes the “data-driven” approach - use available facts to see what all possible “end states”/“goals” can be reached • backward-chaining emphasizes the “goal-driven” approach - see if there are available facts to support some desired “end state”/“goal”


Since they emphasize a different desired solution finding paradigm, they tend to optimize better for that purpose


Meaning, * forward-chaining is likely more performant, and also more natural, when you want the “data-driven” approach. * backward-chaining is more performant, and also more natural, when you want the “goal-driven” approach.


There are engines that do a blend of each at times too. Clara doesn’t currently. An example of how where this could apply, is that a Clara style query (typically defined via defquery) could be utilized in a way where you perhaps could say (query session :?x 5) and the engine could potentially use a backward-chaining approach to arrive at that goal. Perhaps to reduce the search space/work done. Nothing like this exists right now. I think that in the later version of Drools (popular, Java-centric (currently)) Rete-style, forward-chaining rules engine, there was actually limited support of a somewhat backward-chaining approach to deriving query results.


however, if your main target is “goal-drive”, it’d likely still be best to use something centered around a full backward-chaining engine.