Christopher, thanks for the info. My hesitation with Datalog comes from the separation from database and general purpose code. In a way it has the same problem as SQL. Once you get your result set then you are on your own. Clojure is a fantastic language, but I'd like to extend that same logic model to the client. Usually performance is the culprit, if I need to issue several datalog queries to get data to the browser. Once on the browser I can't reuse the same rules.
What I said is not all true. I could possibly use core.logic and reuse the rules. Then what is left is the difference between forward chaining and backward chaining. From what I can research the first is more data driven and the second is more goal oriented. My use case is general information systems, so I thought forward rules would be more appropriate. One other thing I did not know is that there are Datalog to SQL bridges that is good to know. On Wednesday, October 30, 2013 6:27:31 PM UTC-5, Christopher Allen wrote: > > If you just want to build up and apply constraints, Korma can do that. > > If you want something closer to Datalog with unification, then a Datalog > to SQL bridge is the most practical of largely impractical choices. > > On Tuesday, October 29, 2013 9:35:45 AM UTC-7, ArturoH wrote: >> >> I am interested in writing a better SQL mapping tool for clojure. Because >> I am not convinced that simple SQL composition is effective, for various >> reasons. I rather have some kind of logic construct that I could use to >> generate SQL from. My main concern is to eliminate the hard boundary >> between the RDBMS and the rest of the code. Any given logic construct would >> a candidate to be translated into SQL or executed inside the JVM. >> >> One option that I have been considering is a production rule system. The >> most popular are based on the rete algorithm. I know there are a few open >> source productions systems out there, but I think translating into SQL from >> an established rule language may be too complicated. At this point I plan >> to use the language extensions proposed by Anurag Acharya, that eliminate >> sequential guards and adds collection support. The reason is that I want to >> process the rules in parallel, and I want to be as close to SQL as >> possible. Clojure pure functions could also be called from within a >> production rule. >> >> The use case I have in mind is regular IT apps, not necessarily complex >> decision systems. I just find myself writing too much code, and often an >> SQL a clojure procedure and a function in the GUI will have some aspect of >> the same business rule embedded in the code. A layered approach helps to >> alleviate the problem, but it still persists. More support for declarative >> code may be the answer. But other than SQL or LINQ and other minor >> examples, there is little support for declarative code for average IT >> systems. >> >> Anyone has any ideas/opinions? >> >> I would appreciate any feedback. >> >> Arturo Hernandez >> > -- -- 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.
