Hey Maik, I appreciate it! I'm going to look more closely at expresso, but at first glance I think these projects have different objectives. Expresso appears to offer very rich semantics in its domain, where Clara intentionally offers more limited semantics in exchange for scalability and interoperability with existing data. It targets the "lots of data and arbitrary business rules" use case, versus the algebraic focus of expresso. So while it might be possible to force these sorts of expressions into Clara, it won't be straightforward. I suspect this is a case where these tools are complementary, and expresso is better suited for the problems you describe.
In any case, expresso looks like a cool project in its own right, so I'm glad you mentioned it here. -Ryan On Monday, August 19, 2013 2:36:21 AM UTC-5, Maik Schünemann wrote: > > Hi, the library looks very interesting! > I am also working on a rule based translator as part of expresso [1], > my gsoc project Algebraic Expressions, which uses the rule based > translator > to succinctly specify transformations of algebraic expressions. > You can see some examples of this in my recent blog posts on [2]. > > It is, of course, most suited for algebraic expressions, but this > means just s-exps in clojure (it is also backed by protocols so even > java interop should be possible). > > would clara also be applicable to the domain of algebraic expressions? > If so, how does it compare? > > The one cool feature of the rule based translator i like the most is > that it has semantic matching instead of purely syntactical matching. > That means, that for example '+ can specify its own matching algorithm > (in this case commutative matching). > So > (def r (rule (ex (+ 0 ?&*)) :=> (ex (+ ?&*)))) > (apply-rule r (ex (+ 0 1 2))) :=> '(+ 1 2) > (apply-rule r (ex (+ 1 0 2))) :=> '(+ 1 2) > > ?&* here stands for: match zero or more expressions. > > [1] https://github.com/clojure-numerics/expresso > [2] http://kimavcrp.blogspot.de/ > > On Sun, Aug 18, 2013 at 9:54 PM, Shantanu Kumar > <kumar.s...@gmail.com <javascript:>> wrote: > > Thanks for posting. I will certainly explore this. > > > > Did you look at Mimir? https://github.com/hraberg/mimir Could you > outline > > how is Clara's approach different from Mimir? > > > > Shantanu > > > > > > On Sunday, 18 August 2013 23:46:14 UTC+5:30, Ryan Brush wrote: > >> > >> 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, > >> 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 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 clo...@googlegroups.com<javascript:> > > Note that posts from new members are moderated - please be patient with > your > > first post. > > To unsubscribe from this group, send email to > > clojure+u...@googlegroups.com <javascript:> > > 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+u...@googlegroups.com <javascript:>. > > For more options, visit https://groups.google.com/groups/opt_out. > -- -- 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.
