A rules engine for Clojure and ClojureScript that uses id-attribute-value tuples for flexible data modeling and reactive updates.
O'Doyle Rules is a rules engine for Clojure and ClojureScript that allows developers to define reactive logic based on a session of facts. It solves the problem of managing complex, interdependent state changes by automatically triggering rules when data is inserted or updated, using a flexible id-attribute-value tuple system for data representation.
Clojure and ClojureScript developers building applications with intricate state logic, such as games, simulations, text editors, or reactive UIs that benefit from declarative rule-based programming.
Developers choose O'Doyle for its simplicity, unified rule/query model, and seamless spec integration, offering a more flexible and data-oriented alternative to other Clojure rules engines like Clara, especially for use cases requiring fine-grained control over fact updates.
A rules engine for Clojure(Script)
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Stores data as id-attribute-value tuples, enabling automatic updates on insertions and fine-grained control, simplifying state management in games and simulations.
Rules serve as both reactive logic and query endpoints, reducing duplication compared to systems with separate rule and query definitions like Clara.
Optionally validates inserted facts against Clojure specs to catch typos and enforce schemas, with the ability to disable it for flexibility.
Supports runtime rule definition via `->rule`, allowing programmatic or data-driven rule generation for adaptive applications.
Unlike Clara, O'Doyle does not support truth maintenance, which can be a disadvantage for domains requiring automatic dependency tracking and retraction.
Out-of-the-box performance may be slower than Clara, and optimizations like node sharing require manual use of derived facts, adding complexity.
Using `{:then not=}` in joins can lead to unexpected behavior and requires workarounds, such as enforcing equality in `:when` blocks, complicating rule design.