I have a "toy" version of Datalog working now here: http://code.google.com/p/clojure-datalog/
By "toy" I mean it works but is incredibly slow and wasteful. I would not use it in a production system. "Real" Datalog is coming, but I'm now doing research regarding the correct approach. Note, that Datalog is really a query engine, not a computation engine. It is most definitely not Prolog. It you need computation I suggest you look at one of the versions of the "Cells" approach that are out there. There is a simple one in Contrib. On Sat, Feb 21, 2009 at 7:12 PM, Timothy Pratley <timothyprat...@gmail.com>wrote: > > Hi Max, > > Clojure has watchers on IRefs which can do most of what you are > describing. > auto-agent by SS in contrib allows you to define formula which are > automatically updated (inspired by cells - search for cells on lib > page and group). This gives a simple rule system, leaving just the the > GUI interaction - which is simple also! Your specific example is not > far from > > http://github.com/timothypratley/strive/blob/c430759c4a46f1a37c272d7448975b6bc24951b0/src/clj/cells.clj > however in your case you would want to use an auto-agent to calculate > the dependency. Also you want your GUI updating back to the formulas, > again someone has done this for textboxes: > http://bitbucket.org/ksojat/neman/src/tip/src/net/ksojat/neman/cells.clj > > So I think you can achieve a lightweight solution quite easily using > these parts. > > However if you are interested in more complete 'rules' systems then I > suggest searching for Datalog on this group. JS is implementing > Datalog logic querying and has already made great progress. hoeck > wrote a wrapper for IRIS reasoner with macro support (DSL style) which > allows you to write and query rules. > > > Regards, > Tim. > > > On Feb 20, 9:04 pm, max3000 <maxime.lar...@gmail.com> wrote: > > Hi, > > > > I'm new to clojure and lisp in general. I'm trying semi-porting a real > > world application but at this time I lack patterns to reason about > > clojure solutions to problems. I thought I'd ask the community about > > one such problem I'm facing. > > > > To give a simple example for the following discussion, suppose we have > > the following: > > - A "temperature" fact that is updated by some external connection to > > a thermometer. > > - A "heater on" fact that depends on the temperature. If the > > temperature is, say, < 20 degrees true otherwise false. > > > > - Requirements - > > We want to have a collection of "facts", all mutable (i.e. they will > > change over time). > > Each fact is displayed in a GUI. So, there must be a callback > > functionality for when the fact changes (observer pattern, GUI being > > the observer). > > Some facts are "standalone" while others are based on other facts. In > > effect, these other facts are observers of the standalone facts (or of > > other dependent facts). > > Any component (GUI included) can change any fact anytime. When this > > happens, all dependent facts must be recalculated and all observers > > called. > > > > I implemented this in Java like so: > > - Fact class implements observer pattern (w/ PropertyChangeSupport) > > - GUI linked to all facts through addObserver > > - Rules based engine (drools) to update facts when they change (uses > > addPropertyChnageListener/removePropertyChangeListener implemented by > > facts). Whenever a fact change Drools refire rules (Drools handles > > dependencies). > > > > Drools is great but is rather heavy for my needs. My rules/ > > dependencies are really not that complicated. Besides, I would much > > rather have them as a series of clojure functions. > > > > *** > > At this point, I'm a bit lost trying to match these requirements to a > > clojure design. I suppose: > > > > - The facts must be referenced by some unique ID, probably a keyword. > > - The Fact class should be ported to a structmap + related functions. > > - Fact should include a function to set it. (If the set doesn't change > > anything, no callbacks are called). > > - Fact should include a collection containing callback functions. > > Anyone can hence "register" their callback. BUT: how to handle > > unregistrations? Is this a simple matter of passing the same function > > that was used to register? > > - The dependencies are really not part of the facts themselves. I > > should handle them as a series of clojure functions (or should I?). > > E.g.: > > > > (defn rule1 [] (set-fact :heater-on (> (get-fact :temperature) 20))) > > > > - But should I also register dependencies myself? E.g: > > > > (add-fact-observer :temperature rule1) > > > > - Is there a way to make this automatic given that my rule (rule1) > > already contained this information? > > > > - And what about the GUI (in Java)? Basically, each GUI element knows > > what fact it is bound to, so the GUI code itself drives the > > addObserver's. So, I would need to expose an interface in clojure. > > > > (proxy someJavaInterface observer fact-in-java > > (fn [] (add-fact-observer fact-in-clojure (fn [] …callback > > observer…))))) > > > > - ??? How to make a mapping between fact-in-java and fact-in-clojure? > > > > I could go on but I think that is more than enough. > > > > Is my basic design sound? What about the questions I face? (Automatic > > detection of dependencies, mapping between keywords and something java > > can muster, etc.) > > > > I'm really not looking for a complete how to, just general guidance in > > the design. Of course, code fragments are always welcome. ;) > > > > If you have made it this far, thanks! > > > > Max > > > --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
