Perhaps the best aspect of Clojure is how it can adopt the best ideas from other domains to concisely solve problems, as we've seen with core.logic, core.async and other libraries. I recently came across a problem domain that is easily expressed in forward-chaining rules, and found Clojure to be a powerful way to solve it.
While working through this problem space I started to suspect there is a more general need for forward-chaining rules in Clojure to complement core.logic and other libraries. So as a side project I implemented a raw but working engine to do so. I'm posting here to share a draft of this engine, its major design goals, and to ask for input on how we should approach forward-chaining rules in Clojure in general. The rationale and some examples are on the github page for this engine<https://github.com/rbrush/clara-rules>, which I've tentatively named Clara. The state of the code isn't where it needs to be yet; I've been learning the intricacies of Rete and discovering better ways to solve problems along the way, and some of that is reflected in the code base. However, the major pieces of design and functionality are in place, so I'd like to get input on those. The idea is to draw a bit from Jess and Lisa, with the Java interop strength of Drools, but the advantages and idioms available in Clojure. The major goals are: - Focus on problem spaces naturally expressed as forward-chaining rules. Data-driven needs like eventing, data validation, or application of arbitrary business rules fit here. - Embrace immutability. The rule engine's working memory is a persistent Clojure data structure that can participate in transactions. All changes produce a new working memory that shares state with the previous. - Rule constraints and actions are simply Clojure s-expressions. - First-class Java interoperability and APIs. This should be an alternative to Jess or Drools from Java-land. - Usable either as a library to simplify Clojure code, or as a DSL to externalize business logic. - Working memory facts are typically (but not exclusively) Clojure records or Java objects following the Java Bean conventions. - Support the major advantages of existing rules systems, such as explainability of why a rule fired and automatic truth maintenance. - Collections of facts can be reasoned with using accumulators similar to Jess or Drools. These accumulators leverage the reducers API and are transparently parallelized. - The working memory is independent of the logic flow, and can be replaced with a distributed processing system. A prototype that uses Storm <https://github.com/rbrush/clara-storm> to apply rules to a stream of incoming events already exists. I'd love to hear thoughts on a couple questions: What else would you want from a forward-chaining rules engine in Clojure? What design changes would you make, given the above criteria and examples on github? All thoughts are appreciated! -Ryan https://github.com/rbrush/clara-rules https://github.com/rbrush/clara-examples https://github.com/rbrush/clara-storm -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
