oakes / odoyle-rules

A rules engine for Clojure(Script)
The Unlicense
530 stars 20 forks source link

Syntax rationale? #11

Open allentiak opened 3 years ago

allentiak commented 3 years ago

I really value almost all of the odoyle's design choices (particularly, spec support!). The only one I find a little bit strange is its syntax. Could you please elaborate on this? (Why you chose it? How you designed it?...)

I'm asking this because I've been checking minikusari, and whereas it is definitely not optimized for performance in the way odoyle is, I really like that it uses Datalog's syntax. In this way, it is possible to use both systems without having to learn a new syntax...

oakes commented 3 years ago

Hmm well that's a good question. The datalog syntax is quite a bit more complex to parse and i guess that's because it's a full-fledged query language. One big difference between a rules engine like o'doyle and a datalog based database is that the former is basically push-based and the latter is pull-based.

In a normal database, you craft a query with whatever query language it provides, and it does the work to give you a result when you run the query. In o'doyle, you make rules that produce the result you want right when fire-rules is called, not necessarily when you query it. You don't need a query language; you just make rules whose :then blocks contain normal clojure code, and the engine will constantly produce the results.

I gave an example of this here: https://github.com/oakes/odoyle-rules/blob/master/bench-src/todos/README.md

So the short answer is that o'doyle's syntax is different because it just has less syntax.

allentiak commented 3 years ago

that's a good question.

Thanks!

So the short answer is that o'doyle's syntax is different because it just has less syntax.

Then, what about using a subset of datalog's syntax?

In this way, 1) you would be able to extend it if needs arise; and, 2) at the same time, the syntax would be one and the same, avoiding wheel re-invention... (which was my original point) 3) Although I haven't checked Data[Script/Hike]'s code, maybe you could even reuse some of their parsing functions?

oakes commented 3 years ago

I guess it's a subset right now? The tuples in the :what block exactly match the ones in datomic's or datascript's :where. Everything else (:when and :then blocks) are just arbitrary clojure code so they don't impose any special syntax.

At any rate, learning new syntax will be the easiest part of anyone's journey....don't let it dominate your attention. The underlying design is way more important. If you figure out how to use o'doyle, you can probably figure out my other rules engine immediately, even though it's a completely different language.

allentiak commented 3 years ago

At any rate, learning new syntax will be the easiest part of anyone's journey....don't let it dominate your attention.

I see your point, and I think you're absolutely right.

That being said, my "one-language" argument stems from elsewhere. I was more thinking of a scenario where I would have to migrate from one library to another one. In that case, I would like to abstract the language from the engine as much as possible, so I can minimize the rule re-writing effort. If that scenario arises, I would certainly not like to have to migrate from/to clara from/to o'doyle...

jtrunick commented 1 year ago

Although I'm not far into using O'Doyle, I'm attracted to the simple :when statements. I'm considering parsing the rules to embellish them myself, specifically for fetching the data that is being referred to. I'm not sure how that will yet pan out, but it looks more straightforward at this point.