[rules-users] Drools and Clojure

[Mark Proctor]

André Thieme wrote:
> Mark Proctor schrieb:
>   
>> André Thieme wrote:
>>     
>>> Mark Proctor schrieb:
>>>   
>>>       
>>>> Map( this['c'] == 206 )
>>>>
>>>> That should work, we do support MVEL syntax for maps and arrays - we 
>>>> just don't suppor method calls, yet.
>>>>     
>>>>         
>>> Hello Mark. I just tested it and it indeed works for me.
>>> Although as I understand it, this will be compiled into an expression
>>> using eval (or it will even be only interpreted).
>>> So, if that is true it can't bring any performance advantage.
>>>   
>>>       
>> yes, no performance benefit. As this form of use is a "return value" 
>> really, it should be possible to index (if we assume that nest objects 
>> do not change). Although it's a fair bit of work to do this, but 
>> interesting work - if anyone wants to help out :)
>>     
>
> It would be fantastic if there was the same optimization support for
> Maps available as it exists for POJOs. Edson gave a great explanation
> on how things slow down for cross products.
>
> I thought about one thing:
> Could there could maybe be a new attribute, "immutable true" or
> something like that, which would signal that the rule writer promises
> the engine that only immutable objects are used?
> That way my lib could implicitly always set that attribute.
>
>   
It could certainly be done, lots of ways to cook this - from annotation 
on the pojo, type declarations and possibly some annotation on the rule 
or pattern itself. If you want to take a crack at this, you know where 
to find us :)
http://www.jboss.org/drools/irc.html

Mark
>   
>>> The syntax is nothing I worry about. In Clojure, which is a Lisp, I have
>>> macros and can remove any obstacles in the syntax I like. It is trivial
>>> to develop new domain specific languages for rules. So, my rule syntax
>>> for Clojure will look very lispy, and each user is free to change and
>>> extend it. I will also allow the RHS to be written in Clojure code, no
>>> Java needed.
>>>   
>>>       
>> Btw if you are doing "lispy" stuff:
>> http://blog.athico.com/2008/02/drools-clips.html
>> http://blog.athico.com/2008/06/drools-clips-progress.html
>>     
>
> Ah yes, very interesting.
> In principle it is very similar what I do.
> With Clojure there is a full featured Lisp on the JVM.
> What I do is adding some functions and macros, easy to use, which will
> do all the Drools managing and hide it from the user.
> It will be simple to add all kinds of syntaxes as soon I am done.
> You can have the Jess syntax. Just write a macro and expand it into
> mine. It will result in compiled rules code.
> So, in some days (when I have time) the project above will be
> finished ;-)
>
>
>   
>> see "Null-Safe Bean Navigation"
>> http://mvel.codehaus.org/MVEL+2.0+Property+Navigation
>>     
>
> Ah of course, I forgot the null. And MVEL already has the check built
> in.
> I think I will also implicitly add it.
>
>
>   
>>> And another interesting thing I noticed:
>>> to both rules I added the line
>>> global String s;
>>> and in the LHS's of both rules I removed the "c" and put s at its place.
>>> Then the first thing I did after creating a session was to
>>> (.setGlobal session "s" "c")
>>>
>>> The rule 1 accepted this change. I can use s instead of "c". But there
>>> is still the limitation that I can only insert Maps into the session
>>> which do have the String "c" as key. Otherwise: NPE.
>>> The rule 2 (mvel) however does not accept s as a placeholder. I get:
>>> Exception executing predicate this[s] == 206
>>> [Thrown class org.drools.RuntimeDroolsException]
>>>
>>> Any ideas how to get rid of the NPE?
>>>   
>>>       
>> We'll have to look into this, probably a bug.
>>     
>
> Edson confirmed that this is an MVEL problem.
> In a different thread KDR may have discovered another one.
>
>
> André
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20090820/2cfc153f/attachment.html