Re: [rules-users] Expert Systems and Functional programming?

On 11 Mar 2013, at 03:10, Grant Rettke <grettke(a)acm.org&gt; wrote: +1 :) I think the work in expert system tools is the only real paradigm shift going on. All others are just cross pollination of the same ideas. The downside is to get expert system tools to a level where we can compete easily, as a more general purpose tool, is very hard. Research expert system tools stopped in the mid 90s, due to the AI winter: http://blog.athico.com/2012/05/drools-54-artificial-intelligence.html We have plenty of ideas, the problem is in balancing trying to build a system suitable for production use - where people are conservative and don't like change - and a system which is constantly innovating. The other issue is in finding people willing to research these ideas with us. It's very easy for someone to get into scala or jruby or what ever and just start adding features. It's very hard in our case, because the change is too much, it's very hard for people to see how to apply what they already know to this new paradigm. For instance here is an idea I've been mulling over recently (note just random ideas, not roadmap). We don't have the resources to completely compete against other languages, and I'm not sure we should do. With Java8 and 9 it starts to become a more compelling language. Java8 brings lambs and java9 solve the perm gen issue (so we can stop using MVEL, and just go pure code generation and not worry about blowing the perm gen). Could we create a system that better layers with java9? We already want to drop dialects for DRL (it just makes things too hard to explain and write IDE tooling for). So the idea is to have a single language. This made me think of the Pizza language, which layered neatly ontop of java, and eventually became scala. http://pizzacompiler.sourceforge.net So thinking really long term here. Can we build a "java layer" that provide all the rule functionality we need - but fit ontop of the java language neatly. We'd probably need to allow "rule" keyword and have it in Classes, at the method level. All class members and methods would be available to the rules in that class. Can probably think of that containing class as a RuleModule. We'd have to rely on CDI and annotations for declarative wiring of member fields ( http://java.dzone.com/articles/cdi-di-p1). The biggest challenge would be in extending the java language to support LHS literals too (something I've wanted to do anyway) to provide LinQ style features, backed underneath by the Drools engine. A list of layered features might look like: 1) PropertyAccessors (doesn't look like java will ever add this, but DRL needs it to remain compact) 2) Type Inference (same as above, some argue that lack of contract design is a bad thing…..) 3) inline casts (needed for units, and keeps DRL compact) 4) "when" literals, like linq - but supports our entire LHS language. 5) rule keyword (similar at method level). We can use CDI to provide declarative injection of member variables. public class MyClass { @Inject public MyService service; // CDI injected service public void someMethod() { } rule xxx when { …. // normal LHS here. } then { service.call(…..) someMethod(); } } I won't cover LHS literals here, but look at reactive LinkQ, to get some ideas. There is a lot more to this idea of a layered language, and we can exploit annotations in all sorts of ways. Similar to my previous email on meta approach to building rule systems. We could use annotations to wire RuleModules to KnowledgeBases, and vice versa. One of the challenges of doing this layered option, is that the JDK is GPLd + linking exception. We'd even need to develop and maintain our own antlr+asm layer that does 100% of java9 + our extensions, or GPLd+linked exception Drools and extend the JDK. Mark