I didn't want to jade the group's response but I personally had more interest in an inference engine as well. I've used Drools, as well as ILog on several large projects but didn't like the proprietary nature of their underlying language implementations. In short their implementation was a proprietary dead end in terms of extensibility. The line between the inferenced domain and the world that the inference engine needs to operate within I've found to be entirely too restrictive in those implementations.
I've worked with Jess and found it to be comfortable in terms of the LISPy syntax and design approach but again rather than being built bottoms up on top of a full featured functional language it has defined perimeters (basically a sandbox) that is less than ideal. Additionally, the fact that it requires a distinct commercial license for such use is a non-starter. Out of all the inference engine implementations I'm aware of, the foundational concepts in Jess are a good starting point to develop requirements from. Once a core inference engine is constructed on top of a progressive functional langauge such as Clojure, it becomes a much easier exercise to build out the tools on top of it that can match the capabilities of, for example Drools. On the other note, yes I am familiar with Kanren. Converting it from scheme to Clojure would be an interesting exercise and quite honestly not all that difficult. I guess I'm still attracted to the inference engine however. I think there is new ground to be covered there that I might not be able to cover with re-implementing Kanren. With an Inference engine we could achieve seemless integration with an underlying language on par with Clojure's STM integration. This something that I do not currently see in the marketplace. On Jul 26, 9:34 am, jim <jim.d...@gmail.com> wrote: > Hi. I did the min-kanren implementation and the second tutorial. > > I think the better path would be the inference engine in Clojure. Are > you familiar with Kanren? (not mini-kanren but the full blown system) > I'd be interested in your opinion of it compared to Prolog. I would > think implementing it in Clojure would be more productive than Prolog. > > One thing I'd like to do is implement a business rules engine in > Clojure running the Rete algorithm or something similar. Sort of a > Drools in Clojure. > > Jim > > On Jul 26, 7:15 am, "p.bernard" <paul.bern...@teleapp.com> wrote: > > > > > I've been consider doing some work in the rule process space and would > > be interested in the groups feedback. > > I'm considering two separate efforts, but will only have the time to > > work on one, and I'm curious which of the two the group would find > > collectively more useful and of interest in terms of either use or > > participation. > > > 1. Development of an Inference engine in Clojure. > > or > > 2. Development of a Prolog interpreter in Clojure: > > > I'm familiar with with the following logic programming > > work:http://blog.fogus.me/2009/01/15/on-lisp-clojure-prolog-pt-1/http://cl... > > If folks know of others please feel free to pitch in. > > > While interesting as a starting point these logic programming efforts > > don't quite have the formality or thoroughness that would be required > > to go to production. A more formal and dedicated effort might produce > > something more concrete for the group. > > > I was not able to find anything done to date with respect to a > > reasonable implementation of an Inference engine but suspect that this > > might be equally useful. If folks know of any work done in this area > > with respect to clojure I would also appreciate the feedback.- Hide quoted > > text - > > - Show quoted text - -- 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
