Mark Proctor schrieb: > André Thieme wrote: >> Edson Tirelli schrieb: >> >>> ooops... correct version: >>> >>> when >>> Map( this["type"] == "Point", $x : this["x"] ) >>> Map( this["type"] == "Circle", this["x"] == $x ) >>> then >>> end >>> >> > We default to MVEL, because it's simple and already contains everything > we need for expression evaluation. However it would definitely be > possible to implement this natively, effectively "emulating" MVEL - > although you need to think what this actual buys? It doesn't buy > indexing, as it's not MVEL that is the problem here.
Ah okay, I didn't know that you are now defaulting to MVEL. Pretty much all the examples I found online and in the books don't use MVEL. You asked about what it buys: maybe nothing. I am very new to Drools and still need more experience. But now at least I *think* that MVEL rules run slower. I read on the official website that MVEL gets interpreted at runtime. Some days ago Greg did a little test: http://www.mail-archive.com/rules-users@lists.jboss.org/msg09839.html Right now it seems that Drools used from within Clojure would perform not too well in real world examples, because complex rules will have to look at 3-5 Maps. That would mean, as Edson explained, a cross product of all maps, which will reduce performance. If I don't use mvel I will manually say: $m1:Map() $m2:Map() $m3:Map() $m4:Map() eval ( $m1.get ...) eval ( $m2.get ...) and so on. In MVEL syntax it *looks* nicer, because I can make constraints directly by using the this keyword. But as MVEL is nothing but syntactic sugar over the real thing it will need to do the same when the program is running. On top of that, MVEL will be interpreted, thus resulting in even slower execution, although the rules will look more nicely. Now while I write this I just got a new thought: when the Drools engine is fed with the rules, it will also have to compile them, or interpret them at at runtime. I take a string s and do a s.getBytes("utf-8") and have this as an argument to ResourceFactory.newByteArrayResource. This is how I get rules into the Drools engine. It works. But now my new thought: shouldn't I be able to create new rules by purely writing Java code? If that were possible, then I would not compile my Clojure code into a string of either MVEL dialect or non-MVEL, but instead compile it to code which will do everything that would have happened if I had used a user readable string. Yeah, now that I think about it, then *this* is the right way how I should do it. That way I can do anything that Drools allows and not depend on any dialect. And my code would be compiled into byte code at runtime. No interpretation at all. Cool :) Now that I think about it: you could even trivially get a new dialect then with my library. "dialect Lisp" could be the attribute. That one would be as easy as mvel, but lispish (= more parens), but it would run at max speed, because it could be compiled directly into byte code. And it would be trivial to have a domain specific language with that. Could you please give me a start for a trivial example? rule "points" when Point( x == 0 ) then System.out.println("foobar"); end where Point would be a public class Point { private int x; private int y; } plus two getters and a constructor. The rule "points". If you would not have this as a file on disk or as a string in ram, but would want to add it with pure Java code, how would you then do it? André -- Lisp is not dead. It’s just the URL that has changed: http://clojure.org/ _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users