[rules-users] Maps in Drools

[André Thieme]

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/